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

Sat Jan 14 01:35:49 UTC 2023

Pascal Thubert (pthubert) wrote:

Hi,

> Solutions must first avoid broadcast as much as possible, because
> there's also the cost of it.

Though I'm not saying all the broadcast must be repeated,
if you think moderate broadcast is costly, just say,
CATENET.

I remember old days when entire network of CERN with
thousands of hosts was managed to be a single Ethernet
several years after we learned dividing network by
routers can prevent various problems caused by broadcast.

It was, at least partly, because operating multi-protocol
routers is painful. Unlike most sites at that time, non
IP protocols such as DECnet was popular at CERN.

As IPv4 became dominant, problems went away.

> Then you want zerotrust, ND is so easy to
> attack from inside and even outside. This is RFC 8928.

As many people are saying zerotrust relying on PKI, which
blindly trust CAs as TPPs (trusted third parties), which
are confirmed-to-be-untrustworthy third parties by
Diginotar, zerotrust is not very meaningful beyond
marketing hype.

Anyway, relying on link broadcast implies that the link
is trusted to some extent, which is not ND specific.

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

Unlike CERN in the past, today, I can see no point to have large
Ethernet, though some operators may be hyped to deploy expensive
service of telco for nothing.

> Add to that the desire by the device to own more and more addresses.

What? How can it happen with IPv4?

> 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.

Ignoring poor IPv6, I'm afraid it a property of not ARP but DHCP.

>> 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.

I agree with you but my point is that it is more constructive for ARP.

> 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.

But, for adoption, some formal document, not necessarily a (standard
track) rfc, is necessary.

						Masataka Ohta