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
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
Mark Andrews wrote:
> CIDR is much older than that and we still have to avoid .0 and .255
> addresses in class C space.

I use .0 all the time.

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

No address comes with any guarantees. Suppose you are 100% correct. Its
not the IETF's role to manage the community at large resource
expenditures, whatever their opinion may be.

The only effort involved on the IETF's jurisdiction was to stop
squatting on 240/4 and perhaps maybe some other small pieces of IPv4
that could possibly be better used elsewhere by others who may choose to
do so.

Joe
Re: Redploying most of 127/8 as unicast public [ In reply to ]
How much runway would a single /8 give us? Is it worth the headache to gain a single /8 ?

If we’re going to do something that Majorly Breaks the Internet(tm), why not talk about the 240/4 space instead?

<economics>We can’t fight address exhaustion on the supply side. The only way to fix IPv4 exhaustion is by shifting the demand curve inward and that is through IPV6 and aggressive reclamation of IPv4 space.<economics />

Jonathan

Jonathan Kalbfeld

office: +1 310 317 7933 <tel:%28310%29%20317-7933>
fax: +1 310 317 7901 <tel:%28310%29%20317-7901>
home: +1 310 317 7909 <tel:%28310%29%20317-7909>
mobile: +1 310 227 1662 <tel:%28310%29%20227-1662>

ThoughtWave Technologies, Inc.
Studio City, CA 91604
https://thoughtwave.com <https://thoughtwave.com/>

View our network at
https://bgp.he.net/AS54380 <https://bgp.he.net/AS54380>

+1 213 984 1000

> 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@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 ]
Dave Taht wrote:
> 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?

/30 now becomes 2 usable IP addresses for the customer.

/29 "5 static IP addresses" now becomes 6?

Doing vrrp for a customer /29 gets a bit easier.


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

Good thing they werent worried about wasting the IETF's valuable and
precious time running the internet, because the masses cant possibly be
trusted.

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

On the face of it, any of the above statements should be enough to
silence and shameface any and all of the historical naysayers.

However it would appear they are still living in the past, as evidenced
by continued citing of "pre-exhaustion burn rate" as if the excesses of
the past are somehow relevant to the consumption of the future other
than an indictment of non-prudence.

Joe
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
> The only effort involved on the IETF's jurisdiction was to stop squatting on
> 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly
> be better used elsewhere by others who may choose to do so.

The IETF is not the Network Police, and all IETF standards are entirely
voluntary.

Nothing is keeping you from persuading people to change their software to
treat class E addresses as routable other than the detail that the idea is
silly.

R's,
John
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
John R. Levine wrote:
>> The only effort involved on the IETF's jurisdiction was to stop
>> squatting on 240/4 and perhaps maybe some other small pieces of IPv4
>> that could possibly be better used elsewhere by others who may choose
>> to do so.
>
> The IETF is not the Network Police, and all IETF standards are
> entirely voluntary.

And that is exactly why they said that even though they think it might
possibly entail similar effort to deployment of IPv6 and that IPv6 is
supposed to obsolete IPv4 before any such effort can be realized, they
would be amenable to reclassifying 240/4 as anything other than
reserved, removing that barrier from those whom may voluntarily decide
to follow that updated standard, should they find the time to squeeze in
another project the same size and effort of IPv6 into their spare time.

Seems the IETF does indeed think it is the network police. And that they
get to decide winners and losers.
>
> Nothing is keeping you from persuading people to change their software
> to treat class E addresses as routable other than the detail that the
> idea is silly.
>
> R's,
> John
>

And indeed, they have done so. Now who looks silly?

Joe
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Jonathan Kalbfeld via NANOG wrote:
> How much runway would a single /8 give us?
Up to 65280 /24's becoming available through registrars would be quite
welcome to lots of small organizations or startups.

> Is it worth the headache to gain a single /8 ?

I support serious consideration be given to determine the extent of the
headache and to answer that question.

>
> If we’re going to do something that Majorly Breaks the Internet(tm),
> why not talk about the 240/4 space instead?

I think 240/4 is indeed a very good idea deserving of proper
consideration. That does not mean that other ideas arent worthy as well.

But at this point 240/4 is practically a no brainer.

>
> <economics>We can’t fight address exhaustion on the supply side. The
> only way to fix IPv4 exhaustion is by shifting the demand curve inward
> and that is through IPV6 and aggressive reclamation of IPv4
> space.<economics />
>
> Jonathan
>
> Jonathan Kalbfeld
>
> office: +1 310 317 7933 <tel:%28310%29%20317-7933>
> fax: +1 310 317 7901 <tel:%28310%29%20317-7901>
> home: +1 310 317 7909 <tel:%28310%29%20317-7909>
> mobile: +1 310 227 1662 <tel:%28310%29%20227-1662>
>
> ThoughtWave Technologies, Inc.
> Studio City, CA 91604
> https://thoughtwave.com
>
> View our network at
> https://bgp.he.net/AS54380
>
> +1 213 984 1000
>
>> On Nov 17, 2021, at 3:29 PM, Jay R. Ashworth <jra@baylink.com
>> <mailto: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 Nov 18, 2021, at 9:00 AM, John R. Levine <johnl@iecc.com> wrote:
>> The only effort involved on the IETF's jurisdiction was to stop squatting on 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly be better used elsewhere by others who may choose to do so.
>
> The IETF is not the Network Police, and all IETF standards are entirely voluntary.

True…

> Nothing is keeping you from persuading people to change their software to treat class E addresses as routable other than the detail that the idea is silly.

Of course, it’s not quite that simple.

First, https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml <https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml> would need to be updated, then the RIRs would need to issue a request according to https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en <https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en>. At that point, existing requests lodged at the RIRs could be fulfilled using the formerly reserved space. Network operators that received the allocations could then number their devices with the new address space and announcing that space into the routing system.

Of course, there are probably an unknowable number of “bogon” filters out there that are hardcoded into various bits of infrastructure that would need to be updated. There are also various hardware, firmware, and software IP stack implementations, perhaps sitting in closets somewhere, that still think they can’t use reserved space that would need to be updated/replaced.

As far as I can tell, assertions about the scale of that update/replace exercise are based on limited data. Perhaps as an alternative to declaring various chunks of reserved space as free for use, a chunk of that space could be allocated to one or more of the RIRs and announced with a set of services placed upon it to see just how much actually breaks, similar to what APNIC and Cloudflare did with 1.1.1.0/24?

Regards,
-drc
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Thu, 18 Nov 2021 08:53:53 -0800
Jonathan Kalbfeld via NANOG <nanog@nanog.org> wrote:

> If we’re going to do something that Majorly Breaks the Internet(tm),
> why not talk about the 240/4 space instead?

I like the proposal that suggest include a plan to reuse 224/4 (with
the exception of 224.0.0.0/24, but it looks like the plan is OK with
not using any of 224.0.0.0/8). With apologies to our small set of
friends who are keeping the interdomain dream alive, I might help
advocate for such a plan not because of what it adds, but because
of what it helps hasten the demise of. :-)

John
Re: Redploying most of 127/8 as unicast public [ In reply to ]
----- Original Message -----
> From: "Justin Keller" <justincompsci@gmail.com>

> 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

I could be wrong, but I don't think expanding 1918 was the goal of these
proponents....

Cheers,
-- jra

> 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

--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
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 Thu, Nov 18, 2021 at 10:14 AM Jay R. Ashworth <jra@baylink.com> wrote:
> I could be wrong, but I don't think expanding 1918 was the goal of these
> proponents....

Hi Jay,

I would be happy with the compromise where the addresses are assigned
to "unicast; reserved." We can fight over exactly what unicast use
they should be put to 20 years from now when ordinary equipment and
software churn has rendered the addresses more or less usable.

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
The proposals I've seen all seem to deliver minimal benefit for the massive
lift (technical, administrative, political, etc) involved to keep IPv4
alive a little longer.

Makes about as much sense as trying to destabilize US currency by
counterfeiting pennies.

Thank you
jms



On Thu, Nov 18, 2021 at 12:39 PM Joe Maimon <jmaimon@jmaimon.com> wrote:

>
>
> John R. Levine wrote:
> >> The only effort involved on the IETF's jurisdiction was to stop
> >> squatting on 240/4 and perhaps maybe some other small pieces of IPv4
> >> that could possibly be better used elsewhere by others who may choose
> >> to do so.
> >
> > The IETF is not the Network Police, and all IETF standards are
> > entirely voluntary.
>
> And that is exactly why they said that even though they think it might
> possibly entail similar effort to deployment of IPv6 and that IPv6 is
> supposed to obsolete IPv4 before any such effort can be realized, they
> would be amenable to reclassifying 240/4 as anything other than
> reserved, removing that barrier from those whom may voluntarily decide
> to follow that updated standard, should they find the time to squeeze in
> another project the same size and effort of IPv6 into their spare time.
>
> Seems the IETF does indeed think it is the network police. And that they
> get to decide winners and losers.
> >
> > Nothing is keeping you from persuading people to change their software
> > to treat class E addresses as routable other than the detail that the
> > idea is silly.
> >
> > R's,
> > John
> >
>
> And indeed, they have done so. Now who looks silly?
>
> Joe
>
>
Re: Redploying most of 127/8 as unicast public [ In reply to ]
I have read through this thread, and you'll pardon me if it sounds like yet another rehash on yet another list. You might take a look at https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/, which responds to https://datatracker.ietf.org/doc/html/draft-wilson-class-e. I'm not sure what has changed in the past lotsa years other than which prefix people want to make essentially the same arguments about. My observation has been that people don't want to extend the life of IPv4 per se; people want to keep using it for another very short time interval and then blame someone else for the fact that the 32 bit integers are a finite set.

That strikes me as crazy. Put all of the remaining IPv4 prefixes (for some suitable definition of "remaining") in a bucket, decide that if they were all made unicast IP address space that would add <mumble> microfortnights to the life of the IPv4 Internet, and think about what happens next. Immediately, we all go back to sleep, fail to update our applications and deployments, and when that time interval has expired, we all whine about the stupidity of the IPv4 designers that didn't not make IPv4 forward compatible with *any*thing* - the next step has to be a replacement - and try to figure out a way to represent more than 2^32 interfaces in a single 32 bit number (https://datatracker.ietf.org/doc/html/draft-terrell-math-ipaddr-ipv4) or redesign the Internet in some way that would require as much effort and money to deploy as IPv6 has since its inception.

If you don't think that's a true statement, I'd be very interested to hear what you think might be true.
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Fred Baker wrote:
> I have read through this thread, and you'll pardon me if it sounds like yet another rehash on yet another list. You might take a look at https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/, which responds to https://datatracker.ietf.org/doc/html/draft-wilson-class-e. I'm not sure what has changed in the past lotsa years other than which prefix people want to make essentially the same arguments about.

What has changed is that the intervening years have demonstrated that
the proponents were right and the detractors were wrong. Very much so.

> My observation has been that people don't want to extend the life of IPv4 per se; people want to keep using it for another very short time interval and then blame someone else for the fact that the 32 bit integers are a finite set.
>
>
>
> If you don't think that's a true statement, I'd be very interested to hear what you think might be true.
>
On this thread alone very thoughtful and knowledgeable sounding folk
have made it quite clear that the efforts involved are a lot less and
the potential benefits a lot more than the naysayers mantra.

Its time to update some assumptions.

Joe
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Thu, Nov 18, 2021 at 12:40 PM Fred Baker <fredbaker.ietf@gmail.com> wrote:
> I'm not sure what has changed in the past lotsa years other
> than which prefix people want to make essentially the same
> arguments about. My observation has been that people don't
> want to extend the life of IPv4 per se; people want to keep using
> it for another very short time interval and then blame someone
> else for the fact that the 32 bit integers are a finite set.

Hi Fred,

The detractors for this proposal and those like it make the core claim
that we shouldn't take the long view improving IPv4 because IPv6 is
going to replace it any day now. Each day that passes with the end of
IPv4 still not in sight demonstrates how very wrong that strategy is.

If there's a change we can make to a standard now which will result in
IPv4 being better 20 years from now, we should make it. We should hope
that we never need the result because IPv6 takes over the world but we
should make the change anyway. Because hedging our bets is what
responsible people do.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
On Thu, Nov 18, 2021 at 11:05 AM John R. Levine <johnl@iecc.com> wrote:
..> The IETF is not the Network Police, and all IETF standards are entirely
> voluntary.

Yes, however the IETF standards can be an obstacle -- if they are, then
it is reasonable to adjust that which might impede a future useful development:
regardless of the fact that other obstacles may exist and it may be predicted
to be infeasible in the end. The estimation that effort to update
software will not be
worthwhile much later (10 years from now) cannot be made with enough
confidence;
the other efforts that need to happen is not justification to keep the
standard from changing so
that new/updated software coming out in the near future have a chance to
avoid making making future efforts to reclaim class E or a portion of
127/8 any harder than
they already are today.

The improbability or cost involved in getting software updated should
not impede updating a standard -- Just like the low rate of IPv6
deployment and the
estimation that IPv6 Never manage to fully and totally replace IPv4
should Not prevent
further development of IPv6 nor giving up on IPv6, etc.

Both IPv4 and IPv6 are important standards that should continue to be
maintained.

> Nothing is keeping you from persuading people to change their software to
> treat class E addresses as routable other than the detail that the idea is

The standard could keep you from persuading people - if the standard
says that class E is something else, then the chance of it ever getting close
to be globally usable is about zero .

If the Standards are updated to say that it is globally routable,
Then the chance
of it ever becoming globally routable is still close to zero, at least
for a long period of time,
BUT at least it is improved, even the small improvement that can
come from fewer new software programs
outright blocking it justifies updating the standard, there is no
real downside other than the time and effort'
to actually update the standards..


Adjusting 127/8 is the same way. It seem pretty obvious this should be done..
make the reservation 127.0.0.0/24, or /32, even, and declare the full
of 127.0.0.0/8 as
Unicast reserved. This does not immediately change any software or
operating systems nor
affect anyone's network, since the range in question is non-routable
it has only to do
with individual systems using IPv4 internally and privately, not
related to the internet
or any IP networks to begin with (unless some router internally have
a large swath
of 127/8 for internal system services on its main routing table) - anyway,
System applications can continue using 127/8
internally on local loopback interfaces for local IPC to the heart's content,
Until such time as Operating Systems choose to make (or choose not to
make) changes
to their own system networking functions and network libraries.

Or perhaps they would consider a configuration option such as
- "use one of the /8s from Class E for loopback, in Lieu of 127/8."


As a practical matter on modern OSes: "127.*" seem more of a convenience; You
can run network-based apps privately and use standard network tools such
as "telnet 127.0.0.0" to test protocols over your local Loopback
'devices' without needing
to give an interface such as "ssh -B lo0 127.0.0.0" --

If that's not the scenario (Not a need to access Local applications
using a common network utilities such
as 'ssh' or 'web browser'), Then there are ample alternatives
for example: "Open connection to file /opt/var/run/mysql.sock"
So, uh you only really have reason to use by design 127.0.0.0 if your
software wish to be used over a network.

If it's not such a "standard" client/server program being tested locally,
you can give an interface within the design of your local apps and use
Loopback networks all day without any 127 addresses.. if your OS
make you specify an interface instead of routing Loopback device
traffic, then you could
potentially be allowed to accept and use Any IP in all of the IPv4
space on the Loopback
as part of a separate and distinct private "network", so you could
Re-Use all the RFC1918
IP space for your Loopback IP space without conflicting with other
RFC1918 address usage.

You need only 1 IP address to talk to your local system - Maybe you
run something such as Docker container host, I guess, then a whole /16
seem Ok...


> R's,
> John
--
-JH
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On November 18, 2021 at 11:15 cabo@tzi.org (Carsten Bormann) wrote:
> 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.

They do have one thing in common which is people will immediately
shoot down proposals because they would take TEN (pick a number) YEARS
to make any difference.

And they'll continue saying that for 20+ years every time it comes up
absolutely certain each time that it's a showstopper.

My take is people reflexively don't like change, they tend to not like
others' solutions (the NIH reaction), and if they can get past those
they certainly want only a solution which can be deployed in a very
short period of time, likely to make a difference in a year or two if
not sooner, at no "cost".

Which is how we get things like yet another layer of encryption since
they're invariably voluntary (DO/DON'T, WILL/WON'T designs, default
DON'T), just cobbled into some existing protocol so can be deployed
immediately at least by a handful of supporters w/o any disruption or
urgency. At least those are failsafe, when almost no one adopts it who
cares?

(I realize there's no encryption involved here IT'S AN ANALOGY, a
meta-observation, OK?)

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

I don't believe this is being proposed as a final...etc, just:

So long as we do have a shortage how might we at least not waste what
we do have so history doesn't laugh at us.

Let's engineer it to its inevitable depletion and not be even the
tiniest bit guilty of having exacerbated the runout in the vain and
futile hope that it might speed up IPv6 adoption.

--
-Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD
The World: Since 1989 | A Public Information Utility | *oo*
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Time comes at you fast :-)

The POSIX committee has officially adopted 64-bit time_t as a requirement
in the working draft of IEEE Std. 1003.1-202x and ISO/IEC 9945.

One thing to cross off my list. And I was looking forward to all the time
machines crashing into the University of California Berkeley quad on
03:14:07 UTC on 19 January 2038.


On Wed, 17 Nov 2021, Sean Donelan wrote:
> 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
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
Fred Baker <fredbaker.ietf@gmail.com> wrote:
> My observation has been that people don't want to extend the life of
> IPv4 per se; people want to keep using it for another very short time
> interval and then blame someone else for the fact that the 32 bit
> integers are a finite set.

It's an attractive strawman, but knocking it down doesn't
contribute to the discussion.

I am not blaming anybody for the finity of 32-bit integers.

Nor am I trying to extend the lifetime of IPv4, for either a short or a
long time. Personally, I think that IPv4 will already be with us for
the rest of my lifetime. Its life will already extend beyond mine,
without any effort on my part. It was a good design, and it will
outlive its makers. The people who in 2008 predicted that it was
senseless to improve IPv4 because it would be dead by 2018, were
objectively wrong, because it's not dead.

IETF did what the objectors said, back in 2008: They didn't improve
IPv4, on the exact theory that effort would go into IPv6 instead. Hmm.
13 years later, that decision did not cause IPv6 to take over the world
and obsolete IPv4. IPv4 is still here, and the improvements that would
have been fully rolled out to the user base by now, if standardized in
2008, are still missing. Perhaps we should reconsider that wrong
advice, rather than regurgitate the same decision every time the issue
is raised?

> If you don't think that's a true statement, I'd be very interested to
> hear what you think might be true.

IPv6 is still on a remarkable if not meteoric growth ramp; in the last
year it's gone from 30% to 34% of the Internet, according to Google.
There is no need to cut off IPv4 maintenance at the knees in order to
make IPv6 look good. We can make both v4 and v6 better, and let people
choose which one(s) they prefer to use.

That's what I think might be true about why simple low-risk tweaks that
make IPv4 better are not an obviously stupid tactic.

As Brian Carpenter has been saying for 15+ years, IPv4 and IPv6 don't
have a transition strategy, they have a co-existence strategy.
Neglecting or abandoning IPv4 is not a useful part of that strategy.

Keeping the price of IPv4 addresses reasonable means that dual-stack
servers can continue to be deployed at reasonable cost, so that it
doesn't matter whether clients have IPv6 or IPv4. Any company that put
its services on IPv6-only sites today would be cutting off 65% of their
potential customers. Even if v6 had 90% of the market, why would a
company want 10% of its prospects to be unable to reach its service?

(Big companies who run massive public-facing server farms are the
biggest buyers of IPv4 addresses in the market, spending hundreds of
millions of dollars every year. Amazon, Google, Alibaba, Microsoft,
etc. They are already running IPv6, and all their servers already have
free IPv6 addresses from a RIR. Why are they spending that money?
It isn't because they are stupid doodooheads who hate IPv6.)

As Fred points out, this issue has been discussed since 2008. IETF also
faced it in 2014-2018 in the now-sunsetted "sunset4" working group.
That group wrote a bunch of drafts proposing to disable or sunset IPv4.
None of these became RFCs. They didn't pass the sniff test. They
weren't what users and customers wanted.

The issue keeps coming back because the wrong decision keeps getting
offered: "Just switch everybody to use IPv6, and if they won't, then
deny their proposals for IPv4." Another way of putting it was proposed
by Dave Thaler: "Rather than changing any existing software (OS's or
apps) to allow class E addresses, the effort would be better spent
towards getting more IPv6 deployment."

This is not an objection to deploying reserved addresses in IPv4, it is
a plea for more IPv6 deployment. It is like saying, "Do not spend your
time fixing the environment, instead we need to fix the political
system."

It is a hopeless plea, since "allowing Class E addresses" and "more IPv6
deployment" are not the only two possible goals to put forth effort on.
Merely stopping work on one, will not cause the other to be advanced.
There must be a name for this fallacious argument...thank you, Wikipedia,
it's a "false dilemma":

https://en.wikipedia.org/wiki/False_dilemma

The two goals can proceed in parallel, and many of the people who would
happily do Goal 1 are not in any position to affect Goal 2 -- just as
with the environment and politics.

It's pretty simple to understand why IPv6 has not taken over the world
yet. IPv4 got rapid adoption because it was so much better than all the
alternatives available at the time. IPv6 would have gotten equally
rapid adoption if it had been the thing so much better than all the
alternatives. IPv6 is not getting that rapid adoption today, because it
has to compete with the already pervasive IPv4. IPv4 is better in one
key way: everybody you want to talk with is already there. (It's akin
to the issue of why can't people just switch to a better social network
than Facebook? They can, but everybody else they want to talk with is
already on Facebook.)

There is no need to cut off IPv4 maintenance at the knees in order to
make IPv6 look good. Simple, low-risk tweaks that make IPv4 better are
not a stupid thing to do.

John
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
Sent using a machine that autocorrects in interesting ways...

> On Nov 18, 2021, at 5:15 PM, John Gilmore <gnu@toad.com> wrote:
>
> Keeping the price of IPv4 addresses reasonable means that dual-stack
> servers can continue to be deployed at reasonable cost, so that it
> doesn't matter whether clients have IPv6 or IPv4. Any company that put
> its services on IPv6-only sites today would be cutting off 65% of their
> potential customers. Even if v6 had 90% of the market, why would a
> company want 10% of its prospects to be unable to reach its service?

I find myself thinking about Reliance JIO, an Indian company. Iirc, their IPv4 and IPv6 statistics are in the slide deck they presented to the IETF a year or two back, and they came to me/us a little later wanting somehow expand the IPv4 address pool. In short, most of their services are IPv6 only. The only thing they want IPv4 addresses for is their enterprise customers, who want an IPv4 option wherever IPv6 is an option - so they don’t have to select IPv6.

That’s all we’ll and good if the IPv4 addresses exist and work globally. Someone (was it you?) noted earlier in the thread that it might be acceptable to provide IPv4 address space that only worked in certain places. I find myself thinking about the arguments for a global DNS root. What a regional IPv4 connectivity limit creates is a network that doesn’t work everywhere, meaning that the government of <> will be incented to deploy that address space locally within their country and provide a national NAT firewall to somehow protect their citizens - because of course the bad guys are always somewhere else. Kind of like the US wants to regulate encryption because nobody outside the US uses it or whatever. WHATEVER!

I tend to think that if we can somehow bless a prefix and make be global unicast address space, it needs to become Global Unicast Address Space.

This is becoming a rant, so I’ll stop…
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Subject: Re: Redploying most of 127/8 as unicast public Date: Thu, Nov 18, 2021 at 01:46:04PM -0800 Quoting William Herrin (bill@herrin.us):
>
> The detractors for this proposal and those like it make the core claim
> that we shouldn't take the long view improving IPv4 because IPv6 is
> going to replace it any day now. Each day that passes with the end of
> IPv4 still not in sight demonstrates how very wrong that strategy is.

Aw, come on. There is noone (except naive ones in power) who expect this
to happen immediately. We all knew there would be a transition
period. The "improvement" part was CIDR. And a very good one it is at
that -- it sort of sets the standard as to what an improvement should
be to count. 6,25% new addresses from Net 240 is not an improvement in
that regard, and neither would the much smaller contribution from Net
127 be. Both are no more than holding paper money on the deck of the
Titanic.

The essence of an IP address is that it is unique. The larger the network
area is that recognizes it as unique, the better it is. That's why RFC
1918 is free and useless. We all know this.

The only viable future is to convert. This is not group-think, it is simple math.

> If there's a change we can make to a standard now which will result in
> IPv4 being better 20 years from now, we should make it. We should hope
> that we never need the result because IPv6 takes over the world but we
> should make the change anyway. Because hedging our bets is what
> responsible people do.

You are proposing a deal involving paper money you have on your person
to your fellow passengers on the Titanic; that is the essence of your
proposed bet hedging. Having studied the market for IPv4, it is a no-
brainer to realise the driving force behind all these schemes. Delaying
the inevitable is just going to make some people richer, to the detriment
of others. I see no reason to support that.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
Yow! It's a hole all the way to downtown Burbank!
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Thu, Nov 18, 2021 at 11:20 PM Måns Nilsson <mansaxel@besserwisser.org> wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Thu, Nov 18, 2021 at 01:46:04PM -0800 Quoting William Herrin (bill@herrin.us):
> > The detractors for this proposal and those like it make the core claim
> > that we shouldn't take the long view improving IPv4 because IPv6 is
> > going to replace it any day now. Each day that passes with the end of
> > IPv4 still not in sight demonstrates how very wrong that strategy is.
>
> Aw, come on. There is noone (except naive ones in power) who expect this
> to happen immediately. We all knew there would be a transition
> period. The "improvement" part was CIDR. And a very good one it is at
> that -- it sort of sets the standard as to what an improvement should
> be to count. 6,25% new addresses from Net 240 is not an improvement in
> that regard, and neither would the much smaller contribution from Net
> 127 be. Both are no more than holding paper money on the deck of the
> Titanic.
>
> The essence of an IP address is that it is unique. The larger the network
> area is that recognizes it as unique, the better it is. That's why RFC
> 1918 is free and useless. We all know this.
>
> The only viable future is to convert. This is not group-think, it is simple math.
>
> > If there's a change we can make to a standard now which will result in
> > IPv4 being better 20 years from now, we should make it. We should hope
> > that we never need the result because IPv6 takes over the world but we
> > should make the change anyway. Because hedging our bets is what
> > responsible people do.
>
> You are proposing a deal involving paper money you have on your person
> to your fellow passengers on the Titanic; that is the essence of your
> proposed bet hedging. Having studied the market for IPv4, it is a no-
> brainer to realise the driving force behind all these schemes. Delaying
> the inevitable is just going to make some people richer, to the detriment
> of others. I see no reason to support that.

Howdy,

I can't tell if you believe what you just wrote or are trolling me
with satire. If it's satire... good one.

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Mans Nilsson wrote:

> The essence of an IP address is that it is unique. The larger the network
> area is that recognizes it as unique, the better it is.

With proper layering, network addresses including IP ones, certainly,
uniquely identify *hosts*.

However, with proper layering, *applications* only require uniqueness
of IP+Port, which is enough for the worldwide IPv4 network.

As a result, NAT won the battle against IPv6.

IPv6 addresses are free but useless.

Masataka Ohta
Re: Redploying most of 127/8 as unicast public [ In reply to ]
This will break a significant number of existing deployments where people
have come to depend on a feature in Linux where any address within 127.0.0.0/8
can be “listened” and operate as a valid loopback address without configuring
the addresses individually as unicast on the interface.

In fact, this is true of any prefix assigned to the loopback interface, but 127.0.0.0/8
is automatic and difficult to change.

While I’m not sure this implementation in the Linux kernel was such a wonderful
idea, it is widely deployed and in use in a number of environments.

If we’re still using IPv4 widely enough that GUA space matters, we will have
far bigger problems than the lack of available GUA for it.

Owen


> On Nov 17, 2021, at 16:15 , William Herrin <bill@herrin.us> wrote:
>
> 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 ]
> On Nov 17, 2021, at 16:32 , Sean Donelan <sean@donelan.com> wrote:
>
> 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

How is this a problem?

> 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: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 17, 2021, at 19:03 , John Levine <johnl@iecc.com> wrote:
>
> 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.

There is an (admittedly questionable) argument to be made that application updates would not
have been necessary for this, just every OS/Computer/Router/Switch/IDS/IPS/etc.

> 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 fact, the world has not run out, AFRINIC still has a free pool. Unfortunately in an astonishing display
of collective “don’t get it”, they’ve deployed protectionist policies that make it incredibly difficult to get
addresses from AFRINIC, ensuring that while the continent still suffers from the same level of IPv4
address shortage as the rest of the world, the illusion of a useful free pool there will remain for years
to come.

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

Site local was deprecated many many years ago.

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

Depends on your definition of “without any network interfaces”, since technically the loopback interface is a network interface.

If you mean “an IPv6 system with no interfaces other than loopback”, then yes, it can because you are free to assign additional
addresses to the loopback interface, but ::1/128 is the only address universally assigned to the loopback interface.

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

On a system with no network interfaces other than loopback, it really doesn’t matter what you do… LLA, ULA, and GUA
could be used in any combination without negative impact. Nothing is leaving the box, so it might as well be an entire
IPv6 internet unto itself.

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

Meh. I think individually assigning addresses for those cases isn’t the worst thing in the world, but there are some
circumstances in which the linux kernel’s unique behavior in this regard can be convenient.

> In IPv6 I use ULAs since that gives me the option of routing them or not.

Well… I use GUAs because that gives me the option of routing them widely or narrowly or not.

ULAs don’t have the option to route them widely without resorting to at least NPT which is nearly as hideous as NAPT.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 17, 2021, at 19:40 , Jerry Cloe <jerry@jtcloe.net> wrote:
>
>
>
> Subject: Redploying most of 127/8 as unicast public
> To: nanog <nanog@nanog.org <mailto: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 <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.
>

You are assuming facts not in evidence.

The fact that a prefix isn’t in a routing table you can see does not mean it is not used in a circumstance where
having it appear in routing tables you can see would be harmful or disruptive.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 17, 2021, at 21:33 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> 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.

This contention is provably false for some definitions of “in use”.

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

In what way would the LLA or ULA above be meaningfully different from 127/8 as deployed?

> At the very least, it is semantically not.

How so?

> Doesnt IPv6 deserve its own instead of squatting on IPv4?

I don’t see any “squatting on IPv4” here.

Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread, having a prefix
dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best
tradeoff.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Can you be more specific about what changes to IPv6 you believe would resolve the issue?

Owen


> On Nov 18, 2021, at 01:43 , borg@uu3.net wrote:
>
> 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: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
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


> On Nov 17, 2021, at 19:33 , Dave Taht <dave.taht@gmail.com> wrote:
>
> 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 ]
On Fri, Nov 19, 2021 at 7:00 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread, having a prefix
> dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best
> tradeoff.

I would prefer to discuss the other drafts. However, - and this is not
in the 127 draft, and is an opinion not shared with the other authors
-
I have a specific use case for making 127 "more routable", in that
there is nowadays a twisty maze of microservices, bottled up in a
variety of
kubernetes containers, running on top of vms, on top of a hypervisor,
that are often hooked together via rfc1918 addressing and NAT.

Trying to figure out that particular path, from within one of those
containers, can be a PITA. The concept of 127 being local to a
physical host
(and routed internally, rather than natted), where those twisty maze
of services ideally remains within that host, holds some appeal to me.

>
> Owen
>


--
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Owen DeLong wrote:
>
>> On Nov 17, 2021, at 21:33 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>>
>>
>> And I think the basic contention is that the vast majority of 127/8 is not in use. Apples to oranges, indeed.
> This contention is provably false for some definitions of “in use”.

Determining the extent of this would be part of serious consideration.
>
> In what way would the LLA or ULA above be meaningfully different from 127/8 as deployed?

Because 127/8 is the exact same number on every system and it is routed
the same way on every system and every system can choose to use it how
it and it alone wishes to.

So this make it a deterministic prefix solely in control of the local
system without any external context to ever be taken into consideration,
by convention and standard.

LLA and ULA and whatever random prefix you may wish to use for loopback,
whether in IPv6 or even IPv4 have none of these qualities.

>
>> Doesnt IPv6 deserve its own instead of squatting on IPv4?
> I don’t see any “squatting on IPv4” here.

It means that the only deterministic loopback prefix in IPv6 larger than
a single address is the one IPv6 inherited from IPv4.
>
> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread,

This is not my point, it is the contention of the draft standard and it
is something I would hope is taken into serious consideration and
researched properly/

My point is that to the extent this is true, the value of the space for
other purposes could very well warrant re-purposing.
> having a prefix
> dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best
> tradeoff.
>
> Owen
>
But this is how it is to be done in IPv6, so lets get some lack-of-feature parity going with IPv4.

Joe
Re: WKBI #586, Redploying most of 127/8 as unicast public [ In reply to ]
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
Re: Redploying most of 127/8 as unicast public [ In reply to ]
>
> You are proposing a deal involving paper money you have on your person
> to your fellow passengers on the Titanic; that is the essence of your
> proposed bet hedging. Having studied the market for IPv4, it is a no-
> brainer to realise the driving force behind all these schemes. Delaying
> the inevitable is just going to make some people richer, to the detriment
> of others. I see no reason to support that.

That’s because you and I are probably on the wrong side of the benefit/detriment
divide.

No doubt those pushing the proposal(s) think they have a way to be on the
benefit side of said divide.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 19, 2021, at 07:23 , Dave Taht <dave.taht@gmail.com> wrote:
>
> On Fri, Nov 19, 2021 at 7:00 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
>> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread, having a prefix
>> dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best
>> tradeoff.
>
> I would prefer to discuss the other drafts. However, - and this is not
> in the 127 draft, and is an opinion not shared with the other authors
> -
> I have a specific use case for making 127 "more routable", in that
> there is nowadays a twisty maze of microservices, bottled up in a
> variety of
> kubernetes containers, running on top of vms, on top of a hypervisor,
> that are often hooked together via rfc1918 addressing and NAT.
>
> Trying to figure out that particular path, from within one of those
> containers, can be a PITA. The concept of 127 being local to a
> physical host
> (and routed internally, rather than natted), where those twisty maze
> of services ideally remains within that host, holds some appeal to me.

Couldn’t you do this with 169.254.0.0/16 (or IPv6 GUA or ULA)
just as easily without the need to rewrite virtually every layer of the
stack of miscellaneous software defined networking stuff you just listed?

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 19, 2021, at 07:39 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>>
>>> On Nov 17, 2021, at 21:33 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>>>
>>>
>>> And I think the basic contention is that the vast majority of 127/8 is not in use. Apples to oranges, indeed.
>> This contention is provably false for some definitions of “in use”.
>
> Determining the extent of this would be part of serious consideration.
>>
>> In what way would the LLA or ULA above be meaningfully different from 127/8 as deployed?
>
> Because 127/8 is the exact same number on every system and it is routed the same way on every system and every system can choose to use it how it and it alone wishes to.

But the proposal seeks to change that nature of 127.0.0.0/8 to make it more like LLA/ULA, so…

> So this make it a deterministic prefix solely in control of the local system without any external context to ever be taken into consideration, by convention and standard.

At the moment, that’s already true. AIUI, the proposal being discussed seeks to convert 127.0.0.0/8 outside of 127.0.0.1 (or at least outside of 127.0.0.0/16) into
routable GUA.

> LLA and ULA and whatever random prefix you may wish to use for loopback, whether in IPv6 or even IPv4 have none of these qualities.

And if we implement the proposal at hand, which as near as I can tell you are supporting, that changes.

>>> Doesnt IPv6 deserve its own instead of squatting on IPv4?
>> I don’t see any “squatting on IPv4” here.
>
> It means that the only deterministic loopback prefix in IPv6 larger than a single address is the one IPv6 inherited from IPv4.

Well… Worst case, it could use ::ffff:7f00:0000::/96

Whether you consider that “squatting on IPv4” or not is left as an exercise to the reader. I do not, though I can understand and
must admit that it is equally legitimate if someone else does.

>> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread,
>
> This is not my point, it is the contention of the draft standard and it is something I would hope is taken into serious consideration and researched properly/
>
> My point is that to the extent this is true, the value of the space for other purposes could very well warrant re-purposing.

Having trouble following your desired outcome here. It seems as if you both want 127.0.0.0/8 to retain it’s unique properties
as deterministically loopback only and also want the benefits of repurposing it as GUA.

Have cake, Eat cake, please to pick only one.

>> having a prefix
>> dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best
>> tradeoff.
>>
>> Owen
>>
> But this is how it is to be done in IPv6, so lets get some lack-of-feature parity going with IPv4.

I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity.

IMHO, having additional loopbacks be assigned from either LLA or ULA space (or even GUA, really)
where that is needed is a superior choice vs. 127.0.0.0/8.

For one thing, the alternative addressing schemes (other than LLA) allow for routing of the
addresses off the box even though they are configured on loopback interfaces. There are
a number of situations where this can be a useful way to ensure that the addresses remain
usable regardless of the up/down state of connectivity on any particular non-loopback
interface on the box.

It’s one of the reasons, for example, that virtually every IBGP speaking router has a GUA
or ULA/1918 loopback address which is routed in the IGP and almost all IBGP sessions
are terminated on those loopback interfaces.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Fri, Nov 19, 2021 at 8:35 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
> I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity.

Me too, just not in a dystopian Harrison Bergeron sort of way.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: Redploying most of 127/8 as unicast public [ In reply to ]
So see, that was kinda my view, though I hadn't realized there was a kernel
hack advancing the football...

----- Original Message -----
> From: "Owen DeLong" <owen@delong.com>
> To: "William Herrin" <bill@herrin.us>
> Cc: "jra" <jra@baylink.com>, "nanog" <nanog@nanog.org>
> Sent: Friday, November 19, 2021 9:28:01 AM
> Subject: Re: Redploying most of 127/8 as unicast public

> This will break a significant number of existing deployments where people
> have come to depend on a feature in Linux where any address within 127.0.0.0/8
> can be “listened” and operate as a valid loopback address without configuring
> the addresses individually as unicast on the interface.
>
> In fact, this is true of any prefix assigned to the loopback interface, but
> 127.0.0.0/8
> is automatic and difficult to change.
>
> While I’m not sure this implementation in the Linux kernel was such a wonderful
> idea, it is widely deployed and in use in a number of environments.
>
> If we’re still using IPv4 widely enough that GUA space matters, we will have
> far bigger problems than the lack of available GUA for it.
>
> Owen
>
>
>> On Nov 17, 2021, at 16:15 , William Herrin <bill@herrin.us> wrote:
>>
>> 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/

--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
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 ]
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Owen DeLong wrote:
>
>> LLA and ULA and whatever random prefix you may wish to use for loopback, whether in IPv6 or even IPv4 have none of these qualities.
> And if we implement the proposal at hand, which as near as I can tell you are supporting, that changes.
>
> Having trouble following your desired outcome here. It seems as if you both want 127.0.0.0/8 to retain it’s unique properties
> as deterministically loopback only and also want the benefits of repurposing it as GUA.
>
> Have cake, Eat cake, please to pick only one.

Let me clear that up then.

I support serious consideration of the idea. My desired outcome is to
see ideas like these either adopted or not but based solely on their own
merits and especially in their own protocol context. And that folk who
have studied the issue and invested their efforts be taken seriously and
not be met with undeserved and might I add, unkind, scorn.

(I havent studied the issue or invested the effort, so you may continue
to direct your scorn this way)

Its well past time to stop behaving as if we are a bunch of teenagers on
a private BBS.

I like the loopback prefix feature of IPv4.

I can easily concede that its too large, especially in this day and age.
And that there is a good chance that significant benefit can come from
addressing that before IPv4 becomes obsolete.

I question the lack of dedicated loopback feature in IPv6 and I
acknowledge that yes, you can accomplish the same with non loopback
prefixes by essentially assigning them to loopback, but point out that
that does not make them the same thing.

I can understand that sometimes you may explicitly not want to use the
loopback prefix for loopback applications. In fact many times. However,
you dont really have much options when it comes to IPv6.

And I discuss IPv6 loopback simply because of the pushback directed in a
non-meritorious fashion from folk who apparently believe simultaneously
that IPv6 is superior in every way to IPv4 and that any
improvements|changes to IPv4 somehow endanger IPv6 imminent dominance.
>
>>> having a prefix
>>> dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best
>>> tradeoff.
>>>
>>> Owen
>>>
>> But this is how it is to be done in IPv6, so lets get some lack-of-feature parity going with IPv4.
> I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity.


Actually I am (somewhat facetiously) suggesting that IPv4 have
non-feature parity with IPv6 by taking away its loopback prefix.


>
> IMHO, having additional loopbacks be assigned from either LLA or ULA space (or even GUA, really)
> where that is needed is a superior choice vs. 127.0.0.0/8.

Anyone who wants to assign routable IPv4 to loopback is free to do so
and there are plenty of IPv4 ranges to choose from.

The converse is not true in IPv6.
>
> For one thing, the alternative addressing schemes (other than LLA) allow for routing of the
> addresses off the box even though they are configured on loopback interfaces. There are
> a number of situations where this can be a useful way to ensure that the addresses remain
> usable regardless of the up/down state of connectivity on any particular non-loopback
> interface on the box.
>
> It’s one of the reasons, for example, that virtually every IBGP speaking router has a GUA
> or ULA/1918 loopback address which is routed in the IGP and almost all IBGP sessions
> are terminated on those loopback interfaces.
>
> Owen
>
And its the fairly common way of implementing anycast services. But that
is not what we are addressing on this thread.

I actually think that IPv6 evangelicals should welcome any all ideas
like this, especially if they believe it will further degrade the
overall state of IPv4, because that should only serve as stronger
impetus for IPv6 deployment. That mode of thought has been commonly
expressed here and other places before.

Best,

Joe
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
Joe Maimon <jmaimon@jmaimon.com> wrote:
> And all thats needed to be done is to drop this ridiculous .0 for
> broadcast compatibility from standards.....why is this even controversial?

Not to put words in his mouth, but that's how original BSD maintainer
Mike Karels seemed to feel when we raised this issue for FreeBSD. He
was like, what? We're wasting an address per subnet for 4.2BSD
compatability? Since 1986? Let's fix that.

John
Re: Redploying most of 127/8 as unicast public [ In reply to ]
=?utf-8?B?TcOlbnM=?= Nilsson <mansaxel@besserwisser.org> wrote:
> The only viable future is to convert [to IPv6]. This is not
> group-think, it is simple math.

OK. And in the long run, we are all dead. That is not group-think, it
is simple math. Yet that's not a good argument for deciding not to
improve our lives today. Nor to fail to improve them for tomorrow,
in case we live til then.

John </philosophy>
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
Fred Baker <fredbaker.ietf@gmail.com> wrote:
> I tend to think that if we can somehow bless a prefix and make be
> global unicast address space, it needs to become Global Unicast
> Address Space.

Yes, I agree. The intention is that with the passage of time, each
prefix becomes more and more reachable, til it's as close to 100% as any
other IP address.

I was just suggesting a side point, that some kinds of IP users may be
able to make earlier use of measurably less-reachable addresses. That
could possibly enable them to get those addresses at lower prices (and
with no guarantees), compared to people who want and expect 100%
reachable IP addresses. Having users making actual early use of them
would also encourage those users to actively work to improve their
reachability, rather than passively waiting til "somebody else" improves
their reachability. (Indeed, some adventurous early adopters might buy
such addresses, actively improve their reachability, then 'flip' them
for higher prices, as some people do with real-estate.) Just pointing
out a side chance for a win-win situation. Most users would wait til
surveys show high reachability.

John
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Subject: Re: Redploying most of 127/8 as unicast public Date: Fri, Nov 19, 2021 at 12:26:23PM -0800 Quoting John Gilmore (gnu@toad.com):
> =?utf-8?B?TcOlbnM=?= Nilsson <mansaxel@besserwisser.org> wrote:
> > The only viable future is to convert [to IPv6]. This is not
> > group-think, it is simple math.
>
> OK. And in the long run, we are all dead. That is not group-think, it
> is simple math. Yet that's not a good argument for deciding not to
> improve our lives today. Nor to fail to improve them for tomorrow,
> in case we live til then.

The math is true today. Most people now have more devices than they have
IP addresses. (And reachability should be choice, not shortage
consequence) Increasing the available address space by at most a few
percent at the price of a flag day is not a good return. (unless you
are in a position to profit from the shortage, at which point all these
crutch proposals look irresistible if not from a technical standpoint)
Increasing the address space 79228162514264337593543950336 times at
the price of rolling software upgrades that actually mostly are done
(I haven't bought or commissioned non-v6 gear for 15 years now), even
if there's a lot left to turn on and configure, is a slightly better
proposition.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
MY income is ALL disposable!
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Subject: Re: Redploying most of 127/8 as unicast public Date: Fri, Nov 19, 2021 at 09:04:59PM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp):
> Mans Nilsson wrote:
>
> > The essence of an IP address is that it is unique. The larger the network
> > area is that recognizes it as unique, the better it is.
>
> With proper layering, network addresses including IP ones, certainly,
> uniquely identify *hosts*.
>
> However, with proper layering, *applications* only require uniqueness
> of IP+Port, which is enough for the worldwide IPv4 network.
>
> As a result, NAT won the battle against IPv6.
>
> IPv6 addresses are free but useless.

With all due respect, you think about networks. I use and build
networks. And my experience is that IP+port is not enough. We cope,
because a lot of technical debt is amassed in corporate and ISP /
access provider networks that won't change. We don't cope because NAT is
good. Hardly a workday goes past without me thinking "If I could address
this computer uniquely I'd go home earlier and with less grey hair".

We must do better.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
Do you have exactly what I want in a plaid poindexter bar bat??
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Mans Nilsson wrote:

>> With proper layering, network addresses including IP ones, certainly,
>> uniquely identify *hosts*.
>>
>> However, with proper layering, *applications* only require uniqueness
>> of IP+Port, which is enough for the worldwide IPv4 network.
>>
>> As a result, NAT won the battle against IPv6.
>>
>> IPv6 addresses are free but useless.
>
> With all due respect, you think about networks. I use and build
> networks. And my experience is that IP+port is not enough.

Certainly, local uniqueness of IP addresses to identify hosts
is required even in private networks behind NAT. But, because
of layering, that's all.

I do have extensive experiences to use and build networks
with proper layering in mind.

> We cope,
> because a lot of technical debt is amassed in corporate and ISP /
> access provider networks that won't change.

Sounds like abstract nonsense.

> We don't cope because NAT is
> good. Hardly a workday goes past without me thinking "If I could address
> this computer uniquely I'd go home earlier and with less grey hair".

The reality is that application servers only need globally unique
and stable IP+Ports.

You can address application servers with them.

> We must do better.

As IPv6 is worse than IPv4 with NAT, feel free to propose a new
network protocol.

Masataka Ohta
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp):

> > We cope,
> > because a lot of technical debt is amassed in corporate and ISP /
> > access provider networks that won't change.
>
> Sounds like abstract nonsense.

No, it is the real reason that we still have v4 around.

