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

From: Dave Johnson <[email-masked]>
Date: Thu, 27 Apr 2000 14:57:18 -0400

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.txt

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
[email-masked].

Thanks.

					Dave

--
David B. Johnson                         [email-masked]
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 [email-masked]
--------------------------------------------------------------------