Redploying most of 127/8 as unicast public

Thu Nov 18 02:02:48 UTC 2021

> On 18 Nov 2021, at 11:58, Joe Maimon <jmaimon at chl.com> wrote:
> 
> 
> 
> Mark Andrews wrote:
>> It’s a denial of service attack on the IETF process to keep bringing up drafts like this that are never going to be approved.  127/8 is in use.  It isn’t free.
> 
> There are so many things wrong with this statement that I am not even going to try to enumerate them.
> 
> However suffice it to say that drafts like these are concrete documentation of non-groupthink and essentially you are advocating for self-censorship and loss of historical perspective.

I’m advocating for not taking address away that have been allocated for a purpose.  No one knows what the impact of doing that will be.  Perhaps we should just take back 216.222.144.0/20?  You obviously think taking back address that are in use to be a good thing.  This is similar to taking back other address that are allocated but not advertised.

> Which given the state of IPv6 transition, perhaps more of that in the past would have been nice.
> 
> 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.

Again an oranges vs apples comparison.  Class E is not 127/8.  This is “Reserved" vs "Reserved for use on the host”.  Totally different histories.  Totally different expectations.

> Objectively wrong.
> 
> Predictive self-fulfilling circular arguments of this sort should no longer be given any weight, and along your lines, should never even be brought up.
> 
>> 
>> Lots of bad attempts to justify a bad idea.
>> 
>> "The IPv4 network 127/8 was first reserved by Jon Postel in 1981 [RFC0776]. Postel's policy was to reserve the first and last network of each class, and it does not appear that he had a specific plan for how to use 127/8.”
>> 
>> Having a space for permission-less innovation and testing is a good thing.  Jon understood that.
> 
> Yes its a good idea to have space that is guaranteed to be available to every system regardless of its networking condition and that the host has deterministic control over the addressing used in that space.
> 
> However, it turns out that /8 was much too large. The extreme few instances of its usefulness at that size pale in comparison with even the possibility of its usefulness to the public.
> 
> So any attempt to adjust that should be given proper attention and serious thought.
> 
>> 
>> "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.”
>> 
>> 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?

Yes. I’ve been doing testing over the IPv6 loopback for 20+ years now.

> Can I script that, can I template that with hardcoded addresses, same as I can now for 127/8?
> 
> Good thing I can just use ::FFFF:127.0.0.1/104

You can script is to the same extent that you can hard code 127/8 addresses.  I’ve used ULA addresses but conceptually they are the same.  The lo0 interface also has more that 127.0.0.1 IPv4 addresses on it.

% ifconfig lo0 inet6
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	inet6 fd92:7065:b8e:ffff::1 prefixlen 64 
	inet6 fd92:7065:b8e:ffff::2 prefixlen 64 
	inet6 fd92:7065:b8e:ffff::3 prefixlen 64 
	inet6 fd92:7065:b8e:ffff::4 prefixlen 64 
	inet6 fd92:7065:b8e:ffff::5 prefixlen 64 
	inet6 fd92:7065:b8e:ffff::6 prefixlen 64 
	inet6 fd92:7065:b8e:ffff::7 prefixlen 64 
	inet6 fd92:7065:b8e:ffff::8 prefixlen 64 
	inet6 fd92:7065:b8e:ffff::9 prefixlen 64 
	inet6 fd92:7065:b8e:ffff::10 prefixlen 64 
	inet6 fd92:7065:b8e:ff::1 prefixlen 64 
	inet6 fd92:7065:b8e:ff::2 prefixlen 64 
	inet6 fd92:7065:b8e:99ff::1 prefixlen 64 
	inet6 fd92:7065:b8e:99ff::2 prefixlen 64 
	inet6 fd92:7065:b8e:fffe::a35:4 prefixlen 64 
	nd6 options=201<PERFORMNUD,DAD>
% 

>> "In theory, having multiple local loopback addresses might be useful for increasing the number of distinct IPv4 sockets that can be used for inter-process communication within a host. The local loopback /16 network retained by this document will still permit billions of distinct concurrent loopback TCP connections within a single host, even if both the IP address and port number of one endpoint of each connection are fixed.”
>> 
>> But it doesn’t deliver millions of end points.  Sorry you simulation will not work because we don’t have more that 65000 end points anymore.  Sorry RFC 1918 addresses are not always suitable.
>> 
>> "Reserved for <use>" is not the same as “Reserved”.
>> 
>> Mark
> 
> Let them use IPv6 link local for their simulations.

Which doesn’t work when you are simulating dual stack.

>>> On 18 Nov 2021, at 10:45, scott <surfer at mauigateway.com> wrote:
>>> 
>>> 
>>> 
>>> On 11/17/2021 1:29 PM, Jay R. Ashworth wrote:
>>>> This seems like a really bad idea to me; am I really the only one who noticed?
>>>> 
>>>> 
> 
> Its only a relevant idea if you still care about IPv4. In which case, it might be a good idea.
> 
> Joe

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