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

From: "Krishna Kumar" <[email-masked]>
Date: Fri, 6 Dec 2002 13:04:40 -0800

> > should avoid asking two home agents on the same link to defend
> > 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.

I don't see how this way of setting S=1 would work. If multiple agents
on the same link provide different prefixes, the MN cannot decide which HA
to send which address with S=1. It cannot send all addresses to 'n' agents
since they may not support prefixes that don't intersect, on the other
hand for prefixes that intersect, DAD would fail for those addresses on
possibly all HA's.

While I agree the 'S' bit is useful to have, there seems to be another
problem with using it when there are multiple home agents supplying
different prefixes (ofcourse I believe that only one HA is being used
for the BU). Suppose the MN sends the BU with S=0 to one HA, the HA does
DAD only on those prefixes that are onlink on the link the Home Address
is valid. Hence it will not do DAD on other prefixes that are supported
only by other HA's. Hence using 'S' bit doesn't work in this case, it is
not just a case of bad behaviour in case of conflict as per original
Greg's mail, but an incomplete protection ?

A solution to all these can be considered by Jari's (I think ??) earlier
suggestion of DHAAD reply having more stateful information about links/
prefixes. But then the MN planning to use S=0 MUST do DHAAD before it can
send a BU, even if it is configured with a home agent.

- KK

---

From: Jari Arkko <[email-masked]>
Date: Sat, 07 Dec 2002 02:29:28 +0200

> hand for prefixes that intersect, DAD would fail for those addresses on

Ok. Then this appears to be a more general problem. Assume DHAAD gives you a list
of home agents, and you have multiple home addresses with different prefixes.
Then you still need to decide what addresses to send to which home agents,
even if the S bit was never invented.

I believe the only way to fix this is to tell the MN what the mapping
between addresses and home agents is. Either by configuration or an
improved form of DHAAD & MPA. (Or we could forbid bad prefix combinations
between multiple home agents.)

> While I agree the 'S' bit is useful to have, there seems to be another

There seems to be support for the 'S' bit on the list.

> A solution to all these can be considered by Jari's (I think ??) earlier

I believe you are referring to Thomas Narten's proposal that DHAAD be
upgraded to include all addresses of each home agent. I think what you
want to do maybe beyond this, perhaps an upgrade to MPA. Maybe include
all prefix adverts and the router addresses, even if the prefixes are
the same for all home agents?

> send a BU, even if it is configured with a home agent.

If it has been configured with just the home agent, then we need to do
still some more work, basically run MPS/MPA. If it is configured with the
home addresses as well, then we can just go ahead. But that configuration
must include dependencies between addresses and home agents.

Jari

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Mon, 9 Dec 2002 13:52:37 +0100

Hello all

Everyone is discussing about the S bit issues, in the case when MN is having
diferent home addresses per
interface or for multiple interfaces.

It is practicable to use single home address for all interfaces of the MN,
as the other party can identify the
MN with the unique identifier. And also in a multiple interface environment,
MN has a choice to have continuous communication with
the CN even one when interface goes down. (This is considered in MIPv4 RFC
with S bit)

I would like to know why this aspect is not considered in Mobile IPv6 draft
itself. i.e to handle simultaneous multiple binding for single home address.
I know there is a draft for fast handovers, which considers the bit called
B, to introduce simultaneous binding.

Thanks in adavnce

Koojana
-----Ursprungliche Nachricht-----
Von: [email-masked]
[mailto:[email-masked]]Im Auftrag von Jari Arkko
Gesendet: Samstag, 7. Dezember 2002 01:29
An: Krishna Kumar
Cc: Greg O'Shea; Mobile IPv6 mailling list; Vijay Devarapalli
Betreff: Re: [mobile-ip] Issues with the S bit.

> hand for prefixes that intersect, DAD would fail for those addresses on

Ok. Then this appears to be a more general problem. Assume DHAAD gives you a
list
of home agents, and you have multiple home addresses with different
prefixes.
Then you still need to decide what addresses to send to which home agents,
even if the S bit was never invented.

Jari

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 09 Dec 2002 08:05:15 -0800

Hello Koojana,

Koojana Kuladinithi wrote:

> MN with the unique identifier.

True, and it has been done with good success.

> And also in a multiple interface environment,
> the CN even one when interface goes down. (This is
> considered in MIPv4 RFC with S bit)

This is a different thing.  Of course there are many cases, but
the 'S' bit explicitly asks for packet duplication.  One can have
continuous communication without packet duplication, except
that in reality one never has "continuous" communication so
that eventually you have to consider granularity, delay, and
other factors.

The 'S' bit was never shown to be interoperable between
any two implementations that I am aware of.  I think that
this is suffcient cause for deletion from RFC 3344 as that
document progresses towards Draft Standard.  Or maybe
there has been some interoperability testing and I missed it.

For this reason, there is no 'S' bit in Mobile IPv6.

> B, to introduce simultaneous binding.

The 'B' bit is different from the 'S' bit in several important ways,
to my understanding.  I think for both of them, if one considers
mobility not just at the edge of the network, it is possible to get
quadruplicate traffic and other bad effects.  This would happen
typically outside the control of the mobile device.  I think both
of them are problematic.

Regards,
Charlie P.

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Tue, 10 Dec 2002 12:33:42 +0100

Hello Charlie Perkins,

Thank you for your reply. I appreciate the clarifications.

On Monday 09 December 2002 05:24 pm, you wrote:
> Von: Charlie Perkins [mailto:[email-masked]]
> Gesendet: Montag, 9. Dezember 2002 17:05
> An: Koojana Kuladinithi
> Cc: Mobile-Ip
> Betreff: Re: AW: [mobile-ip] Issues with the S bit.

> > It is practicable to use single home address for all interfaces of the
> > MN, as the other party can identify the

It is not clear that how can this be achieved in MIPv6.
Are you talkling about network layer solutions or on other layers ?  What I
talked about was on the n/w layer.  The home IP address makes the mobile
computer
unique.

> For this reason, there is no 'S' bit in Mobile IPv6.

Yes, I agree that S bit multiplicates packets by the number of bindings the
mobile node has.  But I think, the advantage of having one unique ID (IP
address)in a multiinterface environment is more.  We have written a draft
(draft-nomad-mobileip-filters-02.txt)
for filtering data by the binding agent so that there is no need to
multiplicate packets.

We have extended the SunLabs Mobile IP sofware to cater to the S bit as we
understood it to be in the MIPv4 RFC and filtering (as in our draft) to use
the
connections logically, without duplicating packets.

I have no experience with other implementatons that can act on the S bit in
IPv4.
But what I think is that the RFC 3344 is not very clear on how the S bit
should be handled and hence might be the reason for the interoperablity
problems.

By continuous, I means the continuity of the higher levels above the n/w
layer, for example, the applications can run continuously.

> typically outside the control of the mobile device.  I think both

What is your opinion on identifying the mobile computer with a unique home
IP
address, even when it has multiple n/w interfaces and then filtering the
packets without duplicating ?

Kind regards,
Koojana