Subject: RE: Issue 13: Omission of prefix options - resolution

From: Soliman Hesham <[email-masked]>
Date: Tue, 4 Nov 2003 05:59:49 -0500

> >Suggested resolution:
 > >
 > >- Introduce a new code (1) in the router solicitation
 > >and advertisement. When a host sends an RS with code = 1
 > >it requests that the RA include all prefixses valid on
 > >that link. Similarly, when a router sends an RA with code=1
 > >it means that the RA includes all prefixes valid on that
 > >link. This way, a MN can confirm its mobility.
 > 
 > 	we cannot always correlate RS and RA (router can listen 
 > to RS, then
 > 	issue RA on the next periodic advertisement).  also RS 
 > does not solicit
 > 	unicast RA.  

=> Sure, but for code = 1 this behaviour can be modified.
Btw, the RA does not need to be unicast, it only needs to
indicate that all prefixes are included (i.e. the new code). 

Hesham

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Tim Hartrick <[email-masked]>
Date: Tue, 4 Nov 2003 07:45:15 -0800 (PST)

Hesham,

> link. This way, a MN can confirm its mobility.

When this problem was noted in the early days I remember suggesting adding
"Solicited" bit to the router advertisement to address this issue.  Because
of backward compatibility problems that solution will no longer work well.

Is there some reason why we wouldn't want to add a new bit, say the
"Complete" bit, to the reserved field of the router advertisement?  I realize
I just finished ranting against adding new bits but using one of the reserved
bits for this purpose seems cleaner to me.

Tim Hartrick
Mentat Inc.

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 5 Nov 2003 05:14:36 -0800 (PST)

Markku Savela wrote
>> There are pro and con between them. For example, if an MN receives a complete 
>> RA which contains all the prefixes, it can form new CoA immediately. Whereas, if 
>> it receives a RA which contains  LinkID but no prefixe, an additional RS/ RA 
>> exchange is needed. 
>
> MIP6 should not configure new COA just because it sees RA. It should
> always wait until stack has accepted and configured valid address.
 
I was not clear enough. I tried to mean as belows. 
 
"if an MN detects movement (subnet change) by receiving a complete RA ......, 
if it detects movement (subnet change) by receiving a RA which contains Link ID......"
 
> Mobile IP6 should be considered as two almost independent components:
> MIP6 and Movement detection (MOVD). Something like follows
>
>        IP6 Stack
>      ----------
>      |        |
>    MIP6      MOVD
>
> MIP6 has really no need for messing with RA's. It should just detect
> "movement" by the fact that the CoA it has been using has been removed
> from the stack. Then it can find a new CoA from the stack, when it
> configures.
 
In our case, we implemented movement detection module as a part of our 
MIPv6 stack. Correct me if wrong, but currently there is no universal way of 
movement detection. At ETSI event, we found each MIPv6 
stack uses different MD modules. Some use NUD like three NS probes, 
some 1 NS and time out and some ECS (Eager Cell Switching). 
 
I restrain myself from delving into detailed movement detection scheme, barely. :-)

Best regards
 
JinHyeock 

---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 6 Nov 2003 12:42:06 -0500

Hesham,

Host nodes should not be doing this?  We did not put this in ND for very
good reason. We want to reduce what Hosts no about prefixes and leave to
the stateless and stateful. Why do we want to put this into HOsts.  What
is the reason.  That is not below.

What problem is this addition trying to fix or solve?  

I have read the draft below and believe the core issue is resolved.
What prefixes are supplied is in the system not the host or why not just
use DHCPv6?  I think we cannot and must not overrule the essential
meaning of the A and M bits.

In fact I suggest in additon to each member of this list a problem
statement be stated for each change to 2461.

thanks
/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Soliman Hesham
> Sent: Tuesday, November 04, 2003 4:35 AM
> To: [email-masked]
> Subject: Issue 13: Omission of prefix options - resolution
> 
> 
> Hi, 
> 
> This is an attempt to resolve this issue:
> 
> Issue 13: Impacts of the omission of a prefix option. 
>           section 2.2 in :
>         
> http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.t
xt
          describes the impacts of omitting a prefix option from
          an RA on movement detection for mobile nodes. RFC 2461 
          does not require options to be present in every RA.

