On 2005-10-31, Christian Vogt wrote: > > ...there was consensus on the IPv6 mailing list [1] not to include any > specific support for mobility into the successors to RFC2461/2462. At > least, this was said in the context of delays imposed on MLD Report > transmissions. > > (Note: IMO, this is a bit of a bummer, [...]
Agreed! > because RFC2461bis already > explicitly allows mobile nodes to forego the delay for Router > Solicitations; see section 6.3.7 in RFC2461bis. So it could > theoretically include an equivilant passage for the MLD Report, too. > Anyway...) ... and I was kind of hoping it was going to, if only, as you point out, for consistency. > Instead, the discussion in [1] yielded that mobility optimizations ought > to be specified in separate documents. And thinking about this, > draft-ietf-ipv6-optimistic-dad-06.txt is actually one such document. So > it could/should allow Optimistic Nodes to forego the delays defined in > RFC2461[bis] or RFC2462[bis] where necessary and feasible. Sure, I'd be happy to explicitly talk about it in OptiDAD if it's not going to be mentioned elsewhere. > it is RECOMMENDED that the Optimistic Node omit such delays if > sufficient means for de-synchronization are provided otherwise. E.g., a > mobile node can omit delaying the first message sent upon arrival at a > new link [RFC2461] [RFC2462] because mobility generally serves to > de-synchronize signaling to an appropriate extent already. Care must be > taken, however, not to confuse an initial link attachment after boot-up > with a link attachment after movement." Ah, now, this is pushing the scope of OptiDAD, I feel. Just as it has proven tricky to be sure if an address is "manually assigned" vs. assigned by a higher layer (or a script, or something), I think it'll be hard for our poor IPv6 stack to make this call. This whole desyncronised handovers thing is what I was talking about with Hard/Soft handovers ... not sure who that idea came from originally, mind you, or if it's been written up before or since. Does the DNA stuff cover this? If there's sufficient interest from IPv6 WG I guess we could write it up as a separate draft ... Sadly, it looks like I won't make Vancouver either. On the offchance that anyone's disappointed by this, they should contact me with job offers (or handfuls of cash, either will do :-) ). -----N -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
