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

From: "Greg O'Shea" <[email-masked]>
Date: Thu, 2 Jan 2003 11:59:16 -0000

I understand that later drafts will clarify the failure semantics of an
s=0 BU. This goes some way to addressing my original concerns. Herein I
will attempt to expand upon them and arrive at a compromise solution.

Background
----------
A MIPv6 Mobile Node (MN) may have one or more Home Address(es) (HoA) on
one or more Home Networks (HN). The MN may continue to use a HoA while
attached to networks other than a given HN if, and only if, it has
registered the HoA with a Home Agent (HA) on HN. Registration is
achieved by a (BU, BA) message pair, where MN sends a BU message to HA
providing a Care-of Address (CoA) and HA returns a BA message to MN
indicating whether the registration was accepted. Failure may occur for
a variety of reasons, including DAD failure when HA attempts to verify
that no other node on HN is using HoA.

The base case is where BU unambiguously identifies a single HoA as an
argument of the BU message. In this case the S-bit in the BU message is
set to 1 (s=1). Recent drafts specify an s=0 optimisation wherein the MN
indicates that the HA should use the set of network prefixes known to
the HA as a generator for a set of Home Addresses where each member of
the set is constructed by combining part of the HoA appearing in the BU
with each of the network prefixes onlink to the HA. We refer to the set
of Home Addresses constructed by an s=0 BU as the S-set for an HoA,
where HoA is an arbitrary member of the S-set.

Failure semantics
-----------------
Attempts by the HA to register individual members of an S-set may
succeed or fail independently of each other. Future MIPv6 drafts will
clarify the intention that an s=0 registration is deemed to have failed
and that persistent effects must be rolled back at the HA should any of
the registrations in the S-set fail. It remains to be defined what
action the MN should take the event that it receives a failure BA from
an s=0 BU. We return to this point later.

Competition between HA
----------------------
The S=0 mechanism opens the possibility of conflict between two or more
HAs that attempt to register the same HoA on behalf of an MN. As a
preliminary step, consider the networks below.

           |-------|                       |-------|
           |  HA1  |                       |  HA2  |
           |-------|                       |-------|
             |                                    |
   2000:1::  |                                    |   2000:2::
   ------------                                  ---------------

Consider a single MN that registers HoA1=2000:1::1 with HA1 and
HoA2=2000:2::1 with HA2. MN is connected to some distant network but is
able to register both bindings with BU(HA1,HoA1,s=1) and
BU(HA2,HoA2,s=1). The two bindings do not interfere with each other, and
the replies from HA1 and HA2 unambiguously identify whether HoA1 and
HoA2, repectively, have been successfully registered. In this case, no
ambiguity arises if the BU were send with s=0 because the S-set for HoA1
is {2000:1::1} and the S-set for HoA2 is {2000:2::1} and the
intersection of the two sets is the empty set {}.

Next we consider the following network:

           ---------                       ---------
           |  HA1  |                       |  HA2  |
           ---------                       ---------
               |                               |    
   2000:1::    |          2000:3::             |       2000:2::
   ---------------------------------------------------------------

When MN attempts to register HoA1 and HoA2 with s=1 we again have an
empty intersection of the S-sets and both registrations proceed without
interfering with each other. The registrations appear to be distinct,
and they are. If both registrations are send with s=0 then the S-set for
HoA1 is {2000:1::1, 2000:2::1, 2000:3::1} and the S-set for HoA2 is
{2000:1::1, 2000:2::1, 2000:3::1} and the intersection of the two S-sets
is {2000:1::1, 2000:2::1, 2000:3::1}. The registrations appear to be
distinct, but they are not. Note that both HA1 and HA2 will attempt to
register 2000:3::1 even though MN did not specifically mention this HoA.
HA1 and HA2 may interfere with each other in their attempts to register
each and every one of these addresses, causing one or both S-sets to
fail. The response to MN will be that the BU for HoA1 failed or that the
BU for HoA2 failed or that both BU failed.

Observe that conflict would still occur if 2000:3:: prefix were deleted
and only one of the BU was sent with s=0. Note also that in reality
there may be more than two S-sets involved, depending on how many HoA
the MN has acquired and the topology of the network(s) involved.

The current MIPv6 draft does not specify how conflicts such as these may
be prevented, detected or resolved. Observe for instance that race
conditions exist between BU messages and mobile prefix queries that
precede or follow the BU, because S-set membership may change and there
are no mechanisms for the MN to indicate which members of an S-set it
wishes to register. Observe also that a BA indicating that one or more
members of an S-set failed to register does not say which members of the
set failed and which succeeded before being rolled back.

