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

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

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?

...

...

... > > It's ok, I'll wait... > > ... > > There were two other

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

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

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

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

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

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

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

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

John Gilmore wrote on 18/11/2021 19:37:

There will be no future free-for-all that burns through 300 million IPv4 addresses in 4 months.

this is correct not necessarily because of the reasons you state, but because all the RIRs have changed their ipv4 allocation policies to policies which assume complete or near-complete depletion of the available pools, rather than policies which allocate / assign on the basis of stated requirement. For sure, organisations were previously requesting more than they needed, but if stated-requirement were reinstituted as a policy basis, the address space would disappear in a flash. The point remains that 127/8, 0/8, 240/4 are problematic to debogonise, and are not going to make a dramatic impact to the availability of ipv4 addresses in the longer term. Same with using the lowest ip address in a network block. Nice idea, but 30 years late. There's no problem implementing these ideas in code and quietly using the address space in private contexts. Nick

Randy Bush <randy@psg.com> wrote:

as a measurement kinda person, i wonder if anyone has looked at how much progress has been made on getting hard coded dependencies on D, E, 127, ... out of the firmware in all networked devices.

The drafts each have an Implementation Status section that describes what we know. The authors would be happy to receive updates for any of that information. 240/4 is widespread everywhere except in Microsoft products. It works so reliably that both Google and Amazon appear to be bootlegging it on their internal networks. Google even advises customers to use it: https://cloud.google.com/vpc/docs/vpc#valid-ranges 0/8, and the lowest address per subnet, have interoperable implementations that don't cause problems with legacy equipment, but they are not widely deployed. 0/8 has a few years in Linux & Android kernels and distros. Lowest address is in the most recent Linux and FreeBSD kernels, but not yet in any OS distros. In particular, OpenWRT doesn't implement it yet, which could easily be a fast path to a free extra IP address for anyone who has a compatible home router and a globally routed small network like a /29. We used RIPE Atlas to test the reachability of many addresses that end in .0 and .0.0, and they were reachable from all but one probe that we tried. Amazon offers https://ec2-reachability.amazonaws.com/ for this purpose; try it on your own network! Some embedded TCP stacks treat 127/8 as unicast (simply because they don't special-case much of anything), but otherwise we don't know of any current OS distributions that implement unicast for 127/8. The Linux kernel has long had a non-default "route_localnet" option offering similar but more problematic behavior. I would be happy to fund or run a project that would announce small global routes in each of these ranges, and do some network probing, to actually measure how well they work on the real Internet. We are working with RIPE Atlas already to enable this. I thought it would be prudent to propose the changes in detail to IETF, before "bogus" routes showed up in BGP and the screaming on the NANOG list started. :-/ John

John Gilmore wrote on 19/11/2021 01:54:

Lowest address is in the most recent Linux and FreeBSD kernels, but not yet in any OS distros.

