Re: IPv6 RA vs DHCPv6 - The chosen one?

[Masataka Ohta <mohta () necom830 hpcl titech ac jp>]

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