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

[Mark ZZZ Smith <[e-mail]>]

Hi,

A few other points:

- Rogue DHCPv6 servers are also a potential issue, so this sort of problem isn't exclusive to RAs. 

- DHCPv6 uses multicast for Information-Request messages for stateless DHCPv6 service and Solicit messages for stateful DHCPv6 service, so a link suffering from excessive multicast traffic drops may also prevent DHCPv6 working reliably or quickly.

I'm a bit confused by "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". My understanding is that Internet protocols of all types are to be designed with the assumption of the possibility of a low level of packet loss. If the packet loss is too high, then link-layer designers are advised to use link-layer reliability mechanisms, as per advised in RFC3819. I'm interested in details of the "ugly special tricks" if they're more than proprietary wifi link-layer multicast reliability mechanisms. 

General lack of Wifi multicast performance is the motive behind the following draft - replication and link-layer unicasting of unsolicited RAs could be used on Wifi to make them more reliable.

MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6
http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00



- "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 seems to suggest that you can't run VRRP/HSRP if you're using RAs. I don't think they're mutually exclusive, as long as the RAs come from the virtual router link-local address, rather than the routers' physical interface link-local addresses.

Regards,
Mark.


>________________________________
> From: Lorenzo Colitti <[e-mail]>
>To: Andrew Yourtchenko <[e-mail]> 
>Cc: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>; Ted Lemon <[e-mail]>; Ole Troan (otroan) <[e-mail]>; Dave Thaler <[e-mail]> 
>Sent: Tuesday, 29 October 2013 3:53 PM
>Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft:    draft-liu-bonica-v6ops-dhcpv6-slaac-problem
> 
>
>
>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
>>
>
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>