Subject: RE: [mobile-ip] Issues with the S bit.

From: "Greg O'Shea" <[email-masked]>
Date: Tue, 3 Dec 2002 19:10:35 -0000

>Per RFC 2462, two HAs trying to run DAD for the same addresses at the
same time will detect the other attempt and fail.

That is the crux of the problem. We are dealing with *multiple* Home
Agents (maybe more than two) and therefore *multiple* sets of routing
prefixes that may intersect. The current draft doesn't even begin to
consider the ramifications and offers no way of controlling them; I
suspect they were overlooked. 

Sounds like a royal mess to me. Right now I would favour getting rid of
the S bit altogether.

Greg

>-----Original Message-----
>From: Jari Arkko [mailto:[email-masked]] 
>Sent: 02 December 2002 17:12
>To: Greg O'Shea
>Cc: Mobile IPv6 mailling list
>Subject: Re: [mobile-ip] Issues with the S bit.
>
>
>
>Hi Greg -- partial answers inline.
>
>> I have some questions concerning the S bit in Binding Updates of 
>> Section
>> 6.1.7 and 10.3.1. I have no real experience of using this 
>feature, which 
>> appeared sometime post draft 13, but intuitively it seems to me that 
>> attempting to deal with sets of Home Addresses as if they were 
>> individual Home Addresses fundamentally changes the failure and 
>> operational semantics of MIPv6 with respect to the Binding Update 
>> operation.  I cannot see where the draft deals with these 
>matters. (As 
>> always, perhaps I'm overlooking something obvious, like some 
>simplifying 
>> and enforceable assumptions about the intersection of 
>generated HoA or 
>> the number or size of route prefix sets involved.)
>> 
>> 1.  A mobile node has potentially several Home Agents each 
>potentially
>> offering several routing prefixes for home agent service. We cannot 
>> assume that these sets of routing prefixes are distinct, or 
>if they are, 
>> that they won't change such that they suddenly intersect. 
>Assume that 
>> the MN is using the same IFId for all its Home Agents. Now, 
>when the MN 
>> moves it sends BU+S+D to several HA and these Home agents 
>now start to 
>> compete with each other trying to protect the HoA 
>derivatives for their 
>> routing prefix sets. The outcome of the MIPv6 protocol is likely 
>> non-determinsitic in the sense that each Home Agent will 
>only win the 
>> competition sometimes, and potentially all of the will fail 
>always. It 
>> seems to me that the subset of HAs that lose such a competition is 
>> non-deterministic based on the outcome of DAD, but it is always 
>> non-empty when the sets of routing prefixes intersect.
>> 
>> 2.  Is it a failure when the HA cannot defend *all* of the HoA 
>> generated
>> from its route prefix set? If so What does a HA do when it 
>does not win 
>> the competition for all the generated HoA? Does it continue 
>to defend 
>> the ones it has won? That might be at the expense of a 
>competing HA that 
>> has lost the competition for one or more of the HoA. Or does 
>a failing 
>> HA stop defending the addresses it has won if it cannot 
>defend them all, 
>> and maybe retry in case other losing HA are also backing off?
>
>The assumption behind an S=0 registration is that *all* 
>addresses have to pass DAD and other tests successfully. But I 
>agree that this isn't stated in the draft.
>
>If you don't pass all tests the BU fails and you don't defend 
>any of the addresses -- and remember that the DAD tests are 
>just tests i.e. you haven't broken up anyone else's attempt to 
>run DAD even if done at the same time.
>
>> 3.  What are the transaction semantics of #2? Is there to be 
>some sort
>> of two-phase commit protocol between the HA involved, 
>perhaps with the 
>> MN as coordinator, so that the multiple HA can synchronize their 
>> decision to retain or unwind or rerun the results of their 
>DAD attempts?
>
>Presumably the DAD has to be started more or less in parallel, 
>and at a single instant of time the HA decides that it has 
>waited long enough, and declares success. ANY response for the 
>addresses during that time will fail the whole process immediately.
>
>Per RFC 2462, two HAs trying to run DAD for the same addresses 
>at the same time will detect the other attempt and fail.
>
>> 4.  Is it still a failure when the HA cannot defend all of the HoA
>> generated from its route prefix set but one of the competing 
>HA has won 
>> the competition for that HoA and would forward traffic for 
>that address 
>
>As explained above, I don't think we have an issue with 
>partial wins. However, we've had previous discussion on the 
>interaction of trying alternate HAs and DAD even for a single 
>address. If one tries another HA too quickly, the two HAs will 
>both be still trying DAD and will obviously fail.
>
>> to the MN? Arguably the MN is getting what it wants in this scenario,
>> and the failure doesn't matter, but if so how would the competing HA 
>> discover each other and learn about the addresses that each 
>has managed 
>> to win? And how would the respective HA (or the MN) decide 
>whether the 
>> IPSec afforded to that HoA by each of the HA are equivalent?
>> 
>> 5.  The syntax of Binding Acks (6.1.8) is inadequate for 
>reporting the
>> new modalities introduced by the S bit. In particular the HA cannot 
>> signal to the MN which of the generated HoA have passed DAD 
>and which 
>> have failed. This means that the HAs cannot expect the MN to 
>intervene 
>> in a dispute over generated HoA.
>
>This functionality does not exist, i.e., its a total failure 
>if DAD fails.
>
>> 6.  In the event of a drawn competition between competing 
>HA, how many
>> times should the MN try to rerun the failing BUs? In some 
>cases some of 
>> them might eventually get through because they get lucky wrt 
>other HA 
>> that also failed, leaving the MN overall better off. Of 
>course the MN 
>> may need to decide to delete some BU(s) that succeeded in 
>order to give 
>> the failed BU(s) a better chance of success. Also of course 
>the MN would 
>> need to know when to back off because the situation is hopeless.
>> 
>> 7.  Perhaps it is expected that the MN should collect route prefix
>> information from all of its Home Agents and then try and work out 
>> maximal coverage of the union of sets of generated HoA, 
>using S bit to 
>> minimise the number of BU it sends to HA whose sets of 
>generated HoA do 
>> not intersect and single address BUs to remaining HA to mop up the 
>> difference between the union of HoA sets and the set of HoA 
>covered by 
>> S-bit BUs. If so, then the spec needs to say how this should 
>be achieved 
>> at the MN.
>
>Uh, I think we should try and avoid this. Use the S bit if you 
>can do everything with it. Perhaps we should even require that 
>all HAs returned in DHAAD must server the same prefixes.
>
>Anyway, I apologize for not giving a complete answer (I run 
>into this WLAN cell on my trip into the wilderness of northern 
>Lappland but now I need to move on). But does the assumption 
>about complete on/off success and possibly the requirement for 
>the same prefixes help?
>
>Jari
>
>
>

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 3 Dec 2002 12:42:56 -0700

