WKBI #586, Redploying most of 127/8 as unicast public

Joe Maimon jmaimon at jmaimon.com
Fri Nov 19 15:57:44 UTC 2021



Owen DeLong via NANOG wrote:
> I don’t see the difference between 6 and 7 usable addresses on all the /29s
> in the world as actually making a significant impact on the usable lifespan of
> IPv4.
>
> Owen
>

This idea gets better each time I think about it. The changes and 
support required would typically be only local to customer/vendor and it 
can be useful in multiple contexts within a single entity as well.

Or how about this one. I can add VRRP failover to every customer prefix 
with zero negative impact to them by addressing the secondary with the 
all-zero address. Only I have to upgrade since the customer doesnt use 
or refer to that address ever. Now granted, using a FHRP protocol that 
didnt require any address at all in the subnet for the non-primary would 
give the same result. And maybe maybe maybe ICMP from the secondary 
might get dropped by non-updated customer.

How about customers who like to have redundant routers now only require 
an update to do it within /30, which within vendor relationship context, 
should it be standard long enough, they may very well require, and 
should a /29 cost more, the customer may very well prefer.

Getting an extra address out of a /29 and two instead of one out of /30 
can be quite useful to each individual user and use of those prefixes.

Collectively, it may or may not extend IPv4 global resources. Probably 
not in any measurable way and possibly non existent, although it is 
conceivable that /30 would become usable enough that less /29's will be 
assigned, and the same for /29 lasting longer before requiring /28. 
Probably not much beyond that.

Its about getting more mileage from existing allocations, not really 
about making more allocations available.

And all thats needed to be done is to drop this ridiculous .0 for 
broadcast compatibility from standards.....why is this even controversial?

Joe


More information about the NANOG mailing list