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

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

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

What we *can* do is make sure that nothing in our mandatory-to-implement
set requires such a connection.

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

Again, we can avoid *requiring* WAN connectivity. (Therefore, depending
on DNS is not always a good thing, but that is a bit off topic.)
 
>>> 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.

Or where disaster planning is a thing. Of course, ULAs may not always be
the answer, but "will I have an address after an earthquake?" is a
question worth asking.
 
>>> 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.

Fair comment. But IMHO it's the IETF's job to ensure that the bare minimum
set of standards covers all cases, not just the common cases.
 
>>> 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.

Maybe formulating that request in a well-argued draft would be helpful?

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

I don't think the two problems can really be separated, and multiple
upstreams definitely affect enterprise networks too.

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

Doesn't that add an extra hop when a packet gets to the "wrong" exit router?

   Brian