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

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

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