> > We don't cope because NAT is
> > good. Hardly a workday goes past without me thinking "If I could address
> > this computer uniquely I'd go home earlier and with less grey hair".
>
> The reality is that application servers only need globally unique
> and stable IP+Ports.
>
> You can address application servers with them.

If, and that is a big IF, they're designed for that. Hint: They're not,
and I'm required to deploy technology compatible with older systems and
systems outside my control. It would be far easier for me if I could
continue with the original assumption -- IP addresses are identifiers.

I know you will immediately state that if I change everything else except
the IP addressing scheme at 32 bits plus 16 bits of port space (which in
and of itself is a change; granted more so in terms of service location),
I will be fine. But I only want to change the addressing layer. The rest
works fine. And is a bigger mess to alter to your idea.

> > We must do better.
>
> As IPv6 is worse than IPv4 with NAT, feel free to propose a new
> network protocol.

In your application, that assertion on worseness might be true. In my,
where I value the E2E principle higher, no, I think it is not.


--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
I used to be a FUNDAMENTALIST, but then I heard about the HIGH
RADIATION LEVELS and bought an ENCYCLOPEDIA!!
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Sat, 20 Nov 2021, 09:21 Måns Nilsson, <mansaxel@besserwisser.org> wrote:

> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20,
> 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (
> mohta@necom830.hpcl.titech.ac.jp):
>
> > > We cope,
> > > because a lot of technical debt is amassed in corporate and ISP /
> > > access provider networks that won't change.
> >
> > Sounds like abstract nonsense.
>
> No, it is the real reason that we still have v4 around.
>

The "real" reason we have IPv4 around is that it works. Having IPv4+IPv6 is
relatively easy, but dropping IPv4 to run IPv6 only is difficult. Some
examples:

***

1. Your power goes out. When it comes back up, your internet connection is
down. You want to log in to the router... Except you can't. You don't know
the address, and you won't have one until your ISP gives you one via DHCP
(or similar).

Sure, you could maybe provide the link-local address on the bottom of the
router, but expecting a user to get http://[fe80:211:aaff:febb:ccdd] right
(and you might even need interface scoping!) is boring to cause user
frustration when an ISP tech support tries to help, and having the provided
CPE using fe80::1 is probably a recipe for disaster.

Likewise, having an mdns broadcast (ssssh, I know) for "gateway" or
"router" is definitely not something standardised.

2. Your IPv6 prefix changes. With some ISPs, it can change every time your
router reboots, and if you're with my ISP, it crash-reboots about once a
week! If your CPE isn't providing your WiFi (range extender, mesh, nerd
etc) then the old prefix is still valid for a while. Yes, there's an RFC to
deal with this, but realistically it's not out there today.

Also, any local services are going to break if they're on static
addresses... I'm not just talking enterprise AD servers etc, it's also CCTV
cameras, raspberry pis, NAS units etc. DHCP registration of addresses in
DNS exists, yes, but it's just not used by most of these devices.

This could easily be fixed by having a well-known (and short/memorable!)
/48 set aside that would have NAT66 (1:1, not port overload) applied at the
router to the delegated prefix received from the ISP, but I'll be shouted
down to hell for even mentioning that idea.

3. IPv6 "port forwarding" isn't really an easy thing -- people are not used
to each machine having a global address. Sure, on many devices you can add
firewall rules to allow traffic in, but it's not like the "port forwarding"
concept people have gotten used to. I genuinely have no idea whether
upnp/nat-pmp has an IPv6 analogue that "just works" which things like
consoles (or apps like syncthing) can take advantage of.

***

IPv4 works. There is no appreciable benefit to the user in enabling IPv6,
but the ISP does it and it just works. The same can't be said of going IPv6
only -- you can easily provide IPv6 only with NAT64 and DNS64 or some
XLAT464 fun when you're dealing with public WiFi, but this is people's
homes and businesses.

Likewise, there's so many devices that are IPv4 only, and aren't getting
retired anytime soon. In fact, there's a lot of devices released in the
last few years that fully support IPv6, but only when it also has an IPv4
address. I believe either the new Xbox and/or PS5 fit into that category.

IPv4 is getting more expensive for ISPs because of addressing costs, but a
5-tuple CGNAT solution capable of saturating a 100Gb/s pipe is under $10k
these days if you're doing it on the cheap. Yes, this is massively
oversimplified.

Not just that, if you have a CPE capable of doing MAP-T (RFC7599 et al)
then your CGNAT doesn't even need to track state, and you can probably do
it in ASIC, especially with a programmable dataplane (P4 etc).

IPv6 only is the goal. IPv4 is going to be with us for at least a decade.
Getting IPv6 up and running on a network requires a lot of effort when that
network is run by the IT PFY, but it will slowly get that wide penetration
desired... Turning off IPv4 for your regular residential and SME ISP
connections is such a PITA fraught with support problems that it is just
not practical outside of very limited conditions.

Certainly, on the content side, you can make all your HTTP services on IPv6
only servers, and have the IPv4 go to a proxy that routes based on Host
header or SNI, but you need some networking knowledge already to understand
what is going on there.

IPv4 isn't going anywhere anytime soon. Enabling IPv6 reduces IPv4 traffic
levels, it does not reduce IPv4 address usage.

Happy for someone to prove me wrong here, but don't use mobile as an
example. That's a very different market... I'm talking about residential
and SOHO internet access here only.

M
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Mans Nilsson wrote:

>>> We cope,
>>> because a lot of technical debt is amassed in corporate and ISP /
>>> access provider networks that won't change.
>>
>> Sounds like abstract nonsense.
>
> No, it is the real reason that we still have v4 around.

Even more than 25 years after IPv6 became a proposed standard?

It merely means IPv6 is not deployable with the real reason.

>> The reality is that application servers only need globally unique
>> and stable IP+Ports.
>>
>> You can address application servers with them.
>
> If, and that is a big IF, they're designed for that. Hint: They're not,
> and I'm required to deploy technology compatible with older systems and
> systems outside my control. It would be far easier for me if I could
> continue with the original assumption -- IP addresses are identifiers.

The proper layering, which you insist to ignore, is that IP addresses
are identifiers at the network layer whereas IP+Ports are the
identifiers at above layers.

> I know you will immediately state that if I change everything else except
> the IP addressing scheme at 32 bits plus 16 bits of port space (which in
> and of itself is a change;

It was.

It was the changed made by deploying NAT, which was a lot lot lot
less painful to support IPv6.

> But I only want to change the addressing layer.

There is no such layer as "the addressing layer".

At the transport layer, connections are addressed by network
addresses and port numbers, which means address there in the
Internet is IP+Port.

I really recommend you to understand proper layering.

> In your application, that assertion on worseness might be true. In my,
> where I value the E2E principle higher, no, I think it is not.

So, you are rather a theorist than a practitioner.

However, I'm both of them.

See:

https://datatracker.ietf.org/doc/html/draft-ohta-e2e-nat-00

to understand that properly architected NAT preserves the so
valuable E2E principle.

For example, I confirmed with my implementation that PORT command
of ftp perfectly works over the E2E NAT gateways.

After finding that, I, as a theorist, totally abandoned IPv6.

Masataka Ohta
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 11:16:59AM +0000 Quoting Matthew Walster (matthew@walster.org):

> The "real" reason we have IPv4 around is that it works.

It works in our present context, good enough that the pain of moving
looks bad to many people. This is Ohta-san's argument too.

> 3. IPv6 "port forwarding" isn't really an easy thing -- people are not used
> to each machine having a global address.

This is the problem in a nutshell. After 27 years of destroying the
E2E model on the internet, people do not anymore understand how IP
(regardless of version) was supposed to work; any node to any node.

Why should we burden ourselves with this cumbersome and painful, useless
layer of abstraction that is "port forwarding", when the choice of
universal reachability is around the corner?

If people can set a port forward up, they can click "allow" in a
routing-based firewall interface. Only it is better, because one can
have several parallel services using well-known ports. Sometimes (most
of the time) the protocol spec has no option to change port either,
making port forwarding futile anyway. (the let's have a TXT record bunch
at it again, purposefully ignoring SRV since its inception.)

I guess juggling our pains differently is what we are doing here. What
is unthinkable to one is quite OK to someone else.

(But I am right)
--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
We just joined the civil hair patrol!
Re: Redploying most of 127/8 as unicast public [ In reply to ]
During the nation-wide lockdown of 2020, around the world, I took up
live-streaming my DJ sets online, since I couldn't play live. For those
that haven't seen them, you're welcome to my Youtube channel to catch them:

https://yt.djmt.africa/watch

Anyway, what I wanted to say is that I was streaming using an iPhone app
that turns the iPhone and iPad into a digital video capture device.

As per the links below, if this lowly, rather obscure app from an
unknown Canadian iOS developer supports IPv6 as a way to setup a remote
connection between the laptop (encoder) and iPhone/iPad, in order to
make camera adjustments so you don't have to physically walk toward the
device, what is your excuse :-)?

https://ibb.co/C8kbpPc
https://ibb.co/yYPWbvd

Mark.
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 09:04:38PM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp):

> It merely means IPv6 is not deployable with the real reason.

IPv6 is deployable. It is deployed. You are fundamentally in error. Any
conclusions stemming from the false statement "IPv6 is not deployable"
are thus false. While your statements on ports being a part of the address
might hold some value in a world where there is no alternative they are
simply too limited in a world with practically unlimited addresses.

> After finding that, I, as a theorist, totally abandoned IPv6.

You gave up, based on false conclusions.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
... I want a COLOR T.V. and a VIBRATING BED!!!
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Mans Nilsson wrote:

Supplying context you omit:

>>> No, it is the real reason that we still have v4 around.

>> Even more than 25 years after IPv6 became a proposed standard?
>> It merely means IPv6 is not deployable with the real reason.

> IPv6 is deployable. It is deployed.

If you mean ATM is deployable and was deployed, yes, you are
right. So?

>> After finding that, I, as a theorist, totally abandoned IPv6.
> You gave up, based on false conclusions.

Sorry, but I'm not interested in how you falsely recognize the
real world of practical and theoretical internetworking.

Masataka Ohta
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Once upon a time, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> said:
> It merely means IPv6 is not deployable with the real reason.

