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

From: "Greg O'Shea" <[email-masked]>
Date: Thu, 5 Dec 2002 08:28:43 -0000

I think you are trying to read too much into 11.4.1: it me its basic
premise is that you mustn't register a given HoA simultaneously with
multiple HA, in other words, don't register competing home bindings.
Also it would be a mistake to read too much into "home link" being
written in the singular in 11.4.1 and elsewhere, for the draft is
littered with references to "Home Address" in the singular which aren't
to be taken too literally either. (Note also "...the mobile node..." in
11.4.1.)

I would agree that the MN could stick to one HA for a given HoA, at
least until the binding with that HA expires or is deleted. But I may
have some other HoA on route prefix(es) that is (are) not served by a
given HA and obviously I must register it (them) elsewhere.

I am reminded that we had an experimental implementation on draft 12 a
couple of years ago joint with Lancaster University that would
automatically register new (HA,HoA) bindings as it encountered new HA in
its travels, so this is really nothing new.

To move on I suggest making the S-bit optional (MAY) on the HA, although
you still need to be more precise about the failure semantics of a
multiple registration in one BU and reporting of same via Binding Ack.
The MN can always register multiple addresses individually with the HA,
in which case the semantics and reporting are fine. In any case the MN
apparently has to do registrations and deletions individually.

Greg
>-----Original Message-----
>From: Vijay Devarapalli [mailto:[email-masked]] 
>Sent: 04 December 2002 18:16
>To: Greg O'Shea
>Cc: KASSI-LAHLOU Mohammed FTRD/DMI/CAE; Mobile IPv6 mailling list
>Subject: Re: [mobile-ip] Issues with the S bit.
>
>
>Greg O'Shea wrote:
>> 
>> I agree. I do not think the IPv6 world should design to be 
>constrained 
>> to a single [provider|interface|(Home)address|HomeAgent].
>
>and I dont think MIPv6 places this restriction.
>
>> clearly an informational draft would be a good idea at this time. At 
>> the moment the only obvious glitch I've noticed is the S-bit. Do you 
>> know of
>
>no Greg, the glitch is not there. section 11.4.1 says the MN 
>sticks to one home agent.
>
>Vijay
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 05 Dec 2002 10:14:49 -0800

> multiple HA, in other words, don't register competing home bindings.

exactly. and when you use the 'S' bit, it means the MN must not 
register a set of addresses with multiple HAs. period. there is *no* 
glitch. if this is not clear, then we should probably clarify it in 
the MIPv6 spec.

it is kind of simple.

> To move on I suggest making the S-bit optional (MAY) on the HA, although

no. disagree. I dont see the problem first. and moreover MAY will 
not work. the MN sets the 'S' bit to 0 assuming the HA defends all
home addresses. if the HA does not, and the MN does not know about
it, we have something broken. when the MN returs home, some of its
home addresses may not be available for it.

> multiple registration in one BU and reporting of same via Binding Ack.

you mean draft 19 is not precise? that can be clarified. it is all
or nothing. 

if the MN gets a bind ack with DAD failed for a BU with 'S' bit set 
to 0, it should try sending a BU again with 'S' bit set to 1.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Dec 2002 23:14:54 +0200

> to 0, it should try sending a BU again with 'S' bit set to 1.

Section 11.7.1 says:

   "In this case, the mobile node MUST NOT attempt to
    re-use the same home address.  It SHOULD continue to
    register care-of addresses for its other home addresses,
    if any."

Perhaps this should then be changed to

   "In this case, the mobile node MUST NOT attempt to
    re-use the same home address. The mobile node MAY
    retry the registration with the Single Address Only (S)
    bit set to 1, if the bit was set to 0 on the failed attempt.
    The mobile node SHOULD continue to register care-of
    addresses for its other home addresses, if any."

Beyond this, we have the following items of disagreement:

- Can a MN have several independent HAs? I think personally
   yes because IPv6 allows multiple addresses?

- To remove the S bit?

- Or to make the S bit optional in the HA? I think the spec will
   become more complicated with this, we need error codes and
   new text to handle various conditions. I say we either keep
   the S bit or throw it away, but not make it optional... I hate
   optional features.

- Need for stating the assumptions behind prefixes and multiple
   HAs? I think we need to state something about complete success
   or failure of S=0 BUs. We MAY also say something about allowed
   overlap on HAs that can potentially be returned in a DHAAD.

- Whether or not the MN should stick to the home agent it has
   selected? I think it should, need to look at the text to
   see if it is clear enough now. But apparently not.

