nanog mailing list archives

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


From: Masataka Ohta <mohta () necom830 hpcl titech ac jp>
Date: Sat, 14 Jan 2023 10:35:49 +0900

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


Current thread: