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

["Pascal Thubert (pthubert)" <[e-mail]>]

I can certainly sense the irony in asserting there’s such magic.

For instance, which magic makes it so that we would trust better DHCP(-PD) for handing a unique 16-bits word of prefix space as opposed to a unique 64bits word of IID space? In my book, that is effectively harder since you cannot rely for long on LRU to delay reassigning a previously assigned word, you get little help from entropy to cover for your mistakes and race conditions, etc….

Also, at the prefix level, we do not have DAD as the “ultimate” protection against our automated or manual assignment mistakes; routing is not deterred by duplication, it just sees 2 advertisements as alternate ways to get there. Which means that if a /64 is duplicated, packets will be delivered to the nearest of the 2 owners from the perspective of the source. Not a great benefit from the current situation.

So certainly you want to qualify when an idea such as a /64 or shorter for all applies particularly well (e.g. an event starting with a clean slate, with less connected devices in the public than available prefixes, and a clear end of time when all prefixes are released), and when it shows limits. Coming from the very different ground of IoT, and though I am quite convinced by that particular idea, I do not believe in a one-fits-it-all solution.

I’d really love to see a draft that documents a set of reference models (profiles?) to help our users deploy an IPv6 campus network that meets their expectations. Routing to the /64 is definitely a great one.

We have some others in the IOT space to serve different use cases involving very long term deployments, large numbers of devices, dotting line state of connectivity, mobility, and drastically limited capability to do complex stuff such as IPv6 renumbering.  To serve such use cases, we are effectively specifying ND operation and proxy. I do not see that as competition to the /64 approach. It is in fact following the common idea to reintroduce some routing when we hit the limits of bridging.

This has consequences. As we get rid of the illusion of the free and spanning broadcast domain, we need to reconsider how we apply protocols that used to rely on L2 broadcast. I expect to see more and more proxies showing up, like those on the works for ND or DNS SD.

All in all, I fully agree on the fundamentals beneath what you’re saying, that routing must be reintroduced at the borders of L2 networks when the L2 capabilities are so widely different that bridging would fail to provide the expected L2 services end-to-end, typically broadcast. We have opened the Pandora Box, illusions are dissolving, and solutions are emerging. Great stuff.

Take care,

Pascal


From: Ole Troan [mailto:[e-mail]]
Sent: dimanche 16 juillet 2017 10:48
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: Nick Hilliard <[e-mail]>; [e-mail]
Subject: 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) <[e-mail]<mailto:[e-mail]>> 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<https://fr.m.wiktionary.org/w/index.php?title=if_you_want_a_thing_done_well,_do_it_yourself&action=edit&redlink=1>

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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------