Except that is provably wrong. A significant number of people are using
IPv6 (and probably don't even know it, because it works without notice).
Almost everything you do on the US cell networks is IPv6. I'm running
over IPv6 to send this message, or when I go to Google or Facebook or
Netflix for example.

I didn't have to do anything special to get any of that to work; I use
my own CPE (which I didn't have to configure special to get IPv6), but
my provider-provided CPE also supported IPv6 out of the box. The common
client OSes all support IPv6 out of the box (only major snag I'm aware
of is Android and DHCPv6, c'mon Google, but typical residential CPE does
RA anyway so this only affects larger businesses with managed networks).

Non-general-purpose devices are lagging some, but on the game system
front, Xbox (at least) supports IPv6. IPv6 support is even in things
like my home audio receiver (Internet connected for streaming music,
which Pandora and Spotify at least support IPv6) and 5+ year old injket
printer.

Could I run IPv6 only today? No, not quite. But it's getting closer to
that point every day. Providers running CG-NAT see that getting IPv6
dual-stack deployed reduces the IPv4 bandwidth (so reduces the CG-NAT
costs) because so much is IPv6-enabled already.

--
Chris Adams <cma@cmadams.net>
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On 18-Nov-2021, at 09:10, Jerry Cloe <jerry@jtcloe.net> wrote:
>
>
>
> Subject: Redploying most of 127/8 as unicast public
> To: nanog <nanog@nanog.org <mailto: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 <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.
>
This seems to be much better idea then 127/8 or 240/8
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Sat, 20 Nov 2021 at 13:47, Måns Nilsson <mansaxel@besserwisser.org>
wrote:

> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20,
> 2021 at 11:16:59AM +0000 Quoting Matthew Walster (matthew@walster.org):
> > 3. IPv6 "port forwarding" isn't really an easy thing -- people are not
> used
> > to each machine having a global address.
>
> This is the problem in a nutshell. After 27 years of destroying the
> E2E model on the internet, people do not anymore understand how IP
> (regardless of version) was supposed to work; any node to any node.
>
> Why should we burden ourselves with this cumbersome and painful, useless
> layer of abstraction that is "port forwarding", when the choice of
> universal reachability is around the corner?
>

Because it's a REALLY bad idea to have unmanaged devices reachable from the
open internet. Dial-out, not dial-in. You need a firewall. You need a way
of punching holes in that firewall for services you explicitly allow, be
that manually through an interface, or temporarily via an automated system
like upnp/nat-pmp.


> If people can set a port forward up, they can click "allow" in a
> routing-based firewall interface. Only it is better, because one can
> have several parallel services using well-known ports. Sometimes (most
> of the time) the protocol spec has no option to change port either,
> making port forwarding futile anyway. (the let's have a TXT record bunch
> at it again, purposefully ignoring SRV since its inception.)
>

It's not always people. Lots of games, lots of telephony things, services
like Syncthing... They all open firewall holes (yes, NAT is a firewall) to
allow inbound connections for specific conditions, like "this protocol and
port combination".


> I guess juggling our pains differently is what we are doing here. What
> is unthinkable to one is quite OK to someone else.
>

Indeed.


> (But I am right)
>

You are not. I'm glad my internet connected light bulbs are controlled by
the Australian firm that manufactures them and the American firm that has a
surveillance device in my kitchen listening for the immortal words "turn on
the living room lights", rather than Billy* from Doncaster who's looking
for something funny to do after losing at CS:GO again and happens to have
found a list of IP addresses of known vulnerable devices accessible from
the internet.

M

*Billy may or may not be a fictional person living in Yorkshire, UK. For
the sake of argument, Not All Yorkshiremen.
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 19, 2021, at 10:50 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>>
>>> LLA and ULA and whatever random prefix you may wish to use for loopback, whether in IPv6 or even IPv4 have none of these qualities.
>> And if we implement the proposal at hand, which as near as I can tell you are supporting, that changes.
>>
>> Having trouble following your desired outcome here. It seems as if you both want 127.0.0.0/8 to retain it’s unique properties
>> as deterministically loopback only and also want the benefits of repurposing it as GUA.
>>
>> Have cake, Eat cake, please to pick only one.
>
> Let me clear that up then.
>
> I support serious consideration of the idea. My desired outcome is to see ideas like these either adopted or not but based solely on their own merits and especially in their own protocol context. And that folk who have studied the issue and invested their efforts be taken seriously and not be met with undeserved and might I add, unkind, scorn.
>
> (I havent studied the issue or invested the effort, so you may continue to direct your scorn this way)
>
> Its well past time to stop behaving as if we are a bunch of teenagers on a private BBS.
>
> I like the loopback prefix feature of IPv4.
>
> I can easily concede that its too large, especially in this day and age. And that there is a good chance that significant benefit can come from addressing that before IPv4 becomes obsolete.
>
> I question the lack of dedicated loopback feature in IPv6 and I acknowledge that yes, you can accomplish the same with non loopback prefixes by essentially assigning them to loopback, but point out that that does not make them the same thing.

I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
>
> I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6

I have not encountered a device where I could not assign additional prefixes to a loopback interface in IPv6, so I’m having trouble understanding your meaning here.

> And I discuss IPv6 loopback simply because of the pushback directed in a non-meritorious fashion from folk who apparently believe simultaneously that IPv6 is superior in every way to IPv4 and that any improvements|changes to IPv4 somehow endanger IPv6 imminent dominance.

I have little concern (if any) of the latter. I believe that IPv6 is mostly equivalent to IPv4 in virtually every way and vastly superior in exactly one way… It has enough addresses. (and in all the ways that result from that, i.e. potential to restore end to end addressing, elimination of NAPT, etc.). I think that IPv6 also offers some features not available in IPv4, the benefits of which we haven’t fully explored or realized (MIP6, DHCP-PD, improved zeroconf, RD, etc.). Certainly the IPSEC implementation in IPv6 is quite a bit cleaner than it’s back-ported counterpart on IPv4 which has become such a nightmare in most implementations that the vast majority of VPNs have migrated to some cockamamy HTTPS “SSL VPN” thing.

>>>> having a prefix
>>>> dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best
>>>> tradeoff.
>>>>
>>>> Owen
>>>>
>>> But this is how it is to be done in IPv6, so lets get some lack-of-feature parity going with IPv4.
>> I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity.
>
>
> Actually I am (somewhat facetiously) suggesting that IPv4 have non-feature parity with IPv6 by taking away its loopback prefix.

Both have a loopback prefix. IPv4: 127.0.0.0/8 and IPv6: ::1/128

Admittedly, there are a lot more addresses available in the IPv4 loopback prefix, but again, I view that as being mostly waste as a result of historical ignorance at the time a decision was being made.

>> IMHO, having additional loopbacks be assigned from either LLA or ULA space (or even GUA, really)
>> where that is needed is a superior choice vs. 127.0.0.0/8.
>
> Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from.
>
> The converse is not true in IPv6.

I guess that depends on what you mean by “converse”.
If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose.
If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose.
If you mean something else, then I’m still not clear what you’re intent is here.

>> For one thing, the alternative addressing schemes (other than LLA) allow for routing of the
>> addresses off the box even though they are configured on loopback interfaces. There are
>> a number of situations where this can be a useful way to ensure that the addresses remain
>> usable regardless of the up/down state of connectivity on any particular non-loopback
>> interface on the box.
>>
>> It’s one of the reasons, for example, that virtually every IBGP speaking router has a GUA
>> or ULA/1918 loopback address which is routed in the IGP and almost all IBGP sessions
>> are terminated on those loopback interfaces.
>>
>> Owen
>>
> And its the fairly common way of implementing anycast services. But that is not what we are addressing on this thread.
>
> I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before.

I don’t think the current proposals being discussed will improve or degrade IPv4. I think they will distract implementors that choose to implement them from useful work for a while and end in neither benefit nor detriment beyond the detriment that comes from wasting effort.

If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful.

Owen
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast [ In reply to ]
> On Nov 19, 2021, at 11:46 , John Gilmore <gnu@toad.com> wrote:
>
> Joe Maimon <jmaimon@jmaimon.com> wrote:
>> And all thats needed to be done is to drop this ridiculous .0 for
>> broadcast compatibility from standards.....why is this even controversial?
>
> Not to put words in his mouth, but that's how original BSD maintainer
> Mike Karels seemed to feel when we raised this issue for FreeBSD. He
> was like, what? We're wasting an address per subnet for 4.2BSD
> compatability? Since 1986? Let's fix that.
>
> John

Don’t get me started on BSD vs. IETF Standards… The whole stupidity
around VRRP and CARP still irritates me, so I don’t think holding up
the BSD attitude towards network standards is helping your case any.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 09:15:24PM +0000 Quoting Matthew Walster (matthew@walster.org):

> > Why should we burden ourselves with this cumbersome and painful, useless
> > layer of abstraction that is "port forwarding", when the choice of
> > universal reachability is around the corner?
>
> Because it's a REALLY bad idea to have unmanaged devices reachable from the
> open internet. Dial-out, not dial-in. You need a firewall. You need a way
> of punching holes in that firewall for services you explicitly allow, be
> that manually through an interface, or temporarily via an automated system
> like upnp/nat-pmp.

It's like you did not read the next part.

> > If people can set a port forward up, they can click "allow" in a
> > routing-based firewall interface. Only it is better, because one can
> > have several parallel services using well-known ports. Sometimes (most
> > of the time) the protocol spec has no option to change port either,
> > making port forwarding futile anyway. (the let's have a TXT record bunch
> > at it again, purposefully ignoring SRV since its inception.)
> >
>
> It's not always people. Lots of games, lots of telephony things, services
> like Syncthing... They all open firewall holes (yes, NAT is a firewall) to
> allow inbound connections for specific conditions, like "this protocol and
> port combination".

You obviously read it. Now I'm confused.

> You are not. I'm glad my internet connected light bulbs are controlled by
> the Australian firm that manufactures them and the American firm that has a
> surveillance device in my kitchen listening for the immortal words "turn on
> the living room lights", rather than Billy* from Doncaster who's looking
> for something funny to do after losing at CS:GO again and happens to have
> found a list of IP addresses of known vulnerable devices accessible from
> the internet.

( I'd rather not have my lighting in the cloud. But I'm strange like that. )

Routing and allowing traffic are choices. Only that people with unusable
non-unique addresses don't get to make those choices. One can probably
find quantitative research stating that letting people handle their
IT security makes for less secure systems, and from that standpoint
argue that they don't deserve the choice. To me, that is elitist and
condescending (And I oughta know condescending, I'm quite good at it.) and
I think we could do better.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
I want another RE-WRITE on my CEASAR SALAD!!
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 20, 2021, at 03:16 , Matthew Walster <matthew@walster.org> wrote:
>
>
>
> On Sat, 20 Nov 2021, 09:21 Måns Nilsson, <mansaxel@besserwisser.org <mailto:mansaxel@besserwisser.org>> wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp <mailto:mohta@necom830.hpcl.titech.ac.jp>):
>
> > > We cope,
> > > because a lot of technical debt is amassed in corporate and ISP /
> > > access provider networks that won't change.
> >
> > Sounds like abstract nonsense.
>
> No, it is the real reason that we still have v4 around.
>
> The "real" reason we have IPv4 around is that it works. Having IPv4+IPv6 is relatively easy, but dropping IPv4 to run IPv6 only is difficult. Some examples:
>
> ***
>
> 1. Your power goes out. When it comes back up, your internet connection is down. You want to log in to the router... Except you can't. You don't know the address, and you won't have one until your ISP gives you one via DHCP (or similar).

This is contrived. It only happens if you have ignored all reasonable possibility to address this situation in advance.

> Sure, you could maybe provide the link-local address on the bottom of the router, but expecting a user to get http://[fe80:211:aaff:febb:ccdd] right (and you might even need interface scoping!) is boring to cause user frustration when an ISP tech support tries to help, and having the provided CPE using fe80::1 is probably a recipe for disaster.
>
> Likewise, having an mdns broadcast (ssssh, I know) for "gateway" or "router" is definitely not something standardised.

Nor, frankly, should it be, but you are ignoring a number of other possible mitigations:

1. Assign an additional “easy” LL address to the device in its configuration. (e.g. fe80::1). Do you think the average user
would buy unable to correctly type fe80::1?

2. Assign a ULA prefix to the interface (not my preference, but it can work).

3. Us a static GUA assignment (more complicated, but not impossible).

4. Use a non-standardized MDNS name — Who cares that it isn’t standardized, you just have to remember what you
named each of your routers. Brady, Brother, and Dymo all make products to aid in this endeavor.

The only reason this situation doesn’t exist in IPv4 is because we lack unique addresses for LANs in IPv4.
In reality, if this were truly an issue, the simple solution would be to predesignate fd00:: as a “household”
prefix and give every household fd00:: as a prefix in addition to whatever other prefixes may or may not be
assigned. I don’t see this as desirable, but if you wanted to replicate the problems of IPv4 in this regard, that
would be one mostly harmless way to do it.

> 2. Your IPv6 prefix changes. With some ISPs, it can change every time your router reboots, and if you're with my ISP, it crash-reboots about once a week! If your CPE isn't providing your WiFi (range extender, mesh, nerd etc) then the old prefix is still valid for a while. Yes, there's an RFC to deal with this, but realistically it's not out there today.
>
> Also, any local services are going to break if they're on static addresses... I'm not just talking enterprise AD servers etc, it's also CCTV cameras, raspberry pis, NAS units etc. DHCP registration of addresses in DNS exists, yes, but it's just not used by most of these devices.
>
> This could easily be fixed by having a well-known (and short/memorable!) /48 set aside that would have NAT66 (1:1, not port overload) applied at the router to the delegated prefix received from the ISP, but I'll be shouted down to hell for even mentioning that idea.

There are mitigations for this as well. The situation is not any better in IPv4 than it is with ULA IPv6. The difference is that with IPv4, you expect to have to use NAPT to break your network in order to talk to the outside world and with IPv6, you’re now asking to have your cake and eat it too.

There are implementations of exactly what you say you want readily available, but fortunately they are not standardized.

> 3. IPv6 "port forwarding" isn't really an easy thing -- people are not used to each machine having a global address. Sure, on many devices you can add firewall rules to allow traffic in, but it's not like the "port forwarding" concept people have gotten used to. I genuinely have no idea whether upnp/nat-pmp has an IPv6 analogue that "just works" which things like consoles (or apps like syncthing) can take advantage of.

Yes, “permit X in” is so much more complicated than “translate Y to X and map Z to A and…”

Oh, wait, no it isn’t… People will get used to the new normal. Ignorance is not a reason to halt progress.

> ***
>
> IPv4 works. There is no appreciable benefit to the user in enabling IPv6, but the ISP does it and it just works. The same can't be said of going IPv6 only -- you can easily provide IPv6 only with NAT64 and DNS64 or some XLAT464 fun when you're dealing with public WiFi, but this is people's homes and businesses.

The same can’t be said today because of the number of services users want that are not yet available on IPv6. Once that changes, yes, actually, you will be able to provide IPv6 only without NAT64/etc.

Further, there will, likely soon be home gateways that do provide IPv6 only with NAT64/DNS64 which will permit IPv6-only inside and either IPv6-only and/or dual-stack upstream.

The biggest trick there is the number of legacy IPv4-only devices in the home.

IMHO, the solution not that is a cheap dongle which has two ethernets and a small NAT64/DNS64 implementation for a single device embedded in it such that you plug the dongle into the IPv4-only device and it speaks IPv4 on that side and plug the ethernet cable into the other side where it speaks IPv6, problem solved.

> Likewise, there's so many devices that are IPv4 only, and aren't getting retired anytime soon. In fact, there's a lot of devices released in the last few years that fully support IPv6, but only when it also has an IPv4 address. I believe either the new Xbox and/or PS5 fit into that category.

See above. Much like the NTSC->ATSC migration and the set top box fiasco (which was a problem with the management of the program by the government, not an issue with the functioning of the set top boxes).

> IPv4 is getting more expensive for ISPs because of addressing costs, but a 5-tuple CGNAT solution capable of saturating a 100Gb/s pipe is under $10k these days if you're doing it on the cheap. Yes, this is massively oversimplified.

There are some pretty nasty security implications to CGNAT that have not yet been fully explored. There are a number of services out there (Yes, Philips, I’m talking about you among others) that identify households based on a common public IPv4 address. The assumptions built into these systems mean that they break if the different devices within the household have unique addresses and also that they assume you are in the same household if you are behind the same CGN. Isn’t that delightful as we contemplate all the various smart home controllers and such?

> IPv6 only is the goal. IPv4 is going to be with us for at least a decade. Getting IPv6 up and running on a network requires a lot of effort when that network is run by the IT PFY, but it will slowly get that wide penetration desired... Turning off IPv4 for your regular residential and SME ISP connections is such a PITA fraught with support problems that it is just not practical outside of very limited conditions.

If we can start turning off IPv4 on the service provider side of things, then the other side doesn’t really matter that much.

> Certainly, on the content side, you can make all your HTTP services on IPv6 only servers, and have the IPv4 go to a proxy that routes based on Host header or SNI, but you need some networking knowledge already to understand what is going on there.

Many are already doing this. However, eliminating the need for those silly IPv4 proxies is still worth while.

> IPv4 isn't going anywhere anytime soon. Enabling IPv6 reduces IPv4 traffic levels, it does not reduce IPv4 address usage.

Yes and no. The vast majority of IPv4 addresses are not actually deployed in residential and SOHO. Many more are deployed on
things like CDNs, enterprises, content providers, etc.

If we can eliminate the IPv4 need in those locations, that’s a win and it does free up IPv4 addresses.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Sat, 20 Nov 2021 at 22:35, Owen DeLong <owen@delong.com> wrote:

> On Nov 20, 2021, at 03:16 , Matthew Walster <matthew@walster.org> wrote:
> On Sat, 20 Nov 2021, 09:21 Måns Nilsson, <mansaxel@besserwisser.org>
> wrote:
>
>> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov
>> 20, 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (
>> mohta@necom830.hpcl.titech.ac.jp):
>>
>> > > We cope,
>> > > because a lot of technical debt is amassed in corporate and ISP /
>> > > access provider networks that won't change.
>> >
>> > Sounds like abstract nonsense.
>>
>> No, it is the real reason that we still have v4 around.
>>
>
> The "real" reason we have IPv4 around is that it works. Having IPv4+IPv6
> is relatively easy, but dropping IPv4 to run IPv6 only is difficult. Some
> examples:
>
> ***
>
> 1. Your power goes out. When it comes back up, your internet connection is
> down. You want to log in to the router... Except you can't. You don't know
> the address, and you won't have one until your ISP gives you one via DHCP
> (or similar).
>
>
> This is contrived. It only happens if you have ignored all reasonable
> possibility to address this situation in advance.
>

Yup. Though this isn't contrived, this is the exact situation I'm having
with my ISP at the moment, whose CPE crash-reboots every couple of days and
gets a new IPv6 prefix every time... Except when the power goes out (again,
annoyingly regularly -- I have had more power outages in 15 months of
living here than the last 37 years of my life) and it takes up to 10
minutes for the street to get connectivity again.

> Sure, you could maybe provide the link-local address on the bottom of the
> router, but expecting a user to get http://[fe80:211:aaff:febb:ccdd]
> right (and you might even need interface scoping!) is boring to cause user
> frustration when an ISP tech support tries to help, and having the provided
> CPE using fe80::1 is probably a recipe for disaster.
>
>
> Likewise, having an mdns broadcast (ssssh, I know) for "gateway" or
> "router" is definitely not something standardised.
>
>
> Nor, frankly, should it be, but you are ignoring a number of other
> possible mitigations:
>
> 1. Assign an additional “easy” LL address to the device in its
> configuration. (e.g. fe80::1). Do you think the average user
> would buy unable to correctly type fe80::1?
>

It would be http://[fe80::1] actually, and I presume you need to use
interface scoping? I actually don't know that answer...



> 2. Assign a ULA prefix to the interface (not my preference, but it can
> work).
>
> 3. Us a static GUA assignment (more complicated, but not impossible).
>
> 4. Use a non-standardized MDNS name — Who cares that it isn’t
> standardized, you just have to remember what you
> named each of your routers. Brady, Brother, and Dymo all make products to
> aid in this endeavor.
>
> The only reason this situation doesn’t exist in IPv4 is because we lack
> unique addresses for LANs in IPv4.
> In reality, if this were truly an issue, the simple solution would be to
> predesignate fd00:: as a “household”
> prefix and give every household fd00:: as a prefix in addition to whatever
> other prefixes may or may not be
> assigned. I don’t see this as desirable, but if you wanted to replicate
> the problems of IPv4 in this regard, that
> would be one mostly harmless way to do it.
>

Indeed, that's what I'm proposing. As /etc/gai.conf (or the equivalent in
Windows) would prefer the non-ULA space for addressing, once a connection
is up, it would just work with that new prefix, but it would continue to
work locally for that non-U ULA.

> 2. Your IPv6 prefix changes. With some ISPs, it can change every time your
> router reboots, and if you're with my ISP, it crash-reboots about once a
> week! If your CPE isn't providing your WiFi (range extender, mesh, nerd
> etc) then the old prefix is still valid for a while. Yes, there's an RFC to
> deal with this, but realistically it's not out there today.
>
> Also, any local services are going to break if they're on static
> addresses... I'm not just talking enterprise AD servers etc, it's also CCTV
> cameras, raspberry pis, NAS units etc. DHCP registration of addresses in
> DNS exists, yes, but it's just not used by most of these devices.
>
> This could easily be fixed by having a well-known (and short/memorable!)
> /48 set aside that would have NAT66 (1:1, not port overload) applied at the
> router to the delegated prefix received from the ISP, but I'll be shouted
> down to hell for even mentioning that idea.
>
>
> There are mitigations for this as well. The situation is not any better in
> IPv4 than it is with ULA IPv6. The difference is that with IPv4, you expect
> to have to use NAPT to break your network in order to talk to the outside
> world and with IPv6, you’re now asking to have your cake and eat it too.
>

Oh I'm fine with connections being broken. But when they're broken, they
re-establish. When a prefix changes, what's the procedure to invalidate the
old RA if the router doesn't know what prefix it had before?



> There are implementations of exactly what you say you want readily
> available, but fortunately they are not standardized.
>
> 3. IPv6 "port forwarding" isn't really an easy thing -- people are not
> used to each machine having a global address. Sure, on many devices you can
> add firewall rules to allow traffic in, but it's not like the "port
> forwarding" concept people have gotten used to. I genuinely have no idea
> whether upnp/nat-pmp has an IPv6 analogue that "just works" which things
> like consoles (or apps like syncthing) can take advantage of.
>
>
> Yes, “permit X in” is so much more complicated than “translate Y to X and
> map Z to A and…”
>
> Oh, wait, no it isn’t… People will get used to the new normal. Ignorance
> is not a reason to halt progress.
>

I'm not talking about halting progress, I'm saying that it's currently a
stumbling block that I know for *certain* confuses a lot of people right
now. Hell, I just looked at the IPv6 firewall page for my ISP's CPE and had
to read it several times to work out what to do. I wanted to see what the
UPNP menu did, whether it supported that new-fangled PCP thing for opening
ports, but it genuinely just crash-rebooted my router twice. If I wasn't
moving in a couple of months...

> ***
>
> IPv4 works. There is no appreciable benefit to the user in enabling IPv6,
> but the ISP does it and it just works. The same can't be said of going IPv6
> only -- you can easily provide IPv6 only with NAT64 and DNS64 or some
> XLAT464 fun when you're dealing with public WiFi, but this is people's
> homes and businesses.
>
>
> The same can’t be said today because of the number of services users want
> that are not yet available on IPv6. Once that changes, yes, actually, you
> will be able to provide IPv6 only without NAT64/etc.
>

Chicken and egg.


> Further, there will, likely soon be home gateways that do provide IPv6
> only with NAT64/DNS64 which will permit IPv6-only inside and either
> IPv6-only and/or dual-stack upstream.
>

Strongly doubt that these will be at all common this decade, but I'd love
to be proved wrong.


> If we can start turning off IPv4 on the service provider side of things,
> then the other side doesn’t really matter that much.
>
We can't turn off IPv4 on the service provider side until almost every
client has IPv6. And as you said before, there's some stuff that will never
have IPv6 compatibility, and it will be a long time before they are phased
out. In fact, there's a lot of devices out there that are capable of IPv6
but have it disabled because it only supports static configuration, which
you can't get if you've got a dynamic interior prefix.

I agree with your point, I just think that expecting the next phase to be
gated on pervasive IPv6 is just going to mean there's no hurry to roll it
out because "IPv4 works".

> IPv4 isn't going anywhere anytime soon. Enabling IPv6 reduces IPv4 traffic
> levels, it does not reduce IPv4 address usage.
>
> Yes and no. The vast majority of IPv4 addresses are not actually deployed
> in residential and SOHO. Many more are deployed on
> things like CDNs, enterprises, content providers, etc.
>
> If we can eliminate the IPv4 need in those locations, that’s a win and it
> does free up IPv4 addresses.
>

They're only deployed there generally because the clients need IPv4
addresses to connect to. I genuinely believe we're reaching a stalling
point for IPv6 service enabling, and it's time to focus energy on running
IPv6 only clients -- and to do that, we need to make the IPv6 only
experience for residential / soho be as pain-free as possible, no extra
knowledge required. Better/easier than IPv4 even. The rest of the IPv4-only
services will rapidly want to deploy IPv6 because the IPv4 path may be less
stable than the IPv6 due to CGNAT, tromboning, all that jazz.

That's just my viewpoint, anyway. I would love to see an GL.iNet / OpenWRT
style router that was plug-and-play, that based on a hardware switch event
(like the one on the GL-AR750S-Ext I use to enable/disable WireGuard) on
the outside went from Dual-Stack mode to IPv6-only mode. Leave it with your
family and friends, in IPv6-only mode, and get them to call you if they're
having trouble. When you're suitably annoyed that they're hitting a problem
that isn't going to be solved soon, get them to flick the switch over to
Dual-Stack. I think it'd be a really interesting study into real-world
usage.

M
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Owen DeLong wrote:
>
> I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.

Since the loopback prefix in IPv4 is present and usable on all systems,
IPv6 parity would require the same, so merely designating a prefix would
only be the beginning.

There may not be a need. But there is clearly some benefit.

>> I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6
> I have not encountered a device where I could not assign additional prefixes to a loopback interface in IPv6, so I’m having trouble understanding your meaning here.

In IPv6 if you want a loopback prefix you have to pick one yourself or
determine which one the system has chosen on its own. Because there is
no dedicated loopback prefix other than ::1/128

>
>> Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from.
>>
>> The converse is not true in IPv6.
> I guess that depends on what you mean by “converse”.

I mean that in IPv6 you must assign an otherwise non-loopback prefix if
you want one.

> If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose.

It works, but it is non deterministic and system dependent.
> If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose.

And IPv4 has that too.
>
>> I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before.
> I don’t think the current proposals being discussed will improve or degrade IPv4. I think they will distract implementors that choose to implement them from useful work for a while and end in neither benefit nor detriment beyond the detriment that comes from wasting effort.

There seems to be some weird mental representation of how standards
affect the real world. Standards do not demand or direct or control in
any way what individuals do based upon their own assessment of their
needs, available resources and resulting benefits.

You are neither responsible or in control of how people choose to expend
their implementing resources. Nor should you.

What standards do is increase the potential benefits of conforming to
certain behavior.

So what you are really saying is that standardizing something that
others may then choose to recognize as a worthwhile expenditure of their
resources is something you would like to prevent on the assumption that
those efforts would have otherwise gone into IPv6 advancement.

You dont have the immediate moral high ground on that one.

You dont have the long term moral high ground on that one because such
thinking isnt new and we know its wishful at best.

You dont have the logical high ground on that one because you are
assuming facts not in evidence, namely that

- Resources are being feverishly expended deploying IPv6 (as if)

- Those same resources will be the ones redirected to implement ideas
such as these

- That those efforts are in anyways comparable in scope to work being
done on IPv6 (which is supposed to be done already)

- That any such diversion of activity will actually have any real world
affect on the state of IPv6


> If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful.
>
> Owen
>

Reclaiming 127/8 while assigning a /64 for loopback in IPv6 would create
a clear (but narrow) case where IPv6 would be superior to IPv4,
irrelevant of overall network state.

Objectors to the proposal based upon their real world use of far larger
than v4 /16 for loopback applications could implement on IPv6 with even
more space, and in the exact same addressing context.

Which GUA and LL are not, no matter how readily available and easily
assignable and otherwise equivalent they are in every way but the one.
They are not loopback designated by standard (and system implementation).

Joe
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 20, 2021, at 13:15 , Matthew Walster <matthew@walster.org> wrote:
>
>
>
> On Sat, 20 Nov 2021 at 13:47, Måns Nilsson <mansaxel@besserwisser.org <mailto:mansaxel@besserwisser.org>> wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 11:16:59AM +0000 Quoting Matthew Walster (matthew@walster.org <mailto:matthew@walster.org>):
> > 3. IPv6 "port forwarding" isn't really an easy thing -- people are not used
> > to each machine having a global address.
>
> This is the problem in a nutshell. After 27 years of destroying the
> E2E model on the internet, people do not anymore understand how IP
> (regardless of version) was supposed to work; any node to any node.
>
> Why should we burden ourselves with this cumbersome and painful, useless
> layer of abstraction that is "port forwarding", when the choice of
> universal reachability is around the corner?
>
> Because it's a REALLY bad idea to have unmanaged devices reachable from the open internet. Dial-out, not dial-in. You need a firewall. You need a way of punching holes in that firewall for services you explicitly allow, be that manually through an interface, or temporarily via an automated system like upnp/nat-pmp.

This is a common fallacy… The real concept here isn’t “universal reachability”, but universal transparent addressing. Policy then decides about reachability.

Think stateful firewall without NAT.

If you want to allow the incoming connection, you simply permit it rather than having to set up some sort of convoluted port forward.

You can allow open access to a hardened host entirely, or you can open specific ports.

What you don’t have to do is carefully map a limited number of external ports to each be forwarded to a particular port on a particular
internal destination host because you aren’t recycling the one and only public address that all the incoming packets have to first land
on, each host has its own address that you can simply enable.

So again, how is port forwarding better than this? (it isn’t).

> If people can set a port forward up, they can click "allow" in a
> routing-based firewall interface. Only it is better, because one can
> have several parallel services using well-known ports. Sometimes (most
> of the time) the protocol spec has no option to change port either,
> making port forwarding futile anyway. (the let's have a TXT record bunch
> at it again, purposefully ignoring SRV since its inception.)
>
> It's not always people. Lots of games, lots of telephony things, services like Syncthing... They all open firewall holes (yes, NAT is a firewall) to allow inbound connections for specific conditions, like "this protocol and port combination".

No, NAT is not a firewall. The stateful inspection that NAT depends on is a firewall.

You can do all of the exact same things without needing NAT. You just get additional capabilities without NAT that you didn’t have with NAT due to the limitations of shared addressing.

> I guess juggling our pains differently is what we are doing here. What
> is unthinkable to one is quite OK to someone else.
>
> Indeed.

Why juggle pains when you can (mostly) relieve them.

There’s no need for the UI to open a port in IPv6 direct addressing to be any more complex (or really even any different) from the UI to set up a port forward in IPv4 with NAT. In fact, it’s simpler because you don’t need to configure external to internal port mapping, you can simply permit traffic to host X port Y.

> (But I am right)
>
> You are not. I'm glad my internet connected light bulbs are controlled by the Australian firm that manufactures them and the American firm that has a surveillance device in my kitchen listening for the immortal words "turn on the living room lights", rather than Billy* from Doncaster who's looking for something funny to do after losing at CS:GO again and happens to have found a list of IP addresses of known vulnerable devices accessible from the internet.

Yes, well, that’s still just as possible with direct addressing as it is with NAT.

You an do stateful inspection and reject unwanted packets without having to mutilate the packet header in the process.

So to that extent, he is actually right, but you’re applying an emotional reaction to a poorly chosen term and it’s overriding actual logic.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Please make sure there’s video we can all watch when you try to take DoD’s IP addresses
by force.

ROFLMAO

Owen


> On Nov 20, 2021, at 11:20 , Gaurav Kansal <gaurav.kansal@nic.in> wrote:
>
>
>
>> On 18-Nov-2021, at 09:10, Jerry Cloe <jerry@jtcloe.net <mailto:jerry@jtcloe.net>> wrote:
>>
>>
>>
>> Subject: Redploying most of 127/8 as unicast public
>> To: nanog <nanog@nanog.org <mailto: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 <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.
>>
> This seems to be much better idea then 127/8 or 240/8
> <https://amritmahotsav.nic.in/>
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 20, 2021, at 15:35 , Matthew Walster <matthew@walster.org> wrote:
>
>
>
> On Sat, 20 Nov 2021 at 22:35, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
>> On Nov 20, 2021, at 03:16 , Matthew Walster <matthew@walster.org <mailto:matthew@walster.org>> wrote:
>> On Sat, 20 Nov 2021, 09:21 Måns Nilsson, <mansaxel@besserwisser.org <mailto:mansaxel@besserwisser.org>> wrote:
>> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp <mailto:mohta@necom830.hpcl.titech.ac.jp>):
>>
>> > > We cope,
>> > > because a lot of technical debt is amassed in corporate and ISP /
>> > > access provider networks that won't change.
>> >
>> > Sounds like abstract nonsense.
>>
>> No, it is the real reason that we still have v4 around.
>>
>> The "real" reason we have IPv4 around is that it works. Having IPv4+IPv6 is relatively easy, but dropping IPv4 to run IPv6 only is difficult. Some examples:
>>
>> ***
>>
>> 1. Your power goes out. When it comes back up, your internet connection is down. You want to log in to the router... Except you can't. You don't know the address, and you won't have one until your ISP gives you one via DHCP (or similar).
>
> This is contrived. It only happens if you have ignored all reasonable possibility to address this situation in advance.
>
> Yup. Though this isn't contrived, this is the exact situation I'm having with my ISP at the moment, whose CPE crash-reboots every couple of days and gets a new IPv6 prefix every time... Except when the power goes out (again, annoyingly regularly -- I have had more power outages in 15 months of living here than the last 37 years of my life) and it takes up to 10 minutes for the street to get connectivity again.

