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

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

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

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

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