Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

[Andrew Yourtchenko <[e-mail]>]

On Thu, 24 Oct 2013, Ted Lemon wrote:

> Anyway, that's the rhetorical position I'm going to stake out for now. 
> I'm curious to see if anybody can come up with a reason to disagree that 
> doesn't simplify to either "I hate RA" or "I hate DHCP."

I'll take a shot at outlining the differences as I see them between the 
two, and the factors that may influence the "I hate RA" or "I hate DHCP" 
reply in each particular case...

1) Interworking with different L2 topologies

RA is "server-initiated, send once, receive many, no confirmation" 
abstraction - something that works well on the 10base2-type shared bus 
and even the today's wired ethernet, but looks quite miserable on the 
WiFi media without the ugly special tricks (802.11 provides reliable 
delivery for unicast frames, and does not provide one for multicast 
frames, also the physical speeds are different and even the contention 
management and the speed/modulation can be different as well).

DHCPv6 is "client-initiated, send once, receive once, confirmation" 
abstraction. This may be wasteful on the low-bandwidth links that provide 
bus topology, but maps extremely well onto scenarios like WiFi - as it 
allows to maintain somewhat familiar mode of operation to wired ethernet.

This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - 
on a crowded large-scale WiFi, without dirty tricks, you simply will not 
get the SLAAC working because the multicast RAs will get crunched by the 
interference.

Alternatively, in a very mobile environment and the RFC-compliant router, 
multicast solicited RAs might make a significant portion of your traffic - 
which, due to a difference in modulation, etc. may eat way more bandwidth 
than if they were sent unicast.

2) Acknowledged vs. unacknowledged

DHCPv6 needs at least 2 packets. RA is just one packet.

RA Plus: RA is quicker

RA Minus: you have to take care that it is legitimate router and not your 
evil neighbor sending you the RAs you take the configuration from.

DHCPv6 Plus: works well in the noisy/lossy environments

DHCPv6 minus: takes at least 1 RTT to the server.


3) Client initiated vs. server initiated

Despite of the division above, RA can be client-initiated, to some extent, 
with RS, and DHCPv6 can be server-initiated, to some extent, with 
"Reconfigure" messages.

If we treat these as "nudge" messages, the behavior of the sending 
and receiving parties is similar - the "nudge" message 
causes the orderly protocol exchange to occur before the due time.

The part that is different, though, is that RA, due to its "send once, 
receive many" nature, can aggregate the "nudge" messages, so intuitively 
seems best for a scenario with a very large number of the hosts, as it 
should have self-stabilizing properties, compared to DHCPv6.

This "self-stabilizing" property intuitively seems to make RA safer to 
use, IFF it is used in purely "multicast" fashion.
However, refer to (1) for the interaction with the underlying media.

4) Centralized coordination vs. distributed coordination

RA, due to its "send once, receive many" nature, in its pure 
form necessarily can not dictate a per-client settings, but rather 
can only advise the domain the client would pick from (SLAAC).

DHCPv6 on the other hand, due to its p2p nature is by default well suited 
for the individual per-client tweaking.

The distributed nature can be a blessing if you do not care about who gets 
which address and a curse if you need to account everyone strictly.

NB: address assignment does not mean that the hosts will always use those 
addresses - e.g. it's perfectly possible to statically configure a 
different address, but we talk just homogenous standards-compliant 
well-behaved hosts for simplicity sake).

That's why I do not use the word "control" but use the word 
"coordination".

5) Involvement or not into routing

RAs are a mechanism to provide some form of reliability for the routing in 
an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was 
specifically denied any involvement in the routing.

While architecturally "pure", the reliability and timing of the routing 
resiliency provided by the RAs is far below those achieved by FHRP 
protocols which are used in today's networks predominantly.

This might create a dissonance between those who want to ensure RAs are 
used for routing, and those who do not see any use of them in that regard - 
with the corresponding contention of adding anything routing-related into 
DHCPv6.


6) Server locality

Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 
has a means to "jump" over multiple hops by use of the relays. This means 
RA *has* to be distributed, while DHCPv6 can be both centralized and 
distributed. Frequently it is made centralized because of other benefits 
that centralized administration brings, but almost any router today can 
run a DHCPv6 server on the box with no problem.

7) Programming: UDP vs. ICMP

For a random programmer today, coding a server to receive the data on a 
UDP socket is a more familiar exercise than working with ICMP. 
Disclaimer: the value of "random" was chosen to be "me" for arbitrary 
reasons. This point is more of a rathole and a personal preference, 
probably. I think I remember Dave Thaler saying one of the mechanisms in 
Windows was way easier to extend than the other, but I do not remember 
which.

8) Separate vs. unified management

If DHCPv4 and routing is managed by the different groups in the 
organization, then conceivably the "server" people will not like to have 
their work go away and similarly "router" guys are happy to get rid of yet 
another point of coordination and argument. This is where the "I hate 
$protocol" should definitely pop up. Add here the concerns from the 
previous 7 points.

HTH.


--a