The problem is not contrived…The supposed lack of solutions is contrived.

>> Sure, you could maybe provide the link-local address on the bottom of the router, but expecting a user to get http://[fe80:211:aaff:febb:ccdd <>] right (and you might even need interface scoping!) is boring to cause user frustration when an ISP tech support tries to help, and having the provided CPE using fe80::1 is probably a recipe for disaster.
>>
>> Likewise, having an mdns broadcast (ssssh, I know) for "gateway" or "router" is definitely not something standardised.
>
> Nor, frankly, should it be, but you are ignoring a number of other possible mitigations:
>
> 1. Assign an additional “easy” LL address to the device in its configuration. (e.g. fe80::1). Do you think the average user
> would buy unable to correctly type fe80::1?
>
> It would be http://[fe80::1] actually, and I presume you need to use interface scoping? I actually don't know that answer...

Yes, interface scoping is required for any LL address on any system with more than one interface. Since any system
where this would be useful has at least one external facing interface and one loopback interface, that would make it
essentially universally required. As long as your not on Windows, that’s not too bad.

> 2. Assign a ULA prefix to the interface (not my preference, but it can work).
>
> 3. Us a static GUA assignment (more complicated, but not impossible).
>
> 4. Use a non-standardized MDNS name — Who cares that it isn’t standardized, you just have to remember what you
> named each of your routers. Brady, Brother, and Dymo all make products to aid in this endeavor.
>
> The only reason this situation doesn’t exist in IPv4 is because we lack unique addresses for LANs in IPv4.
> In reality, if this were truly an issue, the simple solution would be to predesignate fd00:: as a “household”
> prefix and give every household fd00:: as a prefix in addition to whatever other prefixes may or may not be
> assigned. I don’t see this as desirable, but if you wanted to replicate the problems of IPv4 in this regard, that
> would be one mostly harmless way to do it.
>
> Indeed, that's what I'm proposing. As /etc/gai.conf (or the equivalent in Windows) would prefer the non-ULA space for addressing, once a connection is up, it would just work with that new prefix, but it would continue to work locally for that non-U ULA.

Absolutely nothing prevents you from doing this today and it is, IIRC, already in some of the HOMENET RFCs.

>> 2. Your IPv6 prefix changes. With some ISPs, it can change every time your router reboots, and if you're with my ISP, it crash-reboots about once a week! If your CPE isn't providing your WiFi (range extender, mesh, nerd etc) then the old prefix is still valid for a while. Yes, there's an RFC to deal with this, but realistically it's not out there today.
>>
>> Also, any local services are going to break if they're on static addresses... I'm not just talking enterprise AD servers etc, it's also CCTV cameras, raspberry pis, NAS units etc. DHCP registration of addresses in DNS exists, yes, but it's just not used by most of these devices.
>>
>> This could easily be fixed by having a well-known (and short/memorable!) /48 set aside that would have NAT66 (1:1, not port overload) applied at the router to the delegated prefix received from the ISP, but I'll be shouted down to hell for even mentioning that idea.
>
> There are mitigations for this as well. The situation is not any better in IPv4 than it is with ULA IPv6. The difference is that with IPv4, you expect to have to use NAPT to break your network in order to talk to the outside world and with IPv6, you’re now asking to have your cake and eat it too.
>
> Oh I'm fine with connections being broken. But when they're broken, they re-establish. When a prefix changes, what's the procedure to invalidate the old RA if the router doesn't know what prefix it had before?

