Subject: RE: [mobile-ip] Resolution for issue #198

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Jan 2003 11:26:29 -0000

Hi Jari. 

What if, though, the MN lost knowledge of its Home Agent Home Address? 

If you take a scenario where the MN discovers a HA by DHAAD, then binds
with it for along duration. Then the MN is powered off, brought back
home, then powered on while the HA still defends the MN's addresses. If
the MN looses its states when rebooted, and performs DAD to insert
itself into the home network, it will be shut off till the binding
ellapses. Even at that point, since there's no retrying DAD in the
standard, it will not be able to communicate with its own addresses,
unless you manually restart it.

version a) If we are assuming persistent memory on the MN, we should add
a few words about that, shouldn't we? 

version b) Alternatively, (I must be missing something here, cause this
looks too simple), we could actually target the MN Home Address as
opposed to the HA's in the NS using plain DAD. If a HA exists with a
binding, it should respond with a NA with the Target Link Layer Adress
option set (since IP dest of NS is multicast). At this point, as opposed
to dropping the address, the MN could unbind (using which source
address?), and then retry DAD.

version c) In the other hand, we may want to dig a bit deeper into DAD
and its purposes... As far as I understand it, DAD is intended to
preserve the address ownership to the node that has it assigned, as
opposed to newcomers autoconfiguring it, in order to preserve active
connections and application states. Now, in the case of MIP, is that
really what we want? The HA is not terminating any connection, and
denying the MN its own address actually breaks the active connections.
Also, a real case of duplicate address (misconfiguration) should be less
frequent than simple homecomings, shouldn't it?

If we are ready to tweak ND (we're doing it already with the new
proposal, right?), then maybe we could revisit the above rules for our
case.

Somehow, in MIP, the home address of the MN is "less then assigned" on
the HA after BU, and "more than tentative" on the MN since boot. A first
try to give semantics to these states:

"less then assigned": successfully performed DAD from tentative state.
Accepting unicast packets on that address. Node responds to DAD as if
the address was tentative and to address resolution as if it was
assigned. Override bit is never set. For a HA, a DAD coming from a
different node also causes a Binding cache cleanup for that address.

"more than tentative": node performs ND as if address was assigned. If
no NA is received from a different node for that adress for a period of
time, the address goes assigned. Otherwise, drop the address as if DAD
failed.

Version c allows the MN to come back up faster and with less control
traffic. The proposal is in early stage, to test if it actually gets
some support, in which case we could refine...

Pascal

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: lundi 20 janvier 2003 22:11
> To: Vijay Devarapalli
> Cc: Ville Nuorvala; gab; Mobile IP Working Group
> Subject: Re: [mobile-ip] Resolution for issue #198
> 
> 
> Here's some text for solution #5.
> 
> Section 11.5.4:
> 
>     ...
>     solicitation.  In this special case of the mobile node returning
>     home, the mobile node MUST multicast the packet, and in 
> addition set
>     the Source Address of this Neighbor Solicitation to the 
> unspecified
>     address (0:0:0:0:0:0:0:0).  The target of the Neighbor 
> Solicitation
>     MUST be set to the home agent's IPv6 address, which is 
> known to the
>     mobile node.  The destination IP address MUST be set to the
>     Solicited-Node multicast address [3]. The ICMP Code field MUST be
>     set to 1 in order to distinguish this solicitation from a similar
>     packet that would only be used for DAD, as described in 
> Section 7.x.
>     The home agent will send a multicast Neighbor Advertisement back
>     to the mobile node with the Solicited flag (S) set to zero. In any
>     case, the mobile node SHOULD record the information from 
> the Source
>     Link-Layer Address option or from the advertisement, and set the
>     state of the Neighbor Cache entry for the home agent to REACHABLE.
> 
> Section 7.x, Modified Neighbor Solicitation Message Format
> 
>     Mobile nodes may need to send Neighbor Solicitations to
>     their home agent when the home agent still has a binding
>     for them. As the home agent defends the mobile node's
>     addresses on the home link, the mobile node can
>     not use its own addresses until it it successfully
>     deletes the binding. However, in order to do this
>     it must send a Binding Update to the home
>     agent, and possibly find its link-layer address.
> 
>     The modified Neighbor Solicitation message allows this to
>     be done with the IP Source Address set to the unspecified
>     address and the ICMP Code field set to 1. The modified
>     format MUST NOT be used except for the purpose of
>     discovering the link-layer address of a home agent
>     when the mobile node is returning home (Section 11.5.4).
> 
>           0                   1                   2           
>         3
>           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> 6 7 8 9 0 1
>          
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |     Type      |     Code      |          Checksum  
>            |
>          
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |                           Reserved                 
>            |
>          
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |                                                    
>            |
>          +                                                    
>            +
>          |                                                    
>            |
>          +                       Target Address               
>            +
>          |                                                    
>            |
>          +                                                    
>            +
>          |                                                    
>            |
>          
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |   Options ...
>          +-+-+-+-+-+-+-+-+-+-+-+-
> 
>     This format represents the following changes over that originally
>     specified for Neighbor Discovery [12]:
> 
>     IP Fields:
> 
>        Source Address
> 
>                       The unspecified address.
> 
>     ICMP Fields:
> 
>        Code
> 
>                       1
> 
>     Upon receiving a Neighbor Solicitation message from the 
> unspecified
>     address with the Code field set to 1, home agents MUST 
> process this
>     message as described in Section 7.2.3 of RFC 2461 [ref]. 
> Such messages
>     MUST NOT be considered as a sign that the sending node is 
> performing
>     Duplicate Address Detection [ref].
> 
> Section 8.4:
> 
>     o Every home agent MUST support the extended Neighbor Solicitation
>       message format described in Section 7.x.
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 21 Jan 2003 10:07:12 -0800

hi Pascal,

> unless you manually restart it.

this has been raised by Ed Remmell. take a look at issue #172 at
http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html

and in section 11.7.1 of draft 20 

>       Mobile nodes that use dynamic home agent address discovery should
>       be careful with long lifetimes.  If the mobile node loses the
>       knowledge of its binding with a specific home agent, registering a
>       new binding with another home agent may be impossible as the
>       previous home agent is still defending the existing binding.
>       Therefore, mobile nodes that use home agent address discovery
>       SHOULD ensure information about their bindings is not lost,
>       de-register before losing this information, or use small
>       lifetimes.