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

[Lorenzo Colitti <[e-mail]>]

Andrew, those are good points, though from the perspective of protocol
design I think semantics and functionality are a bit more important than
performance. Once you have the semantics right you can look at improving
performance (e.g., via QoS, prioritization, queue isolation, etc. etc.),
but if the semantics are wrong it's hard to fix that.

So, semantics I think you forgot:

1. DHCPv6 makes it very hard to update client information from the network
side.

You can use reconfigure, but that requires authentication (clients MUST
discard reconfigure messages that aren't authenticated). I don't know if
anyone actually implements authentication. Also, it requires that the
server know the DUID of the client. How do you do this if the client has
never talked to you before, (e.g., if you booted after the client)? You'd
have to have all the DHCPv6 servers on link communicate with each other.

Also, it's not clear to me how you would implement reconfigure in a
stateless environment, since the server doesn't know which clients are
still there and not all clients (none?) implement RFC 4242.

For an example of why this is useful, consider a homenet. You have two
routers on the same link that share state via a routing protocol. Router A
is unplugged. Router B knows this and wants to tell the client "don't use
router A as DNS server any more". How do you do this? Using an RA you can
just send out a message with a lifetime of zero. How do you do it with
DHCPv6?


2. DHCPv6 doesn't support multiple sources of information.

In particular, stateful DHCPv6 requires that the client choose one of the
advertise messages it receives. The spec doesn't prevent it from starting a
new transaction with a transaction ID, but I don't know what the original
server would do if it received such a message. The RFC doesn't seem to
specify this very well, if at all.


3. You can do per-client configuration using RA as well.

There's nothing preventing routers from replying to RS packets with unicast
RAs, so per-client configuration is possible. There's also nothing stopping
you from causing an RS to trigger a provisioning (e.g., radius) request to
a server asking for configuration parameters for that client - for example,
giving it its own VLAN and its own /64. (I've built networks that do this,
so I know it works). So your "it's not possible to jump" assertion is not
entirely true. It's true that RAs can't jump by themselves, but the
information requests can.


I'm also don't think the "multicast doesn't work in congested networks"
argument is valid. In a network where multicast is so overloaded that it's
completely broken, it's not just RAs that will fail. NSes will get dropped
too; MDNS won't work; basically, the network is broken. That said, unicast
RAs don't have this problem.

I'd be happy to contribute to a draft documenting these issues. Andrew,
were you going to start one?


On Tue, Oct 29, 2013 at 4:17 AM, 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<https://www.ietf.org/mailman/listinfo/v6ops>
>