TJ wrote:
RA initiated DHCPv6 is slower than RA, of course.
I am not counting the "delay" caused by waiting for the RA against DHCPv6.
Do you count random delay between RA and DHCPv6 solicit? Do you count DAD delay after DHCPv6?
Isn't the stateless operation of a router providing a prefix in a RA always going to be faster than statefully providing an address via DHCPv6 (even with rapid commit enabling 2 messages to suffice; and noting that normally DHCPv6 involves 4 messages and relaying)?
As the stateless operation is actually stateful to keep address assignment states by all the related nodes, DAD is required to confirm the state is consistent, which means delay. With DHCP only, there is no DAD necessary.
Only when you are using mobile IPv6 and there still remains delay caused by DAD.
I would say that it is only possible on platforms that support it. You are not required to enable mobile anything in order to set the advertisement interval to be that tight.
Can I? I'm refering to RFC3775: One method which can provide for faster movement detection, is to increase the rate at which unsolicited Router Advertisements are sent. Mobile IPv6 relaxes this limit such that routers MAY send unsolicited multicast Router Advertisements more frequently. which is applicable only to MIPv6 routers.
In either case, yes, DAD "must" happen ... although Optimistic DAD can help there,
The straight forward solution is to remove DAD along with stateful SLAAC.
or perhaps other link specific solutions.
A link specific solution is DHCPv6 without RA.
Cell size must shrink as bandwidth requirements of mobile devices increase.
Understandable, but down to the 100m range?
It is also a typical range for WLAN.
*(Partially tongue in cheek pre-response to your next statement: And why should they bother, if the users can just hop onto WiFi? :) )*
Moving users should be able to keep hopping onto WLANs.
In general, ND is wrong to specify link specific timings assuming infrequent changes.
In principle I agree, but assumptions must be made somewhere or nothing can get done. If there is a change required to make it work, do so - the "IPv6 over Foo" RFCs are a good place to specify preferred values for $Foo.
The fundamental problem of ND is that it tries to be the only way to have IPv6 over all the possible link layers. Instead of having "IPv6 uber Alles", the wrong goal of "ND uber Alles" was targeted. So, if we give up the goal to have "IPv6 over Foo", there is no reason to insist on "ND uber Alles". Masataka Ohta