See recent IETF work by Fernando Gont on exactly this subject. In short, the router shouldn’t “not know” what prefix it had before, because it’s supposed to store that in non-volatile storage. However, there are
mitigations available even if it doesn’t know.

> There are implementations of exactly what you say you want readily available, but fortunately they are not standardized.
>
>> 3. IPv6 "port forwarding" isn't really an easy thing -- people are not used to each machine having a global address. Sure, on many devices you can add firewall rules to allow traffic in, but it's not like the "port forwarding" concept people have gotten used to. I genuinely have no idea whether upnp/nat-pmp has an IPv6 analogue that "just works" which things like consoles (or apps like syncthing) can take advantage of.
>
> Yes, “permit X in” is so much more complicated than “translate Y to X and map Z to A and…”
>
> Oh, wait, no it isn’t… People will get used to the new normal. Ignorance is not a reason to halt progress.
>
> I'm not talking about halting progress, I'm saying that it's currently a stumbling block that I know for *certain* confuses a lot of people right now. Hell, I just looked at the IPv6 firewall page for my ISP's CPE and had to read it several times to work out what to do. I wanted to see what the UPNP menu did, whether it supported that new-fangled PCP thing for opening ports, but it genuinely just crash-rebooted my router twice. If I wasn't moving in a couple of months...

Why would anyone be more confused by “permit traffic to host X port Y” if they can navigate “map ip address X port Y to internal address Q on port Z”?

If you’re saying that your ISP’s CPE has a bad UI for IPv6, then I’m not going to argue with you about that, but that’s a UI problem, not an IPv6 standards problem.

File a bug with the equipment vendor in question. There is IPv6 CPE available that has pretty much the same UI for doing the equivalent things in IPv4 and IPv6.

>> ***
>>
>> IPv4 works. There is no appreciable benefit to the user in enabling IPv6, but the ISP does it and it just works. The same can't be said of going IPv6 only -- you can easily provide IPv6 only with NAT64 and DNS64 or some XLAT464 fun when you're dealing with public WiFi, but this is people's homes and businesses.
>
> The same can’t be said today because of the number of services users want that are not yet available on IPv6. Once that changes, yes, actually, you will be able to provide IPv6 only without NAT64/etc.
>
> Chicken and egg.

Not entirely. Content is slowly (too slowly) adding IPv6 capabilities. As that starts to become more ubiquitous (a few more big applications/sites would get us most of the way to where we need to be), then ISPs will be able to start either turning down IPv4 services and/or offering discounts for IPv6-only service or other incentives to get away from IPv4.

> Further, there will, likely soon be home gateways that do provide IPv6 only with NAT64/DNS64 which will permit IPv6-only inside and either IPv6-only and/or dual-stack upstream.
>
> Strongly doubt that these will be at all common this decade, but I'd love to be proved wrong.

Depending on whether you mean the next 10 years, or the decade ending 2029, perhaps. I suspect it will likely be a close call on “widely deployed”.

> If we can start turning off IPv4 on the service provider side of things, then the other side doesn’t really matter that much.
> We can't turn off IPv4 on the service provider side until almost every client has IPv6. And as you said before, there's some stuff that will never have IPv6 compatibility, and it will be a long time before they are phased out. In fact, there's a lot of devices out there that are capable of IPv6 but have it disabled because it only supports static configuration, which you can't get if you've got a dynamic interior prefix.

That’s not at all true… We can turn off IPv4 on the service provider side as soon as the potential customer loss costs less than the savings gained.

That’s _WAY_ before “almost every client…”

Look at the NTSC->ATSC cutover. That happened well before “almost every client” and the next day, a whole lot of set top boxes flew off the shelves.

> I agree with your point, I just think that expecting the next phase to be gated on pervasive IPv6 is just going to mean there's no hurry to roll it out because "IPv4 works".

Except that it doesn’t, really, and it’s getting progressively worse.

>> IPv4 isn't going anywhere anytime soon. Enabling IPv6 reduces IPv4 traffic levels, it does not reduce IPv4 address usage.
> Yes and no. The vast majority of IPv4 addresses are not actually deployed in residential and SOHO. Many more are deployed on
> things like CDNs, enterprises, content providers, etc.
>
> If we can eliminate the IPv4 need in those locations, that’s a win and it does free up IPv4 addresses.
>
> They're only deployed there generally because the clients need IPv4 addresses to connect to. I genuinely believe we're reaching a stalling point for IPv6 service enabling, and it's time to focus energy on running IPv6 only clients -- and to do that, we need to make the IPv6 only experience for residential / soho be as pain-free as possible, no extra knowledge required. Better/easier than IPv4 even. The rest of the IPv4-only services will rapidly want to deploy IPv6 because the IPv4 path may be less stable than the IPv6 due to CGNAT, tromboning, all that jazz.

We can’t run IPv6-only clients until we get at least a majority of the most popular applications/sites running on IPv6. We’re getting close to that point, but we’re not as far along as we should be.

> That's just my viewpoint, anyway. I would love to see an GL.iNet / OpenWRT style router that was plug-and-play, that based on a hardware switch event (like the one on the GL-AR750S-Ext I use to enable/disable WireGuard) on the outside went from Dual-Stack mode to IPv6-only mode. Leave it with your family and friends, in IPv6-only mode, and get them to call you if they're having trouble. When you're suitably annoyed that they're hitting a problem that isn't going to be solved soon, get them to flick the switch over to Dual-Stack. I think it'd be a really interesting study into real-world usage.

That doesn’t seem like it would be all that hard.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Owen DeLong via NANOG wrote:

(snips for brevity and reply relevancy)
>
> This is a common fallacy… The real concept here isn’t “universal
> reachability”, but universal transparent addressing. Policy then
> decides about reachability.
>
> Think stateful firewall without NAT.
>
> No, NAT is not a firewall. The stateful inspection that NAT depends on
> is a firewall.
>
> You can do all of the exact same things without needing NAT. You just
> get additional capabilities without NAT that you didn’t have with NAT
> due to the limitations of shared addressing.
>
> You an do stateful inspection and reject unwanted packets without
> having to mutilate the packet header in the process.
>
>
> Owen
>

You are completely correct in theory.

However, in IPv4 there is a generally true assumption that there are all
these sorts of devices that will be deployed in a somewhat secure
fashion and not by virtue of any particular efforts on the part of their
manufactures, because they are rarely deployed without a NAT in front of
them simply due to address scarcity, where NAT becomes a feature of
network functionality and not of network security.

The hope that there will be equivalent pervasiveness of a statefull
deny-any layer in front of these classes of devices or that they will be
deployed|developed with sufficient/equivalent security without that
layer is not nearly as re-assuring.

Worse, with the assumption of NAT induced security in place its all too
logical to predict and expect that these devices are woefully
under-equipped to protect themselves in any way without it.

Best case scenario is that practically all SOHO v6 gateways default
configuration is statefull deny-any. In which case all you can hope to
get from theoretical E2E is less packet mangling.

(Packet mangling is a good test case for protocols who needlessly commit
layering violations by embedding lower layer addressing directly or
implicitly into their behavior, so NAT has actually been beneficial in
this manner)

The security conscious are better off deploying these devices with IPv6
turned off. Much less chance of them accidentally becoming individually
responsible for their own protection due to any network changes that may
not take their existence or particularly sensitive and vulnerable state
into consideration.

Further, security track records as they are suggest that security will
never become the prime focus or even more than an afterthought for the
producers of these classes of devices.

We can all wish that were not the case but it would be naive to assume
otherwise.

Joe
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 20, 2021, at 19:11 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>>
>> I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
>
> Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning.
>
> There may not be a need. But there is clearly some benefit.

Which is? You still haven’t answered that question.

>>> I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6
>> I have not encountered a device where I could not assign additional prefixes to a loopback interface in IPv6, so I’m having trouble understanding your meaning here.
>
> In IPv6 if you want a loopback prefix you have to pick one yourself or determine which one the system has chosen on its own. Because there is no dedicated loopback prefix other than ::1/128

Well, technically, fe80::/10 is also present and predictable on every loopback interface. It does come with the additional baggage of having to specify a scope id when referencing it, but that’s pretty minor.

>>> Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from.
>>>
>>> The converse is not true in IPv6.
>> I guess that depends on what you mean by “converse”.
>
> I mean that in IPv6 you must assign an otherwise non-loopback prefix if you want one.

Again, not really…fe80::/10 is right there waiting for you.

>> If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose.
>
> It works, but it is non deterministic and system dependent.

Nope… It’s every bit as deterministic as 127.0.0.0/8.

If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you try it on something other than linux, it probably doesn’t work.
That’s also true of 127.*.*.*.

>> If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose.
>
> And IPv4 has that too.

Right, so we have parity or better in the case of IPv6.

In IPv4, you have 16.7 Million addresses reserved for this purpose. In IPv6, it’s considerably more if you count all of fe80::/10.

(somewhere north of 340,000,000,000,000,000,000,000,000,000,000,000 addresses IIRC)

You can also get away with IPv6 loopback behavior on a dual stack system by using ::ffff:7fxx:xxxx as well.

>>> I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before.
>> I don’t think the current proposals being discussed will improve or degrade IPv4. I think they will distract implementors that choose to implement them from useful work for a while and end in neither benefit nor detriment beyond the detriment that comes from wasting effort.
>
> There seems to be some weird mental representation of how standards affect the real world. Standards do not demand or direct or control in any way what individuals do based upon their own assessment of their needs, available resources and resulting benefits.

Maybe, maybe not. They certainly influence some of those choices in a variety of ways.

> You are neither responsible or in control of how people choose to expend their implementing resources. Nor should you.

Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here.

My right to attempt to discourage it by opposing proposed standards is exactly equal to your right to encourage it by promoting them.

> What standards do is increase the potential benefits of conforming to certain behavior.

No, what standards do is encourage people to implement things in compatible ways in hopes that doing so is beneficial. A proposed standard that doesn’t provide an apparent clear benefit, therefore doesn’t merit adoption.

> So what you are really saying is that standardizing something that others may then choose to recognize as a worthwhile expenditure of their resources is something you would like to prevent on the assumption that those efforts would have otherwise gone into IPv6 advancement.

I’m really saying what I said. That IMHO, there’s no benefit to the internet overall if this proposed change is accepted and/or implemented and I see no benefit to standardizing it. As such, I remain opposed to doing so.

Whether or not the effort that would be wasted implementing it would go to IPv6 or to some other more useful pursuit is not a concern I factor into my opinion in this case.

> You dont have the immediate moral high ground on that one.

I’m really not concerned about where your misinterpretations of my statements land me in your opinion of the moral high ground, but thanks for playing.

> You dont have the long term moral high ground on that one because such thinking isnt new and we know its wishful at best.

Same response.

> You dont have the logical high ground on that one because you are assuming facts not in evidence, namely that

Same response.

> - Resources are being feverishly expended deploying IPv6 (as if)

Some are. More certainly would be beneficial.

> - Those same resources will be the ones redirected to implement ideas such as these

I have made no such assumption. I have made the assumption that since this is a complete waste of effort, whatever else those resources could be used for would likely be more useful.
I believe there to be sufficient evidence to support that assumption, though I understand you don’t agree with the assertion it is based upon.

> - That those efforts are in anyways comparable in scope to work being done on IPv6 (which is supposed to be done already)

I’ve made no such assumption, nor do I consider the relative scope to be in any way relevant.

> - That any such diversion of activity will actually have any real world affect on the state of IPv6

Again, have not made any such assumption here, either. It’s not relevant. The only thing I consider relevant is that any resources expended on a complete waste of time could be better
expended elsewhere.

>> If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful.
>>
>> Owen
>>
>
> Reclaiming 127/8 while assigning a /64 for loopback in IPv6 would create a clear (but narrow) case where IPv6 would be superior to IPv4, irrelevant of overall network state.

Why do you need another /64 when you already have a /10?

> Objectors to the proposal based upon their real world use of far larger than v4 /16 for loopback applications could implement on IPv6 with even more space, and in the exact same addressing context.

They can already effectively do that today.

> Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation).

And this matters why?

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Owen DeLong wrote:
>
>> On Nov 20, 2021, at 19:11 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>>
>>
>>
>> Owen DeLong wrote:
>>> I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
>> Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning.
>>
>> There may not be a need. But there is clearly some benefit.
> Which is? You still haven’t answered that question.

You have right below.

And if there is indeed no benefit, than there is no reason not to
repurpose 127/8 considering that you may use many other ranges in IPv4
for loopback and that you can just use IPv6 for loopback and there you
go you have a whole /10.

Its not like it will overnight cause system admin headaches. And they
should be running their loopback apps on IPv6 anyways.
>
> Well, technically, fe80::/10 is also present and predictable on every loopback interface. It does come with the additional baggage of having to specify a scope id when referencing it, but that’s pretty minor.
>
>
> Nope… It’s every bit as deterministic as 127.0.0.0/8.
>
> If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you try it on something other than linux, it probably doesn’t work.
> That’s also true of 127.*.*.*.

So fe80::/10 is the loopback prefix for IPv6


Joe
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Owen DeLong wrote:

> Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here.
>
> My right to attempt to discourage it by opposing proposed standards is exactly equal to your right to encourage it by promoting them.

Since your discouragement may take form in preventing some amount of
improvement or amelioration to IPv4 users, there is a human cost
associated to that.

Absent the equivalent clear correlation of harm to whatever else you
believe those resources are engaged in, I would not say those two
behaviors are of equal consequence.

> I’m really saying what I said. That IMHO, there’s no benefit to the internet overall if this proposed change is accepted and/or implemented and I see no benefit to standardizing it. As such, I remain opposed to doing so.

There is a clear difference of opinion on this, that there stands a very
good chance that prompt implementation now may prove to provide
significant benefit in the future, should IPv6 continue to lag, which
you cannot guarantee it wont.

Further, there is historical precedent that discouraging re-purposing
IPv4 addressing is the wrong decision.

>
> Whether or not the effort that would be wasted implementing it would go to IPv6 or to some other more useful pursuit is not a concern I factor into my opinion in this case.

And I appreciate that, as I consider that reasoning to be specious at
best, morally dubious at worst.

> Again, have not made any such assumption here, either. It’s not relevant. The only thing I consider relevant is that any resources expended on a complete waste of time could be better
> expended elsewhere.

I dont consider my opinion as to what people's effort should be spent on
relevant to whether a particular proposal has merit all of its own.

>> Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation).
> And this matters why?
>
> Owen

So re-purpose 127/8 and if users and developers agree with you, it will
become available right about the time IPv6 should have finally managed
to obsolete IPv4, no harm no foul. And if it fails at that again, at
least we will have 127/8 and cohorts.

Joe
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On 21 Nov 2021, at 00.00, Joe Maimon <jmaimon@jmaimon.com> wrote:
>
> There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you cannot guarantee it wont.

The reassignment being implemented faster than IPv6 seems like a big assumption.
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Max Harmony via NANOG wrote:
> On 21 Nov 2021, at 00.00, Joe Maimon <jmaimon@jmaimon.com> wrote:
>> There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you cannot guarantee it wont.
> The reassignment being implemented faster than IPv6 seems like a big assumption.
>
>
Suppose you are correct. This time. Even a broken clock can be right
twice a day.

The only loss for the most part in most of these related proposals is
the time spent dickering on them and a few extra patches thrown in over
the next decade.

So just agree already.

