A straightforward transition plan (was: Re: V6 still not supported)

Fri Jan 13 06:50:55 UTC 2023

Hello Masataka-san

> When I mentioned a problem for the first time in IPng or IPv6 (I can't
> find any archive, are there any?) list, Christian Huitema mentioned it
> could be solved by ND over NBMA but the problem is not NB but broadcast
> of Wifi is unreliable.
> 
> As such, the solutions should be based on a fact that repeated
> unreliable broadcast is reliable.

Solutions must first avoid broadcast as much as possible, because there's also the cost of it. There's a scale where it hurts any network, and repeating them even more cannot be the answer.
And then, I agree with you completely, whatever is broadcast (e.g., beacons for initial discovery) is repeated and, not expected to be reliable.
This is in essence RFC 8505.
Then you want zerotrust, ND is so easy to attack from inside and even outside. This is RFC 8928.

> 	Reducing the speed at the physical (PHY) layer for
> 	broadcast transmissions can increase the reliability
> 
> longer packets mean more collision (with hidden terminals) probability
> and less reliability.

Agreed. The draft tries to look at all angles. It is certainly not pleading to use broadcast. It is pleading to deprecate ND because of its use of broadcast even on networks where it plain does not work. In practice today, DAD is a joke on any large wireless fabric and still you see all those broadcasts in the air. Save the planet! 

> >  So far we failed to get those RFCs implemented on the major stacks
> > for WiFi or Ethernet.
> 
> Ethernet? Even though its broadcast is reliable?

Ethernet is enterprise networks is largely virtualized. We cannot offer fast and reliable broadcast services on a worldwide overlay. 

If we filter BUM we end up with so-called "silent nodes" that are effectively disconnected. If we try and serve them broadcast storms are a visible penalty on the overlay.

Add to that the desire by the device to own more and more addresses. You end up in a situation where the devices thinks the own an address and are reachable at that address but in fact the network will not serve that address because 1) it missed the creation (a snooped DAD?), 2) it has forgotten about it, or 3) the max count of addresses that the network maintains per host is passed. Note that 3) may be reached because the network ignores that the host deprecated one of the addresses. 

You want a contract between that the host and the network that the host owns an address and is reachable at that address. Like any contract, that must be a negotiation. ND is not like that. RFC 8505 is exactly that. 

> It may be more constructive to work for proxy ARP suitable for Wifi,
> which may be enforced by Wifi alliance. An RFC may be published if Wifi
> industry request IETF to do so.

This is effectively done already for ND. 

The draft text in .11me recommends RFC 8929 as the ND proxy. 802.11md had it already since the Bangkok meeting but at the time of the freeze, RFC 8929 was still a draft and the text was removed at the last minute. RFC 8929 describes how RFC 8505 can be used buy the STA to negotiate a contract with the AP so the AP does ND proxy. Then the draft discusses how the AP represents the STA over the wired backbone, how mobility is handled, etc...

I guess the design can be easily retrofitted to ARP. ND is really designed exactly as ARP. The differences were for the show, the real steps that should have been made were not. But now with RFC 8505 we have a modern solution. The problem is no more on the standard side, it is adoption. People will not move if it does not hurt enough. And they can bear a lot.

All the best

Pascal 

> -----Original Message-----
> From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
> Sent: vendredi 13 janvier 2023 6:36
> To: Pascal Thubert (pthubert) <pthubert at cisco.com>; nanog at nanog.org
> Subject: Re: A straightforward transition plan (was: Re: V6 still not
> supported)
> 
> Pascal Thubert (pthubert) wrote:
> 
> Hi,
> 
> > For that issue at least there was some effort. Though ATM and FR
> > appear to be long gone, the problem got even worse with pseudo wires /
> > overlays and wireless.
> >
> > It was tackled in the IoT community 10+ years ago and we ended up with
> > RFC 8505 and 8928. This is implemented in LoWPAN devices and deployed
> > by millions. Allowing IPv6 subnets of thousands on constrained radios.
> 
> When I mentioned a problem for the first time in IPng or IPv6 (I can't
> find any archive, are there any?) list, Christian Huitema mentioned it
> could be solved by ND over NBMA but the problem is not NB but broadcast
> of Wifi is unreliable.
> 
> As such, the solutions should be based on a fact that repeated
> unreliable broadcast is reliable.
> 
> > I spent a bit of time explaining the architecture issue (in mild
> > terms) and solutions in
> > https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-
> wireless-12.
> 
> Though you wrote in the draft:
> 
> 	Reducing the speed at the physical (PHY) layer for
> 	broadcast transmissions can increase the reliability
> 
> longer packets mean more collision (with hidden terminals) probability
> and less reliability.
> 
> A link broadcast domain must be same for all the members of the link and
> should be defined as set of terminals which can receive broadcast from a
> central station (or, stations) with certain probability, which is why
> Wifi broadcast is relayed by a central station.
> 
> >  So far we failed to get those RFCs implemented on the major stacks
> > for WiFi or Ethernet.
> 
> Ethernet? Even though its broadcast is reliable?
> 
> Though Wifi bridged by Ethernet may have its own problems, they are
> Wifi-specific problems.
> 
> > There’s a new thread at IETF 6MAN just now on adopting just the draft
> > above - not even the solution. It is facing the same old opposition
> > from the same few and a lot of silence.
> 
> You can't expect people still insisting on IPv6 as is much.
> 
> > My suggestion is still to fix IPv6 as opposed to drop it, because I
> > don’t see that we have another bullet to fire after that one. For that
> > particular issue of fixing ND, new comments and support at the 6MAN on
> > the draft above may help.
> 
> It may be more constructive to work for proxy ARP suitable for Wifi,
> which may be enforced by Wifi alliance. An RFC may be published if Wifi
> industry request IETF to do so.
> 
> 						Masataka Ohta