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

From: "Greg O'Shea" <[email-masked]>
Date: Mon, 2 Dec 2002 09:47:46 -0000

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?

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?

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
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.

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.

These are the issues that occur to me immediately. Thanks for any
insights.

Greg

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Dec 2002 19:12:13 +0200

Hi Greg -- partial answers inline.

> 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.

> 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.

> 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.

> in a dispute over generated HoA.

This functionality does not exist, i.e., its a total failure if DAD
fails.

> S-bit BUs. If so, then the spec needs to say how this should be achieved 

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: Vijay Devarapalli <[email-masked]>
Date: Tue, 03 Dec 2002 12:24:13 -0800

hi Greg,

> Greg O'Shea wrote:
> 
> 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,

it was called the prefix length field before. it used to be a fixed
8 bit length field in the BU. if the prefix length field is non-zero 
it is the same as setting the 'S' bit to 0. instead of using 8 bits, 
it was replaced by the 'S' bit.

> 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 

??? several HAs? why is the MN using more than one HA at a time?"
maybe I am ignorant, but I cant figure out why the MN would use
multiple home agents. anyway, in the implementations I have seen
so far, the MN at any time uses only one home agent.

Vijay