Greg -

A MN sending a Binding Update to a HA with L=1, S=0 is equivalent to
registering an interface ID with the HA. This interface ID is assumed to be
globally unique (in many cases it will be). Randomly generated interface IDs
(which, BTW, come out of a different space, so they never conflict with the
globally unique type of interface ID) per RFC-3041 are not allowed to use
this type of registration.

Because of IPv6 stateless address auto-configuration, which in many cases
will be used to generate a MN's home addresses, being able to register the
IID that these home addresses are formed from seems like a nice
optimization, because it results in the MN having to send fewer Binding
Update messages to the HA.

The HA will likely only do DAD for a single home address in this case
(assuming it optimizes DAD), which is the link-local scope address formed
from the IID. Since the IID is globally unique, DAD doesn't really seem
necessary even for that address, since it isn't expected to conflict with
any other node on the home network (if it does, then likely it is an
administrative problem outside of the scope of the protocol specification,
i.e. two Ethernet cards that have the same MAC address configured etc.).

The one case where this is an exception is when the MN returns home and the
HA is still defending its set of addresses. Then things get slightly hairy,
but all of the burden is on the MN to successfully deregister in that case.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Greg O'Shea
> Sent: Tuesday, December 03, 2002 12:11 PM
> To: Jari Arkko
> Subject: RE: [mobile-ip] Issues with the S bit.
>
>