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

[Andrew Yourtchenko <[e-mail]>]

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.
2) Fix your link.

for (1): RA is probably the only one that does not incorporate a robust 
retransmit mechanism.

for (2): It's great if you can, but I'd like to have protocol work in all 
conditions. Especially that legacy IP does look more robust.


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

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

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.

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.

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

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



>
> Regards,
> Mark.
>
>
>
>
>
>
>
>
>
>
> ----- Original Message -----
>> From: Andrew Yourtchenko <[e-mail]>
>> To: [e-mail]
>> Cc: 
>> Sent: Thursday, 28 November 2013 12:06 AM
>> Subject: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
>> 
>> Hello all,
>> 
>> Finally I managed to comb a little bit and finally submit the doc that 
>> aims to compare RAs with DHCPv6 which emerged from the discussion on this 
>> list a few weeks ago.
>> 
>> I'll be very happy to hear any comments, suggestions, flames, etc.
>> 
>> --a
>> 
>> 
> <snip>
>>
>