Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

[Owen DeLong <[e-mail]>]

I see unicast RAs from time to time on my network. Haven't delved too deeply into whether they come from the Juniper, Mikrotik, Linux, or all three.

Sorry, I stopped using $C here years ago because the power and cooling were getting out of hand compared to what I could do with much cheaper $M and $J boxes.

(This is my home network, 2620:0:930::/48. I'm not speaking of or for $DAYJOB at the moment).

Is a link-local multicast on WiFi implemented as multiple unicasts for some reason? If not, then I can't imagine it would be any worse than ARP.

Owen

On Dec 6, 2013, at 18:25 , Bernie Volz (volz) <[e-mail]> wrote:

> Yes, I am aware of that - unicast RA from the router to the client is available. Just isn't clear now often it is used.
> 
> But, this doesn't address the periodic RAs normally sent by routers as those are multicast.
> 
> - Bernie
> 
> -----Original Message-----
> From: Owen DeLong [mailto:[e-mail]] 
> Sent: Friday, December 06, 2013 9:07 PM
> To: Bernie Volz (volz)
> Cc: Mark ZZZ Smith; Andrew Yourtchenko (ayourtch); [e-mail]
> Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 
> 
> On Dec 6, 2013, at 17:25 , Bernie Volz (volz) <[e-mail]> wrote:
> 
>> Mark:
>> 
>> The difference between DHCPv6 and RA multicast is the direction.
>> 
>> DHCPv6 multicast is client to server (or relay). This has far fewer problems in some networks because the first hop is typically on the wired portion of the network (and the destination multicast address is usually just joined by a few devices (relays and servers) - not all).
> 
> You should study RA a little better.
> 
>> 
>> RA multicast is router to client(s). This has problems in distributing the traffic out to all of the clients over some networks.
> 
> 
> Only some RA is done this way.
> 
> Clients starting up (and/or a client whose address is close to its lifetime) send an RS message to a multicast group joined by only a few. There are no "hops" because this is all link-local communication.
> 
> Routers then respond either with a multicast or a unicast RA.
> 
> As such, I think this provides at least the same reliability as DHCPv6 per your comments above, while also providing the additional robustness you already attributed to all-hosts-multicast periodic RAs from the routers.
> 
> Owen
> 
>> 
>> - Bernie
>> 
>> -----Original Message-----
>> From: v6ops [mailto:[e-mail]] On Behalf Of Mark ZZZ 
>> Smith
>> Sent: Friday, December 06, 2013 8:01 PM
>> To: Andrew Yourtchenko (ayourtch)
>> Cc: [e-mail]
>> Subject: Re: [v6ops] New Version Notification for 
>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
>> 
>> 
>> ----- Original Message -----
>>> From: Andrew Yourtchenko <[e-mail]>
>>> To: Mark ZZZ Smith <[e-mail]>
>>> Cc: "[e-mail]" <[e-mail]>
>>> Sent: Saturday, 7 December 2013 3:34 AM
>>> Subject: Re: [v6ops] New Version Notification for 
>>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
>>> 
>>> Hi Mark,
>>> 
>>> On Thu, 5 Dec 2013, Mark ZZZ Smith wrote:
>>> 
>>>>  Hi,
>>>> 
>>>>  Some criticisms/comments/questions on these pieces of text 
>>>> relating to
>>> layer 2/wifi multicast reliablity:
>>>> 
>>>>  "This is where the peer-to-peer, acknowledged nature of DHCPv6 may 
>>>> be
>>>>  beneficial - on a crowded large-scale WiFi, without special tricks 
>>>> to  ensure the reliable delivery of multicast packets, you simply 
>>>> will not  get the SLAAC working because the multicast RAs will get 
>>>> crunched by the  interference."
>>>>  I'd think that if multicast is unreliable enough to cause RAs to 
>>>> fail  to be delivered often enough, then anything which relies on 
>>>> multicast  traffic is also likely to fail, which would include neighbor discovery.
>>>> So regardless of if RAs were replaced with DHCPv6, the link is not 
>>>> going  to provide reliable IPv6 operation, because IPv6 addresses 
>>>> cannot be  reliably resolved to layer 2 addresses.
>>>> 
>>>>  MLD would probably fail too, so any routed multicast applications, 
>>>> even  low bandwidth ones, wouldn't work either, as would MLD 
>>>> snooping based  layer 2 forwarding optimisation.
>>>> 
>>>>  DHCPv6 uses multicast for DHCPv6 server/relay discovery, so that 
>>>> will
>>> probably be unreliable as well.
>>>> 
>>>>  I don't think broadcasts on wifi are reliable, so IPv4 ARP would 
>>>> be
>>> failing too.
>>>> 
>>>>  So if RAs are failing because of not reliable enough multicast 
>>>> then that is just one symptom of the link being overloaded, and 
>>>> there will be  others.
>>> 
>>> I think I capture several points here, tell me if I get them correctly:
>>> 
>>> 1) There are other protocols that use multicast that will fail.
>> 
>> Yes. 
>> 
>>> 2) Fix your link.
>>> 
>>> for (1): RA is probably the only one that does not incorporate a 
>>> robust retransmit mechanism.
>>> 
>> 
>> In the case of multicast RAs there are two independent reliability mechanisms used, one router side, one host side.
>> 
>> Firstly, the router lifetime in the RA is to be set to AdvDefaultLifetime or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), meaning that for a host to lose knowledge of a router it has to miss 3 unsolicited multicast RAs in a row.
>> 
>> Secondly, hosts retransmit their RSes multiple times (RFC4861, 6.3.7).
>> 
>> I'd argue that DHCPv6, neighbor discovery and MLD are less robust, as they only implement the second mechanism. For DHCPv6, neighbor discovery and MLD to be as robust as RAs, the DHCPv6 server and the hosts would have to also issue periodically unsolicited announcements of themselves so that other hosts and routers don't have to solicit for them, unless they have no existing knowledge of them.
>> 
>> (Should we add the ES-IS neighbor discovery model to IPv6 ND to make it more robust? ES-IS has hosts periodically multicast their presence to the link's routers, routers periodically multicast their presence to the hosts, hosts default to sending to their routers for all destinations, then routers sends a redirects to a host when the destination host is on the same link.).
>> 
>> 
>>> for (2): It's great if you can, but I'd like to have protocol work in 
>>> all conditions.
>> 
>> That sound to me like an assertion that DHCPv6 is going to work in all conditions. Given that DHCPv6 server discovery is less reliable than RAs (because of the lack of unsolicited DHCPv6 server advertisements), how is moving RA functions into DHCPv6 going to make DHCPv6 more reliable than RAs?
>> 
>>> Especially that legacy IP does look more robust.
>> 
>>> 
>> 
>> So I'm curious why legacy IP is supposedly more robust? IPv4 uses broadcasts for ARP and DHCP server discovery. On these links where IPv4 "looks more robust" than IPv6, are broadcasts provided more reliable delivery than multicasts, in particular as broadcasts must be flooded to all hosts, where as multicasts can have their flooding scope limited using MLD snooping?
>> 
>> 
>>> 
>>>>  One idea I've had for this sort of scenario would be for the link 
>>>> to operate as mostly an IPv6 over NBMA segment. The only multicasts 
>>>> on the  link are RAs, providing the necessary NBMA operation parameters.
>>>> It of  course would require changes to clients and routers, but then 
>>>> again, so  would using DHCPv6 for what RAs are used for today.
>>> 
>>> You can do this with no changes today.
>>> 
>>> Block traffic between the hosts (similar to private vlan), advertise 
>>> prefixes as off-link, send all the traffic via the router on the 
>>> wired side, block all the inbound ND from hosts except for the RS and 
>>> NS sent to solicited node address of the router + destined to the router.
>>> 
>>> I tested this, it works like a charm - at least for the strawman 
>>> browsing scenario.
>>> 
>> 
>> Right, and doing that would solve the multicast capacity exhaustion problems that would effect RA multicasts (and DHCPv6, ND and MLD multicasts), because it is a more extreme case of constraining where multicasts are sent than MLD snooping.
>> 
>> My Broadcast Multi-Access (BMA) link operating as NBMA suggestion wouldn't require both having available and enabling any link-layer special features to achieve the goal of significantly reducing multicast traffic. 
>> 
>> (Thinking about it, the recent Efficient ND proposal is perhaps a 
>> special case of operating a BMA link as an NBMA link for the Neighbor 
>> Discovery protocol. I'm starting to wonder if it might be better to 
>> just adopt this complete NBMA model over a BMA link and eliminate all 
>> link-layer multicasts (ND, DHCPv6, MLD), except RAs to announce the 
>> BMA link is operating in NBMA mode. The only multicasts would be 
>> unsolicited RAs, which, for a single router, could be only once every 
>> 30 minutes (15 minutes for two routers). I'd think that sort of 
>> interval would be adequate to address the concerns of multicasts 
>> consuming mobile device battery life.)
>> 
>> 
>>>> 
>>>>  "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."
>>>> 
>>>>  The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a 
>>>> link  can't handle 1 multicast every few seconds, it's also past the 
>>>> point
>>> of
>>>> it's capacity (and as above, other multicast/broadcast would also be 
>>>> contributing to exceeding link capacity.)
>>> 
>>> Modulation. Your multicast packets may take in the most extreme case 
>>> 54x time more airtime than a unicast. This means 54x more probability 
>>> it will be dropped. Also, forget the home wireless with one AP. Now 
>>> imagine
>>> 300-500 APs having to send these packets. You have 3 frequencies on 
>>> 2.4Ghz spectrum that you can use. So remembering that the whole 
>>> construct is 3D, you are *bound* to have some interference.
>>> 
>> 
>> Are all of those 300-500 APs in a single broadcast/multicast domain i.e., one large link? That's convenient, but if multicasts/broadcasts aren't reliable enough, that suggests the link capacity is exhausted. Dividing the link up using routers to reduce multicast/broadcasts is and has been the common solution since broadcast multiaccess links were invented (which I think would be since around late 1970s when Ethernet was invented).
>> 
>> Moving to an NBMA model by effectively modelling the BMA link as a full mesh of virtual point-to-point links would probably be an alternative method of overcoming multicast/broadcast capacity limitations.
>> 
>>> So, it can be quite delicate in the most extreme cases.
>>> 
>>> And again, I want the protocol to be deployable in the most extreme 
>>> cases
>>> - especially when legacy IP survives them fine.
>>> 
>> 
>> How does it? Legacy IP uses broadcasts. 
>> 
>>> Yes, not everyone will have them.
>>> 
>>> But dismissing those cases just because they do not apply to one's 
>>> environment is incorrect.
>>> 
>>> And this is to me the whole point of the argument, which I would like 
>>> to get back to, instead of trying to argue about the details:
>>> 
>>> Yes, RA-only operation is *fantastic* for some circumstances. I love 
>>> it myself and do it whenever I can because this allows me to avoid 
>>> doing boring work.
>>> 
>>> But I may be forced to do DHCPv6. For any of the reasons already 
>>> present in the draft, pick one. And this means I am forced to do also 
>>> RA, which is a pain.
>>> 
>> 
>> So the objections I have are,
>> 
>> - I don't see how anything in DHCPv6 makes it dramatically more reliable than RAs, given that it too uses multicasts for DHCPv6 server discovery. Adding RA functions into DHCPv6 is described or asserted to be the panacea to all issues that RAs could suffer from, yet analysis shows it isn't.
>> 
>> - I think it would be better to incrementally tune and optimise the 
>> existing designed, standardised, code developed, code debugged and 
>> widely deployed mechanism (RAs) to overcome corner cases, and/or to 
>> adopt past developed methods such as IPv6 over NBMA, than to spend the 
>> next 5 to 10 years waiting for the design, standardisation, code 
>> development, code debugging and widespread deployment of RA functions 
>> to be incorporated into DHCPv6, and then also have to develop methods 
>> of conflict resolution when RAs and DHCPv6 options disagree (because 
>> they will, unless you don't plan to transition to DHCPv6 only until 
>> DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions will 
>> have to co-exist on a link for many years if you can't demand or 
>> guarantee DHCPv6 RA functionality from the host implementations.)
>> 
>> - Using DHCPv6 for RA functionality won't eliminate one of the supposed causes of RA unreliability - multicast unreliability. All of DHCPv6, neighbor discovery and MLD would have to be made more robust against multicast unreliability to truly solve that problem.
>> 
>> - I'm for a single method that works adequately. DHCPv6 with RA options would probably qualify if we didn't already have a existing method. Existing methods that work are always better than non-existent ones that need to be developed, tested and ubiquitously deployed before they become significantly useful and can be assumed to be available.
>> 
>> 
>>> I think the large part of the tussle comes from the people wanting to 
>>> make the functionality of the RA/DHCPv6 more symmetric and being told 
>>> "no".
>>> 
>> 
>> The thing they need to demonstrate is that the costs of deploying a new and second mechanism that is near functionally equivalent to the first is worth the benefits. Given that the costs of developing and deploying RAs has already been paid, I think the benefits of using DHCPv6 for RA functions have to be very significant before the price should be paid. The benefits of DHCPv6 for RA functions now needs to be compelling. I don't think they are, otherwise I'd be quite happy to advocate for DHCPv6 for RA functions.
>> 
>> 
>>> And if we then tell them "Either use RA or no IPv6 for you" they say
>> 
>>> "fine, I choose no IPv6". And keep stacking on these NATs to support 
>>> devices that "do not support IPv6" in that circumstances.
>>> 
>> 
>> I don't think RAs are the single reason some people are resisting deploying IPv6 at all. I think some people are resisting deploying IPv6 because it needs to do one or both of two things for them - solve a foreseeable problem that will effect them, or provide a tangible benefit. If it won't do either of those things, then they don't currently see any value from the effort involved. What are foreseeable problems or tangible benefits is completely up to the perspective of the decision maker. Eventually they'll see value in it, and deploy it. In some cases, some people who could deploy IPv6 may never see any value in deploying it, so they never will.
>> 
>> There is no single answer to why people might resist deploying IPv6, no single solution, and things that motivate people to deploy or not IPv6 may have nothing to do with how IPv6 itself works.
>> 
>> 
>> 
>>> I think in this discussion are again getting into the argument of 
>>> "the best solution" instead of trying to collect the properties of 
>>> the RA and DHCP.
>>> 
>>> My position is that single best solution does not exist, because
>> 
>>> everyone's problems are slightly different. So, rather than preaching 
>>> for everyone to adopt the single solution which is the best in one 
>>> scenario and suboptimal in the other, we should be engineering a way 
>>> to be able to apply different solutions in different circumstances 
>>> without the overhead of double work.
>>> 
>> 
>> A single solution that solves most cases is better than two different, near functionally equivalent solutions that solve the same cases. Multiple near-equivalent solutions create more code, more bugs and then require conflict resolution mechanisms, creating even more code and more bugs, with very little actual benefit.
>> 
>> There are multiple ways of solving the neighbor discovery/router discovery/host parameter configuration problem (read Radia Perlman's "Interconnections" book as a starting point, and then perhaps "Inside Appletalk", and also look into Novell's IPX and Network Directory Services.). They all have different trade-offs, but fundamentally the trade-offs aren't significantly different or compelling. Yet because there are multiple methods to solve these problems, does that justify implementing all of them because they each have some minor benefits over the others, that different people might prefer?
>> 
>> Regards,
>> Mark.
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops