Subject: Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Dec 2021 15:54:27 +0100

Le 21/11/2021 à 20:56, Keith Moore a écrit :
> I don't hate this draft.   But making tweaks to IPv4 at this stage 
> seems like making improvements to the altimeter in a Dusenberg.

The other day I noticed dedibox allocates a /128 IPv6 'subnet' when
enabling SLAAC on a virtual server.  That is supposedly a technique
similar to this I-D 'lowest-address' but in IPv6.

As such, it might make sense to ask dedibox scaleway what is their
algorithm to form that /128 'subnet' when enabling SLAAC, and maybe
document that instead.

https://www.scaleway.com/en/docs/dedibox-network/ipv6/quickstart/
> How to enable IPv6 SLAAC
> 
> Activation of IPv6 SLAAC assigns one /128 IPv6 subnet to your server 
> (one usable IPv6 address). This IP will be statically linked to your 
> server and can not be attributed to another server.
> 
> Note:
> 
> This feature is not yet available for all servers. Only the servers 
> that are compatible will show the related button.

> IMO IPv4 should be declared at EOL in 2025, and further work on IPv4
>  should require significant justification.

I agree.

> The questions for any proposed enhancements to IPv4 at this stage
> should be like:
> 
> (a) will this change to IPv4 improve or facilitate adoption of IPv6 
> or ease the transition away from IPv4 in favor of IPv6? (b) is this 
> change to IPv4 helpful to permit continued interoperability with 
> legacy IPv4-only systems that are still needed?

It's a good list.

Alex

> 
> I'm not saying these are absolutely the only reasons to do additional
> work on IPv4 at this stage, but the list of valid reasons is probably
> small.
> 
> Perhaps more importantly, while protocol changes that require 
> software changes can sometimes be widely deployed rather quickly 
> (thanks to automatic or semi-automatic over-the-wire software 
> updates), protocol changes that require changes to manual 
> configuration of hosts, routers, or middleboxes are unlikely to be 
> deployed nearly as quickly.
> 
> In this case it seems like use of .0 at this late date creates 
> additional potential for operational networks to become more brittle
>  and to result in strange inconsistencies that are difficult for 
> ordinary users (and some other operators of small LAN segments) to 
> track down.
> 
> ***
> 
> But I am somewhat sympathetic to the idea that tiny subnets need all
>  of the addresses that they can get.   It shouldn't be necessary to 
> get a /29 prefix just to be able to put three hosts on a LAN segment.
> My house has a /28 and sometimes that's not been enough (though
> thankfully my carrier is finally supporting IPv6, so I care much less
> now).
> 
> It strikes me that it is the tiny subnets that not only need this 
> relief most, but also are the ones that are least likely to be 
> disrupted by meddleboxes, intrusion detectors, security monitors, 
> etc. trying to be too clever.     But plenty of tiny networks have 
> such meddleboxes.
> 
> Or maybe .0 should be the preferred address for the on prem router's
>  configuration interface, freeing up other addresses on the subnet
> for ordinary hosts.   That way, most problems will show up
> immediately, and the ISP will be the ones who have to deal with it
> when it breaks. (How many consumer-facing ISPs would want to make
> that change to their default router configurations?   I'm guessing
> not many, which might be a good indication of something.)
> 
> Overall, I think there's some potential for publication of this 
> document to do more harm than good, even if it only recommends use of
> .0 for hosts on network segments that have, say, /26 or longer 
> prefixes.  Is it really worth it?  (Or as one person suggested, is 
> this a way to make IPv4 even more broken so that people will have to
>  switch to IPv6?)
> 
> Keith
> 
> On 11/16/21 2:09 AM, Loganaden Velvindron wrote:
>> I would support seeing this work move forward. There are still
>> many countries in the developing world who will not be able to
>> update to IPv6 any time soon due to legacy equipment and will be
>> using IPv4 for a long time.
>> 
>> (Disclaimer:  I submitted a few patches to the IPv4 extension 
>> project).
>> 
> 
> _______________________________________________ Int-area mailing
> list [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area