Re: Adoption Call for <draft-troan-6man-universal-ra-option>

[Philip Homburg <[e-mail]>]

>Yes, I think that was the world view in ~1994 when this conversation started.
>I was thinking of SLAAC, not SLAAC+RA. SLAAC starts with link-local addresses.
>Certainly, a modern version of "dentist's office" is more like a homenet with
>several in-house routers. RA is what you get out of the box when you install
>an IPv6 router. Then you need ULAs unless you have an active ISP.

Maybe we should leave the "dentist's office" in 1994 with the original 
definition: no router at all.

Then we can have another term for a network with routers, but without a
connection to the wider internet.

>Just to be clear, we defined IPv6 in such a way that it doesn't depend on
>having an active ISP or any kind of centralised top-down configuration.
>That's something we need to keep; we aren't here to support any 
>particular business model such as an ISP-based Internet. (The very
>concept of "CPE" assumes that business model.)

Recently my home network is a bit unstable. Quite a few devices are
complaining that they don't have a network connection when there is no link
to the internet.

So client side, we already moved on, a 'network' implies a connection to the
internet.

As far as I can tell, there is barely any market for networks that are
not connected to the internet. Of course they exists. It is just that for
most people a network without an internet connection is a broken network.

It is good that we have the mechanisms (such as ULA) for disconnected
operation. But it's a corner case.

>Of course, we also need the ability to add either top-down configuration via
>something like DHCP, or automatic self-configuration. The latter could make
>DHCP redundant. There's nothing magic about DHCP; it's just an overlay on
>the basic IPv6 mechanisms if you want centralised top-down configuration.
>If you don't want that, you don't want DHCP.

As DHCPv4 shows, DHCP works in the same environment as RA. There is nothing
particularly heavy weight, or centralised about DHCP. DHCP supports those
things, whereas RA does not. DHCP on it's own is perfectly fine for network
configuration.

With one exception: in networks where network parameters change a lot,
RA is better. In my experience, those networks are rare. Obviously, we want
to keep RA for those cases.

>I remind you that we did the basic IPv6 design, including RA, before DHCP
>was a thing. (Strictly speaking, it was an emerging technology.)
>DHCPv6 is an add-on.

DHCPv4 was a thing before IPv6 was deployed at any scale. Even DHCPv6 was
defined before there was any significant deplyment of IPv6.

I'm not saying we should get rid of RA. It is just that there is a constant
stream of negativity to anybody who would want to use DHCPv6 configure all
network parameters of IPv6 hosts in a network.

>> Where RA goes beyond DHCP is in supporting multiple default routers. Which
>> is no longer a small, simple network. And in my experience, having multiple
>> routers announcing their own prefixes, creates interesting corner cases.
>
>It does. Hence RFC8028 and PVDs.

Indeed there is RFC 8028. It is tricky to implement and very few hosts 
support it. And realistically, it only works if all hosts in a subnet support
it. It is good have, but it may take a very long time before all hosts
support it.

Each time I look at PVD, it seems to be information that could be put in
DHCP, but got a different transport and is defined in an informational RFC.

It is funny how RFC 8801 went to work around the limitations of RA. In
DCHP a host would request a particular piece of information. Section 5.2 in
RFC 8801 describes how you can send RAs from different link-local addresses
to address hosts that are PvD-aware and Non-PvD-aware. And then extra
hacks to include an RA header in the PvD-option.

It seems a rather deperate attempt to keep using the RA hammer.

I have to admit, the PvD option is sufficiently convoluted that it would
be a very good candidate to be expressed in CBOR.