Home page logo

nanog logo nanog mailing list archives

Re: IPv6 RA vs DHCPv6 - The chosen one?
From: TJ <trejrco () gmail com>
Date: Wed, 28 Dec 2011 20:45:29 -0500

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
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

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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]