[Roll] draft-thubert-6man-ipv6-over-wireless-06.html -- only you can help stamp out low-speed broadcasts

[Michael Richardson <[e-mail]>]

I hope the reply-to: [e-mail] might survive, but I ask you to verify
when you Reply-All that it goes to that list only.

In https://www.ietf.org/id/draft-thubert-6man-ipv6-over-wireless-06.html
Pascal Thubert provides a well written survey explanation of the challenges
of ND across a wide variety of mesh-under network topologies.

Normally, I think of "mesh-under" to be technologies like 802.15.10,
but in reading it realize that the entire pantheon of 802 technologies
after 10base5 [Big Yellow Coax Cable-1] and 10base2 [Small Grey Coax Cable-2],
actually fall into the category of "mesh-under".

35 years of what I like to call "stupid layer-2 tricks".
 ... They all seemed to make sense at the time
          (to paraphase Douglas Adams's Arthur Dent).


Specifically, they were tricks because IPv4 gave us such pathetic subnet
limitations, and broadcast emulation was costing more and more bandwidth.
We have extensive broadcast mitigation techniques in IPv6.
We use of various multicast groups such that, given we had a
[Big-Yellow-Coax-Cable], we can push multicast filters down into hardware and
avoid waking that overworked Sun-2 20Mhz 68020 CPU for stupid things.
The reality today is that none of that matters: the host registers the
multicast groups it cares about with the switch using MLD, we hope the IGMPv6
snooping works
(I have a closet where IPv6 ND is broken, I think because it isn't working,
and I can't get in due to lockdown rules to investigate in person.  IPv6-LL
works, btw...)

What I'm trying to say is that the model we have about the physical network
has been wrong for 25 to 30 years now.  Yet, we continue to design networks
as if that model is correct, and the folks over at IEEE continue to try to
emulate things.  It's a deadly embrace in which neither party has the guts to
point out that whatever clothing the emperor thinks they are wearing are not
in fact the ones we observe.

Now, in homenet we have talked about putting /128s into our visible and
debuggable routing protocol, vs putting (to-be-randomized) /48 L2 addresses
into the invisible L2 "switching" protocol.
The /128 routing was deemed "too complex" by some, who are somehow content to
do exactly the same thing at L2 using hardware implementations that can't be
upgraded... ever.

We have all sorts of mechanisms to deal with discovery across multiple
networks, given that the wired and wifi networks are bridged, yet half the
devices can see both at the same time.

In ROLL, we have the /128s in the routing protocol, and some profiles have
adopted RFC8505, but not all yet.  So, we got halfway there, but yet all the
way.

So, please read Pascal's draft.   It sat open in a tab on my desktop for too long.
It's a very nice and educational survey.

I am not quite sure what the actionable item in it is yet.
I don't know what 6man should do exactly about it.
It's not yet a loud call to action.

The draft hints that using RFC8505 more is a good idea, but I'm not sure it
actually says this.

To my mind, the question is really about deployment.
If Cisco enterprise class APs supported RFC8505 would any wifi client devices
consider supporting it?  Is there a killer application that makes it worth
it?  Maybe in warehouse/logistics situations. I don't know exactly where it
might take off.

Maybe it can be shown that it helps avoiding dropped packets when roaming
among APs within an Enterprise.  Is there some other situation?

Can routing IPv6 /128s that have mapped IPv4 in them keep all the IPv4 ARP
multicast traffic away from the wireless media?


[Big Yellow Coax Cable-1] https://en.wikipedia.org/wiki/Vampire_tap#/media/File:VampireTap.jpg
                          https://en.wikipedia.org/wiki/10BASE5
[Small Grey Coax Cable-2] https://en.wikipedia.org/wiki/10BASE2

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide