Re: IPv6 RA vs DHCPv6 - The chosen one?

[TJ <trejrco () gmail com>]

2011/12/28 Masataka Ohta <mohta () necom830 hpcl titech ac jp>

> TJ wrote:
>
> > > However, assuming you change the cells every 100m in average
> > > and you are moving at 100km/h, you must change the cells every
> > > 3.6 seconds in average, which means you must be able to change
> > > the cells frequently, which means each cell change take a lot
> > > less than 3.6 seconds.
>
> > To me, that sounds like an argument in favor of SLAAC.  SLAAC is
> noticeably
> > faster in my experience than DHCP (v4 or v6).
>
> RA initiated DHCPv6 is slower than RA, of course.

I am not counting the "delay" caused by waiting for the RA against 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)?

Note that RA initiated DHCPv6 is even required to suffer from DAD delay.
> > Also, RAs can be sent in the ms range
>
> 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.  And regardless of the
specified interval setting, a node sending a RS and getting back a RA is
still faster than the 4-way (default) message (which may require relaying)
exchange required for DHCP ... In either case, yes, DAD "must" happen ...
although Optimistic DAD can help there, or perhaps other link specific
solutions.



> > Also:
> > Isn't 100m an arbitrarily tight range for a cel tower?
>
> Cell size must shrink as bandwidth requirements of mobile
> devices increase.

Understandable, but down to the 100m range?
*(Partially tongue in cheek pre-response to your next statement: And why
should they bother, if the users can just hop onto WiFi? :)   )*

> And for cellular, isn't the real churn happening more at the Layer2 side
> > ... no L3/IPv6/IPv4 interaction?
>
> Because of large amount of traffic caused by smart phones,
> mobile providers, at least those in Japan, are trying to
> bypass traffic from 3G to WLAN/Internet with IPv4 L3.

I applaud the apparent easy access to (open?) WiFi ... and the user
expecting that to work seemlessly, "at speed".


> Boot time, or anytime a change in network attachment point is detected ...
> > is that not sufficient?
>
> It is wrong to assume intervals between changes 6 seconds.

Again, IMHO, that has been addressed where relevant (IIRC, Cisco supports
down to advertising every 20ms; and solicited RAs happen 'as needed').  For
the enterprise side, even 6s is way too often and I believe most agree that
this aspect isn't a problem.


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.


/TJ