Mailing List Archive

Redploying most of 127/8 as unicast public
This seems like a really bad idea to me; am I really the only one who noticed?

https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html

That's over a week old and I don't see 3000 comments on it, so maybe it's just
me. So many things are just me.

[. Hat tip to Lauren Weinstein, whom I stole it from ]

Cheers,
-- jra

--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info
St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Redploying most of 127/8 as unicast public [ In reply to ]
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?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me. So many things are just me.
>
> [. Hat tip to Lauren Weinstein, whom I stole it from ]

-------------------------------------------------------------------------------------------------



Everyone's just tired of rehashing this stuff... ;)  I looked up the
"IPv4 Unicast Extensions Project" the authors (S.D. Schoen, J. Gilmore
and D. Täht) are a part of.


https://github.com/schoen/unicast-extensions

------------------

Fixing the odd nooks and crannies still mildly broken in IPv4, by:

* Making class-e (240/4), 0/8, 127/8, 224/4 more usable
* Adding 419 million new IPs to the world
* Fixing zeroth networking
<https://github.com/schoen/unicast-extensions/blob/master/ZEROTH.md>
* Improving interoperability with multiple protocols and tunnelling
technologies
* Supplying tested patches and tools that address these problems

------------------

Some of these are hardcoded in ASICs, I believe.  Change that! ;)

scott
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Wed, Nov 17, 2021 at 3:31 PM Jay R. Ashworth <jra@baylink.com> wrote:
> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html

Hi Jay,

I think it's a good idea. It won't be usable any time in the next two
decades but if we're still using IPv4 in two decades we'll be glad to
have anything we can scrounge. Why not ask OS authors to start
assigning 127.0.0.1/16 to loopback instead of 127.0.0.1/8?

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: Redploying most of 127/8 as unicast public [ In reply to ]
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.

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.

"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.

"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

> On 18 Nov 2021, at 10:45, scott <surfer@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?
>>
>>
>> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>>
>>
>> That's over a week old and I don't see 3000 comments on it, so maybe it's just
>> me. So many things are just me.
>>
>> [. Hat tip to Lauren Weinstein, whom I stole it from ]
>>
> -------------------------------------------------------------------------------------------------
>
>
>
> Everyone's just tired of rehashing this stuff... ;) I looked up the "IPv4 Unicast Extensions Project" the authors (S.D. Schoen, J. Gilmore and D. Täht) are a part of.
>
>
>
> https://github.com/schoen/unicast-extensions
>
> ------------------
>
> Fixing the odd nooks and crannies still mildly broken in IPv4, by:
>
> • Making class-e (240/4), 0/8, 127/8, 224/4 more usable
> • Adding 419 million new IPs to the world
> • Fixing zeroth networking
> • Improving interoperability with multiple protocols and tunnelling technologies
> • Supplying tested patches and tools that address these problems
> ------------------
>
> Some of these are hardcoded in ASICs, I believe. Change that! ;)
>
> scott
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Wed, Nov 17, 2021 at 01:45:04PM -1000, scott 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?
> >
> > https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> https://github.com/schoen/unicast-extensions
>
> ------------------
>
> Fixing the odd nooks and crannies still mildly broken in IPv4, by:
>
> * Making class-e (240/4), 0/8, 127/8, 224/4 more usable
> * Adding 419 million new IPs to the world
> * Fixing zeroth networking
> <https://github.com/schoen/unicast-extensions/blob/master/ZEROTH.md>
> * Improving interoperability with multiple protocols and tunnelling
> technologies
> * Supplying tested patches and tools that address these problems
>
> ------------------
>
> Some of these are hardcoded in ASICs, I believe.? Change that! ;)

Probably easier to change the ASICs than it'll be to get those "tested
patches" they've apparently written deployed to the millions of Windows XP
boxes still out there.

- Matt
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Wed, Nov 17, 2021 at 11:29:49PM +0000, Jay R. Ashworth wrote:
> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me. So many things are just me.

I didn't comment because I was laughing too hard to be able to reliably use
the keyboard.

- Matt
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Wed, 17 Nov 2021, Jay R. Ashworth wrote:
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me. So many things are just me.

Someone is wrong on the Internet.
https://xkcd.com/386/

Other problems which will occur sooner:

