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

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Oct 2020 11:39:50 -0400

I hope the reply-to: [email-masked] 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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 1 Oct 2020 18:45:20 +0000

Multicast is definitely the big problem for any wireless, especially if wireless is advanced (beam forming, different modulation for different distance)

I like the decision that should be centralized repository for all IP/MAC bindings. Pascal calls it "proactive address registration".
It is not the big restriction: any practical network has some network device that could play this role.
Distributed nature of Classic ND does create a lot of complexity that in my view does not have enough justification.

It looks interesting proposition that L2 should inform hosts about MAC address of at least one L3 that could manage the rest.
It is proposed in the relation to IEEE Std. 802.11 OCB.
It could eliminate multicast completely. Else at least router broadcast should be visible.
I am not sure that this new radical requirement to any L2 make sense to introduce. But it would be good if...

Routing inside subnet (or 2 layers structure for L2 in general) looks as excessive complexity. Pascal calls it "Multi-link subnets".
It was probably inspired by the desire to create big L2 domains to simplify L2 roaming.
It looks like 1 additional Mobile IP story: keep permanent IP address for roaming host.
Why EVPN was not possible to use? Over plain IP routed infrastructure.
IMHO: could be easily detached as the separate solution. It needs a deep dive to say: is it better than EVPN, Mobile IP, LISP, AERO, etc.
PS: Hub-and-spoke was possible to signal by some flag L, means: router is the forwarder, would redirect if possible. 2 layer structure was not needed for that.

/Ed
> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: 1 октября 2020 г. 18:40
> To: man <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: draft-thubert-6man-ipv6-over-wireless-06.html -- only you can help
> stamp out low-speed broadcasts
> 
> 
> I hope the reply-to: [email-masked] might survive, but I ask you to verify when
> you Reply-All that it goes to that list only.
> 
> 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".
> 
> 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.
> 
> 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.
> 
> adopted RFC8505, but not all yet.  So, we got halfway there, but yet all the way.
> 
> 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.
> 
> [Big Yellow Coax Cable-1]
> https://en.wikipedia.org/wiki/Vampire_tap#/media/File:VampireTap.jpg

---

From: Mark Smith <[email-masked]>
Date: Fri, 2 Oct 2020 09:19:03 +1000

On Fri, 2 Oct 2020, 04:46 Vasilenko Eduard, <[email-masked]>
wrote:

> Multicast is definitely the big problem for any wireless, especially if
> wireless is advanced (beam forming, different modulation for different
> distance)
>
> I like the decision that should be centralized repository for all IP/MAC
> bindings. Pascal calls it "proactive address registration".
> Distributed nature of Classic ND does create a lot of complexity that in
> my view does not have enough justification.
>

A central and stateful allocation device is a single point of failure.

To mitigate that, that you need to come up with a state synchronisation
mechanism between multiple allocation devices, as well as a fail over
mechanism. You can also have scaling issues because all of the hosts rely
on the performance of one or two central devices.

See the OSPF database synchronisation mechanism as an example of the
complexity involved.

Complexity is unavoidable regardless of how you do it, you just have to
choose where to put it - in all of the hosts, that only impact themselves
when they fail, or in a few central devices that will impact all hosts in
some way when one fails.

SLAAC avoids some of this complexity by limiting the state to within the
hosts themselves ('stateless' in the name is about not having to maintain a
stateful address database), and therefore doesn't need to have a state
synchronisation mechanism between any devices.

> It looks interesting proposition that L2 should inform hosts about MAC
> address of at least one L3 that could manage the rest.
> Routing inside subnet (or 2 layers structure for L2 in general) looks as
> excessive complexity. Pascal calls it "Multi-link subnets".
> IMHO: could be easily detached as the separate solution. It needs a deep
> dive to say: is it better than EVPN, Mobile IP, LISP, AERO, etc.
> PS: Hub-and-spoke was possible to signal by some flag L, means: router is
> the forwarder, would redirect if possible. 2 layer structure was not needed
> for that.
>
> /Ed
> [Big-Yellow-Coax-
> multicast
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 2 Oct 2020 07:16:05 +0000

Hi Mark,
It is not mandatory to do synchronization between routers. I do agree that state replication is the complexity. It is less than really distributed architecture (like ND has now), but still too much that it should be for address resolution protocol.
KISS.
It is possible to ask hosts to teach all routers that are visible. It would be the same procedure, does not matter how many routers are on the link.
Eduard
From: Mark Smith [mailto:[email-masked]]
Sent: 2 октября 2020 г. 2:19
To: Vasilenko Eduard <[email-masked]>
Cc: man <[email-masked]>
Subject: Re: draft-thubert-6man-ipv6-over-wireless-06.html -- only you can help stamp out low-speed broadcasts

On Fri, 2 Oct 2020, 04:46 Vasilenko Eduard, <[email-masked]<mailto:[email-masked]>> wrote:
Multicast is definitely the big problem for any wireless, especially if wireless is advanced (beam forming, different modulation for different distance)

To mitigate that, that you need to come up with a state synchronisation mechanism between multiple allocation devices, as well as a fail over mechanism. You can also have scaling issues because all of the hosts rely on the performance of one or two central devices.

See the OSPF database synchronisation mechanism as an example of the complexity involved.

Complexity is unavoidable regardless of how you do it, you just have to choose where to put it - in all of the hosts, that only impact themselves when they fail, or in a few central devices that will impact all hosts in some way when one fails.

SLAAC avoids some of this complexity by limiting the state to within the hosts themselves ('stateless' in the name is about not having to maintain a stateful address database), and therefore doesn't need to have a state synchronisation mechanism between any devices.

/Ed
> From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Michael Richardson
> To: man <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> I hope the reply-to: [email-masked]<mailto:[email-masked]> might survive, but I ask you to verify when
> Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------