127/8 is actually the proposal with the most potential for
implementation issues as the definition change wends its way into system
updates. And its easy to see that typical system updates tend to bring
far greater disruption to system administrators on a regular basis. I
would not rule out this change in that regard.

And if you are wrong, as history suggests you may very well be?

What is lost by not acting now is possibly far greater.

Joe
Re: Redploying most of 127/8 as unicast public [ In reply to ]
Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 10:47:10PM -0500 Quoting Joe Maimon (jmaimon@jmaimon.com):

> layer in front of these classes of devices or that they will be
> deployed|developed with sufficient/equivalent security without that layer is
> not nearly as re-assuring.

The inside/outside paradigm inherent in the reasoning of "NAT is a good,
big part of my firewall" crowd is woefully inadequate to describe and
counter the threats of today. The techniques to get past uni-reachability
(The NATted client can ask the net, but not in reverse) are many and
advanced. Since there is a somewhat inflated belief of the efficiency
of the unroutability paradigm, once inside, the rules tend to be relaxed.

It might very well be so that the resultant protection level will be better
once you realise you can't trust the net to not deliver packets to you.

Also, I much prefer writing firewall rules where the IP addresses don't
change in-flight. Less to screw up.
--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
Of course, you UNDERSTAND about the PLAIDS in the SPIN CYCLE --
Re: Redploying most of 127/8 as unicast public [ In reply to ]
On Sat, Nov 20, 2021 at 7:16 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:
> This is a common fallacy… The real concept here isn’t “universal reachability”, but universal transparent addressing. Policy then decides about reachability.
>
> Think stateful firewall without NAT.
>
> If you want to allow the incoming connection, you simply permit it rather than having to set up some sort of convoluted port forward.
>
> You can allow open access to a hardened host entirely, or you can open specific ports.
>
> What you don’t have to do is carefully map a limited number of external ports to each be forwarded to a particular port on a particular
> internal destination host because you aren’t recycling the one and only public address that all the incoming packets have to first land
> on, each host has its own address that you can simply enable.
>
> So again, how is port forwarding better than this? (it isn’t).

Hi Owen,

This has been hashed and rehashed on this group about a gajillion
times but for the sake of those who are new:

Firewalls are programmed by people. People make mistakes. Lots of
mistakes. 1:1 stateful firewalls and 1:many stateful firewalls (NAT)
behave differently in the face of those mistakes. When 1:1 stateful
firewalls are mistakenly told to pass all traffic they faithfully do
so exposing unhardened hosts directly to the Internet. When 1:many
stateful firewalls (NAT) are mistakenly told to pass all traffic they
can't do so. They don't have enough information to decide which
interior host to send a packet to so they simply break.

One fails as a security perimeter breach. The other fails as a system
down. Pick which security posture you prefer but they're very much not
the same. A knocked over fence versus a lost padlock key and well into
the zombie apocalypse.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 20, 2021, at 19:47 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong via NANOG wrote:
>
> (snips for brevity and reply relevancy)
>>
>> This is a common fallacy… The real concept here isn’t “universal reachability”, but universal transparent addressing. Policy then decides about reachability.
>>
>> Think stateful firewall without NAT.
>>
>> No, NAT is not a firewall. The stateful inspection that NAT depends on is a firewall.
>>
>> You can do all of the exact same things without needing NAT. You just get additional capabilities without NAT that you didn’t have with NAT due to the limitations of shared addressing.
>>
>> You an do stateful inspection and reject unwanted packets without having to mutilate the packet header in the process.
>>
>>
>> Owen
>>
>
> You are completely correct in theory.
>
> However, in IPv4 there is a generally true assumption that there are all these sorts of devices that will be deployed in a somewhat secure fashion and not by virtue of any particular efforts on the part of their manufactures, because they are rarely deployed without a NAT in front of them simply due to address scarcity, where NAT becomes a feature of network functionality and not of network security.

This is a fallacy which has repeatedly been proven false by numerous security researchers. It’s time to educate beyond this silly assertion and recognize that NAT is an obfuscation tool, not a security tool.

They are at least as secure behind a non-NAT stateful firewall as they are behind NAT.

> The hope that there will be equivalent pervasiveness of a statefull deny-any layer in front of these classes of devices or that they will be deployed|developed with sufficient/equivalent security without that layer is not nearly as re-assuring.

Virtually all home gateways today ship with a stateful default deny-all policy for IPv6, so it’s not a hope, it’s current reality.

There is hope that manufacturers will eventually start improving security as well, but I agree that depending on that at this stage is rather perilous.

OTOH, it’s also perilous to believe that NAT provides adequate protection for their failures in this arena.

> Worse, with the assumption of NAT induced security in place its all too logical to predict and expect that these devices are woefully under-equipped to protect themselves in any way without it.

NAT does not induce security. It induces headaches. It induces difficulties in troubleshooting. It induces difficulties in correlating logs and audit trails. It induces all manner of things that make it harder to address security incidents. It does NOT induce security.

Further, 100% of the alleged or perceived security gains attribute to NAT come from stateful inspection, not NAT itself. As such, no, there’s no need for NAT to have equivalent security even if you just assume a stateful default deny-all in the gateway vs. assuming NAT.

I agree that the idea of producing a home gateway without a stateful default deny-any inbound policy should be (and basically is, frankly) as unrealistic as producing a home gateway for IPv4 without NAT, but once that’s the case (and really, from what I have seen of current market entrants, it is), there’s no meaningful difference in the security level between the two options. The non-NAT option does provide greater choice and freedom in controlling your security and permitting things in, but not significantly more dangerous than current port forwarding setups with NAT.

> Best case scenario is that practically all SOHO v6 gateways default configuration is statefull deny-any. In which case all you can hope to get from theoretical E2E is less packet mangling.

That’s already the case from my observations. OpenWRT, Linksys, Netgear, D-Link, Belkin, and several others all default this way already.

> (Packet mangling is a good test case for protocols who needlessly commit layering violations by embedding lower layer addressing directly or implicitly into their behavior, so NAT has actually been beneficial in this manner)

If you want to put packet mangling capability into test equipment in SQA environments, by all means, feel free, but it has no useful place in the modern internet once we move forward from restricted addressing.

> The security conscious are better off deploying these devices with IPv6 turned off. Much less chance of them accidentally becoming individually responsible for their own protection due to any network changes that may not take their existence or particularly sensitive and vulnerable state into consideration.

We can agree to disagree here. The security conscious are better off deploying these products IPv6-only where they can get proper audit and log correlation with transparent addressing and making sure that the upstream router(s) have adequate protection configured. That’s at least as good as having a NAT upstream, given that a NAPT port forward can be just as dangerous to these devices as a transparent permit.

> Further, security track records as they are suggest that security will never become the prime focus or even more than an afterthought for the producers of these classes of devices.

I can’t effectively argue against this, but my hope is that we can eventually arrive at a place where manufacturers face real liability for damages inflicted by the insecurity of these products. Kind of a “unsafe at any bandwidth” equivalent of the “unsafe at any speed” campaign to improve automotive safety and get seatbelt mandates and the like. Much of that happened through product liability law.

> We can all wish that were not the case but it would be naive to assume otherwise.

It’s naive to assume it’s otherwise today. I do have hope that real progress will be made in liability laws helping to remedy the situation in the future.

Nothing says “fix your broken security” like a multi-million dollar jury verdict against your unlucky competitor.

Nonetheless, even with that remaining the case, I still believe that a stateful inspection without header mutilation is better security than a NAPT.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 20, 2021, at 20:37 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>>
>>> On Nov 20, 2021, at 19:11 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>>>
>>>
>>>
>>> Owen DeLong wrote:
>>>> I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
>>> Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning.
>>>
>>> There may not be a need. But there is clearly some benefit.
>> Which is? You still haven’t answered that question.
>
> You have right below.
>
> And if there is indeed no benefit, than there is no reason not to repurpose 127/8 considering that you may use many other ranges in IPv4 for loopback and that you can just use IPv6 for loopback and there you go you have a whole /10.

One doesn’t need a reason for inaction… One needs a reason to act. There is (so far) no compelling reason to repurpose 127/8 as far as I can see.

> Its not like it will overnight cause system admin headaches. And they should be running their loopback apps on IPv6 anyways.

You are arguing that just because we can do a thing, we should do a thing. I am arguing that unless there’s a compelling reason to change the standard, we should leave it as is until it dies a natural death of old age.
(or alternatively until we finally disconnect the life support keeping it artificially alive which is a more accurate metaphor for the current state of IPv4).

>> Well, technically, fe80::/10 is also present and predictable on every loopback interface. It does come with the additional baggage of having to specify a scope id when referencing it, but that’s pretty minor.
>>
>>
>> Nope… It’s every bit as deterministic as 127.0.0.0/8.
>>
>> If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you try it on something other than linux, it probably doesn’t work.
>> That’s also true of 127.*.*.*.
>
> So fe80::/10 is the loopback prefix for IPv6

It’s link local. It’s present on loopback. fe80::/10%lo0 (on a linux box) is a loopback prefix for IPv6 which is universally deployed.
The scope id becomes important in this context, but other than that, it’s identical to the semantics of IPv4.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 20, 2021, at 21:00 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>
>> Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here.
>>
>> My right to attempt to discourage it by opposing proposed standards is exactly equal to your right to encourage it by promoting them.
>
> Since your discouragement may take form in preventing some amount of improvement or amelioration to IPv4 users, there is a human cost associated to that.

Since wasted effort may prevent other things I see as advantageous to the network and humanity in general from happening, there is a human cost to not preventing it.

> Absent the equivalent clear correlation of harm to whatever else you believe those resources are engaged in, I would not say those two behaviors are of equal consequence.

You are entitled to your opinion. I do not happen to share it.

>> I’m really saying what I said. That IMHO, there’s no benefit to the internet overall if this proposed change is accepted and/or implemented and I see no benefit to standardizing it. As such, I remain opposed to doing so.
>
> There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you cannot guarantee it wont.

There stands some chance. It’s not clear how good that chance is. Obviously you think it is a higher probability than I do. You also assume that it would be widely implemented faster than deployment of IPv6 which is also an assertion of which I remain unconvinced.

> Further, there is historical precedent that discouraging re-purposing IPv4 addressing is the wrong decision.

Nope… There is historical precedent that you don’t like it. IMHO, we’ve done far too many things and put far too much effort into avoiding rather than completing IPv6 transition. As such, I think that the historical precedent argues that adding to those errors will not accelerate IPv6 transition and is, therefore, wasted effort at best and potentially counterproductive.

>> Whether or not the effort that would be wasted implementing it would go to IPv6 or to some other more useful pursuit is not a concern I factor into my opinion in this case.
>
> And I appreciate that, as I consider that reasoning to be specious at best, morally dubious at worst.

At least we agree on something.

>> Again, have not made any such assumption here, either. It’s not relevant. The only thing I consider relevant is that any resources expended on a complete waste of time could be better
>> expended elsewhere.
>
> I dont consider my opinion as to what people's effort should be spent on relevant to whether a particular proposal has merit all of its own.

IMHO, the proposal has no merit and is therefore a waste of time. Clearly you disagree. That’s fine.

>>> Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation).
>> And this matters why?
>>
>> Owen
>
> So re-purpose 127/8 and if users and developers agree with you, it will become available right about the time IPv6 should have finally managed to obsolete IPv4, no harm no foul. And if it fails at that again, at least we will have 127/8 and cohorts.

Meh, feel free to do whatever you want. In terms of any IETF WG adoption call or consensus call, I’ll object as I consider it useless at best and harmful at worst.

Nothing you have said provides any indication that there is sufficient merit to be worth the time I have wasted on this thread, let alone further effort.

Owen
Re: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 20, 2021, at 6:35 PM, Matthew Walster <matthew@walster.org> wrote:
>
> I genuinely believe we're reaching a stalling point for IPv6 service enabling, and it's time to focus energy on running IPv6 only clients -- and to do that, we need to make the IPv6 only experience for residential / soho be as pain-free as possible, no extra knowledge required.


If I may play devils advocate,

Google’s WiFi pucks did something I thought was interesting that I have not seen replicated by others that may or may not be of use to us in this regard. By using a local DNS resolver running on the main WiFi puck in the network, they handed it out via DHCP for clients to use which helped resolve a local webpage that showed devices that were connected to the local network by navigating to “on.here” inside a web browser.

That got me thinking,

So we know RFC 2606 defined reserved TLDs like .lan and .home so there is already a known list of .TLDs that we know would be safe to use in local scope, and besides the people who are already doing their own thing eg: people running PiHole or similar service inside their networks, or those who insist on setting their DNS servers static, everybody else should be defaulting to whatever is being handed out by their routers' DHCP server so keeping that in mind what if we did something like this:

In order to solve the chicken/egg problem of having to know your IPv6 prefix and the address assigned to your router dynamically for nontechnical users to reach their router configuration pages, the router can run a local DNS resolver for the “.lan” TLD by default that it hands out through RDNSS in it’s RAs. Since the router is the “first” device in the network, it should always take the “router.lan” entry for itself and populate it with its IPv6 address. (Obviously proper inbound filtering should prevent external hosts out on the Internet from reaching the router configuration page.) Local devices will then be able to resolve and reach stuff from within the internal network by hostname. Since the router would also be the first device to become aware of any IPv6 prefix change from the ISP, it lends itself to loop this prefix update into the same processes it would use to update the router’s RA configuration back to the clients and to update it’s local DNS entry for “router.lan”. Best case scenario the prefix update will happen fast enough that it goes unnoticed and clients see minimal disruption.

I feel users may find this method preferable in comparison to the old method of “type in 192.168.1.1 in your browser” where those instructions were not always 100% accurate due to some vendors deciding to use a different variation of private range addresses (I’m looking at you 192.168.0.1, and 192.168.100.1). Everybody would be able to quickly find their routers regardless of vendor, model, firmware version, or ISP.

So (in theory) we have a reliable method of discovering our router configuration page without any prior knowledge of our IPv6 prefix, the IPv6 address assigned to ourselves, or that of the router. We could possibly even support dynamic DNS entries for connected devices that used DHCPv6 (Android obviously not able to take advantage of due to lack of support) to request addresses from the pool. As long as vendors set unique hostnames that don't overlap at the factory or attempt to re-use simple hostnames like chromecast.lan (sorry, I’m picking on Google a lot here.) where the potential for multiple devices to be named the same could occur, I can’t imagine that occurring in Residential / SoHo networks all that often but the potential for it is cetainly there.

But this solution is by no means perfect, there are various situations I can think of where this kind of automation may break down and not work entirely as anticipated, eg: devices joining the network with device MAC address randomization turned on which I know is a default on certain devices and OSes (Android 11 comes to mind), or networks where the administrators do not want to allow joined devices to create their own dynamic DNS entries into the zone, but I digress, those environments are outside the scope of who this is designed for.

I hope others may take inspiration from this idea and maybe expand upon it or even get inspiration to design something that better fits the bill for what you’re looking for. Feedback is always welcome.

(Sorry to Matt and Owen who got this message twice. I originally sent this reply from my secondary address that is not subscribed on the list and the original reply got rejected)

-
Francis Booth
boothf@boothlabs.me
Re: fun with TLDs and captive portals was, Redploying most of 127/8 as unicast public [ In reply to ]
It appears that Francis Booth via NANOG <boothf@boothlabs.me> said:
>So we know RFC 2606 defined reserved TLDs like .lan and .home so there

Um, this must be a different RFC 2606 than the one the rest of us have read.
It mentions neither .lan nor .home.

>In order to solve the chicken/egg problem of having to know your IPv6
>prefix and the address assigned to your router dynamically for
>nontechnical users to reach their router configuration pages, ...

SLAAC lets hosts find their prefix and router and optionally other
stuff like the DNS servers. See RFC4862. This is a thoroughly solved problem.
If your router is a captive portal like at a coffee shop and client devices
need to open a web page to log in, see RFC 8910.

R's,
John