Proposal
Prevention of s=0 conflicts is unspecified in the draft and would add
further complexity to the MIPv6 spec and its implementations.

Detection of conflicts will be specified in future drafts in the sense
that an HA must completely fail a BU with S=0 and roll back any side
effects if one or more of the members of the S-set fail (DAD for
example). This will be signalled to the MN with a BA, but since the
semantics of a BA do not extend to sets of HoA the MN will be unable to
detect which of the several HoA in the S-set encountered a problem.
Indeed, the MN cannot even be sure of which HoA the MN tried to register
on its behalf before the first failure in the S-set. However, because
the HA will in future be required to roll back any registrations within
the S-set that completed successfully, the MN is assured that there are
no after effects from the BU (although there may well be side effects,
such as the failure of a concurrent BU).

The best solution, in my personal opinion, would be to remove the S bit
altogether. Failing that, the best compromise would seems to be the
specification of recovery action by the MN. My proposal would be to add
the following text to the sections indicated.

10.3.1
In the event that a binding update requests multiple addresses to be
registered and/or defended, then the binding update is deemed to have
failed if one or more of the addresses cannot be registered and/or
defended. In such cases the Home Agent MUST deregister any Home
Addresses that were successfully registered and MUST cease defending any
addresses infered from that Binding Update except that the details of
any registrations and/or defence of address(es) that were current prior
to the Binding Update that failed shall prevail as if the failing
Binding Update had never been attempted. In the event of such failure
the Home Agent shall return a Binding Acknowledgement to the Mobile
Node. If all of the failures encountered during processing of the
Binding Update were of the same type, and that type is adequately
described by one of the Status codes for Binding Update, then that
Status code MUDT be used in the Binding Acknowledgement. If multiple
failures of different type were encountered during the processing of the
binding update then the Status code in the Binding Acknowledgement MUST
be set to "Reason Unspecified".

11.7.3
- If the Status field indicates that the Binding Update was rejected
with Status codes 128, 129, 130, 132, 133 or 134, and if the Binding
Update was attempting to register multiple addresses in a single
operation, then it is possible that some of the addresses would register
successfully if retried individually. In these circumstances the Mobile
Node SHOULD attempt to determine the set of addresses upon which the
Home Agent attempted to operate, for example by sending a Mobile Prefix
Solicitation message to discover the set of prefixes known to the Home
Agent. (Note, the set of prefixes may change between the time of the
Binding Update and the time of the Prefix Discovery message.) It is
assumed that the Mobile Node has an appropriate IPSec Security
Association for each of these addresses with the Home Agent and the
Mobile Node MUST then attempt to register each of the addresses
individually with the Home Agent by sending a distinct Binding Update
for each address; these Binding Updates may be sent concurrently.

I have no opinion on the matter of deregistrations and refreshing
registrations of addresses in an S-set because I still don't understand
the intent of the existing text:
   "The value of the Single Address Only (S) bit field is examined only
   for new registrations.  Its value is ignored on de-registrations and
   re-registrations of the same addresses." [10.3.1]
 
       "The value of the Single Address Only (S) bit MUST be set
       equivalently for subsequent de-registrations and re-registrations
       with the same addresses." [11.7.1]

Regards
Greg

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Jan 2003 17:38:13 +0200

> Failure semantics

Yes.

> an s=0 BU. We return to this point later.

Agreed.

> set failed and which succeeded before being rolled back.

Agreed. Note that there's a further complication in the situation
since the MN may not know the structure of the home networks. For instance,
it may think HA1 and HA2 are from different operators and networks -
they do have different prefixes. Only configuration information or
prefix discovery could tell whether the MN's HAs really are on the
same or different networks.

> the following text to the sections indicated.

I would personally be ready for the removal as well, but I sense
that there are folks in the WG who want to keep it. Also, it is fair
to note that it's pretty late in the process to make big changes.
So, perhaps the above compromise approach is the only practical
way forward.

> be set to "Reason Unspecified".

I'm in principle OK with the above approach. I may comment on the
specific text later.

> for each address; these Binding Updates may be sent concurrently.

Lets think about this. Given that we established above that the
S=0 registrations can fail, the essential questions are (1) is
it necessary for the mobile node to try to recover the situation,
and (2) if so, how?

If the mobile node can do nothing (outside off-line actions) to
avoid getting into this situation and not recover through e.g.
retransmissions, then I'd say the answer to question (1) is yes.

It appears that we can get to a failure when the mobile node has
more than one home address, and there is no off-line guarantee
that the addresses are certainly on the same or certainly on a
different network. For instance, I could get a home address from
our lab network and the company intranet. If these two are merged
one day, then my mobile node could get confused. But is this failure
permanent or temporary? If I rerun prefix discovery, I will notice
that the two home networks are now both in the same location. The
mobile node could use this information and, for instance, de-register
the current registrations and submit a new single S=0 registration.

