> => 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.
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 > advertised (or not) as an input to the movement detection > 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 > 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. 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. > > 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. What problem. You don't like the ND R bit? > 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 ? 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. > > > 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. 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. > > I think we cannot and must not overrule the essential > > meaning of the A and M bits. > > => Agreed. We won't do that. Good. > > > > > 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. 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
