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 > -----Original Message----- > From: Soliman Hesham [mailto:[EMAIL PROTECTED] > Sent: Friday, November 07, 2003 3:50 AM > To: Bound, Jim; [EMAIL PROTECTED] > Subject: RE: Issue 13: Omission of prefix options - resolution > > > > > 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. > > => 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 ? > > > 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? > > => 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 > > meaning of the A and M bits. > > => 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 > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