So the question I have is whether it makes sense for the MN to
   (a) Register individual addresses, or
   (b) De-register everything and send a new S=0 registration
       that covers all addresses. If the networks have split,
       multiple S=0 registrations may be required.

Approach b seems simpler for the mobiles that use S=0 anyway.
On the other hand, only approach a can cope with real failures,
such as one of the addresses actually being in use on the home
network.

Opinions?

>        with the same addresses." [11.7.1]

What they mean is that once you create a binding, the setting of the S
bit in the first BU will control all subsequent behaviour. The second BU
for the same binding (any address within the set) assumes the same S value.

As far as I can see, the behaviour in de-registration is simple. In a
re-registration you could get new prefixes for which e.g. DAD fails.
I suppose the semantics are equivalent here, i.e. its an all-or-nothing
event. If the re-reg BU fails, then the current binding stays unaffected
until its lifetime expires.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 02 Jan 2003 17:43:56 -0800

Greg O'Shea wrote:
> HoA1 is {2000:1::1, 2000:2::1, 2000:3::1} 

isnt the S-set for HoA1 just {2000:1::1}?

two reasons
1. HA1 never hears about 2000:2::
2. the link between HA1 and HA2 (prefix 2000:3::) is not a home 
   link for the MN

> and the S-set for HoA2 is
> {2000:1::1, 2000:2::1, 2000:3::1} 

and for HoA2, the S-set is {2000:2::1}

in our implementation, HA is always configured per interface. 
for example if HA1 has home agent functionality enabled only 
on the interface with prefix 2000:1::, and HA2 has it enabled 
only on the interface with prefix 2000:2::, the problem is 
avoided. binding cache entries for addresses with prefix 
2000:3:: are never created.

and if I had a network as you described above, I would not 
configure HA functionality on all interfaces.

MIPv6 spec always talks about a home link with Home Agents. 
if a router is a home agent, it does not mean it is a home 
agent on all interfaces. it needs to be told which is the 
home link. this is what I have always assumed. maybe it needs 
to be made clear.

so I am still unable to see the problem that you describe.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 04 Jan 2003 00:46:47 +0200

> 2. the link between HA1 and HA2 (prefix 2000:3::) is not a home 

I think Greg's picture above has just one link, and three
prefixes on it.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 03 Jan 2003 16:31:14 -0800

> I think Greg's picture above has just one link, and three

then the MN does not send BUs to both HA1 and HA2, because it 
never picks more than one HA per home link. it knows both HA1 
and HA2 belong to the same home link through dynamic home agent 
discovery.

what am I missing?

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 04 Jan 2003 11:54:23 +0200

> and HA2 belong to the same home link through dynamic home agent 

I see. So running dhaad would get you the home network structure.
Presumably running prefix discovery would complement this
information.

There's only two problems with this:

- The information may change between doing dhaad and sending the
   BUs. Ok, so maybe you could rerun dhaad if your S=0 bu fails.

- I don't think we have required doing dhaad before using S=0
   anywhere. Section 11.4.1 starts with the word "Sometimes"...

Overall, its pretty hard to get atomic transaction semantics
for S=0 given that any information listing the actual prefixes
will be in another message (dhaad or prefix discovery). But
perhaps the merge/split of home networks is rare enough that
we shouldn't be worrying about this; the rerun-dhaad-and-pd-
if-it-fails approach seems sufficient for this.

Then we have the question of what do when a BU fails, do
we need to go for S=1 registrations, or is it enough to
get the new information, send some de-registrations, and
new S=0 registrations? I'm beginning to think that rerunning
dhaad & pd, de-registration, and a new S=0 registration is
sufficient.

If a MN uses S=0, does that imply mandatory support for
dhaad & pd then?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 05 Jan 2003 17:15:04 -0800

Jari Arkko wrote:

> But
> we shouldn't be worrying about this; 

I _very_ much think so.

> the rerun-dhaad-and-pd-if-it-fails approach seems sufficient for this.

okay.

> dhaad & pd, de-registration, and a new S=0 registration is

I think the MN should immediately go for S=1 registration. then
maybe later on run DHAAD and Prefix discovery. and based on the
information returned it could try S=0 registration again.

> If a MN uses S=0, does that imply mandatory support for

not necessarily. if the S=0 registration fais and the MN doesnt
want to do DHAAD, it can set the S bit to 1.

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 6 Jan 2003 10:34:21 -0700

Jari -

> If a MN uses S=0, does that imply mandatory support for

