Fw: New version of "Mobility Support in IPv6" draft

FYI. Regards, Thomas Trede ----- Original Message ----- From: "Dave Johnson" <dbj@cs.cmu.edu> To: <mobile-ip@standards.nortelnetworks.com>; <ipng@sunroof.eng.sun.com> Sent: Thursday, April 27, 2000 8:57 PM Subject: New version of "Mobility Support in IPv6" draft

I just submitted a revised version of the Internet-Draft "Mobility Support in IPv6", which corrects a number of minor problems and adds several clarifications over the previous version of the draft. Here is a list of some of the changes since the previous version:

- Moved the definition of IPsec requirements for Binding Updates and Binding Acknowledgements to Section 4.4), giving this important information its own specific section with a section title (IPsec Requirements for Mobile IPv6 Destination Options) that will be identifiable in the table of contents for this document. This makes these requirements harder to miss than where they were defined in Sections 5.1 and 5.2, mixed in with the definition of the format of these destination options.

- In Section 4.6, added a precise definition of Sequence Number value comparison modulo 2**16. Also added a reference to this definition in each other place where Sequence Number comparison is discussed.

- Added a statement in Section 9.5 to clarify the sending of a Neighbor Advertisement message by the home agent on behalf of the mobile node in order to intercept packets addressed to the mobile node. Except for the specific fields defined there, all fields in each such Neighbor Advertisement SHOULD be set in the same way they would be set by the mobile node itself if sending this Neighbor Advertisement while at home [17].

- In Section 10.6, specified that the Lifetime in the Binding Update sent by a mobile node to its home agent SHOULD be less than or equal to the remaining lifetime of the home address and the care-of address specified for the binding.

- In Section 10.8, modified the specification that was there about the correct setting of the Lifetime in the Binding Update sent by a mobile node to a correspondent node. The original specification stated that the Lifetime value MUST be no greater than the remaining lifetime of the mobile node's home registration of its primary care-of address at its home agent. However, there should be no necessary relationship between the remaining lifetime of a home registration and the lifetime of a binding at a correspondent node. Instead, as with the home registration Binding Update, the Lifetime in the Binding Update sent by a mobile node to a correspondent node SHOULD be less than or equal to the remaining lifetime of the home address and the care-of address specified for the binding.

- In Section 5.4, added a statement that a packet MUST NOT contain more than one Home Address option, except that an encapsulated packet [4] MAY contain a separate Home Address option associated with each encapsulating IP header.

- In Section 4.6, added a new field in the Binding Update List entry format to record the initial value of the Lifetime field sent in that Binding Update.

- In Section 10.12, defined a new step in processing a received Binding Acknowledgement: if the value specified in the Lifetime field in the Binding Acknowledgement is less than the Lifetime value sent in the Binding Update being acknowledged, then the mobile node MUST subtract the difference between these two Lifetime values from the remaining lifetime for the binding as maintained in the corresponding Binding Update List entry. The effect of this step is to correctly manage the mobile node's view of the binding's remaining lifetime (as maintained in the corresponding Binding Update List entry) so that it correctly counts down from the Lifetime value given in the Binding Acknowledgement, but with the timer countdown beginning at the time that the Binding Update was sent. This change also affected Section 10.8 in sending Binding Updates, to record both the original lifetime and the remaining lifetime in the Binding Update List.

- In Sections 5.1 and 9.3, clarified that the Duplicate Address Detection performed by the home agent if the Duplicate Address Detection (D) bit is set in the Binding Update, is performed before returning the Binding Acknowledgement for that Binding Update.

- In Section 5.1, clarified that the mobile node SHOULD set the Duplicate Address Detection (D) bit in its home registration Binding Updates based on any requirements for Duplicate Address Detection that would apply to the mobile node if it were at home [17, 27].

- In Section 9.3, specified that a home agent, when performing Duplicate Address Detection for a mobile node when the Duplicate Address Detection (D) bit is set in a received Binding Update, SHOULD NOT delay sending the initial Neighbor Solicitation message of Duplicate Address Detection by the random delay specified for normal processing of Duplicate Address Detection [17, 27].

- In Section 10.5, defined special considerations for a mobile node's use of Duplicate Address Detection upon forming a new care-of address. In particular, the mobile node MAY begin using the new care-of address without performing Duplicate Address Detection, and MAY optionally bypass Duplicate Address Detection or begin Duplicate Address Detection asynchronously when it begins use of the address, allowing the Duplicate Address Detection procedure to complete in parallel with normal communication using the address. In addition, the mobile node SHOULD NOT delay sending the initial Neighbor Solicitation message of Duplicate Address Detection by the random delay specified for normal processing of Duplicate Address Detection [17, 27], unless the mobile node is initializing after rebooting.

- In Section 4.6, added a clarification to the definition of the Binding Update List, that for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Update (i.e., with the greatest Sequence Number value) sent to that destination. This was already noted in previous versions of the draft in the sending of Binding Updates, as defined in Section update-corresp, but was not previously stated explicitly in the definition of the Binding Update List conceptual data structure.

- In Section 9.3, added a specification that the lifetime for the Binding Cache entry (and thus the Lifetime value returned in the Binding Acknowledgement) MUST NOT be greater than the Lifetime value specified in the Binding Update. Also added a similar specification (and clarification) in Section 8.3 for the Binding Cache entry in a correspondent node.

- In Section 10.6, added a clarification that, when sending a Binding Update to its home agent, the mobile node MUST also create or update the corresponding Binding Update List entry, as specified in Section 10.8.

The official announcement of the draft should appear on the mailing lists shortly, but you can get a copy of the new draft now from

http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-12.tx t

We expect to go to Last Call on this version of the draft shortly. Please send any comments on the draft to the Mobile IP mailing list at mobile-ip@standards.nortelnetworks.com.

Thanks.

Dave

-- David B. Johnson dbj@cs.cmu.edu Associate Professor http://www.cs.cmu.edu/~dbj/ Computer Science Department http://www.monarch.cs.cmu.edu/ Carnegie Mellon University Phone: (412) 268-7399 5000 Forbes Avenue Fax: (412) 268-5576 Pittsburgh, PA 15213-3891

-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------