Subject: RE: the real issue (was Re: Issue 13: Omission of prefix options - resolution)

From: "Bound, Jim" <[email-masked]>
Date: Sat, 8 Nov 2003 22:31:33 -0500

IPv6 has been receptive to all changes. How fast they accept them is
directly proportional to the way it is presented to them.

/jim

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Friday, November 07, 2003 3:20 PM
> To: Bound, Jim
> Cc: Soliman Hesham; [email-masked]
> Subject: the real issue (was Re: Issue 13: Omission of prefix 
> options - resolution)
> 
> 
> 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
> 
> Bound, Jim wrote:
> > 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
> > --------------------------------------------------------------------
> 
> 

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