Subject: [mobile-ip] new draft versions

From: Jari Arkko <[email-masked]>
Date: Wed, 21 May 2003 01:47:26 +0300

I intend to submit these draft versions:

- http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html
- http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.html

(Still a few nits to take care-of, takes some hours...)

The modifications in the base are as follow:

    o  The specification no longer discusses the differences of using
       randomly generated and EUI-64 based interface identifiers for
       link-local addresses while away from home (traked issue 302).

    o  The rules for treating IKE cookies when using the Key Management
       Capability (K) flag have been specified in Section 10.3.1 (tracked
       issue 298).

    o  Section 6.2.7 now makes it clear why the home address does not
       need to be a part of the formula for calculating the MAC; the home
       address is taken in account in the construction of the keygen
       tokens (tracked issue 298).

    o  The security considerations discuss the need for payload packet
       protection in more depth than previously.  In particular, the use
       of payload packet protection is now recommended when communicating
       with hosts in a home network protected with some form of perimeter
       defense (tracked issue 298).

    o  The rules for treating IKE cookies when using the Key Management
       Capability (K) flag have been specified in Section 10.3.1 (tracked
       issue 298).

    o  Section 11.5.1 has been rewritten as a collection of hints about
       movement or the lack thereof.  Appropriate actions are specified
       for each of the received hints (tracked issue 297).

    o  Section 11.5.1 no longer claims that tracking of inbound traffic
       from the router ensures symmetric reachability (tracked issue
       297).

    o  The specific mechanisms for tracking inbound reachability when not
       sending any traffic have been moved outside this document (tracked
       issue 297).

    o  The return routability MAC calculation formula has been aligned
       between Section 5.2.6 and Section 6.2.7 (tracked issue 293).

    o  It is now required that nodes may not implement the Home Address
       option or type 2 Routing header without conforming to all requires
       in Section 8.2 (tracked issue 290).

    o  Section 9.5.1 now clearly specifies in which order the various
       checks on Binding Updates must be performed before the update of
       the sequence number can take place (tracked issue 290).

    o  It is now required that when sending packets to a correspondent
       node using route optimization, mobile nodes use the same care-of
       address which has been registered by the correspondent node as the
       current location of the mobile node (tracked issue 289).

    o  The administrative capability for disabling route optimization is
       now a SHOULD, not a MUST (tracked issue 289).

    o  The aggregate list of prefixes on the home network has been
       replaced with the home agent's own AdvPrefixList and a
       recommendation that the home agents be configured with the same
       prefixes (tracked issue 289).

    o  It is now required that the mobile node MUST NOT use the Home
       Address destination option for IPv6 Neighbor Discovery packets
       (tracked issue 289).

    o  Section 11.7.2 now excludes any return routability related message
       from initiating the need to update a binding (tracked issue 289).

    o  Section 11.7.2 no longer discusses what to do when the
       correspondent node has a stale Binding Cache entry, because in
       most cases this can not be detected (tracked issue 289).

    o  Section 11.7.3 has been clarified to explain that after receiving
       a Status value 128 or larger, the mobile node node should take
       steps to correct the problem, and only if this fails it should
       avoid resending Binding Updates (tracked issue 289).

    o  The events causing a Mobile Prefix Advertisement to be sent have
       been clarified to not include prefix lifetime changes due to
       passing of real-time (tracked issue 289).

    o  Section 15.4 and Section 15.4.6 discuss separately on-path attacks
       and blind guessing of keygen tokens (tracked issue 288).

    o  The document now has an extensive discussion of the implications
       of either using or not using IKE (tracked issue 282).

    o  A timeout mechanism has been specified for peers marked as not
       supporting the Mobility Header protocol (tracked issue 281).

    o  The document now explicitly mentions that multiple home addresses
       are supported (tracked issue 281).

    o  Mobile nodes are now allowed to respond to all Neighbor
       Solicitations on the home link while waiting for a Binding
       Acknowledgement from their home agent, as the Solicitations from
       home agent can not be distinguished from other Solicitations
       (tracked issue 279).

    o  Section 11.5.1 takes in account that the link-local addresses of
       two routers on different links can be equal.  To counteract the
       effect of this for movement detection, home agents are required to
       send consistent information about their global address through the
       Router Address (R) flag in Router Advertisements, and mobile nodes
       track these addresses as well as the source address of the
       advertisement when doing movement detection (tracked issue 278).

    o  The treatment of the Home registration (H) flag and the existence
       of mobility options related to return routability has been
       clarified.  The options for return routability are must be present
       if and only if the flag is zero (tracked issue 277).

    o  The sequence number example in Section 9.5.1 has been corrected
       (tracked issue 276).

    o  ICMPv6 Parameter Problem and Binding Error messages are now sent
       without a Binding Cache lookup (tracked issue 273).

    o  A new Binding Acknowledgment Status value 139 (Registration type
       change disallowed) has been added to report an error where the
       mobile node tries to change a home registration to a correspondent
       registration, or vice versa (tracked issue 273).

    o  The use of Home Address destination option, type 2 Routing header,
       and Binding Cache lookups has been clarified for all Mobility
       Header messages in Section 6.1 (tracked issue 269).

    o  Looping Binding Cache entries are now forbidden (tracked issue
       268).

    o  A number of editorial modifications have been performed (tracked
       issues 267, 280, 283, 289, 290, 301, and 304).

and in the ha-ipsec draft:

    o  The required IPsec SPD checks have been clarified.  While it is
       required that policy checks be based on the home address (from the
       Home Address destination option), this does not imply a change in
       the IPsec SPD entries.  Instead, this is a mere processing order
       issue (tracked issue 292).

    o  Justifications have been added to explain why return routability
       packets require protection (tracked issue 292).

    o  The precise meaning of "inactive" SPD entries and SAs has been
       clarified (tracked issue 292).

    o  The IKE text has been made more precise with respect to the IKE
       version the text applies to (tracked issue 292).

    o  "Manual keying" has been clarified to mean manually created IPsec
       security associations, not the configuration of preshared secret
       in IKE (tracked issue 296).

    o  Most of AH discussion has been left out from the document, and
       replaced with a note in the introduction (tracked issue 296).

    o  Section 7 no longer recommends replacing routers in the face of
       certificate fragmentation problems (tracked issue 287).

    o  The draft now explains the background for the decision to use
       care-of addresses as the source address for IKE and in the tunnel
       packets from the mobile node (tracked issue 284).

    o  The draft now explains that the decision to use care-of addresses
       in IKE implies that shared secrets can not be used with Main Mode
       even where a static (home) address is available (tracked issue
       284).

    o  The draft now explains where the API between the IPsec and the
       Mobile IPv6 should and should not be used (tracked issue 284).

    o  The draft clarifies now the requirements with respect to the use
       of IPsec tunnel mode versus the use of IP-in-IP encapsulation
       (tracked issue 284).

    o  The draft clarifies the implications of either using or not using
       IKE (tracked issue 282).

    o  Some editorial modifications have been performed (tracked issues
       287 and 292).

--Jari