Subject: [MEXT] [mext] #16: HA behaviour upon MN returning Home [Pascal Thubert <[email-masked]>]

From: "mext" <[email-masked]>
Date: Wed, 16 Jul 2008 23:22:40 -0000

Ticket #16: HA behaviour upon MN returning Home   [Pascal Thubert <[email-masked]>]

 HA behaviour upon MN returning Home   [Pascal Thubert
 <[email-masked]>]

 With both the original RFC 3775 and the current rework, a HA that has a
 binding to a Home Address owns that Home Adddress over the Home Link
 till either the node unbinds or the binding times out. Until then the HA
 will defend that Home Address using the Override bit in the NA messages
 over the Home Link, and until then a mobile node would be out of
 compliance
 to use its Home Address if it is at Home or switch to another HA if it is
 not at Home.

 There are multiple issues with this behaviour:

 - service: Whether it is at Home or not, a node that looses the states
 about its current binding might be unreachable until the end of its
 binding lifetime. It will take a manual operation to recover from that
 situation when the lifetime is too long. And it will cause excess
 traffic or load on the HAs if the lifetime is too short. In any case
 there will be a service disruption that the user might perceive.

 - security: The HA defends an address that it does not own so it can not
 prove it owns it. With SeND, it would just be nonsense for a HA to try
 and reclaim SeND based addresses when a MN proves ownership on link.

 - compatibility with other proxies: The HA performs a form of ND
 proxying for the Mobile Node. We can expect that there will be new forms
 of ND proxies coming up - see for instance
 http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-01 -,
 and there should be a common behaviour over a shared link for proxies,
 regardless of the registration mechanism; in particular a proxy should
 yield in the face of the object it proxies for.

 - speed: A Mobile Node reaching Home should be able to use its Home
 Address as optimistic (RFC 4429) right away like it could do on any
 visited link with any CoA.

 Proposed resolution:

 The proposal to fix this issue is to let the MN use DAD/oDAD over the
 Home Link with its Home Address. A proxy would defend the address
 without the O bit, and the MN would ignore it, and upon DAD completion,
 NA(Override) its address. The HA would be allowed to set the override
 bit only within a binding flow, when it knows synchronously that it
 represents the live MN. That would enable new HA to take over old HA
 when the MN looses states away from home. That would also enable MN to
 make before break a tunnel with new HA.

 Still it would still be beneficial to clear the binding properly so we
 can still SHOULD or MUST it, but whether that flow works properly or
 not, the MN would get its address back.

 ---------------------------------------------------------------------

 Vijay Devarapalli  <[email-masked]>:

 > - security: The HA defends an address that it does not own so it can not
 > prove it owns it. With SeND, it would just be nonsense for a HA to try
 > and reclaim SeND based addresses when a MN proves ownership on link.

 Well, if SeND is not being used, does it make sense for the home agent to
 allow the mobile node to claim its address, until the mobile node de-
 registers with a secure binding update? What if a misbehaving mobile node
 on the home link tries to claim the legitimate mobile node's home address
 while the home agent is defending the address?

 > The proposal to fix this issue is to let the MN use DAD/oDAD over the
 > Home Link with its Home Address. A proxy would defend the address
 > without the O bit,

 This would modify the existing behavior. For unsolicited neighbor
 advertisements, the Home Agent sets the 'O' bit. See section 10.4.1.

----------------------------------------+-----------------------------------
 Reporter:  [email-masked]       |       Owner:  [email-masked]
     Type:  defect                      |      Status:  new                  
 Priority:  major                       |   Milestone:  IETF72               
Component:  draft-ietf-mext-rfc3775bis  |     Version:  2.0                  
 Severity:  Active WG Document          |    Keywords:  Returning Home       
----------------------------------------+-----------------------------------
-- 
Ticket URL: <http://wiki.tools.ietf.org/wg/mext/trac/ticket/16>
mext <http://tools.ietf.org/wg/mext/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext