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

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

Hesham,

>  > 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.  
> 
> => Completely understand, but I was not referring to the L
> bit in my email, I was referring to the disappearance
> of the _entire_ prefix option. 

Who said the prefix option is disappearing?  Its part of the standard.

The L bit can be NOT SET too.

> 
> I happen to agree with a few people that the best solution
> to this problem is to introduce the LinkID which makes
> it much simpler to detect movement. 

Thats fine but do it in DNA or some other focus group on movement
detection is my point and it should not be listed as issue for 2461bis
here at this point is my view.

> 
>    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 :--)
> 
> => Sure. But in the scenario discussed in this issue, 
> the whole prefix option disappears. Therefore, there is
> no R bit either.

Why and how.  Then one is saying drop the ND msg to support the R bit?
Thats absurd.  It is part of MIPv6 and going to PS.  Un-confuse me?

> The question is if some router designer 
> decided to save BW and not advertise all options all the 
> time. The MN first hears Prefix1 and Prefix2 (from one or two 
> routers doesn't matter). It derives a CoA based on Prefix1. 

Ok here we go again.  That is is a bogus router and not participative of
MIPv6. 
I could come up with scenarios like this for TCP, Telenet, NFS, etc etc.
We have to assume products that support MIPv6 will do what they are
suppose to do.

> The next adv contains Prefix2 only (because its timer was 
> about to expire and therefore had to be advertised again, 
> while prefix1 didn't need to.

But either prefix will provide movment detection it is the absence of
the prefix that is the problem and that is the absence of a valid
participating router.  Ergo broken network configuration for MIPv6
deployment.  Simple replace the router with one that knows how to
operate to support MNs via MIPv6.   We don't add yet more options to
specs in the IETF to do end run around bogus products.

>Or because there were two 
> routers and one of them decided 
> that it doesn't need to advertise its prefix this time). 

This is called routers being in synch again a deployment issue, not
anything broken in ND and MIPv6.  We decided I guess long ago to not put
the same config controls on routers we do hosts for whatever reason and
this is the end result. 

> Now, this might force a movement detection implementation
> to think that it _might_ have moved. Depending on how 
> "conservative" that implemenation is, the reaction will vary
> from: "form a new CoA based on prefix2" (not conservative) to 
> "check that prefix1 and default router are still alive" 
> (conservative). 
> If the MN hadn't moved at all (as is the case in this 
> example), neither action is desirable. 

This is why we cannot ignore detection without layer 2 and I stated that
on the first thread.  It is quicker than getting new options like a
link-id it is a very fast lookup to see if I had a link state change at
layer 2.

But this should not happen if the routers are in synch.

And only one router should be sending prefixes with the R bit make that
policy.

> 
> Having a new option (not suggesting to add that to 2461)
> called a LinkID (could be a globally unique address) and 
> included in every RA sent from all routers on the same link, 
> would allow the router to save other options, while 
> eliminating movement detection problems.

That is to much overhead for all routers add it just to when the R bit
is used and put it in MD or DNA spec. But having only one router
permitted to send RA with R bit solves it too.

> 
> But since there is no concensus on the solution (some prefer 
> the "complete bit"), or its inclusion in 2461 (Vs DNA or 
> another IPv6 draft), 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.

We have to wait then.  But I will add the other one and that is make a
policy.

> 
>  > Help me here I think this is pretty basic stuff :--)  
> 
> => Hope this helps :)  

Yes but it still comes down to where the most efficient scalable fix is
and that requires more discussion this is not ready for 2461biz.

thanks
/jim

> Hesham

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 07 Nov 2003 12:20:05 -0800

I am not sure what is being discussed here. I am confused...

Neighbor Discovery as it is today is kind of very very unfriendly
for movement detection (and therefore mobile nodes).

just to make it clear, Mobile IPv6 spec currently is quite
conservative when it comes to movement detection. there were a
bunch of mechanisms in the earlier Mobile IPv6 drafts which would
have made faster movement detection  possibly. these mechanism
included a lot of changes to the ND specs. they were all removed
from the spec (I wont go into why they were removed). a new WG
called "Detecting Network Attachment" (DNA) is being chartered to
work on faster movement detection.

absence of prefix information (that the mobile node saw earlier)
is not used for movement detection currently. but it is considered
as one of the hints that the mobile node may have moved. there are
weak hints and strong hits. this for example is a weak hint. an L2
trigger for example is a strong hint. weak hints are always
ambiguous. the mobile node has to do additional steps to confirm
if it has moved.

if the routers always include all prefix information in the router
advertisement, it makes it *easier* for movement detection by
eliminating a weak hint.

the complete bit is one solution for this. if the bit is set, it
means all the prefixes for that particular link are included in the
router advertisement. but this has some backward compatibility
issues.

the linkid, where each router includes a linkid in the router
advertisement the linkid being unique for each link), is another
solution.

I guess this issue can be handled in the DNA WG, when it is formed.
but if DNA WG modifies/extends Neigbor Discovery specs, I hope the
IPv6 WG would be receptive to these changes. my previous experience
shows this is not the case, unfortunately. :(

Vijay

---

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Nov 2003 08:48:00 +0200 (EET)

> router advertisement. but this has some backward compatibility

Was this really what we talked about??

I think we were discussing a Complete bit which would say "I didn't omit 
any prefixes".

Whether a router on a link can administratively assure that all the 
prefixes ever to be seen on a physical link are included is IMO a 
completely separate topic.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 08 Nov 2003 20:36:45 -0800

you are right. not all prefixes for the particular link. all prefixes
advertised by the router.

Vijay