mailing list archives
Re: IPv6 RA vs DHCPv6 - The chosen one?
From: Masataka Ohta <mohta () necom830 hpcl titech ac jp>
Date: Thu, 29 Dec 2011 13:50:52 +0900
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
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
or perhaps other link specific solutions.
A link specific solution is DHCPv6 without RA.
Cell size must shrink as bandwidth requirements of mobile
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"
So, if we give up the goal to have "IPv6 over Foo", there is
no reason to insist on "ND uber Alles".
Re: IPv6 RA vs DHCPv6 - The chosen one? Glen Kent (Dec 20)
Re: IPv6 RA vs DHCPv6 - The chosen one? Ray Soucy (Dec 21)
Re: IPv6 RA vs DHCPv6 - The chosen one? Kevin Loch (Dec 22)