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 protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