Prefix Discovery must be used by the MN as the mechanism to auto-configure
the home addresses associated with the S=0 binding. DHAAD is optional. In
our MN implementation, we will not be tracking each HA in the DHAAD Reply
message to detect that they are on the same link, all we care about is
finding a single HA on our home network that we can successfully register a
binding with.

Regarding S=0 BUs:
I agree there is extra complexity involved in S=0 BUs. One of the painful
parts of implementing MN "return to home" functionality is the fact that
with a S=0 binding, the HA is defending the MN's auto-configured link-local
scope address when it returns home, and that creates a special case that
adds complexity to a MN implementation. I can go either way on S=0, however.
S=0 does allow the MN to reduce the number of BUs that it sends to the HA
when it moves, which can be a significant benefit.

I agree with the basic problem that Greg O'Shea describes (in fact, I
identified it earlier as issue #172 "Infinite lifetime and MN forgets its
binding and HA", also see my comments for issue #168 "L bit is not worth the

> Next we consider the following network:

This is essentially the same scenario I described in issue #172 where the MN
doesn't remember which HA it has an active S=0 binding with after being
power-cycled on a foreign link, the MN uses DHAAD and discovers a different
HA on its home link to register with, when attempting a S=0 registration
with the 2nd HA this fails (duplicate address detection failure) because the
1st HA with the active S=0 binding is actively defending the MNs set of home
addresses (including the link-local scope address formed from the MN's IID).
Solution? Well, in my implementation I'm not allowing the MN to create a
binding with an infinite lifetime, also I'm expecting that once a working HA
is found (and successfully registered with) that the application continues
to use that same HA even when it appears that it is not responding (i.e. due
to a transient loss of network connectivity) until the MN knows for sure
that the S=0 binding has expired on the HA (one indication of this is
getting a failure result back in the BA from the HA). This implies that
short (i.e. a few hours or less) binding lifetimes are preferred, if the
application expects that it will need to change the HA it is using.

I did have a suggested solution on the HA for this scenario, per issue #172:
"... change the MIPv6 HA to not defend the MNs home address, but instead to
monitor for another node on the home network using or attempting to use that
home address, in which case the HA transitions the MN home address binding
into a "dormant" state, suspends tunneling packets to the MN, and forces the
MN to reregister by periodically retransmitting a BRR to the MNs primary CoA
(per the "dormant" binding) until either the MN responds with a BU, or the
binding lifetime expires, or the HA makes some informed decision that the MN
will not respond and deletes the binding. Note that while the binding is in
a "dormant" state, if a node on the home network is using the MNs home
address (i.e. responding to NS for that home address), then packets sent to
the MNs home address must be routed to that other node on the home network."

This does not work for the RFC-3041 case, but it actually works fairly well
for the S=0 case (since a S=0 BU is always associated with a globally unique
IID used to form the home addresses, and does not use RFC-3041 to generated
home addresses). Perhaps it is worth considering this change on the HA
specifically for the S=0 case? Basically, it would make the HA, only in the
S=0 case, monitor and proxy for the MN's home addresses associated with the
S=0 binding, but not actively defend them. Then when the HA detects that
another node on the network is using the MNs home address (which probably in
99% of all the cases is due to the MN returning home and/or the MN
reregistering S=0 with a different HA, since the MN is registering a
globally unique IID when it creates the S=0 binding so there should not be
any DAD conflict except from the same MN), the HA stops proxying (i.e. does
not actively defend, in the S=0 case) for that home address, assumes that
the MN is still reachable through the CoA in the binding and sends a BRR to
that CoA to force a BU/BA failure and subsequent deregistration (in the
"return to home" case the MN won't be there on the foreign link, and won't
respond to the BRR), and then finally deletes the S=0 binding.

This proposed change to HA functionality adds some extra complexity on the
HA side, but it has the following advantages:

1) it completely fixes the issue that Greg and I identified with S=0
bindings when the MN attempts to register the same set of home addresses
with multiple HAs, i.e. it fixes issue #172 "Infinite lifetime and MN
forgets its binding and HA".
2) it extremely simplifies MN return to home operation: the MN can just
return to home and start using its home addresses, knowing that in the
process the HA will detect this and auto-deregister its active S=0 binding
(if it is still active). This avoids all of the hacks to ND and DAD
otherwise needed for this case to allow the MN to explicitly deregister.
This is a very low latency "return to home" MN algorithm.

Also, I do think that it makes sense to treat S=0 registration/bindings as
being sufficiently different from S=1 bindings to warrant this difference in
HA behavior.

So, please consider this suggested change to HA functionality specifically
for the S=0 case.

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