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

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

----- Original Message -----
> From: Bernie Volz (volz) <[e-mail]>
> To: Owen DeLong <[e-mail]>
> Cc: Mark ZZZ Smith <[e-mail]>; Andrew Yourtchenko (ayourtch) <[e-mail]>; "[e-mail]" <[e-mail]>
> Sent: Saturday, 7 December 2013 1:25 PM
> Subject: RE: [v6ops] New Version Notification for	draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 
> 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.
> 

As a router would have knowledge of the hosts it has sent unicast RAs to via its neighbor cache, for the purposes of NUD, a router could periodically unicast RAs directly to the individual hosts.


Regards,
Mark.


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