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

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

Hi Bernie,


----- Original Message -----
> From: Bernie Volz (volz) <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>; Andrew Yourtchenko (ayourtch) <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Sent: Saturday, 7 December 2013 12:25 PM
> Subject: RE: [v6ops] New Version Notification for	draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 
> Mark:
> 
> The difference between DHCPv6 and RA multicast is the direction.
> 

That's a good point.

> 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).
> 
> RA multicast is router to client(s). This has problems in distributing the 
> traffic out to all of the clients over some networks.
> 

I'd think in that case multicast RS / unicast RA response mechanism could be used. Perhaps the thing to tweak in RAs to better suit this scenario would be to change the default of responding to multicast RSes with a multicast RA to responding with a unicast RA, as allowed in 6.2.6 of RFC4861.


Thanks,
Mark.



> - 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
>