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

[Ted Lemon <[e-mail]>]

Andrew, this is a really great analysis.  It would be nice if it could be turned into a draft.

Andrew Yourtchenko <[e-mail]> wrote:


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
_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops