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

[Philip Homburg <[e-mail]>]

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

I fully agree that a TV should work without any network connection. Though
I'm not sure what the IETF can do about that.

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

As far as I can tell, most IoT devices are connected to the internet. Of
course, I prefer IoT device communication to stay within my network. Again
not something the IETF has a lot of influence on.

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

I don't see why that business model would change. Maybe in areas where
network outages are common.

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

It seems right to me to support the mainstream business model first and then
deal with other cases. A lot of RA discussions are about rare cases and
solutions come at the expense of the common case. I understand the
engineering desire to handle all cases. But it can lead to overly 
complex solutions that are not a good fit for the common case.

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

They are hard to change because people here have actively resisted change for
a very long time. And the change requested is not about taking away
something. It is just adding a bit more support for DHCPv6 in some places.

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

I don't see the business advantage in blocking DHCP. Nobody seems to gain
here. Unless the business model is about keeping IPv4 alive as long as
possible. 

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

I don't know what MIF was supposed to do in this area (multiple upstreams).
I thought MIF was about hosts having multiple interfaces.

It seems to me that multiple upstream problem is something for homenet.

For many years now I have been running with multiple upstreams on
different routers transparant to hosts. This works perfectly fine with 
existing hosts as long as the routers know about each other and each other's
prefixes. Which is where homenet comes in.