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

Thu Nov 18 07:43:19 UTC 2021

> On 18 Nov 2021, at 17:21, Joe Maimon <jmaimon at jmaimon.com> wrote:
> 
> 
> 
> John Levine wrote:
>> It appears that Joe Maimon <jmaimon at jmaimon.com> said:
>> 
>>> For example
>>> https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 from 2008
>>> which fell prey to the "by the time this is usable IPv6 will have taken
>>> over" groupthink.
>>> 
>>> Objectively wrong.
>> I will agree that your explanation of the reasons the IETF didn't repurpose 240/8 is objectively wrong.
>> 
>> The amount of work to change every computer in the world running
>> TCP/IP and every IP application to treat 240/4 as unicast (or to treat
>> some of 127/8) is not significantly less than the work to get them to
>> support IPv6. So it would roughly double the work, for a 2% increase
>> in the address space, or for 127/8 less than 1%.  The code for IPv6
>> is already written, after all.
> And since 2008, IPv6 related updates and patches were so few and far between that they could not compare with those that would have been required if the IETF had ordered the internet to enable 240/4.
> 
> All 240/4 needed was a decade of normal product lifecycle patching. Basically an afterthought. A not insignificant percentage of which has happened practically all by itself to date.

CIDR is much older than that and we still have to avoid .0 and .255 addresses in class C space.  Similarly for .0.0 and .255.255 for class B space and .0.0.0 and .255.255.255 for class A space.  Getting everybody you want to contact and the path in between to be clean for 240/4 is more than just a replacement cycle.  There is a lot of really old gear out there that still talks to the world and it will never work with 240/4 addresses.

If you are selling IPv4 connectivity and your customer is given a 240/4 address but can’t reach some place on the internet that their neighbour with out a 240/4 can who are they going to blame?  Can you afford the defective product law suite.  You gave then an address that you knew fore well would not work reliably with the Internet as a whole.

Using 1/8 is still fraught.  At least with 1/8 you are not fighting kernels that need to be modified for which source is not available.

> And you seriously suggest that "effort" FSVO is equivalent to IPv6, which deployment wise is pretty much in the same state as 240/4, even with the IETF's full backing?
> 
> Which statistic are you torturing to somehow equate the two software and deployment projects? Its like comparing an ant to an elephant.
> 
> And given the current sorry state of IPv6 deployment, forgive me for thinking that perhaps they got the numbers a teeny weeny bit wrong.
>> Also, while the world has run out of free IPv4 address space, there is
>> plenty of IPv4 if you are willing to pay for it. A 2% increase in v4
>> addresses would not change that.
> 
> In the decade it would have taken for 240/4 to become globally usable, the rate of consumption, allocation and utilization of IPv4 has changed to the point that yes, it would have made a big difference. In another decade, should IPv6 not have finally managed to obsolete IPv4, the appreciation of utilitarian value can only to be greater.
> 
> Its like a whole nother do-over of the final /8 give out, except twice.
> 
> Think of it in terms of /24s because thats really all any small outfit ever needs of IPv4 and its critical for any startup. 65k is nothing to sneeze at looking at it that way.
> 
>> 
>>>> "By contrast, IPv6, despite its vastly larger pool of available address space, allocates only a single local loopback address (::1)
>>> [RFC4291]. This appears to be an architectural vote of confidence in the idea that Internet protocols ultimately do not require millions of
>>> distinct loopback addresses.”
> 
> IPv6 evangelicals are fond of citing the in-exhaustiveness of IPv6 in support of most any not particularly prudent allocation methodology or use of astonishingly large (in comparison to IPv4) amounts of it, but ::1 is all that can be mustered up for loopback.
> 
> On the other hand, we must take great pause and care of doing anything to disturb the 1/256th of the entire address pool allocated for that purpose to IPv4.
> 
> In-congruent, to say the least.
> 
> Anyways, IPv6 is supposed to save us from the degrading IPv4 network, whats one more degradation in the form of 127/8 -> 127.0/16 ?
> 
>>>> This is an apples-to-oranges comparison.  IPv6 has both link and site local addresses and an architecture to deliver packets to specific
>>> instances of each.  This does not exist in the IPv4 world.
>>> 
>>> SO an IPv6 only system without any network interfaces can run multiple
>>> discrete instances of the same daemon accepting connections on the same
>>> TCP port?
>> Sure.
>> 
>>  Can I script that, can I template that with hardcoded
>>> addresses, same as I can now for 127/8?
>> Sure, if you think that's a good idea which it isn't.  Use LLAs on your loopback interface.
> 
> Which LLA's does an IPv6 stack without any IPv6 enabled interfaces have?
> 
> Or worse, which LLA's will the IPv6 stack have with an IPv6 enabled interface? Depends on the hardware address?
> 
> LLA's are not a loopback range. So using them for that purpose is less than ideal, and unworthy of this new protocol thats supposed to take all the good of IPv4, discard the bad, innovate the new, usher in a renewal for the internet, and fail at all of that.
> 
>> 
>> Personally, I take my 127/8 addresses from a configuration file since I don't know in advance what
>> other daemons might also want to run on addresses only visible on the local machine.
> 
> How you deal with loopbacks on your system, is by definition, local to your system.
> 
> All other mechanisms are not. Maybe by convention, but not definition.
> 
> Dont we appreciate standards for that very reason?
> 
>>   Or, you know,
>> some maniac might decide that part of 127/8 isn't loopback so I have to move them to the part that
>> still is.
>> 
>> In IPv6 I use ULAs since that gives me the option of routing them or not.
>> 
>> R's,
>> John
>> 
>> 
> ULA and registered ULA are one of those things thats hard to think about with a straight face. They betray a variety of dichotomies that are quite ridiculous.
> 
> Joe

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org