Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

Pascal,

Agree with all you're saying. 
The pragmatic solutions from our perspective is to treat the media as a set of point to point links with /64 to each host. Then all these problems of multicast, DAD etc magically disappear. 

Ole

> On 16 Jul 2017, at 08:58, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> I respectfully disagree.
> 
> There are a number of cases where an SDO designs on false assumptions of what the other is doing.
> 
> IPv6 ND expects that IEEE protocols can serve 2^24 Mulcair groups which enables DAD and discovery to be perfectly fine. ND also expects that the core service that 802.1 provides on Ethernet (reliable broadcast) extends to the whole ESS so we have our problems solved. Sadly, no such thing.
> 
> The same exists in the other direction as well. IEEE expects that the AP will implement a magical ND proxy and that solves the problem. Again, the IETF has no such thing, at least for ND. Some people at IEEE think that bridging 48bits address to 64bits addresses will enable bridging with all it's nice properties on 802.15.4 links. Good thing this illusion is dissolving rapidly.
> 
> The solution is probably to stop throwing our problems over the fence (thanks to Norm Finn for the quote). As they say, if_you_want_a_thing_done_well,_do_it_yourself
> 
> The solution is probably to understand the IEEE design of an ESS for L2 operations and emulate it at L3. A step towards reconciliation of the designs may be to effectively provide the proxy that the IEEE expects to see at the boundary of the mediums.
> 
> All the best,
> 
> Pascal
> 
> Le 16 juil. 2017 à 00:23, Nick Hilliard <nick@foobar.org> a écrit :
> 
>> Ole Troan wrote:
>>> This a protocol problem. DAD is built with the assumption that
>>> physical links are reliable. 20% packet loss for multicast is common
>>> on wifi...
>> 
>> most protocols will croak at 20% packet loss.  If wifi cannot support
>> multicast properly, then this is an 802.11 problem rather than a problem
>> with DAD or any of the many other bits of ipv6 that depend on moderately
>> reliable multicast.    
>> 
>> Nick
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------