> On 18 Nov 2021, at 11:58, Joe Maimon <jmai...@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 <sur...@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: ma...@isc.org