lowest addresses will not be viable until widely supported on router (including CPE) platforms. This is hard to test in the wild - ripe atlas will only test the transit path rather than the local connection. I.e. it's not clear that what you're measuring here is a valid way of working out whether a lowest address is generally going to work, because .0 has been mostly accepted in the transit path since the 1990s (bit alarming to see that it's still not universal). The other risk with the lowest address proposal is that it will break network connectivity transitivity with no fallback or detection mechanism. I.e. consider three hosts on a broadcast domain: A, B and C. A uses the lowest address, B accepts a lowest address, but C does not. Then A can talk to B, B can talk to C, but C cannot talk to A. This does not seem to be addressed in the draft. Nick

Joe Maimon wrote on 19/11/2021 14:30:

Its very viable, since its a local support issue only. Your ISP can advise you that they will support you using the lowest number and you may then use it if you can....all you may need is a single patched/upgraded router or firewall to get your additional static IP online.

That would be an entertaining support phone call with grandma. So, she gets a new CPE which issues 192.168.1.0 to her laptop and .1 to her printer, and then her printer can no longer talk to her laptop. I'm sure that the ISP would be happy to walk her through doing a firmware upgrade on her printer or that her day would end up better for having learned about DHCP assignment policies on her CPE. They could even email her a copy of the RFC and a link to the IETF working group if she felt there was a problem. Nick

Nick Hilliard wrote:

Joe Maimon wrote on 19/11/2021 14:30:

...

Its very viable, since its a local support issue only. Your ISP can advise you that they will support you using the lowest number and you may then use it if you can....all you may need is a single patched/upgraded router or firewall to get your additional static IP online.

That would be an entertaining support phone call with grandma.

Starting to get annoyed with ageism from tech nerds. Lots of grandma and grandpa computer geeks in existence these days. I think its time we start using great-grammy instead.

So, she gets a new CPE which issues 192.168.1.0 to her laptop and .1 to her printer, and then her printer can no longer talk to her laptop.

So she has a datacenter cab with a cat6a multi-gig drop and the ISP included in the price an on-link public /30, but more is gonna cost her, and this is for the non-profit she is running out of her SSI. Now she gets to use her link with two IP addresses instead of one, although she may have to click update firmware from the device's web interface, which might be harder than you think since she grew up using punch cards and these new fangled mouse thingies are a pain in her arthritic fingers, she'll take a CLI any day. She might use that for a redundant router, or for the second 443 port mapping inevitably required. Two can play the fake anecdote game.

I'm sure that the ISP would be happy to walk her through doing a firmware upgrade on her printer or that her day would end up better for having learned about DHCP assignment policies on her CPE.

They could even email her a copy of the RFC and a link to the IETF working group if she felt there was a problem.

Nick

ISP's may very well be inclined to advise customers that a free extra IP is theirs for the taking should their equipment support it. Best, Joe

On Fri, Nov 19, 2021 at 10:22 AM Zu <mu@zuqq.me> wrote:

One anecdote (the non-technical grandma) illustrates a very real problem that would need to be addressed -- there are non-technical people (of all ages, if your concerned about ageism) which will need to implement technical changes for which they are not equipped with the skills to do.

Howdy, That depends on your timeline. Do you know many non-technical people still using their Pentium III computers with circa 2001 software versions? Connected to the Internet? Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

That fine. XP supports IPv6 and apart from the DNS needing a IPv4 recursive server it works fine. -- Mark Andrews

On 21 Nov 2021, at 11:23, ML <ml@kenweb.org> wrote:



...

On 11/19/2021 1:27 PM, William Herrin wrote:

...

On Fri, Nov 19, 2021 at 10:22 AM Zu <mu@zuqq.me> wrote: One anecdote (the non-technical grandma) illustrates a very real problem that would need to be addressed -- there are non-technical people (of all ages, if your concerned about ageism) which will need to implement technical changes for which they are not equipped with the skills to do. Howdy,

That depends on your timeline. Do you know many non-technical people still using their Pentium III computers with circa 2001 software versions? Connected to the Internet?

Regards, Bill Herrin

A huge chunk of a country (Armenia) still using Windows XP...

https://en.wikipedia.org/wiki/Windows_XP#Market_share

Jay Hennigan wrote:

On 11/19/21 10:27, William Herrin wrote:

...

Howdy,

That depends on your timeline. Do you know many non-technical people still using their Pentium III computers with circa 2001 software versions? Connected to the Internet?

There are lots of very old networked industrial machines with embedded computers operated by non-network-savvy people that are still very much in use.

Think CNC machines in machine shops, SCADA systems, etc. I wouldn't be a bit surprised to find quite a few 2001-era boxes still in service.

In the context of re-purposed IPv4 address scopes specialized equipment will tend to be fairly limited in its communication needs and unlikely to be affected. I certainly hope they are, otherwise the security implications are severe. How about we recast this as general purpose internet communicating platforms likely to have occasion to interact with these re-purposed addresses are nearly certain to undergo an upgrade or more over the next decade, or how many non-technical people are still using the original wrtg platform to connect them to the internet? And yes, its quite possible that even then those addresses may have some more baggage than the typical IPv4 block in use today (which are hardly clean bills of health more often than not). But the sooner the effort begins the more likely the utilitarian value will be there if or when its needed. Joe

J. Hellenthal wrote:

FreeBSD operators have been using this space for quite a long time for many NAT'ing reasons including firewalls and other services behind them for jail routing and such.

https://dan.langille.org/2013/12/29/freebsd-jails-on-non-routable-ip-address...

That's just one example that I've seen repeated in multiple other ways. One of which a jail operator with about 250 addresses out of that range that enabled his jail routed services.

Thank you for letting us know! We would be happy to improve the draft so that it has less impact on such pre-existing users. When we surveyed publicly visible applications based on Linux, we only found them configured to use the lowest /16. It's true that any system operator could configure their system in any part of 127/8, but we focused on the default configurations of popular software (such as systemd and Kubernetes). Do you know of any FreeBSD software that comes with a default configuration in 127/8 but not in 127/16? (It looks like the web page you referenced is about specific manual configuration, not about the default behavior of supplied software.) I do not know the details of FreeBSD jail configuration, nor the precise behavior of its loopback interface. From my limited understanding, it looks like the jail configured in the web page you referenced, with address 127.1.0.128/32 on lo1, would provide loopback service regardless of whether the default address on lo0 was 127.0.0.1/8 or 127.0.0.1/16. That's because lo1 is a separate interface from lo0, and the "lo" interfaces always loop back any packets sent through them, no matter what addresses are configured on them. (Indeed the example configures it with a 10.80.0.128 address as well, which would not normally be considered a loopback address.) So, if I am right, then even if our current Internet-Draft became a standard and FreeBSD was modified to implement it, the recommended commands would continue to work. The only impact would be that such a FreeBSD machine would be unable to reach a potential global Internet service hosted out on the Internet at address 127.1.0.128 (because a local interface has been configured at that address, shadowing the globally reachable address). I anticipate that no such global services would be created before 2026 at the very earliest (other than for reachability testing), and likely much later in the 2020's or early 2030's. If it turns out that FreeBSD usage of 127.1/16 is widespread, and the above analysis is incorrect or unacceptable to the FreeBSD community, we would be happy to modify the draft to retain default loopback behavior on 127.0.0.1/17 rather than 127.0.0.1/16. That would include both 127.0.x.y and 127.1.x.y as default loopback addresses. This would completely resolve the issue presented on the "FreeBSD jails on non-routable IP addresses" web page, while still recovering more than 16 million addresses for global use. The worst case might be if FreeBSD sysadmins have become accustomed to picking "random" addresses manually from all over the 127/8 space. If so, it is not unreasonable to expect that when manually configuring a node to use "non-routable" addresses, that in the passage of time, some of them might become routable in the future. When upgrading any machine to a new OS release, various small things typically need adjusting to fit into the revised OS. Renumbering the in-system use of up to a few hundred non-routable addresses like 127.44.22.66 into addresses like 127.0.22.66 (in a smaller non-routable range that still would still contain 65,000 or 130,000 addresses) might be one of those things that could be easily adjusted during such an upgrade. John

On 11/20/21 9:29 PM, Jay Hennigan wrote:

On 11/19/21 10:27, William Herrin wrote:

...

Howdy,

That depends on your timeline. Do you know many non-technical people still using their Pentium III computers with circa 2001 software versions? Connected to the Internet?

There are lots of very old networked industrial machines with embedded computers operated by non-network-savvy people that are still very much in use.

Think CNC machines in machine shops, SCADA systems, etc. I wouldn't be a bit surprised to find quite a few 2001-era boxes still in service.

At some level I think there's a good chance that they'd just work. I wrote a significant amount of the Lantronix terminal server code and it never occurred to me that I should enforce rules about 127.0.0.0 or Class D or Class E. It really didn't have much bearing on a terminal server or the other host-like things we built. If you typed it in, it would work, if you  listened on a port it wouldn't care what the address was. I would imagine that lots of stacks from back in the day were just like that. Mike

Zu wrote:

One anecdote (the non-technical grandma) illustrates a very real problem that would need to be addressed -- there are non-technical people (of all ages, if your concerned about ageism) which will need to implement technical changes for which they are not equipped with the skills to do.

They do not. Only if they want the extra address. Otherwise they are no worse off. Unless of course their ISP somehow decides its a good idea to put their router on the allzero, but you cant fix stupid. Joe

On Nov 18, 2021, at 4:31 PM, Randy Bush <randy@psg.com> wrote:

as a measurement kinda person, i wonder if anyone has looked at how much progress has been made on getting hard coded dependencies on D, E, 127, ... out of the firmware in all networked devices.

At least the E space is largely usable last I checked (eg: IOS-XR, JunOS). You can even measure traceroutes that have the class-e space in them from some cloud providers if your network and the intermediaries don’t do u-rpf as well. Most OS’es (MacOS, Linux, various *BSD) also permit this as well. My understanding is that the RedmondOS may not handle this, but if you need to number your infrastructure these addresses may work well. - Jared

On 11/19/21 8:27 AM, Randy Bush wrote:

these measurements would be great if there could be a full research- style paper, with methodology artifacts, and reproducible results. otherwise it disappears in the gossip stream of mailimg lists.

Maybe an experimental rfc making it a rfc 1918-like subnet and implementing it on openwrt or something like that to see what happens. how many ip cameras and the like roll over and die? same for class E addresses too, I suppose. The question with anything that asks about legacy is how long the long tail actually is. Mike, not that have any position on whether this is a good idea or not

On Thu, Nov 25, 2021 at 8:25 AM Jared Mauch <jared@puck.nether.net> wrote:

On Fri, Nov 19, 2021 at 09:43:26AM -0800, Michael Thomas wrote:

...

On 11/19/21 8:27 AM, Randy Bush wrote:

...

these measurements would be great if there could be a full research- style paper, with methodology artifacts, and reproducible results. otherwise it disappears in the gossip stream of mailimg lists.

Maybe an experimental rfc making it a rfc 1918-like subnet and implementing it on openwrt or something like that to see what happens. how many ip cameras and the like roll over and die? same for class E addresses too, I suppose. The question with anything that asks about legacy is how long the long tail actually is.

Mike, not that have any position on whether this is a good idea or not

I can tell you it's observable out there and if i use my home network to follow default i can tell it is working through those devices at least.

I agree with Randy it would be good if someone did this, it shouldn't be too hard with ripe atlas and a provider deciding to announce something

the atlas is good stuff, I am curious (OT) if they have added a videoconferencing-like test to it?

like 240.2.3.0/24 to see if it can be reached.

I very much would like a study of 240/4. In particular, announcing 255.255/16 might pick up a lot of misconfigured routers out there. Tests of the DNS would also be useful. This test setup has been working for years now... $ host postel.taht.net postel.taht.net has address 85.90.246.167 postel.taht.net has address 255.255.255.254 # wireguard vpn presently postel.taht.net has address 0.0.0.1 # wireguard vpn postel.taht.net has IPv6 address 2a01:7e01:e001:28:f3ee:d002:0:beef # ironically the ipv6 address is down and I hadn't noticed!

That's at least a decent measurement and report, but the client side OS will still be a variable that is difficult to digest. Not sure how many people are running very old IP stacks. This is another hard to measure problem.

- Jared

-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

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

That suggests an idea: Repurpose these addresses and allow the RIRs to sell them in the IPv4 secondary markets with some earmark for the funds. Plus or minus perhaps some worthy causes for "free" (not quite free but old school) allocations. If you can't agree on any worthwhile earmark you can always send me the proceeds. -- -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*

On Fri, Nov 19, 2021 at 10:32 AM John Curran <jcurran@istaff.org> wrote:

There’s this organization called the Internet Engineering Task Force that has been working hard to establish long-term financial independence and stability via the IETF Endowment project <https://www.ietf.org/endowment/> –

Several of the Internet community organizations have made substantial contributions to this goal, but much more will be needed if the IETF is to achieve long-term funding stability. Speaking entirely in my own personal capacity, I believe that long-term financial stability of the IETF is an extremely worthwhile goal for all of us to support and – to the extent that somehow changes to the IPv4 address specification result in a financial upside – I believe that the IETF Endowment would be a very appropriate beneficiary.

Hi John, That has some clever layers of subtlety to it. Instead of the IETF having to decide when the IPv4 changes have a wide enough deployment to release the addresses for use, they can simply make them available for sale with proceeds to the endowment. When would-be buyers decide they're good enough they'll be bought and used. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

John, On Nov 18, 2021, at 11:37 AM, John Gilmore <gnu@toad.com> wrote:

At current rates, 300 to 400 million addresses would last more than a decade!

Doesn’t this presume the redeployed addresses would be allocated via a market rather than via the RIRs? If so, who would receive the money?

There will be no future free-for-all that burns through 300 million IPv4 addresses in 4 months.

I suspect you underestimate the global demand and may not fully understand the rationale for address acquisition. Regards, -drc

On 20-Nov-2021, at 02:21, gnu@toad.com wrote:

David Conrad <drc@virtualized.org> wrote:

...

Doesn't this presume the redeployed addresses would be allocated via a market rather than via the RIRs?

If so, who would receive the money?

You ask great questions.

The community can and should do the engineering to extend the IP implementations. If that doesn't happen, the rest of the issues are moot. There would be no addresses to allocate and no money to receive.

It would take multiple years post-RFC and post-implementation before anyone could even contemplate doing allocation, of any sort. So while it's an entertaining sideline to think about later, at this point it is a distraction.

John

PS: It's conceivable that RIRs could allocate via a market. One has already done so (APNIC). What exactly APNIC has done (just for curiosity) ?

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

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

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.

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

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

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.

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

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

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/

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/

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

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

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!

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

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

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

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

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

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

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

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>

On Sat, Nov 20, 2021 at 1:02 PM Michael Thomas <mike@mtcc.com> wrote:

On 11/20/21 10:44 AM, Chris Adams wrote:

that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it seems that class D and class E would be a much better target than loopback. Mike, not that I have any stake in this

400M addresses may be excessive, but not so much the Low-hanging fruit you seemed to suggest. May be worth the consideration to reduce, but need to see your draft standard first, about what exactly you propose to reclaim from class D.. Unlike class E and 127/8, there are many protocols and applications that communicate between separate devices on a network over class D in a non-unicast manner to contend with that utilize either official MC assignments, or Private/org-specific assignments from available class D space - Multicast/broadcast addresses used by many control systems such as routing protocols (VRRP), camera systems / physical security, etc. -- -JH

On 11/20/21 11:51 AM, William Herrin wrote:

If I had to guess, changing 224/4 is probably the biggest lift. The other proposals mainly involve altering configuration, removing some possibly hardcoded filters and in a few cases waiting for silicon to age out of the system. Changing 224/4 means following a different code path which does something fundamentally different with the packets -- unicast instead of multicast.

Yes, I agree it's the hardest. But if you're going to make changes at all you might as well get all of them. Was it the politics of ipv6 that this didn't get resolved in the 90's when it was a lot more tractable? Mike

On 11/20/21 12:37 PM, William Herrin wrote:

On Sat, Nov 20, 2021 at 12:03 PM Michael Thomas <mike@mtcc.com> wrote:

...

Was it the politics of ipv6 that this didn't get resolved in the 90's when it was a lot more tractable? No, in the '90s we didn't have nearly the basis for looking ahead. We might still have invented a new way to use IP addresses that required a block that wasn't unicast. It was politics in the 2000's and the 2010's, as it is today.

In the early to mid 90's it was still a crap shoot of whether IP was going to win (though it was really the only game in town for non-lan) but by when I started at Cisco in 1998 it was the clear winner with broadband starting to roll out. It was also obvious that v4 address space was going to run out which of course was the core reason for v6. So I don't understand why this didn't get done then when it was a *lot* easier. It sure smacks of politics. Mike

“In the early to mid 90's it was still a crap shoot of whether IP was going to win (though it was really the only game in town for non-lan) but by when I started at Cisco in 1998 it was the clear winner with broadband starting to roll out” </Lurk> IP was the clear winner since the Clinton-Gore Initiative of 1991, as we called it in 1991. (History records this as the “Gore Bill”, feel free to Google.) [ He invented the Internet, you know! 😊 ] at which time we began prototype conversion of non-DOD Government agencies to “The IP Paradigm”, till about 94-95, when the next phase was rollout to K-12 and Public libraries, as well as mainstream ISP’s. This necessitated the birth of the NAP’s. These NAP’s were supposed to be -Private- sector, not Public. Many of us “Riding the Bill” left Public sector contracting to Private sector to facilitate this transition. (Hence the date of my ARIN-POC, actually just POC, ARIN didn’t exist yet) The debate in 95 was not “IP or not IP”, it was “Will your NAP be FDDI like the MAE’s, ATM, or even the LINX model of a GIGE switch. (Frame was already fading) “ While in private sector there may have been some doubt, the IP Juggernaut was well underway in Government by almost half a decade, and as they say “That is the sound of inevitability, Neo”, at that point. IP was as “nailed to the wall” early to mid 90’s as Tony Li’s resignation was to his bosses door, at Cisco, a year or so, later. However, FWIW, the private sector had yet to hear the sound of the train. Many brand protocol loyalist fought IP adoption all the way until their favorite brand -adopted- it, so I understand your perspective. FWIW, I miss being able to fit into my “No 53” Tee Shirt. ☹ Matter of fact, many of us missed the foreshadowing of the “woke” generation when we got in trouble for painting cross hairs on a backhoe for a NANOG Tee… it got “banned” for “possibly inciting violence against backhoe operators” . :-* <Lurk> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: Michael Thomas<mailto:mike@mtcc.com> Sent: Saturday, November 20, 2021 3:52 PM To: William Herrin<mailto:bill@herrin.us> Cc: nanog@nanog.org<mailto:nanog@nanog.org> Subject: Re: Class D addresses? was: Redploying most of 127/8 as unicast public On 11/20/21 12:37 PM, William Herrin wrote:

On Sat, Nov 20, 2021 at 12:03 PM Michael Thomas <mike@mtcc.com> wrote:

...

Was it the politics of ipv6 that this didn't get resolved in the 90's when it was a lot more tractable? No, in the '90s we didn't have nearly the basis for looking ahead. We might still have invented a new way to use IP addresses that required a block that wasn't unicast. It was politics in the 2000's and the 2010's, as it is today.

In the early to mid 90's it was still a crap shoot of whether IP was going to win (though it was really the only game in town for non-lan) but by when I started at Cisco in 1998 it was the clear winner with broadband starting to roll out. It was also obvious that v4 address space was going to run out which of course was the core reason for v6. So I don't understand why this didn't get done then when it was a *lot* easier. It sure smacks of politics. Mike

On Sun, Nov 21, 2021 at 4:16 AM Eliot Lear <lear@ofcourseimright.com> wrote:

In 2008, Vince Fuller, Dave Meyer, and I put together draft-fuller-240space, and we presented it to the IETF. There were definitely people who thought we should just try to get to v6, but what really stopped us was a point that Dave Thaler made: unintended impact on non-participating devices, and in particular CPE/consumer firewall gear, and at the time there were serious concerns about some endpoint systems as well. Back then it might have been possible to use the space as part of an SP interior, but no SP demonstrated any interest at the time, because it would have amounted to an additional transition.

Hi Eliot, I wasn't in the working group so I'll take your word for it. Something rather different happened later when folks on NANOG discovered that the IETF had considered and abandoned the idea. Opinion coalesced into two core groups: Group 1: Shut up and use IPv6. We don't want the IETF or vendors distracted from that effort with improvements to IPv4. Mumble mumble titanic deck chairs harrumph. Group 2: Why is the IETF being so myopic? We're likely to need more IPv4 addresses, 240/4 is untouched, and this sort of change has a long lead time. Mumble mumble heads up tailpipes harrumph. More than a decade later, the "titantic" is shockingly still afloat and it would be strikingly useful if there were a mostly working /4 of IP addresses we could argue about how best to employ. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

Greg Thanks for posting the links.  Our old draft seems to have largely had its intended effect without ever having been issued as an RFC (moohaha).  Most implementations don't hardcode 240/4 into a bogon filter.  We had at the time left open what next steps should be. So what's the road to actually being able to use this space?  It depends.  If you want to use it for your interior, and return routability beyond your AS and external in-addr service is NOT important, all that stops you today is whatever set of issues you find in your own back yard. If you want to allocate space to customers or need in-addr/return routability, obviously that's More Work that should not be underestimated.  240/4 appears in a number of bogon filters, not all of which are controlled by people tracking operator lists or the IETF. And that complicates matters in terms of whether the space should be moved to a unallocated or treated like 10/8.  At least the latter seems to match the testing that has thus far been performed. Eliot On 23.11.21 02:01, Greg Skinner via NANOG wrote:

...

On Nov 21, 2021, at 1:20 PM, William Herrin <bill@herrin.us> wrote:

On Sun, Nov 21, 2021 at 4:16 AM Eliot Lear <lear at ofcourseimright.com <http://ofcourseimright.com>> wrote:

...

In 2008, Vince Fuller, Dave Meyer, and I put together draft-fuller-240space, and we presented it to the IETF. There were definitely people who thought we should just try to get to v6, but what really stopped us was a point that Dave Thaler made: unintended impact on non-participating devices, and in particular CPE/consumer firewall gear, and at the time there were  serious concerns about some endpoint systems as well.  Back then it might have been possible to use the space as part of an SP interior, but no SP demonstrated any interest at the time, because it would have amounted to an additional transition.

Hi Eliot,

I wasn't in the working group so I'll take your word for it. Something rather different happened later when folks on NANOG discovered that the IETF had considered and abandoned the idea. Opinion coalesced into two core groups:

Group 1: Shut up and use IPv6. We don't want the IETF or vendors distracted from that effort with improvements to IPv4. Mumble mumble titanic deck chairs harrumph.

Group 2: Why is the IETF being so myopic? We're likely to need more IPv4 addresses, 240/4 is untouched, and this sort of change has a long lead time. Mumble mumble heads up tailpipes harrumph.

More than a decade later, the "titantic" is shockingly still afloat and it would be strikingly useful if there were a mostly working /4 of IP addresses we could argue about how best to employ.

Regards, Bill Herrin

-- William Herrin bill at herrin.us <http://herrin.us> https://bill.herrin.us/

I agree, generally speaking.  IMO, it’s unfortunate that these addresses are being held in “limbo” while these debates go on.  I’m not complaining about the debates per se, but the longer we go without resolution, these addresses can’t be put to any (documented) use.

There’s background information available that might be helpful to those who haven’t yet seen it:

https://datatracker.ietf.org/doc/slides-70-intarea-4/ (links to the draft-fuller-240space slides from IETF 70) https://datatracker.ietf.org/doc/minutes-70-intarea/ (IETF 70 INTAREA meeting minutes) https://mailman.nanog.org/pipermail/nanog/2007-October/thread.html (NANOG October 2007 mail archives, containing links to the “240/4” thread) https://puck.nether.net/pipermail/240-e/ (the 240-e archives) https://mailarchive.ietf.org/arch/browse/int-area/ (IETF INTAREA archives, containing comments on the 240space draft and related issues, roughly in the same time frame as in the previous links)

—gregbo

On Nov 23, 2021, at 10:33 AM, William Herrin <bill@herrin.us> wrote:

On Tue, Nov 23, 2021 at 5:03 AM Eliot Lear <lear@ofcourseimright.com> wrote:

...

So what's the road to actually being able to use [240/4]?

1. Move it from "reserved" to "unallocated unicast" (IETF action) 2. Wait 10 years 3. Now that nearly all equipment that didn't treat it as yet-to-be-allocated unicast has cycled out of use, argue about what to allocate the addresses to for best effect.

Or… 1. IAB or IESG requests the IANA team to delegate one of the 240/4 /8s to the RIRs on demand for experimental purposes for a fixed period of time (a year or two?). 2. The RIRs, with input from their communities, formulate research programs to explore the viability of the space they have just received for “normal” unicast space. 3. The RIRs assign that space in accordance with those research programs. 4. At the end of the fixed period of time, research reports are published. 5. Armed with hard data on the usability of the 240/4 /8s allocated, people can scream past each other much more authoritatively on the topic of what to do with 240/4.

Bottom line though is that the IETF has to act before anyone else reasonably can.

To be honest, I don’t think it actually matters if it is the IAB, the IESG, or the NRO that directs the IANA to do stuff (although Kim @ IANA might have a different opinion and he’s more authoritative). What I believe matters is that there is consensus that additional data is needed. I’m not sure we’re at that point as yet — too many people appear to know The Truth. Regards, -drc

Bill, On Nov 23, 2021, at 11:12 PM, William Herrin <bill@herrin.us> wrote:

...

1. IAB or IESG requests the IANA team to delegate one of the 240/4 /8s to the RIRs on demand for experimental purposes for a fixed period of time (a year or two?).

I like research but what would the RIRs study? The percentage of the 2021 Internet reachable from a station assigned a 240/4 IP address? Suppose it's 95%? Or 50%? Is there a difference? Neither one is enough to deploy the addresses for 2021 global use.

Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC and they said similar things when 1.1.1.0/24 was stood up as an experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.

...

5. Armed with hard data on the usability of the 240/4 /8s allocated, people can scream past each other much more authoritatively on the topic of what to do with 240/4.

Which is not particularly valuable. We already know the addresses are dysfunctional on the 2021 Internet. There's no credible disagreement on that point.

Seems to me that a number of folks on this list and during this discussion would disagree with a blanket assertion that 240/4 is “dysfunctional on the 2021 Internet” - some of them even wrote a draft discussing the possibility.

...

2. IAB or IESG requests the IANA team to delegate one of the 240/4 /8s to the RIRs on demand for experimental purposes for a fixed period of time

But that still starts with:

...

1. Move 240/4 from "reserved" to "unallocated unicast"

OK, but this seems like a quibble. The status for 240/4 is “ RESERVED: designated by the IETF for specific non-global-unicast purposes as noted.” The “as noted” part is “Future Use”. As far as I’m aware, “future use” would not preclude “experimental use” however if it makes people feel better to have an IANA considerations section that says the prefixes need to be moved to ALLOCATED, I struggle to see how that would be a problem. Regards, -drc

Le Wed, Nov 24, 2021 at 05:08:43PM -0800, William Herrin a écrit :

I don't recall there being any equipment or software compatibility concerns with 1.0.0.0/8. If you do, feel free to refresh my memory.

Perhaps not the whole /8 but definitely some buggy implementations : https://seclists.org/nanog/2018/Apr/52

Eliot Lear <lear@ofcourseimright.com> wrote:

In 2008, Vince Fuller, Dave Meyer, and I put together draft-fuller-240space, and we presented it to the IETF. There were definitely people who thought we should just try to get to v6, but what really stopped us was a point that Dave Thaler made: unintended impact on non-participating devices, and in particular CPE/consumer firewall gear, and at the time there were serious concerns about some endpoint systems as well.

I was not in this part of IETF in those days, so I did not participate in those discussions. But I later read them on the archived mailing list, and reached out by email to Dave Thaler for more details about his concerns. He responded with the same general issues (and a request that we and everyone else spend more time on IPv6). I asked in a subsequent message for any details he has about such products that he thought would fail. He was unable or unwilling to point out even a single operating system, Internet node type, or firewall product that would fail unsafely if it saw packets from the 240/4 range. As documented in our Internet-Draft, all such products known to us either accept those packets as unicast traffic, or reject such packets and do not let them through. None crashes, reboots, fills logfiles with endless messages, falls on the floor, or otherwise fails. No known firewall is letting 240/4 packets through on the theory that it's perfectly safe because every end-system will discard them. As far as I can tell, what Eliot says really stopped this proposal in 2008 was Dave's hand-wave of *potential* concern, not an actual documented problem with the proposal. If anyone knows an *actual* documented problem with 240/4 packets, please tell us! (And as I pointed out subsequently to Dave, if any nodes currently in service would *actually* crash if they received a 240/4 packet, that's a critical denial of service issue. For reasons completely independent from our proposal, those machines should be rapidly identified and patched, rather than remaining vulnerable from 2008 thru 2021 and beyond. It would be trivial for an attacker to send such packets-of-death from any Linux, Solaris, Android, MacOS, or iOS machine that they've broken into on the local LAN. And even Windows machines may have ways to send raw Ethernet packets that could be crafted by an attacker to appear to be deadly IPv4 240/4 packets.) John

Subject: Re: Class D addresses? was: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 11:51:24AM -0800 Quoting William Herrin (bill@herrin.us):

Multicast is not the same as broadcast and yes, it's a thing. Mainly it's a thing confined to the local broadcast domain but in that scope it's quite widely used.

All the heavy lifting in video production via IP is done over multicast. Mostly, it is internal to one organisation, and the 239/8 (RFC2365) block is being used, but routing multi-gbit RTP flows over multicast is a thing where I work. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 YOU!! Give me the CUTEST, PINKEST, most charming little VICTORIAN DOLLHOUSE you can find!! An make it SNAPPY!!

It appears that Michael Thomas <mike@mtcc.com> said:

There is just as big a block of addresses with class D addresses for broadcast. Is broadcast really even a thing these days?

It's multicast and no, but it hardly matters. It's the same problem, if you wanted to turn it into unicast space you'd need a global forklift upgrade. FWIW, I see a trickle of class D traffic coming through my router but no class E. R's, John

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

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!

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…

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