Anything else?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 05 Dec 2002 14:15:27 -0800

>     addresses for its other home addresses, if any."

yes. this looks good.

>    yes because IPv6 allows multiple addresses?

yes. but not more than one per home link. basically the MN 
should avoid asking two home agents on the same link to defend 
its addresses at the same time.

> - To remove the S bit?

no.

>    the S bit or throw it away, but not make it optional... I hate

I agree. making it optional is a bad idea.

>    or failure of S=0 BUs. 

I thought we already did this. if not we should. I prefer the 
all or nothing approach. otherwise the implementation becomes 
too complicated.

>    see if it is clear enough now. But apparently not.

I think the MN should stick to one home agent as long as the
existing bindings are still valid. this should be clarified.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Fri, 06 Dec 2002 11:01:13 +0200

> yes. but not more than one per home link. basically the MN 

Agreed.

> its addresses at the same time.

Hmm... here's an idea: why don't we require that if multiple
home agents are being used, the S-bit will be set to 1. This
would make sure that there is no problem, even if the mobile node
wouldn't know if the two home agents it has happen to be on the
same link. Remember that there could be different prefixes.

> all or nothing approach. otherwise the implementation becomes 

It does need clarification. In 10.3.1, we need to say the following
in the DAD discussion:

   If this Duplicate Address Detection fails for the given home address
   or any of the implied other addresses, then the home agent MUST reject
   the complete Binding Update and MUST return a Binding Acknowledgement
   to the mobile node, in which the Status field is set to~134 (Duplicate
   Address Detection failed). When the home agent sends a successful
   Binding Acknowledgement to the mobile node, the home agent assures to
   the mobile node that its address(es) will continue to be kept
   unique by the home agent at least as long as the lifetime granted for
   the bindings is not over.

> existing bindings are still valid. this should be clarified.

Rereading the text and Conny's e-mail, perhaps this is in fact
already said in the text.

So where are now? We have clarified the complete-success-or-failure
thing, we think we are clear on the thou-shall-not-switch-ha issue,
and we have clarified the DAD failure action for MNs. We still have
to decide:

- To keep the S bit or not or even make it optional; I'm sensing that
   the optionality case at least is not in favor.

- Whether to state something about the assumptions regarding overlapping
   addresses. How about requiring what I presented above i.e. if multiple
   home agents are being used then S must be 1 to avoid accidental overlap.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 06 Dec 2002 09:55:40 -0800

> same link. Remember that there could be different prefixes.

no Jari. as long as the MN is using only one home agent per 
home link at any time, there is *no* problem. it can set the 
'S' bit to 0 even though there are multiple home agents on 
the home link. 

if the MN is planning to use more than home agent at the same
time, then it probably makes sense introducing the above
requirement. nobody has yet made a case for the MN using more 
than one home agent per home link simultaneously. and if we go 
with what is written in section 11.4.1, it is already prohibited. 
we are trying to find a solution to a problem that does not 
exist, IMO.

regards
Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 06 Dec 2002 13:23:43 -0500

Vijay

> 'S' bit to 0 even though there are multiple home agents on 

My concern is how does a mobile node deside that any two given
homeagents are on the same link?

I guess one way would be to do DHAAD to both home agents and
see if each of them is in both lists, but is there another way.

For example, two HAs are statically configured on the MN.  How
does it determine that they are on the same home network/link
or not?

Note, I agree that "S" bit functionality is usefull and we
do implement it in our Home Agents, but the above bugs me a little.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 06 Dec 2002 11:14:43 -0800

> homeagents are on the same link?

same prefix(?). the MN definitely knows the prefix of the home
link.

> see if each of them is in both lists, but is there another way.

when the MN receives a DHAAD reply which contains more than one
home agent, it assumes all these home agents are on the same link.
it has to be, right? how was the DHAAD reply constructed by a HA
otherwise?

> does it determine that they are on the same home network/link

if you are statically configuring two HAs on the MN, you better
make sure the MN knows about them. the MN needs to atleast know
the following

1. which HA to use for which home address?
2. do they belong to the same home link? if yes, which to use when?

maybe we got to wait for Kassi's draft which talks about multiple
home agents from different providers/home link.

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 06 Dec 2002 14:59:47 -0500

Vijay

> same prefix(?). the MN definitely knows the prefix of the home

That's not necessarily always true.  I would imagine that it would
be perfectly valid to have 2 routers acting as a HAs on the same
link and advertise different prefixes.  This would mean that each
routers would have a different prefix as part of its address, but
they will be on the same link.  The MN will not know that unless
it runs through DHAAD and parses the responses.