In case you haven't had time to look through the draft 
here is the background info:

This issue raises the problem with omitting some prefixes
from an RA. The problem here is that 2461 says that a router may choose
to omit some prefixes from the RA to save BW (i.e. while the lifetime of
that prefix has not expired). 
A mobile node might take this as an indication of movement (i.e. it is
no longer reachable on the CoA that was derived from the omitted
prefix). This may unnecessarily cause the 
mobile node to send a binding update to the HA/CNs to indicate that its
CoA has changed. 

The other problem is that a host has no idea whether an RA contains all
the prefix options that are valid on a link. Therefore, even if it sends
an RS it might still get an RA with an incomplete list of prefixes.

Suggested resolution:

Comments?

Hesham

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 7 Nov 2003 05:00:39 -0500

Hesham,

I realize hosts today "could" use prefixes from L bit being set to know
its on a new link. But that is not why the L bit is there.  The L bit is
there as an optimization to avoid an NS or direct send knowing it is
onlink and a fast path could be written to just move the packet to the
link-layer address.  

The reason it is good to not use it is when one does not want to make an
annoucement of all prefixes on a Link and force NS's.  Let me give you
example.  911 Attack, Squad in Military Engaged Operation, or EMS
helping a victim with Wearable Medical Devices. In each case the entity
does not want to advertise those prefixes over a wireless, Satcom, or
cellular link.  Same for a shopper in a mall with GPS device locating
ones favorite perfume or firearm shop in the mall.  

Regardless this L bit has a use and dependency and was not created for
mobility but for stationary nodes.  The R bit defined in MIPv6 solves
the problem below.  When the node reaches the link it will hear the new
RA with R bit set and new router prefix.  So what has to happen is MIPv6
routers have to be turned on to deploy.  But that is ok because without
MIPv6 routers MIPv6 won't work :--)

But if one insists inform links that are supporting MIPv6 to just set
the L bit with policy admin and that fixes it too.

Help me here I think this is pretty basic stuff :--)  This is not a flaw
in 2461 but a good feature and I like it and want to use it as is and
don't want L bit as default.

/jim

------------------------------------
He said my name is Private Andrew Malone
if you're reading this then I didn't make it home
but for every dream that's shattered another one 
comes true this car was once a dream of mine
now it belongs to you 
and though you may take her and make her your own
you'll always be riding with Private Malone
- David Ball
www.minibite.com/america/malone.htm

> From: Soliman Hesham [mailto:[email-masked]] 
> Sent: Friday, November 07, 2003 3:50 AM
> To: Bound, Jim; [email-masked]
> Subject: RE: Issue 13: Omission of prefix options - resolution
> 
> 
> 
> => I should have described the scenario a bit better. 
> This is a case where hosts need to know whether they have 
> changed links or not. The only way we know that today is 
> through the contents of the RA. Hosts today use the prefixes 
> advertised (or not) as an input to the movement detection 
> algorithm amongst other things. There are different flavours 
> of movement detection depending on how conservative an 
> implementor wants 
> to be. But in all those flavours, the prefix option (or absence
> of) may well trigger the algorithm. 
> 
> I don't have a strong opinion on whether this should go into 
> 2461bis or not. But I do think that there is a problem. 
> Another consideration is how _real_ this problem is. Does 
> anyone know of 
> a router implementation that sometimes does not advertise 
> all options to save BW ? 
> 
>  > I have read the draft below and believe the core issue is 
> resolved.  > What prefixes are supplied is in the system not 
> the host or 
>  > why not just
>  > use DHCPv6?  
> 
> => DHCPv6 can be used, but in order to trigger DHCPv6 a host 
> needs to know that it has changed links. Otherwise it will be 
> triggered unnecessarily. 
> 
>    I think we cannot and must not overrule the essential
> => Agreed. We won't do that.
> 
>  > 
>  > In fact I suggest in additon to each member of this list a 
> problem  > statement be stated for each change to 2461.
> 
> => I'll try to cover that briefly in a "background" section 
> when I send a suggestion to resolve an issue.
> 
> Hesham 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 7 Nov 2003 14:28:49 -0500

> through the contents of the RA. 

Thats a pretty good indication and definite detection at layer 3. 

Just for clarification that is the MIPv6 R bit set so we are on same
page.

> Hosts today use the prefixes 
> algorithm amongst other things.

The prefixes advertized should not be used that way.

The MN must use the R bit.

I do not support making MNs work by changing this in 2461.

MNs will not work at layer 3 until either ND with R bit, FMIP, or HMIP
is deployed.  
That is life all have to deal with it.  Thats my position.

Or I do believe layer 2 notification works.

> There are different flavours 

That is a bogus assumption and inaccurate reading of the spec.  That is
what we call in an implmeentation ill-behaved code.  The L bit was never
mean't to do this and an implementor should not assume such things in a
spec to use or accept the penalty later.  
 
> 2461bis or not. But I do think that there is a problem. 

What problem.  You don't like the ND R bit?

> a router implementation that sometimes does not advertise 

This is totally irrelevant.  The L bit is very clear and if offers one
or infinity prefixes is not the point of the technical interpetation
issue.  The L bit was not mean't as a feature for movement detection
ever.  Assuming that is a mistake.

> needs to know that it has changed links. Otherwise it will be 

You misread my comment.  I am not advocating DHCPv6 but was using
juxtaposition to point out that the L bit is key for what it does on the
link and that is not to support any form of movement detection but for
optimization of the link.  That is all.

> => Agreed. We won't do that.

Good.

> when I send a suggestion to resolve an issue.

We went on this thread first thinking prefixes could be duplicated on
two links, now to reinventing what the L bit is and does.

But you did not respond to a very important issue in this mail thread.

The mechanism defined as standard (waiting for RFC) in MIPv6 ND
extension to address movement detection at layer 3 is the R bit for the
RA.  What I am hearing is some don't want to wait for that to be
deployed.  And we can use the end result of the L bit to do end run
around needing the R bit and I disagree.  This WG supported MIPv6 to use
the R bit and it will work.  Until that is deployed then MNs won't be
deployed. 

Another issue is with L bit set and just one prefix is provided and MN
sees it then it knows it is hearing the RA thus a new link.  1+N
prefixes is irrelevant for movement detection.  

Good discussion.
/jim

---

From: Soliman Hesham <[email-masked]>
Date: Sat, 8 Nov 2003 01:00:19 -0500

> 
 > LinkID solution can prevent MN from assuming movement 
 > while it has not. But I am afraid, when an MN actually moves, 
 > LinkID by itself is of limited use.  
 > 
 > Assume an MN actually moves into another link and receives 
 > an unsolicited RA with only LinkID. To get necessary prefix 
 > information, an MN should perform additional RS/ RA exchange. 
 > This will take time because a router is supposed to execute random 
 > delay before sending RA. 
 > 
 > Otherwise, after movement, an MN may receive a link-layer hint 
 > notifying link-layer change. Then an MN can sent triggered 
 > RS message 
 > and will receive a solicited RA with all the options. In 
 > this case, LinkID 
 > plays little role.  

=> So does the complete bit if you assume that routers
follow the recommendation of 2461 of sending a complete 
RA when solicited. But in any case, the LinkID does not 
play a limited role in the above scenario, it plays the role
of confirming that a MN has moved. It doesn't solve all
problems, but it is certainly a strong indication of movement.
You substituted it with the L2 trigger in naothe scenario
but it's worth noting that the L2 trigger is not as strong an
indication as the LinkID because it does not necessarily
indicate IP mobility.

 > > it seems like we should either reject
 > > this issue or delay the discussion until we resolve
 > > all the other issues and hope that opinions have converged
 > > by that time.
 > 
 > I agree. We need more elaboration and IPv6 WG may not be the best 
 > place for this. 
 > 
 > I have one question. Is it possible for us to define 
 > complete bit in DNA? 

=> Of course. MIPv6 extended ND in the MIPv6 specification.
There is no reason why any WG in IETF can do the same.

 > As Jim wrote above, if DNA spec can extend a core spec, RFC 2461, 
 > it's O.K. for me to close this issue. 

=> New options/extensions can be defined in a separate
spec for sure. Thanks! 

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Sat, 8 Nov 2003 07:22:10 -0500

Fatal typo below ;)

 > There is no reason why any WG in IETF can do the same.
=>                                          ^^
                                       should be: cannot do the same

Hesham