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

[Brian E Carpenter <[e-mail]>]

On 23-Sep-21 21:16, Philip Homburg wrote:
>> 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.

I'm pretty sure that scenario was considered by HOMENET, and it's certainly
one we've considered (at least during network construction) in ANIMA.

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

And that's something we need to fix. I was very disturbed when I acquired
a new TV that its first demand was that I should create an account with
$MANUFACTURER before I could continue the setup. This may be current
reality, but it isn't OK.
 
> 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.

Of course. But that doesn't (or shouldn't) apply to IoT deployments or
any situation where an air gap is a basic security environment.
> 
> It is good that we have the mechanisms (such as ULA) for disconnected
> operation. But it's a corner case.

It is for today's mainstream business model.

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

Right. But as I just said, your argument applies to today's mainstream
business model.

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

That's true. I was talking about when the basic design decisions were
taken. As with any technology, those are very hard to change.

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

Because of a business model tussle, perhaps? Not the only example of that
in IETF history.

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

I agree with all you say about PVDs. RFC8028 would have happened about
5 years earlier if I hadn't hoped that MIF would find a neat solution.

    Brian