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

[Philip Homburg <[e-mail]>]

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

Indeed. Though it seems to me that RFCs are in relatively good shape in this
area. I don't think there is anything mandatory that would fail with
disconnected operation.

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

I don't know where we (the IETF) are requiring WAN connectivity.

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

I guess this depends on lot on where you are. Where I live, a disaster
that kill network connectivity is likely to kill power as well. Not much
network without power.

Of course, some organisations have backup power. But in those cases,
why bother with ULA. Just get a static prefix and configure that in
all onsite routers.

For home use, we see that many games require internet connectivity even if
the game itself doesn't require a server.

In the past, people had their own media collections. These days, everything
is streamed.

So yes, you may be able to print. And with a bit of luck you can check
your internet connected fridge. But not much else is likely to work without
an internet connection.

>> They are hard to change because people here have actively resisted change fo
>r
>> 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 doubt it. 

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

It seems to me that multiple interfaces brings problems that you typically
don't find in a network with multiple upstream (certainly not in a managed
entrerprise network).

Multiple interfaces often requires a host to deal with a cost problem:
typically wifi is cheaper than mobile data (or at most as expensive). When
do you use mobile data? Multiple interfaces bring a split universe. Maybe
a DNS lookup on one interface needs to be paired with a connection on
that same interface. Each interface may have its own DNS resolvers, etc.

A host on a network with multiple upstreams can and should rely on 
the routers telling the host what to do. 

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

Yes. But with redirects, only the first packet that goes to a particular 
destination. In theory, a host can pick a source address from a different
prefix for each flow that it creates to a single destination. Then
many packets may end up at the wrong router. In that case it is best if the
host also records the source address in the destination cache.