> it has to be, right?  how was the DHAAD reply constructed by a HA

That's what I stated above as one way to figure out if 2 HAs are
on the same link.  I was wondering if there is another?

I guess one can also use MPS/MPA as another way a look for prefxies
in the MPA.

I haven't had time to read draft 19 yet, but since the question
came up, maybe some of these should be make into a draft (or an
appendix).

> home agents from different providers/home link.

Yes, I am waiting for that draft as well.

-vlad

---

From: Jari Arkko <[email-masked]>
Date: Sat, 07 Dec 2002 01:16:59 +0200

> 'S' bit to 0 even though there are multiple home agents on 

Yes, but let me clarify my proposal. If the *mobile node* intends
to use multiple HAs simultaneously, *then* it MUST use S=1.

> we are trying to find a solution to a problem that does not 

You have a point there. OTOH IPv6 in general allows multiple
addresses, routers etc, and I think the language in 11.4.1 is vague
about 'home link'; I could interprete it also as allowing potentially
multiple home links and respective home addresses and agents.

Jari

---

From: Conny Larsson <[email-masked]>
Date: Fri, 06 Dec 2002 08:03:33 +0100

Jari, Vijay,

Section 11.4.1 says

   "If the mobile node has a current registration with some home agent
   on its home link (the Lifetime for that registration has not yet
   expired), then the mobile node MUST attempt any new registration
   first with that home agent.  If that registration attempt fails
   (e.g., times out or is rejected), the mobile node SHOULD then
   reattempt this registration with another home agent on its home link.

   If the mobile node knows of no other suitable home agent, then it MAY

   attempt the dynamic home agent address discovery mechanism described
   above."

I interpret the above as that the MN have to stick with the HA that it
has its current registration with, even if a new registration attempt
failed, until it times out. The MN may then choose a new HA.

/Conny Larsson

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 12 Dec 2002 08:53:59 -0700

Conny -

Almost, not quite. It says:

"If that registration attempt fails (e.g., times out or is rejected)..."

This failure (i.e. in the case of "times out") could be due to a transient
loss of network connectivity, which will very likely happen occasionally for
a wireless mobile node.

Perhaps if this was reworded to say: "If that registration attempt fails due
to be rejected by the home agent, ..."

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Conny Larsson
> Sent: Friday, December 06, 2002 12:04 AM
> To: Vijay Devarapalli; Jari Arkko
> Cc: Mobile IPv6 mailling list

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 12 Dec 2002 13:54:37 -0500

Ed

> loss of network connectivity, which will very likely happen occasionally for

Registration timeout seems like kind of a"soft error" to me that should be
correctible by retransmition.  Once max retrasmissions is reached,
the it becomes a "hard error" and the MN can try another HA or do DHAAD.

Outright rejections is a "hard error" so the MN can try another HA.

-vlad

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 12 Dec 2002 11:45:27 -0700

Vlad -

Please refer to the error scenario I described in issue #172
http://www.piuha.net./~jarkko/publications/mipv6/issues/issue172.txt.

If you switch home agents when you have an active registration with a
different home agent than the one you are trying to register with, it is
(currently) a very bad thing for the MN, so you want to avoid this at all
costs. Basically, you end up with a MN that cannot register because some
other HA (that it is no longer using) is defending its home addresses, this
does not allow it to register those same addresses with a different HA on
the home network (i.e. DAD failure). The only thing that recovers this
situation (currently) is the registration lifetime expiring in the HA - if
it is an infinite binding lifetime, you are out of luck.

So, I don't agree with your statement that after X number of registration
attempts with a specific HA, it becomes a hard error, then it is OK to
switch to a different HA. It is only OK to switch if the MN knows that the
old HA it is switching from is no longer maintaining active bindings for it.
One obvious indicator of this is receiving a BA from the old HA that
indicates that the registration was rejected (i.e. confirming that there is
network connectivity), then it is OK to switch to a new HA.

I had proposed a significant architectural change which would have made the
MN a 2nd-class citizen when operating on a foreign link but which would have
resolved this failure scenario for the case where the MN registers with L=1.
I know that didn't work too well (however) for home addresses generated
using RFC-3041, which is why it disappeared off of my radar screen.
Anyways...

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

> From: Vladislav Yasevich [mailto:[email-masked]]
> Sent: Thursday, December 12, 2002 11:55 AM
> To: Ed Remmell
> Cc: Conny Larsson; Vijay Devarapalli; Jari Arkko; Mobile IPv6 mailling
> list