I hope the reply-to: 6...@ietf.org 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
