Subject: Re: [MOBILE-IP] New version of "Mobility Support in IPv6" draft

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 3 May 2000 16:46:21 -0700

Dave,

The IPsec processing section is not very clear on what exact bits
pass through AH i.e at least what does the source address and the
Home address option contain ? Without this, there might be
potential inter-operability problems.

In section 10.2, it describes that HOME address option is inserted,
*replacing* the source address in the packet's IP header with a COA,
then AH ICV is computed. What does the HOME address option contain ?
I understand that it contains the original ip6_src which is the
HOME address. *replacing*  is really *swap* then. In section 5.4 and
other places, on inbound if a packet contains HOME address option,
it states that it should be processed first which implies that
the source address will be replaced with the HOME address. Again,
this is before the computation of the AH ICV. ICV computed this
way will not match with what was done on outbound as ip6_src
contains the COA while ICV was computed. Is it possible to
clarify this so that everybody computes the ICV with the same
set of bits..

thanks
-mohan

> 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