Subject: [netlmm] #100: Message Count for care of address change is off

From: netlmm <[email-masked]>
Date: Mon, 31 Jul 2006 16:25:08 -0000

#100: Message Count for care of address change is off
------------------------------------------+---------------------------------
 Reporter:  [email-masked]      |       Owner:  [email-masked]
     Type:  defect                        |      Status:  new                     
 Priority:  minor                         |   Milestone:  milestone3              
Component:  draft-ietf-netlmm-nohost-req  |     Version:  2.0                     
 Keywords:  REQ draft                     |  
------------------------------------------+---------------------------------
 Jari Arkkko, INT AD, submitted this comment for AD Review:

 >      1) Movement detection using DNA [6] or possibly a link specific
 >         protocol,
 >      2) Any link layer or IP layer AAA signaling, such as 802.1x [7] or
 >         PANA [8]. The mobile node may also or instead have to obtain a
 >         router  authorization  certificate  using  SEND  [9],  if  the
 >         certificate is not already cached,
 >      3) Router discovery which may be part of movement detection,
 >      4) If  stateless  address  autoconfiguration  is  used,  address
 >         configuration and Duplicate Address Detection (unless optimistic
 >         Duplicate Address Detection [10] is used) including for link
 >         local addresses. If stateful address configuration is used, then
 >         DHCP is used for address configuration,
 >      5) Binding Update to the home agent,
 >      6) If route optimization is in effect, return routability to
 >         establish the binding key,
 >      7) Binding Update to correspondent nodes for route optimization.

 This needs some improvement. (Or you might also consider making it less
 detailed to avoid getting problems with the details. E.g., talk about
 home registration instead of Binding Updates.)

 Is the list ordered? For 1, DNA can not happen until 2 is done.
 For 2, it seems that SEND would be a logical part of 3, not 2.

 Binding acknowledgements are missing.

 There's more to link layer signaling than 802.1x.

 The text in 4 about "including" seems to need some editing.

 What about MLD?

 >      The result is approximately 10 messages at the IP level before a
 >      mobile node can be ensured that it is established on a link and has
 >      full IP connectivity.

 Even without DNA and SEND, I'm counting twelve for the basic
 case of: RS/RA, MLD, DAD, HA BU/BA, HOTI/HOT, COTI/COT,
 CN BU/BA.

 Christian Vogt submitted this followup:

 Yes, and 3 little follow-ups concerning this:

 - Assuming the use of RFC 2462bis rather than RFC 2462, at least 2 DAD
 NSs are necessary:  one for the link-local address and one for each
 global  IP address.  RFC 2462 facilitates simultaneous uniqueness
 verification for multiple IP addresses through a single DAD run when the
 IIDs of these IP addresses are the same.  However, RFC 2462bis removes
 this option and requires separate DAD runs due to the potential presence
 of nodes using privacy addresses or SEND.

 - Not sure you want to add address resolution here but IMO it should be
 menioned:  A MN typically sends the RS from a link-local address or from
 the unspecified address.  In either case, the access router will at some
 point have to initiate an NS/NA exchange for the MN's global IP
 address(es).  Furthermore, the access router is likely to initiate an
 NS/NA exchange for the MN's link-local address if (a) the MN uses
 Optimistic DAD, (b) sends an RS from its optimistic link-local address,
 but (c) does not add a TSLLAO, and if (d) the access router prefers to
 unicast solicited RAs back to the solicitor.

 - Multiple MLD Report messages may be sent if the IIDs for link-local
 and global IP addresses are different.  This may, e.g., happen with
 SEND, due to the random modifier in CGA computation.

-- 
Ticket URL: <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/100>
netlmm <http://tools.ietf.org/wg/netlmm/>
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: netlmm <[email-masked]>
Date: Mon, 31 Jul 2006 16:25:21 -0000

#100: Message Count for care of address change is off
-------------------------------------------+--------------------------------
  Reporter:  [email-masked]      |       Owner:  [email-masked]
      Type:  defect                        |      Status:  assigned                
  Priority:  minor                         |   Milestone:  milestone3              
 Component:  draft-ietf-netlmm-nohost-req  |     Version:  2.0                     
Resolution:                                |    Keywords:  REQ draft               
-------------------------------------------+--------------------------------
Changes (by [email-masked]):

  * status:  new => assigned

---

From: netlmm <[email-masked]>
Date: Mon, 31 Jul 2006 22:47:01 -0000

#100: Message Count for care of address change is off
-------------------------------------------+--------------------------------
  Reporter:  [email-masked]      |       Owner:  [email-masked]
      Type:  defect                        |      Status:  closed                  
  Priority:  minor                         |   Milestone:  milestone3              
 Component:  draft-ietf-netlmm-nohost-req  |     Version:  2.0                     
Resolution:  fixed                         |    Keywords:  REQ draft               
-------------------------------------------+--------------------------------
Changes (by [email-masked]):

  * resolution:  => fixed
  * status:  assigned => closed

Comment:

 Rewrote most of Section 2.2 to make the list of messages more precise. It
 will vary depending on circumstances, but this looks to be about the
 minimum. Here is the new text:

 Considering Mobile IPv6 as the global mobility protocol (other mobility
 protocols require about the same or somewhat less), if a mobile node using
 address autoconfiguration is required to reconfigure on every move between
 links, the following signaling must be performed:

 1)      Link layer signaling required for handover and reauthentication.
 For example, in 802.11 [7] this is the Reassociate message together with
 802.1x [8] reauthentication using EAP.
 2)      Active IP level movement detection, including router reachability.
 The DNA protocol [6] uses Router Solicitation/Router Advertisement for
 this purpose. In addition, if SEND [9] is used and the mobile node does
 not have a certificate cached for the router, the mobile node must use
 Certification Path Solicitation/Certification Path Advertisement to obtain
 a certification path.
 3)      Two Multicast Listener Discovery (MLD) [24] REPORT messages, one
 for each of the solicited node multicast addresses corresponding to the
 link local address and the global address,
 4)      Two Neighbor Solicitation (NS) messages for duplicate address
 detection, one for the link local address and one for the global address.
 If the addresses are unique, no response will be forthcoming.
 5)      Two NS messages from the router for address resolution of the link
 local and global addresses, and two Neighbor Advertisement messages in
 response from the mobile node,
 6)      Binding Update/Binding Acknowledgement between the mobile node and
 home agent to update the care of address binding,
 7)      Return routability signaling between the correspondent node and
 mobile node to establish the binding key, consisting of one Home Test
 Init/Home Test and Care of Test Init/Care of Test,
 8)      Binding Update/Binding Acknowledgement between the correspondent
 node and mobile node for route optimization.

 Note that Steps 1-2 may be necessary, even for intra-link mobility, if the
 wireless link protocol doesn't provide much help for IP handover. Step 3-5
 will be different if stateful address configuration is used, since
 additional messages are required to obtain the address. Steps 6-8 are only
 necessary when Mobile IPv6 is used. The result is approximately 18
 messages at the IP level, where the exact number depends on various
 specific factors such as whether the mobile node has a router certificate
 cached or not, before a mobile node can be ensured that it is established
 on a link and has full IP connectivity.