1. Unix 32-bit time_t overflow.
2. North American Numbering Plan runs out of +1 zone phone numbers
3. IPv6 deployed and working everywhere/everything on the Internet
4. Analog AM and FM radio broadcasting deprecated (see digital DAB/DRM/HD)
5. Heat death of the universe

Again, covered by XKCD
https://xkcd.com/2240/

I've got other things to do first.
Re: Redploying most of 127/8 as unicast public [ In reply to ]
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.

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.

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? 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


>
> "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.


>
>> On 18 Nov 2021, at 10:45, scott <surfer@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
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On 18 Nov 2021, at 11:58, Joe Maimon <jmaimon@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@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@isc.org
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
It appears that Joe Maimon <jmaimon@jmaimon.com> said:
>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.

Aw, c'mon, don't leave us guessing.

>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.

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.

>> "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?

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.

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. 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
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
I am sad to see the most controversial of the proposals (127/16) first
discussed here.

Try this instead?

https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/

in my mind, has the most promise for making the internet better in the
nearer term.

Could I get y'all to put aside the 127 proposal and read that over, instead?

...

It's ok, I'll wait...

...

There were two other proposals concerning 240/4 and 0/8 also worth
reading for their research detail and attention to history.

The amount of work required to make 240/4 work in most places is now
very close to zero, having been essentially completed a decade ago.
240/4 and 0/8 checking is not present in the SDN codes we tried, and
we ripped the 0/8 check out of linux 3? 4? years back. Saves a few ns.

All but one iOt stack we tried worked with these, many of those stacks
still lack, or have poor ipv6 support. esp32 anyone?

Just as ipv6 today is not globally reachable, these address spaces may
never be globally reachable, but defining a standard for their
potential sub-uses
seems like a viable idea.
RE: Redploying most of 127/8 as unicast public [ In reply to ]
 

 
Subject:Redploying most of 127/8 as unicast public
To:nanog <nanog@nanog.org>;
This seems like a really bad idea to me; am I really the only one who noticed?

https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html

 
I can think of about a dozen /8's that would be better to use. (Hint, they all have DOD in the name.) They haven't been in routing tables for decades and there wouldn't be hardly any technical issues (like there would be with 127/8). The only drawback is I've seen a lot of organizations treat them like rfc1918 space.

 
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On 11/18/21 01:29, Jay R. Ashworth wrote:

> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me. So many things are just me.

There is a better chance of writing a successful RFC to clean up "cisco,
cisco" for user/pass on Google.

Mark.
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Mark Andrews wrote:
>
>> On 18 Nov 2021, at 11:58, Joe Maimon <jmaimon@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.

I am advocating for serious discussion on the merits, and only the
merits, of each individual idea and proposal and to respect those
willing to put in the effort even while likely knowing of the undeserved
scorn bound to come their way from those who choose not do as I would
advocate them doing.

And I think the basic contention is that the vast majority of 127/8 is
not in use. Apples to oranges, indeed.

> 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
>
Thats twice now you have suggested that ULA and LLA are an exact
substitute for dedicated system loopback prefix.

At the very least, it is semantically not.

Doesnt IPv6 deserve its own instead of squatting on IPv4?


Joe
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
John Levine wrote:
> It appears that Joe Maimon <jmaimon@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.

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
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
> On 18 Nov 2021, at 17:21, Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> John Levine wrote:
>> It appears that Joe Maimon <jmaimon@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@isc.org
Re: Redploying most of 127/8 as unicast public [ In reply to ]
No, you are not alone. This just gets kinda pathetic.
It also shows how an IPv6 is a failure.
(No please, leave me alone all you IPv6 zealots).

I think its time to go back to design board and start
working on IPv8 ;) so we finnaly get rid of IPv4...

---------- Original message ----------

From: Jay R. Ashworth <jra@baylink.com>
To: nanog <nanog@nanog.org>
Subject: Redploying most of 127/8 as unicast public
Date: Wed, 17 Nov 2021 23:29:49 +0000 (UTC)

This seems like a really bad idea to me; am I really the only one who noticed?

https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html

That's over a week old and I don't see 3000 comments on it, so maybe it's just
me. So many things are just me.

[. Hat tip to Lauren Weinstein, whom I stole it from ]

Cheers,
-- jra

--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info
St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Redploying most of 127/8 as unicast public [ In reply to ]
It’s being discussed on Hacker News.

https://news.ycombinator.com/item?id=29246420

> On Nov 17, 2021, at 3:29 PM, Jay R. Ashworth <jra@baylink.com> wrote:
>
> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me. So many things are just me.
>
> [. Hat tip to Lauren Weinstein, whom I stole it from ]
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth Baylink jra at baylink.com
> Designer The Things I Think RFC 2100
> Ashworth & Associates http://www.bcp38.info
> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On 2021-11-18, at 00:29, Jay R. Ashworth <jra@baylink.com> wrote:
>
> This seems like a really bad idea

Right up there with the FUSSP.

https://www.rhyolite.com/anti-spam/you-might-be.html

Someone should write a page like that about the FUSIAS (final ultimate solution to the IPv4 address shortage) proposals.

Grüße, Carsten
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
John Levine wrote on 18/11/2021 03:03:
> 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.
>
> 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.

putting more numbers on the table, the pre-exhaustion burn rate of
unallocated ipv4 address space was around 13 x /8 a year, i.e. a /8
every four weeks.

The ask is to update every ip stack in the world (including validation,
equipment retirement, reconfiguration, etc) and the gain is 4 weeks of
extra ip address space in terms of estimated consumption.

Nick
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Jay R. Ashworth wrote:

> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html

That's definitely a stupid idea.

As it requires to update all the end systems not to recognize 127/8
as loopback, releasing Class E, which is 16 times larger than 127/8,
as an additional public unicast address range is a lot (16 times)
better.

Though intermediate systems such as backbone routers must be updated
to release Class E, that is a lot lot lot less painful to replace the
end systems.

Masataka Ohta
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On 17 Nov 2021, at 6:29 PM, Jay R. Ashworth <jra@baylink.com> wrote:
>
> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html


Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-schoen-intarea-unicast-127-00
Updates:
1122 <https://www.rfc-editor.org/rfc/rfc1122>, 1812 <https://www.rfc-editor.org/rfc/rfc1812>, 2827 <https://www.rfc-editor.org/rfc/rfc2827>, 3704 <https://www.rfc-editor.org/rfc/rfc3704> (if approved)
Published:
8 November 2021






Perhaps it was just submitted 144 days too earlier and thus was miscategorized?
;-)
/John

Disclaimer(s): my views alone. Contains 100% recycled electrons.
Re: Redploying most of 127/8 as unicast public [ In reply to ]
This is actually worse than our collective progress on replacing v4 to
date.

-jim

On Wed, Nov 17, 2021 at 7:31 PM Jay R. Ashworth <jra@baylink.com> wrote:

> This seems like a really bad idea to me; am I really the only one who
> noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> That's over a week old and I don't see 3000 comments on it, so maybe it's
> just
> me. So many things are just me.
>
> [. Hat tip to Lauren Weinstein, whom I stole it from ]
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth Baylink
> jra@baylink.com
> Designer The Things I Think RFC
> 2100
> Ashworth & Associates http://www.bcp38.info
> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647
> 1274
>
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
On Thu, 2021-11-18 at 10:51 +0000, Nick Hilliard wrote:
> The ask is to update every ip stack in the world (including
> validation, 
> equipment retirement, reconfiguration, etc) and the gain is 4 weeks
> of
> extra ip address space in terms of estimated consumption.

(Not to mention the static 127.in-addr.arpa zone that pretty much every
resolver has configured by default these days.)

The burn rate is the best argument I've seen against the idea so far.

-- Steven
Re: Redploying most of 127/8 as unicast public [ In reply to ]
I'd be fine if newish devices use it like a 1918 but I don't think
it's worth the headache and difficulty of making it globally routed.
Maybe Amazon could use it too

On Wed, Nov 17, 2021 at 6:31 PM Jay R. Ashworth <jra@baylink.com> wrote:
>
> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me. So many things are just me.
>
> [. Hat tip to Lauren Weinstein, whom I stole it from ]
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth Baylink jra@baylink.com
> Designer The Things I Think RFC 2100
> Ashworth & Associates http://www.bcp38.info
> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

1 2 3 4 5  View All