Hi, Tom: 0)    Thanks to your thoughts. 1)    First, logistics: Since this was my first post to this Forum, I got an auto-response stating that my post was being moderated. Then, I got your message even before I received any follow-up notice from such, nor my writing being published. Are you responding to the general distribution or acting as a moderator? 2)    " .... an overly convoluted mechanism to tunnel 240/4. ....    ":    We started our work due to curiosity. As we made progresses in various areas, quite a few topics have distilled to a different yet much clearer picture. Allow me to describe the current EzIP proposal with respect to these aspects:     A.    "overly convoluted":    EzIP proposes to make use of the long-reserved 240/4 NetBlock by utilizing the RFC791 to carry it.  However, this is only needed for the long term full end-to-end deployment. For the immediate EzIP configuration that is for supporting the current Server / Client (Master /Slave) model (similar to the current CG-NAT, or CDN), EzIP will be using a degenerated configuration which we call it RAN (Regional Area Network) where the standard IPv4 packet header will be suffice, even without the RFC791. I believe these schemes are opposite to "convoluted".     B.    "tunnel": Instead of tunneling in the current sense of 6to4 tunneling, or similar, which interacts with the parameters of transmission environment, EzIP is an */overlay/* network consisting of RANs (Regional Area Networks), each is tethered from the current Internet via one IPv4 public address. Since each RAN appears to be a private network to the Internet core, pretty much everything in the RAN is independent of the latter. Direct communications between IoTs residing in separate RANs, when needed, will still be carried by native IPv4 packets (with the addition of Option Words carrying IoTs' Source and Destination addresses within the host RANs, respectively).     Could you please clarify your characterizations of the above? Regards, Abe (2022-03-08 10:46) On 2022-03-08 09:09, Tom Beecher wrote:

I recall reading the IETF draft some time ago. It seemed like an overly convoluted mechanism to tunnel 240/4.

On Tue, Mar 8, 2022 at 8:50 AM Abraham Y. Chen <aychen@avinta.com> wrote:

Dear Colleagues:

0)    I was made aware of a recent discussion on this Forum that cited our work on the 240/4 NetBlock, nicknamed EzIP (Phonetic for Easy IPv4). (Please see, at the end of this MSG, the URL to the discussion and the highlighted text where the citation was made.)

1)    As the lead investigator of the EzIP Project, I would like to  formally introduce our solution by bringing your attention to an overview whitepaper:

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

    In a nutshell, EzIP proposes to disable the program codes in current routers that have been disabling the use of the 240/4 NetBlock. The cost of this software engineering should be minimal. The EzIP deployment architecture is the same as that of the existing CG-NAT (Carrier Grade Network Address Translation). Consequently, there is no need to modify any hardware equipment. There is an online setup description (Reference II), called RAN (Regional Area Network), that demonstrates the feasibility of this approach.

2)    There are additional consequential benefits by deploying EzIP, such as those mentioned by our comment to Reference III in the above whitepaper.

I look forward to addressing your thoughts.

Regards,

Abe (2022-03-07 17:14 EST) VP Engineering Avinta Communications, Inc. Milpitas, CA 95035 USA +1(408)942-1485 Skype: Abraham.Y.Chen eMail: AYChen@Avinta.com WebSite: www.Avinta.com <http://www.Avinta.com>

***********************

https://mailman.nanog.org/pipermail/nanog/2021-November/216766.html

Class D addresses? was: Redploying most of 127/8 as unicast public

*Greg Skinner* gregskinner0 at icloud.com <mailto:nanog%40nanog.org?Subject=Re%3A%20Class%20D%20addresses%3F%20was%3A%20Redploying%20most%20of%20127/8%20as%20unicast%20public&In-Reply-To=%3CFEDBF677-BC75-47F3-A92D-2611F43283BA%40icloud.com%3E> /Mon Nov 29 18:47:14 UTC 2021/

* Previous message (by thread): Class D addresses? was: Redploying most of 127/8 as unicast public <https://mailman.nanog.org/pipermail/nanog/2021-November/216640.html> * Next message (by thread): Class E addresses? 240/4 history <https://mailman.nanog.org/pipermail/nanog/2021-November/216602.html> * *Messages sorted by:* [ date ] <https://mailman.nanog.org/pipermail/nanog/2021-November/date.html#216766> [ thread ] <https://mailman.nanog.org/pipermail/nanog/2021-November/thread.html#216766> [ subject ] <https://mailman.nanog.org/pipermail/nanog/2021-November/subject.html#216766> [ author ] <https://mailman.nanog.org/pipermail/nanog/2021-November/author.html#216766>

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

>/On Nov 24, 2021, at 5:08 PM, William Herrin <bill at herrin.us <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: />//>/On Wed, Nov 24, 2021 at 4:36 PM David Conrad <drc at virtualized.org <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: />>>/I like research but what would the RIRs study? The percentage of the />>//>>/Lots of people said similar things when 1.0.0.0/8 <http://1.0.0.0/8> was allocated to APNIC />>/and they said similar things when 1.1.1.0/24 <http://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. />//>/Hi David, />//>/I don't recall there being any equipment or software compatibility />/concerns with 1.0.0.0/8 <http://1.0.0.0/8>. If you do, feel free to refresh my memory. As />/I recall it, there were concerns with prior local use and potential />/trash traffic. It seemed likely those concerns could be addressed with />/experiments, and the experiments in fact addressed them. />//>/The prior local use worry reared its head again with 240/4 but given />/the prior experience with 1.0.0.0/8 <http://1.0.0.0/8> I don't personally believe we need />/to re-run that experiment just because the numbers are part of a />/different block. />//>//>>/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. />//>/Line them up. Show of hands. Who really thinks that if we assign />/240.0.0.1 to a customer tomorrow without waiting for anyone to clean />/up their software and hardware, you won't get enough complaints about />/things not working that you have to take it back and assign a />/different address instead? />//>//>>/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”. />//>/It's not a quibble. Some vendors take the current status to mean />/"treat it like unicast until we're told otherwise." Others take the />/status to mean, "packets with these addresses are bogons without a />/defined routing behavior until we're told otherwise." The result is />/incompatible behavior between vendors. Changing that direction to />/"treat it like unicast" without ambiguity is not a quibble. />//>/Regards, />/Bill Herrin />//>/-- />/William Herrin />/bill at herrin.us <https://mailman.nanog.org/mailman/listinfo/nanog> />/https://bill.herrin.us/ / For what it’s worth, I’ve been tracking this issue on other netops mailing lists. There is a recent post on the LACNOG list from Leandro Bertholdo <https://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html> referencing https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ <https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/>, a draft proposing another way to make additional IPv4 address space available I haven’t had time to read the draft closely, but I noticed that it involves the use of 240/4. Subsequent googling about the draft turned up a presentation <https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf> describing how the techniques described could be deployed. I noticed that the presentation made reference to OpenWRT, so perhaps the authors are aware of the work that the authors of the IPv4 Unicast Extensions Project have done in that area.

The adaptive-ipv4 draft will expire sometime next month, so anyone interested in seeing it move forward should contact the authors.

—gregbo

*******************

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>

<#m_-6939840509531889009_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

It appears that Anne Mitchell <amitchell@isipp.com> said:

...

Cc: NANOG <nanog@nanog.org>, Greg Skinner <gregskinner0@icloud.com>, "Karandikar, Abhay" <Director@iitk.ac.in>, Rama Ati <rama_ati@outlook.com>, Bob Corner GMAIL <bobbiecorner@gmail.com>, "Hsing, T. Russell" <tHsing@ieee.org>, "Chen, Henry C.J." <hcjchen@avinta.com>, ST Hsieh <uschinaeetc@gmail.com>, "Chen, Abraham Y." <AYChen@alum.mit.edu>

This is a whole lot of cc:s to people who aren't even part of this group/list. One wonders with this many cc:s, how many bcc:s there also were, and to whom.

There are several thousand people on the NANOG list, and public web archives. I don't think this is a useful question. FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require that every host on the Internet update its network stack, which would take on the order of a decade, to free up some space that would likely be depleted in a year or two. It's basically the same amount of work as getting everything to work on IPv6. R's, John

It appears that William Herrin <bill@herrin.us> said:

On Tue, Mar 8, 2022 at 12:34 PM John Levine <johnl@iecc.com> wrote:

...

FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require that every host on the Internet update its network stack,

Hi John,

That's incorrect and obviously so. While repurposing 240/4 as general purpose Internet addresses might require that level of effort, other uses such as local LAN addressing would only require the equipment on that one lan to be updated -- a much more attainable goal.

If you want to patch your devices so they use 240/4 as a version of 10/8 on your own network, you can do that any time you want.

Reallocating 240/4 as unpurposed unicast address space would allow some standards-compliant uses to become practical before others. A few quite quickly.

So long as we agree that "quickly" means a decade. If we did this bad idea, at some point there would be a tipping point where enough hosts recognized them to be useful, but we say the same thing about IPv6.

Is it not past time we admit that we have no real idea what the schedule or level of effort will be for making IPv6 ubiquitous?

Oh, absolutely. I have conversations with my hosting provider in which they tell me that nobody has ever asked for IPv6 other than me, and they had no idea their upstream (Spectrum) had native IPv6. So I keep using a tunnel. I would expect the same conversations about 240/4. R's, John

John Levine wrote:

Oh, absolutely. I have conversations with my hosting provider in which they tell me that nobody has ever asked for IPv6 other than me, and they had no idea their upstream (Spectrum) had native IPv6. So I keep using a tunnel.

Why do you think you need IPv6? What is the point to have a tunnel even if people, maybe excluding you, are fine without it? Masataka Ohta

On Tue, 2022-03-08 at 19:25 -0500, Tom Beecher wrote:

The only way IPv6 will ever be ubiquitous is if there comes a time where there is some forcing event that requires it to be. 

Unless that occurs, people will continue to spend time and energy coming up with ways to squeeze the blood out of v4 that could have been used to get v6 going instead. I don't foresee anything changing for most of the rest of our careers, and possibly the next generation behind us. 

<sarcasm> Exactly. The only thing I see changing anything is when the MTU gets low enough that you are sending more encapsulation headers than payload. When the effective MTU is 8, then... But by then I'll have a 1Tb link to my house... so who cares?! </sarcasm>

John R. Levine writes:

This still doesn't mean that screwing around with 240/4 or, an even worse 127/8 minus 127/24, is a good idea.

I hope you'll be slightly mollified to learn that it's actually 127/8 minus 127/16. https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-127/ That's the most challenging one, but we've still seen something of a lack of people getting in touch to point out concrete problems. One person did get in touch to describe an unofficial use of, apparently, all of 127/8 as private address space in a VPN product. If people let us know about more, we can investigate workarounds or possible changes to our proposals. We previously thought that the reference NTP implementation was using all of 127/8 to identify hardware clock drivers. But it turns out it doesn't actually connect to these. If anyone reading this knows of something that uses a loopback address outside of 127/16 for an application, or something that can't be updated and would be harmed if the rest of the network stopped treating this as loopback, we'd be glad to hear about it.

Owen DeLong via NANOG wrote:

One thing is for certain… If folks had put 0.10 as much effort into deploying IPv6 as has been put into arguing about whether or not ~17 /8s worth of IPv4 makes a meaningful difference to the internet as a whole, IPv4 would long since have become irrelevant as it must eventually be.

Owen

You might have had a decent point there instead of a soundbite, except that you are conflating different people together, as if the ones arguing to extend IPv4 are conveniently the same ones whom if they redirected their efforts would have IPv6 deployed in a few jiffies. Reality is quite a bit different. Joe

On Tue, Mar 8, 2022 at 11:30 PM Mark Andrews <marka@isc.org> wrote:

Given the draft lies about the status of 127/8. Words have meanings.

When all of 127.0.0.0/8 was reserved for loopback addressing, IPv4 addresses were not yet recognized as scarce. Today, there is no justification for allocating 1/256 of all IPv4 addresses for this purpose, when only one of these addresses is commonly used and only a handful are regularly used at all. Unreserving the majority of these addresses provides a large number of additional IPv4 host addresses for possible use, alleviating some of the pressure of IPv4 address exhaustion.

It is not RESERVED, it is ASSIGNED.

The class A network number 127 is assigned the "loopback" function, that is, a datagram sent by a higher level protocol to a network 127 address should loop back inside the host. No datagram "sent" to a network 127 address should ever appear on any network anywhere.

If it was actually reserved there would be much less complaint. People have made use of that space based on the fact that it was ASSIGNED a purpose whether you like that or feel that it was a good use of resources.

Compulsory acquisition is something that should not be done lightly. It also requires fair compensation to be paid.

...

On 9 Mar 2022, at 13:35, Seth David Schoen <schoen@loyalty.org> wrote:

John R. Levine writes:

...

This still doesn't mean that screwing around with 240/4 or, an even worse 127/8 minus 127/24, is a good idea.

I hope you'll be slightly mollified to learn that it's actually 127/8 minus 127/16.

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

That's the most challenging one, but we've still seen something of a lack of people getting in touch to point out concrete problems.

One person did get in touch to describe an unofficial use of, apparently, all of 127/8 as private address space in a VPN product. If people let us know about more, we can investigate workarounds or possible changes to our proposals.

What’s “unofficial” about it? The point of ASSIGNING 127/8 for loopback meant the ANYONE could use that address space OFFICIALLY so long as packets with those addresses didn’t leave the machine.

re: *the machine*. This touches upon the one use case I've come up with for narrowing the scope of the loopback 127.x, and widening it slightly. What is a "machine"? nowadays there are fleets of microservices (:cough: kubernetes) being deployed. Crossing a security barrier within one machine is one thing, crossing it into the wire between machines, another. Local compute, separated by vms or containers, is often orders of magnitude faster than going over a wire, and a cluster of those can be carried from physical machine to physical machine. I otherwise don't want to be drawn into the tar-baby discussion about 127, it's discussion of utilizing 240/4 sanely and 0/8 sanely I desire more.

...

We previously thought that the reference NTP implementation was using all of 127/8 to identify hardware clock drivers. But it turns out it doesn't actually connect to these.

If anyone reading this knows of something that uses a loopback address outside of 127/16 for an application, or something that can't be updated and would be harmed if the rest of the network stopped treating this as loopback, we'd be glad to hear about it.

What does it matter what people are using those addresses for. They are using them in good faith and are under no obligation to report how they are using them.

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

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

Tom Beecher wrote:

The only way IPv6 will ever be ubiquitous is if there comes a time where there is some forcing event that requires it to be.

Unless that occurs, people will continue to spend time and energy coming up with ways to squeeze the blood out of v4 that could have been used to get v6 going instead. I don't foresee anything changing for most of the rest of our careers, and possibly the next generation behind us.

I dont think it is as bad as that, but what you are implicitly saying is that even multi-decades efforts to prolong IPv4 have clear justification to begin now, if not sooner. As for the rest of this popular meme, instead of aspirations to force a chosen technology down the throats of many clearly unwilling and/or uninterested parties whom make up a still significant percentage of the internet, perhaps more effort should be expended on A) making the chosen technology more attractive, more useful, more deployable, more compatible, etc. Because clearly its not enough of those things for many, regardless of whatever personal experience or theories you may have on the matter. B) Keeping the rest of the internet as functional as possible, with whatever tradeoffs make send, for the actual potential duration of A instead of pie-in-the-sky estimates. Which have a 100% track record of being wrong. Persuasion, not coercion. Which even if it were possible, is wrong and immoral. The internet is supposed to be about mutually beneficial cooperation, not hierarchical coercion. Joe

I agree. iMO, this 240/4 issue is another one of those tussles in cyberspace <https://david.choffnes.com/classes/cs4700fa14/papers/tussle.pdf>. But I don’t fault IETF people or anyone else who pursues technical solutions to these types of problems as long as they are open and honest about the limitations of these solutions. Also, IMO, the value of having a discussion about this issue here (and other NOG forums) is to get the perspective of people who (generally speaking) deal more immediately with the problems the broader “online" population has with IETF-based technology. —gregbo

On Mar 8, 2022, at 9:25 PM, bzs@theworld.com wrote:

I'm beginning to wonder if the internet will survive the ipv6 adoption debates.

Here's the real problem which you all can promptly ignore:

The IETF et al are full of bright technical people who can design protocols, packet formats, etc.

But many of the major problems facing the internet are not, at their core, engineering problems.

They're in the realm of social, legal, marketing, politics, int'l policy, governance, law enforcement, commerce, economics, sociology, psychology, etc. which TBH as bright as many of the engineers et al are these problems are way beyond their ken, occasional polymath excepted.

But first you have to admit you have a problem, and limitations.

Shouting at the rafters about address space depletion etc while waving RFCs may not quite do it.

Similar can be said about spam, malware attacks, phishing, etc.

Yet another cryptographic protocol probably won't save the day but as the expression goes when all you have is a hammer the whole world looks like a nail.

-- -Barry Shein

Software Tool & Die | bzs at 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*

What struck me is how NONE of those challenges in doing IPv6 deployment in the field had anything to do with fending off attempts to make IPv4 better.

Let me say that again. Among all the reasons why IPv6 didn't take over the world, NONE of them is "because we spent all our time improving IPv4 standards instead".

I’ll somewhat call bullshit on this conclusion from the data available. True, none of the reasons directly claim “IPv6 isn’t good enough because we did X for v4 instead”, yet all of them in some way refer back to “insufficient resources to make this the top priority.” which means that any resources being dedicated to improving (or more accurately further band-aiding) IPv4 are effectively being taken away from solving the problems that exist with IPv6 pretty much by definition. So I will stand by my statement that if we put half of the effort that has been spent discussing these 16 relatively useless /8s that would not significantly improve the lifespan of IPv4 on resolving the barriers to deployment of IPv6, we would actually have a lot less need for IPv4 and a lot more deployment of IPv6 already. Owen

So your answer is do nothing because we should be spending the time on v6? There are a lot of barriers to v6, and there is no logical reason why this range of v4 subnets wasn’t made available to the world a decade (or two) ago. The next best time to do it is now though. On Wed, Mar 16, 2022 at 12:21 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:

...

What struck me is how NONE of those challenges in doing IPv6 deployment in the field had anything to do with fending off attempts to make IPv4 better.

Let me say that again. Among all the reasons why IPv6 didn't take over the world, NONE of them is "because we spent all our time improving IPv4 standards instead".

I’ll somewhat call bullshit on this conclusion from the data available. True, none of the reasons directly claim “IPv6 isn’t good enough because we did X for v4 instead”, yet all of them in some way refer back to “insufficient resources to make this the top priority.” which means that any resources being dedicated to improving (or more accurately further band-aiding) IPv4 are effectively being taken away from solving the problems that exist with IPv6 pretty much by definition.

So I will stand by my statement that if we put half of the effort that has been spent discussing these 16 relatively useless /8s that would not significantly improve the lifespan of IPv4 on resolving the barriers to deployment of IPv6, we would actually have a lot less need for IPv4 and a lot more deployment of IPv6 already.

Owen

...

Let me say that again. Among all the reasons why IPv6 didn't take over the world, NONE of them is "because we spent all our time improving IPv4 standards instead".

I'll somewhat call bullshit on this conclusion from the data available. True, none of the reasons directly claim "IPv6 isn't good enough because we did X for v4 instead", yet all of them in some way refer back to "insufficient resources to make this the top priority." which means that any resources being dedicated to improving (or more accurately further band-aiding) IPv4 are effectively being taken away from solving the problems that exist with IPv6 pretty much by definition.

Hi, Owen. Your reasoning proves too much. You propose that every minute of every day that every human isn't actively working at top priority to make IPv6 the default protocol on the Internet, are misguided efforts. "Pretty much by definition." "Any resources being dedicated to" eating, sleeping, going to the bathroom, listening to music, painting a canvas, repairing cars, steering ships, growing food, running railroads, going to school, going to work, riding bicycles, ending homelessness, stopping wars, reforming drug laws, band-aiding IPv4, reducing corruption in government, posting to mailing lists (as you pointed out -- by posting a message to a mailing list!), hopping, skipping, and jumping, "are effectively being taken away from solving the problems that exist with IPv6." Given the billions of people who eat and sleep for HOURS every day, I think I am doing pretty well by just coordinating three people part-time trying to improve IPv4 a little bit. The eaters' and sleepers' level of non-IPv6 effort is billions of times stronger than my level of non-IPv6 effort. Can you forgive me? John

I have qualms about these drafts also. However, even if the IETF does not move forward with any of them (not even to adopt them as WG items), that doesn’t mean they never will. Times change. Circumstances change. The IETF has changed its position on several (IMO) key issues during its existence. Perhaps this will be one of those times. Incidentally, if you take a look at this post from Theodore Ts’o <https://mailarchive.ietf.org/arch/msg/ietf/IGKkL8IM1IptV4Q3Z3pko6OC1Xs/> he’s pretty much saying the same thing that Barry Shein said, that the IETF isn’t as good at policy as it is in producing protocol standards. (The thread it’s from started from a response to the publication of RFC2008 <https://www.rfc-editor.org/rfc/rfc2008.txt> as a Best Current Practice, in spite of “vigorous opposition”.) The other thing I wanted to say is for anyone who doesn’t know a lot about the IETF workings, the contributions of some of the authors of the Schoen drafts are recognized and respected in the IETF Transport Area. They’re not new to this stuff. They have “clue”. They do due diligence. They produce running code, and (IMO) are seeking rough consensus. I believe that in the IETF of, say, a quarter century ago, their drafts would have progressed further through the standards process. For various reasons, today’s IETF is different, but could still change its minds. I believe the authors of the Schoen drafts are capable of drumming up support for their ideas even if they don’t (immediately) become IETF drafts, and that the IETF might change its position on their ideas, as a result of such support. —gregbo

On Mar 16, 2022, at 5:28 AM, Tom Beecher <beecher@beecher.cc> wrote:

No quibble about the discussion happening on a NOG list, not at all.

But frankly unless the proposal is even starting to move forward in the IETF process such that a standards change is possible, it's just noise. ( I don't predict that the draft being discussed ever gets that far anyways ; it has serious deficiencies.)

On Sat, Mar 12, 2022 at 6:53 PM Greg Skinner via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote: I agree. iMO, this 240/4 issue is another one of those tussles in cyberspace <https://david.choffnes.com/classes/cs4700fa14/papers/tussle.pdf>. But I don’t fault IETF people or anyone else who pursues technical solutions to these types of problems as long as they are open and honest about the limitations of these solutions.

Also, IMO, the value of having a discussion about this issue here (and other NOG forums) is to get the perspective of people who (generally speaking) deal more immediately with the problems the broader “online" population has with IETF-based technology.

—gregbo

...

On Mar 8, 2022, at 9:25 PM, bzs@theworld.com <mailto:bzs@theworld.com> wrote:

I'm beginning to wonder if the internet will survive the ipv6 adoption debates.

Here's the real problem which you all can promptly ignore:

The IETF et al are full of bright technical people who can design protocols, packet formats, etc.

But many of the major problems facing the internet are not, at their core, engineering problems.

They're in the realm of social, legal, marketing, politics, int'l policy, governance, law enforcement, commerce, economics, sociology, psychology, etc. which TBH as bright as many of the engineers et al are these problems are way beyond their ken, occasional polymath excepted.

But first you have to admit you have a problem, and limitations.

Shouting at the rafters about address space depletion etc while waving RFCs may not quite do it.

Similar can be said about spam, malware attacks, phishing, etc.

Yet another cryptographic protocol probably won't save the day but as the expression goes when all you have is a hammer the whole world looks like a nail.

-- -Barry Shein

Software Tool & Die | bzs at TheWorld.com <http://theworld.com/> | http://www.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*

John Levine <johnl@iecc.com> wrote:

FWIW, I also don't think that repurposing 240/4 is a good idea. To be useful it would require that every host on the Internet update its network stack, which would take on the order of a decade...

Those network stacks were updated for 240/4 in 2008-2009 -- a decade ago. See the Implementation Status section of our draft: https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ Major networks are already squatting on the space internally, because they tried it and it works. We have running code. The future is now. We are ready to update the standards. The only major OS that doesn't support 240/4 is Microsoft Windows -- and it comes with regular online updates. So if IETF made the decision to make it unicast space, most MS OS users could be updated within less than a year.

It's basically the same amount of work as getting everything to work on IPv6.

If that was true, we'd be living in the IPv6 heaven now. It doesn't take any OS upgrades for "getting everything to work on IPv6". All the OS's and routers have supported IPv6 for more than a decade. Whatever the IPv6 transition might require, it isn't comparable to the small effort needed to upgrade a few laggard OS's to support 240/4 and to do some de-bogonization in the global Internet, akin to what CloudFlare did for 1.1.1.1. John

On Wed, 9 Mar 2022 11:22:49 -0500 Tom Beecher <beecher@beecher.cc> wrote:

...

It doesn't take any OS upgrades for "getting everything to work on IPv6". All the OS's and routers have supported IPv6 for more than a decade.

There are lots of vendors, both inside and outside the networking space, that have consistently released products with non-existant or broken IPv6 implementations. That includes smaller startups, as well as very big names. An affirmative choice is often made to make sure v4 works , get the thing out the door, and deal with v6 later, or if a big client complains.

This a thousand times. Don't believe the claims of IPv6 support until you have fully tested it. Almost no vendor is including any IPv6 testing in their QA process and nobody is including it in any of their support staff training. Their labs may not even have v6 capability. Some of our biggest vendors who have supposedly supported v6 for over a decade have rudimentary, show-stopping bugs. The support staff at these vendors have often never even seen a customer using v6, and they have no idea what it looks like on their own gear. A subset of these vendors will listen to you and fix the problems. Give them your support and loyalty. I want to name names so bad... --TimH

On 3/9/22 10:46 AM, David Conrad wrote:

Not disagreeing (and not picking on you), but despite hearing this with some frequency, I haven’t seen much data to corroborate these sorts of statements.

My team ran into a bug in Cisco IOS-XR a few years ago wherein IPv6 connected BGP had problems when using on-link IPs that it did not have when using off-link IPs. E.g. on-link (LL or GUA) vs off-link (GUA on loopback / different interface). -- Grant. . . . unix || die

On 3/9/22 1:01 PM, Jay Hennigan wrote:

It's not just equipment vendors, it's ISPs.

I completely agree. I get why line of business applications; e.g. billing, provisioning, repair, haven't been updated to support IPv6. But I believe that any network equipment vendor that is (or has been for the last 1-2 decades) selling /new/ equipment really has no excuse for not IPv6 not having feature parity with IPv4.

Here in Oregon, Frontier was recently acquired by Ziply. They're doing massive infrastructure work and recently started offering symmetrical gigabit FTTH. This is a brand new greenfield PON deployment. No IPv6. It took being transferred three times to reach a person who even knew what it was.

I've had similar lack of success with my municipal GPON provider. At least the people answering support tickets know what IPv6 is and know that it's on their future list without even being in planing / testing phase.

Likewise the Wave Broadband cable operator. No IPv6, no plans for it.

.... -- Grant. . . . unix || die

On 3/9/22 1:46 PM, Josh Luthman wrote:

ISP here.  Deploying gigabit FTTH.  No IPv6.

Customers have 0 complaints about IPv6.  0 Complaints since 2006.

Do customers ever complain about double NAT's? Mike

On Wed, Mar 9, 2022 at 4:32 PM Grant Taylor via NANOG <nanog@nanog.org> wrote:

On 3/9/22 1:01 PM, Jay Hennigan wrote: > It's not just equipment vendors, it's ISPs.

I completely agree.

I get why line of business applications; e.g. billing, provisioning, repair, haven't been updated to support IPv6.

But I believe that any network equipment vendor that is (or has been for the last 1-2 decades) selling /new/ equipment really has no excuse for not IPv6 not having feature parity with IPv4.

> Here in Oregon, Frontier was recently acquired by Ziply. They're doing > massive infrastructure work and recently started offering symmetrical > gigabit FTTH. This is a brand new greenfield PON deployment. No > IPv6. It took being transferred three times to reach a person who > even knew what it was.

I've had similar lack of success with my municipal GPON provider.  At least the people answering support tickets know what IPv6 is and know that it's on their future list without even being in planing / testing phase.

> Likewise the Wave Broadband cable operator. No IPv6, no plans for it.

....

-- Grant. . . . unix || die

On 3/9/22 2:03 PM, Josh Luthman wrote:

IPv4 doesn't require NAT.

But to answer your question, I would say most if not all of the complaints about NAT/double NAT are the Xbox saying strict nat instead of open.  These complaints are super rare.

CGNat -- which is the alternative -- creates a double NAT. I poked around and it seems that affects quite a few games. Mike

On Wed, Mar 9, 2022 at 5:01 PM Michael Thomas <mike@mtcc.com> wrote:

On 3/9/22 1:46 PM, Josh Luthman wrote:

...

ISP here.  Deploying gigabit FTTH.  No IPv6.

Customers have 0 complaints about IPv6.  0 Complaints since 2006.

Do customers ever complain about double NAT's?

Mike

...

On Wed, Mar 9, 2022 at 4:32 PM Grant Taylor via NANOG <nanog@nanog.org> wrote:

On 3/9/22 1:01 PM, Jay Hennigan wrote: > It's not just equipment vendors, it's ISPs.

I completely agree.

I get why line of business applications; e.g. billing, provisioning, repair, haven't been updated to support IPv6.

But I believe that any network equipment vendor that is (or has been for the last 1-2 decades) selling /new/ equipment really has no excuse for not IPv6 not having feature parity with IPv4.

> Here in Oregon, Frontier was recently acquired by Ziply. They're doing > massive infrastructure work and recently started offering symmetrical > gigabit FTTH. This is a brand new greenfield PON deployment. No > IPv6. It took being transferred three times to reach a person who > even knew what it was.

I've had similar lack of success with my municipal GPON provider.  At least the people answering support tickets know what IPv6 is and know that it's on their future list without even being in planing / testing phase.

> Likewise the Wave Broadband cable operator. No IPv6, no plans for it.

....

-- Grant. . . . unix || die

Customers have 0 complaints about IPv6. 0 Complaints since 2006.

Asserting that IPv6 shouldn't be a priority because 'nobody asks for it' is specious. What if customers saw Cloudflare's "isbgpsafeyet" site and demented you stop running BGP because it's "unsafe" ? Is that a valid reason? Customers care about 1 thing only : Does it work when I want to use it, or not. And a lot of ISPs have learned difficult lessons in the last couple years when the small handful of customers who would complain that their work VPN didn't work behind the CGNAT boxes they ran turned into a heck of a lot MORE customers complaining. On Wed, Mar 9, 2022 at 4:48 PM Josh Luthman <josh@imaginenetworksllc.com> wrote:

ISP here. Deploying gigabit FTTH. No IPv6.

Customers have 0 complaints about IPv6. 0 Complaints since 2006.

On Wed, Mar 9, 2022 at 4:32 PM Grant Taylor via NANOG <nanog@nanog.org> wrote:

...

On 3/9/22 1:01 PM, Jay Hennigan wrote:

...

It's not just equipment vendors, it's ISPs.

I completely agree.

I get why line of business applications; e.g. billing, provisioning, repair, haven't been updated to support IPv6.

But I believe that any network equipment vendor that is (or has been for the last 1-2 decades) selling /new/ equipment really has no excuse for not IPv6 not having feature parity with IPv4.

...

Here in Oregon, Frontier was recently acquired by Ziply. They're doing massive infrastructure work and recently started offering symmetrical gigabit FTTH. This is a brand new greenfield PON deployment. No IPv6. It took being transferred three times to reach a person who even knew what it was.

I've had similar lack of success with my municipal GPON provider. At least the people answering support tickets know what IPv6 is and know that it's on their future list without even being in planing / testing phase.

...

Likewise the Wave Broadband cable operator. No IPv6, no plans for it.

....

-- Grant. . . . unix || die

On Wed, 9 Mar 2022 16:46:56 -0500 Josh Luthman <josh@imaginenetworksllc.com> wrote:

ISP here. Deploying gigabit FTTH. No IPv6.

Customers have 0 complaints about IPv6. 0 Complaints since 2006.

Right. And this view point (which I have /some/ sympathy for) is what we're up against. The average person doesn't know IPv6 is a thing, so of course they aren't going to ask for it. But they don't know IPv4 is a thing either, they just want to connect to the Internet. It seems to require an unusual, and difficult-to-justify, drive to make IPv6 happen as part of a forward-looking strategy. ISPs don't deploy it because equipment vendors don't really supply it (or barely). Equipment vendors don't supply it because ISPs don't ask for it (at least that's what my vendors tell me, and I don't think they are lying). Our standard PON and Metro services are dual-stack by default - commercial and residential. Our supplied CPEs are dual stack by default. We offer IPv6 in a variety of configurations on every connectivity product that will support it. However, I do not really blame those who don't, because in order to get where we are I had to make it my personal mission in life to get to a passive FTTP configuration that would work with functional parity between v4 and v6... For over a year I had to test gear, which requires a lot of time and effort and study and support and managerial latitude. I had to isolate bugs and spend the time reporting them, which often means making a pain in the butt out of yourself and championing the issue with the vendor (sometimes it means committing to buying things). I had to INSIST on support from vendors and refuse to buy things that didn't work. I had to buy new gear I would not have otherwise needed. I also had to "fire" a couple of vendors and purge them from my network; I even sent back an entire shipment of gear to a vendor due to broken promises. Basically I had to be extremely unreasonable. My position is unique in that I was able to do these things and get away with it. I can't blame anyone for not going down that road. I'm still waiting to feel like it was worth it. --TimH

On 3/9/22 14:46, Andy Ringsmuth wrote:

“We’re waiting for our upstream to support it.” they say (and HE is their upstream).

Perhaps you should bake them a cake. -- Jay Hennigan - jay@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV

FWIW, most of my ISPs all know about dual stack and want it. I think the legacy websites, CPE and applications that hard code IPv4 make it a tough battle - it's easier to just support v4, but nowadays, some are going all v6. At some point, v4-only ISPs will be at a competitive disadvantage. ISPs that force this will not have to buy CGNAT or spend $60 on a v4 address, but yes, it's still a tough slog. -----Original Message----- From: NANOG <nanog-bounces+tmitchell=netelastic.com@nanog.org> On Behalf Of Tim Howe Sent: Wednesday, March 9, 2022 2:40 PM To: Josh Luthman <josh@imaginenetworksllc.com>; nanog@nanog.org Subject: Re: V6 still not supported On Wed, 9 Mar 2022 16:46:56 -0500 Josh Luthman <josh@imaginenetworksllc.com> wrote:

ISP here. Deploying gigabit FTTH. No IPv6.

Customers have 0 complaints about IPv6. 0 Complaints since 2006.

Right. And this view point (which I have /some/ sympathy for) is what we're up against. The average person doesn't know IPv6 is a thing, so of course they aren't going to ask for it. But they don't know IPv4 is a thing either, they just want to connect to the Internet. It seems to require an unusual, and difficult-to-justify, drive to make IPv6 happen as part of a forward-looking strategy. ISPs don't deploy it because equipment vendors don't really supply it (or barely). Equipment vendors don't supply it because ISPs don't ask for it (at least that's what my vendors tell me, and I don't think they are lying). Our standard PON and Metro services are dual-stack by default - commercial and residential. Our supplied CPEs are dual stack by default. We offer IPv6 in a variety of configurations on every connectivity product that will support it. However, I do not really blame those who don't, because in order to get where we are I had to make it my personal mission in life to get to a passive FTTP configuration that would work with functional parity between v4 and v6... For over a year I had to test gear, which requires a lot of time and effort and study and support and managerial latitude. I had to isolate bugs and spend the time reporting them, which often means making a pain in the butt out of yourself and championing the issue with the vendor (sometimes it means committing to buying things). I had to INSIST on support from vendors and refuse to buy things that didn't work. I had to buy new gear I would not have otherwise needed. I also had to "fire" a couple of vendors and purge them from my network; I even sent back an entire shipment of gear to a vendor due to broken promises. Basically I had to be extremely unreasonable. My position is unique in that I was able to do these things and get away with it. I can't blame anyone for not going down that road. I'm still waiting to feel like it was worth it. --TimH

On 3/10/22 3:44 PM, Josh Luthman wrote:

In my rural market, we're the only option for service, simple as that.

We don't care, we don't have to; we're the phone company. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

not to echo cameron's comment too much, but... On Thu, Mar 10, 2022 at 3:44 PM Josh Luthman <josh@imaginenetworksllc.com> wrote:

...

but nowadays, some are going all v6.

Where is there v6 only services/content?

...

I don't think any of this matters, really. Is deploying v6 doable? yes Is deploying it going to cost some clams? probably? maybe? Is it important to users? no? yes? maybe?

The point of all of this 'deploy v6' conversation is REALLY: "Hey, eventually, in the long term using v4 is going to get more expensive and more inconvenient... probably." Some folk have taken the view that: "Do some work now, flush out the problems and be prepared so it's not an emergency later" some folk are waiting on everyone else (or enough everyone else) to flush out the problems for them. I don't see a lot of profit in trying to convince people that are on the 'meh, waiting on the <whatever> before v6 for me!' -chris btw, The year is 2022, verizon FIOS still has no actual v6 deployment... In the year ~2005 AS701 was fully v6 capable. In ~2009 the AS19262 edge was capable of ipv6. (think my chat with a noc/eng person was pre-aurora... so 2009 seems right) I guess not enough folk in AS701/19262/FIOS land are asking for v6? or something?

Gary, I'm the owner of the business. I answer a lot of tier 1 support calls. I read every single ticket summary. It's not denial, it's just that I'm small enough to be able to follow up on every support issue. You can claim bull if you want but my evidence can beat up your claim. On Wed, Mar 9, 2022 at 5:55 PM Gary E. Miller <gem@rellim.com> wrote:

Yo Josh!

On Wed, 9 Mar 2022 16:46:56 -0500 Josh Luthman <josh@imaginenetworksllc.com> wrote:

...

Customers have 0 complaints about IPv6. 0 Complaints since 2006.

Bull. I have not complained to any corporation in the last 5 years where the stanard response was not "We've never heard that complaint before". recently every one I my street complained about the same things at the same time, but we all got that response.

Denial ain't just a river in Egypt.

RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin

Absolutely. This makes for good discussion. Strictly on the FTTH end of things to make it simpler (since that's where our growth is). We're very much residential with the commercial customers being farmers, home based mechanics/construction/horse stables, and the like - less Netflix and more websites. 1. Our ONT (gpon+nat+wifi) I'm all but certain would work out of the box. Now if the customer wants their own router in which case I guess we force them into one methodology for v6 (correct me if I'm wrong but there isn't a standard way to deploy v6 globally like DHCP, it needs RA which leads into obvious issues with the kid's 14 antenna Netgear). 2. Calix supports it (OLT), I suppose we would just need to enable v6 on the DNS servers and we're done 3. I don't believe our software supports it, but I'm not certain, obviously I haven't looked The biggest issue you completely left out is operational. I'd have to spend time adding on v6, which is a bit of a time sink but at least there's a nearby finish line. Time I'm not getting fiber hooked up to houses. Now when (not if, we all know nothing is perfect) there are issues with v6 but not v4 I have to figure out why "my internet is slow" when v6 has problems. Setting something up once, be it fiber or v6, is a one time capex. Ongoing support problems are indefinite opex. On Thu, Mar 10, 2022 at 10:20 AM Tom Beecher <beecher@beecher.cc> wrote:

I would like to ask an earnest question here, because I work in an environment where IPv6 has been deployed for more than a decade, and it's just automatically part of things we do and have to solve for, so I will openly admit my perspective can be warped. I am truly curious about what the perceived blockers are for you, and others with the same perspective.

You appear to run a residential ISP. There are essentially 3 things you would have to do to deploy IPv6.

1. CPE would need to support it. 2. Your network infrastructure would have to support it. 3. Subscriber services ( DHCP / DNS / IPAM ) would have to support it.

Putting aside the 'zero value' idea, if you were to decide to take steps today , what are your blockers?

On Thu, Mar 10, 2022 at 9:59 AM Josh Luthman <josh@imaginenetworksllc.com> wrote:

...

Gary,

I'm the owner of the business. I answer a lot of tier 1 support calls. I read every single ticket summary. It's not denial, it's just that I'm small enough to be able to follow up on every support issue. You can claim bull if you want but my evidence can beat up your claim.

On Wed, Mar 9, 2022 at 5:55 PM Gary E. Miller <gem@rellim.com> wrote:

...

Yo Josh!

On Wed, 9 Mar 2022 16:46:56 -0500 Josh Luthman <josh@imaginenetworksllc.com> wrote:

...

Customers have 0 complaints about IPv6. 0 Complaints since 2006.

Bull. I have not complained to any corporation in the last 5 years where the stanard response was not "We've never heard that complaint before". recently every one I my street complained about the same things at the same time, but we all got that response.

Denial ain't just a river in Egypt.

RGDS GARY

--------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin

On Thu, 10 Mar 2022 at 15:20, Tom Beecher <beecher@beecher.cc> wrote:

You appear to run a residential ISP. There are essentially 3 things you would have to do to deploy IPv6. [...]

Putting aside the 'zero value' idea, if you were to decide to take steps

today , what are your blockers?

I'm going to turn this on it's head. Why would someone deploy IPv6 today when they have working IPv4, no CGNAT, and enough addressing to last them for a while? There are 3 reasons I can see: 1. More IPv4 is expensive. Let's say the price is currently $50 per IPv4 address, but it's not an expendable resource... You could depreciate it over 4 years and say it's $1/month, but realistically those addresses will probably increase in value for at least the short-medium term, so it's really just minor. Especially considering the cost of the CPE etc, which are generally disposable after a few years. 2. CGNAT is expensive. Well, it can be, but that's mostly because it's stateful. If MAP-T takes off as well as it seems to be doing, then you can pretty much rely on stateless transformation, and that will be cheaper and cheaper as time goes on. 3. Customer demand. The only customers who are demanding it tend to be the whiny folk who also complain about Android not supporting DHCPv6, or that they can't pay their bills with some kind of cryptocurrency. They will always be complaining about something. IPv6 is technologically superior to IPv4, there's no doubt about that. It is vastly inferior when it comes to understanding what is going on by your average sysadmin, network engineer, IT helpdesk person -- it is just far too complicated. Even the wording is confusing, e.g. router/neighbor "solicitation/advertisement" instead of "request/reply". I am not just referencing the longer addresses, the "multiple addresses on an interface" thing takes a long time to get used to, having ULAs for internal addressing and then using GUAs (which may change with no notice) for internet traffic, it just confuses people. Expecting those users who run a server at home (a NAS or similar) to now rely on SLAAC rather than static addressing that they might have done before, or even worse configuring static addressing based on the prefix today and 6-12 months down the line suddenly finding they can't access the NAS any longer in their bookmarks, and no idea what to do to talk to it. They're not going to understand why people use ULAs, or which prefix to use there. Not to mention that it would be a technical support nightmare to only offer IPv6-only services to customers, logging into their router or explaining why their few pieces of software not working may be because of the lack of IPv4 -- we're going to be stuck with IPv4 in the residential access and enterprise space for a long time, so there's very little incentive to put all the effort into IPv6 except for ideological reasons. IPv6 is a case study in how all too often human factors are not considered in the design of engineering projects. IPv4 works, and is relatively inexpensive. Until it isn't, I absolutely understand why an ISP would not consider IPv6 a priority at all. IPv6 cuts your IPv4 costs, but has costs of its own. ... and I don't really know how to fix that. M

On 3/10/22 9:22 PM, Masataka Ohta wrote:

Matthew Walster wrote:

...

IPv6 is technologically superior to IPv4, there's no doubt about that.

It is not. Though IPv6 was designed against OSI CLNP (with 20B, or, optionally, 40B addresses), IPv6 incorporated many abandoned ideas of CLNP and XNS already known to be useless or harmful with experiences on IPv4 to be a protocol as bad as or even worse than CLNP.

For example, address length was extended from original 8B to 16B to allow lower 48bits be MAC addresses, which was what XNS was doing, only to make ISP operations with raw addresses prohibitively painful.

IPv6 as originally designed had 8 byte (64-bit) addresses that had no difficulty including 48-bit MAC addresses for link-local deployment. It was explicitly stated that they would *NEVER* be globally visible, as there were many documented examples of duplicate MAC assignments. Then, the powers that be declared that IPv6 should have 128-bit addresses, and a host of committees were setup with competing CLNP (TUBA) co-chairs. They incorporated many ideas of CLNP and XNS that were thought (by many of us) to be worthless, useless, and harmful. Committee-itis at its worst. My original address plan had the leading 32 bits as the existing ASN, with the lower 32-bits as the existing IPv4 address. Making ISP operations eminently easier, as we already knew those two things.

On Thu, 17 Mar 2022 at 04:27, William Allen Simpson <william.allen.simpson@gmail.com> wrote:

This is intended to replace ARP, ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6] environment. There are also elements of the OSI ES-IS and IS-IS Hello.

We were forward looking to deployments of thousands of systems per link, rather than the 30 maximum under then current ethernet standards. We needed fewer announcements, less chatty traffic, and more specific traffic designation.

Please bear with me, after negativity some sobering remarks follow. And the solution is broken, it assumes snooping packets and creating near arbitrary amounts of multicast groups and forwarding multicast on L2 device is cheaper than flooding. It is not, and everyone keeps MLD off in L2 to simplify and reduce cost. So in reality the multicast L2 resolution is not used, and useless complexity. In addition to this problem of changing broadcast to multicast, the ND can use GUA|LL<->GUA|LL any combination, which makes almost every input ACL broken, because operators simply are not aware of this. Very common problem for us is, we change vendor on our end, and customer IPv6 breaks, customer did 0 changes, so of course they blame us, and we have difficult task to educate them 'look this is how ND works, your ACL is broken, because it assumes special case is generic case, and the special case has changed' because different vendors choose different GUA|LL <-> GUA|LL for ND, it can be wrong and work until the far end does some change. The right solution is not to filter by ADDR, but to filter by hop-limit, but it's too complex for operators to understand. /MOST/ IPv6 'improvements' are like this, they solve problems that either didn't exist or make the existing problem worse. Like extension headers. Like creating large on-link networks, adding a lot more attack vectors. Ok IPv6 is kinda shit, but it's the only thing we have and we can make it work with some effort and some cost. And the effort and cost of making IPv6 work is less than making IPV4+IPV6 work, and we really really need the larger address space, it trumps all other deltas by a wide margin. So yes I have an ugly child, but it's the only child I have, and with my genes, a beautiful child isn't on the cards, so I'll raise this ugly child as best I can. I no longer care how bad IPv6 is, that's crying over spilt milk, it doesn't matter. I care about the cost of doing both IPV4+IPV6. -- ++ytti

It seems team developing IPv6 had ONE way of doing things, with is actually recipe for disaster. Why? Because they were building an IP protocol. Something that will be using globally by ALL networks around. Not some local IOT (useless) shit used here and there. Thats why such IP protocol should be follow KISS concept and flexibility. Some people have different vision how to run network. And because Inter-net is an AS to AS network they should have right to do so. In my opinion all that crypto stuff should be put layer upper because crypto is hard, very hard and can get obsolete quickly. Its same about other weird things embedded into IPv6 that probably should go layer up. And now people wonder why IPv6 adoption is crap and there is high resistance. IPv4 made mistakes too, but hell, it was the first. It seems all the market needed was IPv4 with bigger address space. Instead of delivering it, some contraption has been created trying to solve non-existant (or already fixed) problems. Just my 2 cents... ---------- Original message ---------- From: William Allen Simpson <william.allen.simpson@gmail.com> To: NANOG <nanog@nanog.org> Subject: Re: V6 still not supported Date: Wed, 16 Mar 2022 22:24:14 -0400 I'd wanted to clearly distinguish this from the old methods: This is intended to replace ARP, ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6] environment. There are also elements of the OSI ES-IS and IS-IS Hello. We were forward looking to deployments of thousands of systems per link, rather than the 30 maximum under then current ethernet standards. We needed fewer announcements, less chatty traffic, and more specific traffic designation. We also prioritized network security. Moreover requiring addresses be ephemeral, such that applications would not be able to tie authentication/authorization to an IPv6 address and would be motivated to use cryptographic security. Unfortunately, later committees decided that rather than a single simpler secured address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6. Three ways to do the same thing are always a recipe for disaster. Reminder: I was an operator and one of the original NANOG members. We spent a lot of time considering human factors. I'd pioneered the "Operational Considerations" section of the original draft RFCs. IPv6 is a case study of what happens with committee-itis. The small design team worked well.

Did you read his email? He was saying that what a lot of people wanted was IPv4 + bigger address space, and not any other changes. Speaking for myself, other than the bigger address space, for a corporate/enterprise environment I have yet to see any advantages of IPv6 and many, many issues. Information hiding, aka NAT is very important in the financial world. For example, we have a directly peered connection with our clearing partner at our co-location. Both sides use NAT. This way either side can make a network change without having to involve the other partner. Here is what happens without NAT (circa 2008), and yes, this really happened: 1. We needed to separate out process and move to a different server. The existing server IP couldn’t change since other partners had it in their access list. 2. It took 9 weeks and: * 3 conference calls including one with 30 participants from the clearing company * 2 approvals by committees at the clearing company You can say that this was absurd and should be changed. Yes, but it won’t and we have no control over them. With NAT we can change internal IP addresses at any time as long as we update the NAT tables. This is not something important at ISP or hosting providers, but it’s many issues like this in the corporate world that prevent IPv6 adoption. Things like static addressing, consistent behavior of IPv6 across different operating systems including disabling SLAAC, privacy addressing and others. Based on my experience and people on tech mailing list that are oriented toward enterprises, I would bet that IPv6 deployment (with global addresses) is significantly less than 10% nor is it on their horizon. Matthew Huff | Director of Technical Operations | OTA Management LLC Office: 914-460-4039 mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com> ........................................................................................................................................... From: NANOG <nanog-bounces+mhuff=ox.com@nanog.org> On Behalf Of Tom Beecher Sent: Thursday, March 17, 2022 7:41 AM To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: V6 still not supported “It seems all the market needed was IPv4 with bigger address space. Instead of delivering it, some contraption has been created trying to solve non-existant (or already fixed) problems.” your argument against IPv6 is that they should have created a new version of IPv4, but bigger? So… IPv6? On Thu, Mar 17, 2022 at 06:32 <borg@uu3.net<mailto:borg@uu3.net>> wrote: It seems team developing IPv6 had ONE way of doing things, with is actually recipe for disaster. Why? Because they were building an IP protocol. Something that will be using globally by ALL networks around. Not some local IOT (useless) shit used here and there. Thats why such IP protocol should be follow KISS concept and flexibility. Some people have different vision how to run network. And because Inter-net is an AS to AS network they should have right to do so. In my opinion all that crypto stuff should be put layer upper because crypto is hard, very hard and can get obsolete quickly. Its same about other weird things embedded into IPv6 that probably should go layer up. And now people wonder why IPv6 adoption is crap and there is high resistance. IPv4 made mistakes too, but hell, it was the first. It seems all the market needed was IPv4 with bigger address space. Instead of delivering it, some contraption has been created trying to solve non-existant (or already fixed) problems. Just my 2 cents... ---------- Original message ---------- From: William Allen Simpson <william.allen.simpson@gmail.com<mailto:william.allen.simpson@gmail.com>> To: NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: V6 still not supported Date: Wed, 16 Mar 2022 22:24:14 -0400 I'd wanted to clearly distinguish this from the old methods: This is intended to replace ARP, ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6] environment. There are also elements of the OSI ES-IS and IS-IS Hello. We were forward looking to deployments of thousands of systems per link, rather than the 30 maximum under then current ethernet standards. We needed fewer announcements, less chatty traffic, and more specific traffic designation. We also prioritized network security. Moreover requiring addresses be ephemeral, such that applications would not be able to tie authentication/authorization to an IPv6 address and would be motivated to use cryptographic security. Unfortunately, later committees decided that rather than a single simpler secured address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6. Three ways to do the same thing are always a recipe for disaster. Reminder: I was an operator and one of the original NANOG members. We spent a lot of time considering human factors. I'd pioneered the "Operational Considerations" section of the original draft RFCs. IPv6 is a case study of what happens with committee-itis. The small design team worked well.

Good to know. I’ll keep a look out for future implantations. Currently we are using Cisco 3548P-XL switches with low-latency nat to support microsecond latency natting. Hopefully someday they will support it. Matthew Huff | Director of Technical Operations | OTA Management LLC Office: 914-460-4039 mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com> ........................................................................................................................................... From: Dave Bell <me@geordish.org> Sent: Thursday, March 17, 2022 8:39 AM To: Matthew Huff <mhuff@ox.com> Cc: Tom Beecher <beecher@beecher.cc>; borg@uu3.net; nanog@nanog.org Subject: Re: V6 still not supported You can still do NAT with IPv6 like you ask for. It's been around over a decade now: https://datatracker.ietf.org/doc/html/rfc6296 On Thu, 17 Mar 2022 at 12:02, Matthew Huff <mhuff@ox.com<mailto:mhuff@ox.com>> wrote: Did you read his email? He was saying that what a lot of people wanted was IPv4 + bigger address space, and not any other changes. Speaking for myself, other than the bigger address space, for a corporate/enterprise environment I have yet to see any advantages of IPv6 and many, many issues. Information hiding, aka NAT is very important in the financial world. For example, we have a directly peered connection with our clearing partner at our co-location. Both sides use NAT. This way either side can make a network change without having to involve the other partner. Here is what happens without NAT (circa 2008), and yes, this really happened: 1. We needed to separate out process and move to a different server. The existing server IP couldn’t change since other partners had it in their access list. 2. It took 9 weeks and: * 3 conference calls including one with 30 participants from the clearing company * 2 approvals by committees at the clearing company You can say that this was absurd and should be changed. Yes, but it won’t and we have no control over them. With NAT we can change internal IP addresses at any time as long as we update the NAT tables. This is not something important at ISP or hosting providers, but it’s many issues like this in the corporate world that prevent IPv6 adoption. Things like static addressing, consistent behavior of IPv6 across different operating systems including disabling SLAAC, privacy addressing and others. Based on my experience and people on tech mailing list that are oriented toward enterprises, I would bet that IPv6 deployment (with global addresses) is significantly less than 10% nor is it on their horizon. Matthew Huff | Director of Technical Operations | OTA Management LLC Office: 914-460-4039 mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com> ........................................................................................................................................... From: NANOG <nanog-bounces+mhuff=ox.com@nanog.org<mailto:ox.com@nanog.org>> On Behalf Of Tom Beecher Sent: Thursday, March 17, 2022 7:41 AM To: borg@uu3.net<mailto:borg@uu3.net> Cc: nanog@nanog.org<mailto:nanog@nanog.org> Subject: Re: V6 still not supported “It seems all the market needed was IPv4 with bigger address space. Instead of delivering it, some contraption has been created trying to solve non-existant (or already fixed) problems.” your argument against IPv6 is that they should have created a new version of IPv4, but bigger? So… IPv6? On Thu, Mar 17, 2022 at 06:32 <borg@uu3.net<mailto:borg@uu3.net>> wrote: It seems team developing IPv6 had ONE way of doing things, with is actually recipe for disaster. Why? Because they were building an IP protocol. Something that will be using globally by ALL networks around. Not some local IOT (useless) shit used here and there. Thats why such IP protocol should be follow KISS concept and flexibility. Some people have different vision how to run network. And because Inter-net is an AS to AS network they should have right to do so. In my opinion all that crypto stuff should be put layer upper because crypto is hard, very hard and can get obsolete quickly. Its same about other weird things embedded into IPv6 that probably should go layer up. And now people wonder why IPv6 adoption is crap and there is high resistance. IPv4 made mistakes too, but hell, it was the first. It seems all the market needed was IPv4 with bigger address space. Instead of delivering it, some contraption has been created trying to solve non-existant (or already fixed) problems. Just my 2 cents... ---------- Original message ---------- From: William Allen Simpson <william.allen.simpson@gmail.com<mailto:william.allen.simpson@gmail.com>> To: NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: V6 still not supported Date: Wed, 16 Mar 2022 22:24:14 -0400 I'd wanted to clearly distinguish this from the old methods: This is intended to replace ARP, ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6] environment. There are also elements of the OSI ES-IS and IS-IS Hello. We were forward looking to deployments of thousands of systems per link, rather than the 30 maximum under then current ethernet standards. We needed fewer announcements, less chatty traffic, and more specific traffic designation. We also prioritized network security. Moreover requiring addresses be ephemeral, such that applications would not be able to tie authentication/authorization to an IPv6 address and would be motivated to use cryptographic security. Unfortunately, later committees decided that rather than a single simpler secured address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6. Three ways to do the same thing are always a recipe for disaster. Reminder: I was an operator and one of the original NANOG members. We spent a lot of time considering human factors. I'd pioneered the "Operational Considerations" section of the original draft RFCs. IPv6 is a case study of what happens with committee-itis. The small design team worked well.

Did you read his email? He was saying that what a lot of people wanted was IPv4 + bigger address space, and not any other changes. Speaking for myself, other than the bigger address space, for a corporate/enterprise environment I have yet to see any advantages of IPv6 and many, many issues.

There are absolute parts of the v6 feature set that don't work as well as they should. Some of that is design, some of that is implementation. Nobody asserts it's perfect. I also generally agree certain parts of the design suffer from overcomplication, and could have been simpler. However, it's an ill informed argument to say that IPv6 should have just been 128 bits of addressing with no other changes. That just would never have worked. I'm also very sympathetic to situations such as you describe that things are done a certain way based on human reasons, not technical ones. Trust me, I get it. On Thu, Mar 17, 2022 at 8:01 AM Matthew Huff <mhuff@ox.com> wrote:

Did you read his email? He was saying that what a lot of people wanted was IPv4 + bigger address space, and not any other changes. Speaking for myself, other than the bigger address space, for a corporate/enterprise environment I have yet to see any advantages of IPv6 and many, many issues.

Information hiding, aka NAT is very important in the financial world.

For example, we have a directly peered connection with our clearing partner at our co-location. Both sides use NAT. This way either side can make a network change without having to involve the other partner.

Here is what happens without NAT (circa 2008), and yes, this really happened:

1. We needed to separate out process and move to a different server. The existing server IP couldn’t change since other partners had it in their access list. 2. It took 9 weeks and: 1. 3 conference calls including one with 30 participants from the clearing company 2. 2 approvals by committees at the clearing company

You can say that this was absurd and should be changed. Yes, but it won’t and we have no control over them.

With NAT we can change internal IP addresses at any time as long as we update the NAT tables.

This is not something important at ISP or hosting providers, but it’s many issues like this in the corporate world that prevent IPv6 adoption. Things like static addressing, consistent behavior of IPv6 across different operating systems including disabling SLAAC, privacy addressing and others.

Based on my experience and people on tech mailing list that are oriented toward enterprises, I would bet that IPv6 deployment (with global addresses) is significantly less than 10% nor is it on their horizon.

*Matthew Huff* | Director of Technical Operations | OTA Management LLC

*Office: 914-460-4039*

*mhuff@ox.com <mhuff@ox.com> | **www.ox.com <http://www.ox.com>*

*...........................................................................................................................................*

*From:* NANOG <nanog-bounces+mhuff=ox.com@nanog.org> * On Behalf Of *Tom Beecher *Sent:* Thursday, March 17, 2022 7:41 AM *To:* borg@uu3.net *Cc:* nanog@nanog.org *Subject:* Re: V6 still not supported

“It seems all the market needed was IPv4 with bigger address space. Instead of delivering it, some contraption has been created trying to solve non-existant (or already fixed) problems.”

your argument against IPv6 is that they should have created a new version of IPv4, but bigger?

So… IPv6?

On Thu, Mar 17, 2022 at 06:32 <borg@uu3.net> wrote:

It seems team developing IPv6 had ONE way of doing things, with is actually recipe for disaster. Why? Because they were building an IP protocol. Something that will be using globally by ALL networks around. Not some local IOT (useless) shit used here and there. Thats why such IP protocol should be follow KISS concept and flexibility. Some people have different vision how to run network. And because Inter-net is an AS to AS network they should have right to do so.

In my opinion all that crypto stuff should be put layer upper because crypto is hard, very hard and can get obsolete quickly.

Its same about other weird things embedded into IPv6 that probably should go layer up. And now people wonder why IPv6 adoption is crap and there is high resistance. IPv4 made mistakes too, but hell, it was the first.

It seems all the market needed was IPv4 with bigger address space. Instead of delivering it, some contraption has been created trying to solve non-existant (or already fixed) problems.

Just my 2 cents...

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

From: William Allen Simpson <william.allen.simpson@gmail.com> To: NANOG <nanog@nanog.org> Subject: Re: V6 still not supported Date: Wed, 16 Mar 2022 22:24:14 -0400

I'd wanted to clearly distinguish this from the old methods:

This is intended to replace ARP, ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6] environment. There are also elements of the OSI ES-IS and IS-IS Hello.

We were forward looking to deployments of thousands of systems per link, rather than the 30 maximum under then current ethernet standards. We needed fewer announcements, less chatty traffic, and more specific traffic designation.

We also prioritized network security. Moreover requiring addresses be ephemeral, such that applications would not be able to tie authentication/authorization to an IPv6 address and would be motivated to use cryptographic security.

Unfortunately, later committees decided that rather than a single simpler secured address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6. Three ways to do the same thing are always a recipe for disaster.

Reminder: I was an operator and one of the original NANOG members.

We spent a lot of time considering human factors. I'd pioneered the "Operational Considerations" section of the original draft RFCs.

IPv6 is a case study of what happens with committee-itis.

The small design team worked well.

I agree that parts of IPv6 design suffer from a bit of overcomplication. Maybe it didn't seem that way when they did it, but experience has taught us otherwise. So we should take those learnings and adjust. On Thu, Mar 17, 2022 at 9:27 AM <borg@uu3.net> wrote:

Yes, IPv6.. but for example 64bit address space but with a much closer ties to IPv4 imo. So network people would be much more confortable with it.

I already said how my ideal IPv6 should look like. Many people disagree with that ok. Its very hard to please everyone indeed, hence KISS concept should be followed.

Also, the whole dual stack thing should be required only on content providers, so client should be moved to IPv6, freeing more space from IPv4 with could be moved to content/hosting. Once there is enough critical mass of clients on IPv6, IPv4 could be dropped gradually. This avoids chicken and egg problem.

Lets stop that E2E myth, we do NOT have e2e connectivity on client side from loong time (users NATs, CGNATs). And you know what? Its not that needed these days due to how internet is centralized today. Its good moment for change imo, but we blowed it.

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

From: Tom Beecher <beecher@beecher.cc> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: V6 still not supported Date: Thu, 17 Mar 2022 07:40:32 -0400

˙˙It seems all the market needed was IPv4 with bigger address space. Instead of delivering it, some contraption has been created trying to solve non-existant (or already fixed) problems.˙˙

your argument against IPv6 is that they should have created a new version of IPv4, but bigger?

So˙˙ IPv6?

On Thu, Mar 17, 2022 at 06:32 <borg@uu3.net> wrote:

...

It seems team developing IPv6 had ONE way of doing things, with is actually recipe for disaster. Why? Because they were building an IP protocol. Something that will be using globally by ALL networks around. Not some local IOT (useless) shit used here and there. Thats why such IP protocol should be follow KISS concept and flexibility. Some people have different vision how to run network. And because Inter-net is an AS to AS network they should have right to do so.

In my opinion all that crypto stuff should be put layer upper because crypto is hard, very hard and can get obsolete quickly.

Its same about other weird things embedded into IPv6 that probably should go layer up. And now people wonder why IPv6 adoption is crap and there is high resistance. IPv4 made mistakes too, but hell, it was the first.

It seems all the market needed was IPv4 with bigger address space. Instead of delivering it, some contraption has been created trying to solve non-existant (or already fixed) problems.

Just my 2 cents...

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

From: William Allen Simpson <william.allen.simpson@gmail.com> To: NANOG <nanog@nanog.org> Subject: Re: V6 still not supported Date: Wed, 16 Mar 2022 22:24:14 -0400

I'd wanted to clearly distinguish this from the old methods:

This is intended to replace ARP, ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6] environment. There are also elements of the OSI ES-IS and IS-IS Hello.

We were forward looking to deployments of thousands of systems per link, rather than the 30 maximum under then current ethernet standards. We needed fewer announcements, less chatty traffic, and more specific traffic designation.

We also prioritized network security. Moreover requiring addresses be ephemeral, such that applications would not be able to tie authentication/authorization to an IPv6 address and would be motivated to use cryptographic security.

Unfortunately, later committees decided that rather than a single simpler secured address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6. Three ways to do the same thing are always a recipe for disaster.

Reminder: I was an operator and one of the original NANOG members.

We spent a lot of time considering human factors. I'd pioneered the "Operational Considerations" section of the original draft RFCs.

IPv6 is a case study of what happens with committee-itis.

The small design team worked well.

Yes, you are right. And gradually IPv4 was improved and fixed. We learned how to defend L2. CIDR was added (with should be thing from the begining instead of netmasks, but who could forsee...) And in case of IPv6 it seems that all that experience was throwed out of window. Design was much different that IPv4, adding new issues. I have feeling that IPv6 was made by people who were NOT running networks. The big question is, what we can do that to fix IPv6 problem. I have no clue at all.. Im personally biased against IPv6. ---------- Original message ---------- From: Michael Thomas <mike@mtcc.com> To: nanog@nanog.org Subject: Re: V6 still not supported Date: Thu, 17 Mar 2022 18:52:32 -0700 On 3/17/22 3:30 AM, borg@uu3.net wrote:

It seems team developing IPv6 had ONE way of doing things, with is actually recipe for disaster. Why? Because they were building an IP protocol. Something that will be using globally by ALL networks around. Not some local IOT (useless) shit used here and there. Thats why such IP protocol should be follow KISS concept and flexibility. Some people have different vision how to run network. And because Inter-net is an AS to AS network they should have right to do so. As somebody who designed IoT things back when v6 was being designed, my only question was whether it would get deployed, not whether it was too complex. It was honestly a lot easier than a completely new protocol stack like appletalk or netware.

In my opinion all that crypto stuff should be put layer upper because crypto is hard, very hard and can get obsolete quickly. I don't see what the OS layer has to do with anything. An operating system that doesn't get patches is even worse than app level code that doesn't.

Its same about other weird things embedded into IPv6 that probably should go layer up. And now people wonder why IPv6 adoption is crap and there is high resistance. IPv4 made mistakes too, but hell, it was the first.

It seems all the market needed was IPv4 with bigger address space. Instead of delivering it, some contraption has been created trying to solve non-existant (or already fixed) problems.

There were tons of things that were slapped onto IP that were basically experimental like ARP and bootp. CIDR didn't even exist back then. Also: security, for example, was not an already fixed problem. Far from it. Mike

Michael Thomas <mike@mtcc.com> writes:

I really don't see why people think it's so different that v4. To me back then it mostly seemed like v4 with bigger address.

Then I suppose, like me, you were in favor of the TUBA proposal? :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay

On Fri, 2022-03-18 at 13:17 -0700, Michael Thomas wrote:

...

We weren't part of the wars. What I saw was what eventually became ipv6 and I remember talking to one of my coworkers about how hard he thought it would be to implement. He concurred that he didn't think it would be any big deal. One of our big issues is that we didn't have anybody to interop with, that and nobody was asking for it unlike v4 features.

Classic Second System Effect, as described by Fred Brooks... in 1975. "The Mythical Man-Month" is a great book for remembering how we got here. https://en.wikipedia.org/wiki/Second-system_effect But as all you have said, here we are.

  On Fri, 18 Mar 2022 13:47:00 -0700, Michael Thomas <mike@mtcc.com> wrote: I'd really like to understand what the requirements that are specific to v6 are that make it so much harder or bloated. Not product availability, but actual things that make it difficult to deploy. -------------------------------------------------------------------------------------------- It's all in the nanog archives.  Just the amount of grumping by network operators to finally get DHCPv6 was pretty tremendous. Basically, folks were shouting "we want it whether you think we need it or not!"  Of course, that's just the start.  This thread itself has a lot of the iceberg tops. scott

Tom Ivar Helbekkmo via NANOG wrote:

...

I really don't see why people think it's so different that v4. To me back then it mostly seemed like v4 with bigger address.

Then I suppose, like me, you were in favor of the TUBA proposal? :)

TUBA is TCP/UDP over CLNP (ConnectionLess Network Protocol) designed by so infamous OSI, which is why it was denied by IETF through democratic process even though IAB tried to deploy it. However, as William Allen Simpson wrote:

Then, the powers that be declared that IPv6 should have 128-bit addresses, and a host of committees were setup with competing CLNP (TUBA) co-chairs. They incorporated many ideas of CLNP and XNS that were thought (by many of us) to be worthless, useless, and harmful. Committee-itis at its worst.

IAB hideously striked back to make IPv6 something a lot worse than CLNP and XNS. So, it is rather not the second but the zero-th system syndrome. Masataka Ohta

On 21 Mar 2022, at 12:42 PM, John Curran <jcurran@istaff.org> wrote:

...

This is all quite well covered by the IPv6 recommendation document - https://datatracker.ietf.org/doc/html/rfc1752 <https://datatracker.ietf.org/doc/html/rfc1752> (a document which probably should be required reading for those characterizing the history of IPv6)

Just for the record, IPv6 is definitely far from perfect… There were things put in the specification that had no real world experience (some of which has since been deprecated), and some cases where tradeoffs were made that missed huge opportunities. However, neither the extra cruft nor the missed opportunities really got in the way of deployment – we are the present situation because we made a decision on the next IP protocol (IPv6) despite lacking the required "a straightforward transition plan from IPv4” – that was left as an exercise for the reader. Absent a clear bridge from here to there, it shouldn’t be surprising that there was no serious deployment for more than a decade… After several years of non-solutions out of the IETF, the "very large" network operator community (who realized that they were indeed going to need IPv6 for their broadband and mobile deployments) waded in and came up with workable IPv6 transition solutions. To this day, IPv6 remains essential to those with very large and growing networks, and less so for those with modest or no growth. FYI, /John

On 22 Mar 2022, at 4:08 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:

...

- There was an open call for proposals. - We had many submissions: Nimrod, PIP, SIP, TUBA, IPAE, CATNIP (TP/IX), ... - SIP absorbed IPAE, and then PIP merged with SIP to form SIPP - Three final proposals CATNIP, TUBA, SIPP - Chicago Big-10 workshop did final review and recommended SIPP, only using 128-bit "NSAP-like" addresses

and such steps were controlled by IAB, that is, you merely support my point that:

...

co make IPv6 something a lot worse than CLNP and XNS.

The characterization that the IAB somehow struck back with the IPng decision implies a level of direction over the decision which simply did not exist. That’s not to say that there wasn’t "IETF politics” involved, but rather that such politics were expressed as enormous pressure to “make a decision” rather than IAB/IESG shaping of the various protocol proposals and their technical evolution. The technical teams that submitted each proposal controlled that proposal's evolution, and the IPng Directorate (not the IAB or IESG) made the final IPng protocol selection/recommendation. You can confirm all of this rather easily, as the entire set of IPng materials and decisions are here at Scott Bradner’s archive - https://www.sobco.com/ipng/ <https://www.sobco.com/ipng/>

It should also be noted that merger is just political ceremony to pretend IPng were resulted from cooperation of many contributors only to make it bloat by incorporating all the features without technical merits.

Half correct; the final protocol was indeed the result of compromise whereby features from multiple contributors were included, but such was driven (much like the “extra cruft” I referenced in an earlier message) out of the earnest belief of technical merit of the unproven features rather than politics. Of course, the problem with including new & unproven features is that they as often as not turn out to be either technically flawed or provide no functionality actually desired from the customer (and IPv6 certainly had examples of both) Best wishes, /John John Curran IPng Directorate Member, 1993 - 1996

On 3/22/22 5:45 AM, Randy Bush wrote:

john,

fwiw your story matches what is left of my memory. one nuance

...

That’s not to say that there wasn’t "IETF politics” involved, but rather that such politics were expressed as enormous pressure to “make a decision” my take was that cidr had done a lot to relieve the immediate technical pressure for the short term; but there was a deep fear that the industry press was stirring a major poolpah about the end of the internet due to ipv4 exhaustion. i.e. a seriously flawed technical compromise was pushed on us in reaction to a perception of bad press.

i have learned that, when i am under great pressure to DO SOMETHING, it's time to step back, go make a cup of tea, and think. the ietf did not. and here we are, a quarter of a century later, still trying to clean up the mess.

So are you saying that an ipng that came out in, say, 2000 which was according to you was vastly superior having taken the time to get it right would have had any better chance of being adopted? My experience with Cisco product managers at the time is that they couldn't give a shit about the technical aspects of an ipng. If their silicon forwarding couldn't handle it, they weren't interested unless customers were clamoring for it. I can't see how that negative feedback loop could have ever been prevented other than other ipng being done in, oh say, 1993 when it was all still software forwarding. Mike

On 3/22/22 4:58 PM, Christopher Morrow wrote:

On Tue, Mar 22, 2022 at 5:36 PM Michael Thomas <mike@mtcc.com> wrote:

On 3/22/22 5:45 AM, Randy Bush wrote:

<snip>

right would have had any better chance of being adopted? My experience with Cisco product managers at the time is that they couldn't give a shit about the technical aspects of an ipng. If their silicon forwarding couldn't handle it, they weren't interested unless customers were

Somewhere in this thread Randy sent a link to his ivtf screed^H^H^H^H^H^Hposition-paper. I think his point there was essentially: "Hey, vendors are coin operated, they build what people are asking for, if they are willing to pay AND if there are enough of them paying"

I detect no lies here. If we didn't build the right thing from the standpoint of ISP's, they would have told us what they wanted instead. The truth is they didn't want anything but what they had with v4, and running off the cliff was multiple quarterly earnings away so who cares. IPv6 is a classic case of a standards body pushing on string, technical merits be damned. That people are relitigating something from 30 years ago that has been proven to not make any appreciable difference to deploability is part of the problem, not part of the solution. There is a salt mine's worth of saltiness. When the mobile guys came around and said they wanted to listen, they got the solution they could live with. That's all it took. Mike

George Michaelson wrote:

Thats partly why I find a huge personal disconnect with "failure" -It hasn't failed the way DECnet failed. Far from it.

Since IPv6 was born of the effort to fix the upcoming address shortage visible at the time and to prevent and alleviate the resulting negative effects, the fact that it did not and that globally v4 address shortage is still a problem is a tally of multiple years of failure. I will give you that address shortage and resulting constraints is actually a spectrum, one we have not finished traveling on. I suppose we can date it from the time a class-c stopped being included as part of your leased line all the way to the hasnt happened yet point where you cant get v4 for any affordable amount. So yes, IPv6 will probably save the internet at some point before the end of that spectrum is reached, but the damage has already been done, and lots of it. Now if the goal was to produce a protocol that would work eventually as good as IPv4 and would theoretically fix the address shortage, but only if the non-practical mass conversion occurred immediately, well than its a success and has been for some time. However, successes like that are not what made the internet.

There is this other side: I'm dualstack, and I simply dont notice.

Being in transition state indefinitely is not success. The other side is when you are v6 only and you dont notice. We arent there yet. Thats the failure.

Here's my final (serious) suggestion. We aren't going to be able to reverse course out of the current situation. Maybe the best thing, is to engineer it, not complain about it. Engineering won't end either right now. Betting on 4 continuance is betting on markets over planning. Maybe thats what some people want? What I want doesn't matter that much btw.

-G

Hope for the best and prepare for the worst. That means improving v6 and making it more adoptable and appealing to more diverse user populations. It also means taking measures to prolong v4. That means give them DHCP the way they want it, give them NAT the way they want it. Give them whatever you can whatever they want in v6 the way they want it, whether you like it or not. Just get it out there more and more faster and faster. Ideological concerns had their day and its over. We are past deadline. Just get it done. Or get out of the way of those who want to. Yes, RiR's, IPv6 costing anyone any more money was a false start penalty. It also means taking a real look at proposal like 240/4 and whatever else can be scrounged up, extended, worked around, whatever you have, because if the worst happens and we are still having these threads in a decade, we are going to need it. bad. And if the best happens, who cares about v4 and what was done to it anyways? Now you can say nah, I am betting on things working out just the way they are now, but lets be clear about that. Joe

Michael Thomas wrote:

On 3/22/22 10:34 PM, Joe Maimon wrote:

...

...

There is this other side: I'm dualstack, and I simply dont notice.

Being in transition state indefinitely is not success.

The other side is when you are v6 only and you dont notice. We arent there yet. Thats the failure.

This is a terrible way to look at things. SIP has been gradually been taking over the PSTN signaling for 20 years. It has not rooted out every SS7 installation on the planet and probably won't until I'm long dead. Is that a failure? It's certainly a "transition state". After not paying attention for probably a decade and seeing how much it's penetrated I'd call that a resounding success. The same is true of IPv6 with all of the mobile uptake. Legacy is hard. It always has been hard. Calling something a failure because it doesn't instantly defeat legacy a terrible take. It was always going to be difficult to add address space to IP regardless of how it was done. All of the bagging on IPv6 and imagining a better ipng ignores that basic fact.

Mike

SIP wasnt formulated to save telephony. In fact sip has nearly 100% adoption for ip based telephony. It did displace legacy and proprietary protocols. There is no comparison. IPv6 transition was intended to complete before run out using Dual Stack. Fail. Joe

Michael Thomas wrote:

...

SIP won't displace all legacy PSTN any time soon. So it's a failure by your definition. And by your definition IPv6 was a failure before it was even born because the internet became popular -- something I'll add that nobody knew for certain when it was being designed. There's a lot of sour grapes about stuff that happened 30 years ago.

Mike

The definition of failure flows from the definition of the objective, the goal, the desired outcome. What is your understanding of those for IPv6? My understanding of the goal of IPv6 was to replace IPv4 globally before address shortage caused real problems. If we agree on that, we must also agree that it has failed to do so, ergo, IPv6 as a global solution to IPv4 address shortage has been and thus far continues to be a failure. Now it will almost certainly eventually succeed, but that doesnt change that for all this time, it failed and there were real consequences that or may not carry on with us all for quite some time, and that there were real costs involved to real people. Joe

Michael Thomas wrote:

On 3/23/22 11:53 AM, Joe Maimon wrote:

...

Michael Thomas wrote:

IETF can't force people to adopt things, film at 11. They certainly can't control people's saltiness from something that happened 30 years ago. IPv6 is manifestly deployable for operators that want to. If others don't want to deploy it in the face of the predictable address crunch, that's on the operators and not anybody else. Vendors will build patches and hacks and other abominations if somebody is willing to pay for it. If you like CGN, by all means deploy it from a vendor standpoint. If you don't like CGN either then, well, you're sort of screwed. Going back and relitigating ipng is not ever going to happen.

Mike

Which is why the IETF should not engineer things under the assumption that they can. Which is why the IETF should not be citing IPv6 as cause to deny efforts on IPv4. Because as you say, at this point, even if you dont like CGN, the internet is sort of screwed. And the reasons that IPv6 is not deployed everywhere it could or even should be are myriad. Perhaps unpredictable. That reasons would abound was predictable. Network A deploying IPv6 does not do nearly as much to help A as it does when B-Z do, which is the core problem of IPv6 transition. You can understand then that even in the face of shortage IPv6 is only one of the options on the table at network A for short term alleviation. And usually not even the one with most bang per buck. Those who can choose D) all of the above, the rest prioritize based on resources and various locally defined assessments and analysis. Also unpredictable, but predictable that they would exist. Bygones are bygones, but not if the behavior persists. Yes, I understand referring to the IETF as an individual entity is grossly oversimplifying. Joe

On 23Mar22, Owen DeLong via NANOG allegedly wrote:

I would not say that IPv6 has been and continues to be a failure

Even if one might ask that question, what are the realistic alternatives? 1. Drop ipv6 and replace it with ipv4++ or ipv6-lite or whatever other protocol that magically creates a better and quicker transition? 2. Drop ipv6 and extend above the network layer for the forseeable future? By extend I mean things which only introduce ipv4-compatible changes: NATs, TURN, CDN at the edge, application overlays and other higher layer solutions. 3. Live with ipv6 and continue to engineer simpler, better, easier and no-brainer deployments? I'll admit it risks being a "sunk cost falacy" argument to perpetuate ipv6, but are the alternatives so clear that we're really ready to drop ipv6?

so much as IPv6 has not yet achieved its goal.

As someone previously mentioned, "legacy" support can have an extremely long tail which might superficially make "achieving a goal" look like a failure. Forget ss7 and SIP, what about 100LL vs unleaded petrol or 1/2" bolts vs 13mm bolts? Both must be 50 years in the making with many more years to come. The glacial grind of displacing legacy tech is hardly unique to network protocols. In the grand scheme of things, the goal of replacing ipv4 with ipv6 has really only had a relatively short life-time compared to many other tech transitions. Perhaps it's time to adopt the patience of the physical world? Mark.

On 24Mar22, Vasilenko Eduard allegedly wrote:

Hence, the primary blocking entity for IPv6 adoption is Google: they do not support DHCPv6 for the most popular OS.

No. The primary "blocking entity" is that "legacy" ipv4 works just fine and adopting ipv6 or ipv4++ or ipv6-lite or ipv-magical is harder than doing nothing. That Google/Android don't like DHCPv6 is largely irrelevant. My five year old ISP router only supports ipv4. Yet I get to every site on the planet just fine. Give me one good reason to spend my hard earned pay on an expensive new router which supports ipv6? You have two choices: make my ipv4 router fail or make the new ipv6 router compelling. How do you propose to do either of those? Mark.

On 3/24/22 1:59 PM, Owen DeLong via NANOG wrote:

Home users aren’t the long tail here. Enterprise is the long tail here. Android phones are, indeed, part of the enterprise problem, but not the biggest part.

If this were a purely technical problem, we’d have been done more than a decade ago. The problem is a lack of corporate “round tuits” which for each enterprise are in limited supply and usually go to things that either reduce costs or increase revenue.

So long as they have public facing v6 servers is there really a problem? Sure you're not going to get to 100% deployment, but nothing is going to do that in any of our lifetimes. The object should be to not have to deploy tortured hacks like CGNAT. That is what success is IMO, and we don't from a technical standpoint. Mike

On 3/24/22 3:13 PM, Owen DeLong wrote:

...

On Mar 24, 2022, at 14:46 , Michael Thomas <mike@mtcc.com> wrote:

On 3/24/22 1:59 PM, Owen DeLong via NANOG wrote:

...

Home users aren’t the long tail here. Enterprise is the long tail here. Android phones are, indeed, part of the enterprise problem, but not the biggest part.

If this were a purely technical problem, we’d have been done more than a decade ago. The problem is a lack of corporate “round tuits” which for each enterprise are in limited supply and usually go to things that either reduce costs or increase revenue.

So long as they have public facing v6 servers is there really a problem? Sure you're not going to get to 100% deployment, but nothing is going to do that in any of our lifetimes. The object should be to not have to deploy tortured hacks like CGNAT. That is what success is IMO, and we don't from a technical standpoint.

Mike

Yes… We need them to have v6 deployed to their clients so that content providers can start turning off v4 where it’s costing them money to support it.

Well content providers could pretty easily force the issue if they wanted. MIke

Michael Thomas wrote:

On 3/24/22 3:13 PM, Owen DeLong wrote:

...

...

On Mar 24, 2022, at 14:46 , Michael Thomas <mike@mtcc.com> wrote:

On 3/24/22 1:59 PM, Owen DeLong via NANOG wrote:

...

Home users aren’t the long tail here. Enterprise is the long tail here. Android phones are, indeed, part of the enterprise problem, but not the biggest part.

If this were a purely technical problem, we’d have been done more than a decade ago. The problem is a lack of corporate “round tuits” which for each enterprise are in limited supply and usually go to things that either reduce costs or increase revenue.

So long as they have public facing v6 servers is there really a problem? Sure you're not going to get to 100% deployment, but nothing is going to do that in any of our lifetimes. The object should be to not have to deploy tortured hacks like CGNAT. That is what success is IMO, and we don't from a technical standpoint.

Mike

Yes… We need them to have v6 deployed to their clients so that content providers can start turning off v4 where it’s costing them money to support it.

Well content providers could pretty easily force the issue if they wanted.

MIke

Content providers are rumored to dig into the single digit percentages of failing connections to ensure their audiences is as large as possible. And enterprises would likely happily settle on edge solutions for v6 only content so long as they are workable. Joe

On 3/24/22 2:13 PM, Owen DeLong via NANOG wrote:
>
>> On Mar 24, 2022, at 02:04 , Vasilenko Eduard via NANOG <nanog@nanog.org> wrote:
>>
>> Hi all,
>>>  From 10k meters: IPv6 is different from IPv4 only by:
>> - extension headers
>> - SLAAC instead of DHCP
>> Everything else is minor.
> There’s no such thing as SLAAC instead of DHCP… There’s SLACC in addition to DHCP and operators
> are free to choose the solution that best fits their network.
>
> I suppose the argument could be made that Android is SLAAC instead of DHCP, but I don’t buy that as a
> complete showstopper these days. I do wish Lorenzo and Google would pull their collective crania out of
> their hind quarters on this issue, but my vote is to treat Android as damage and route around it.

If you have SLAAC and DHCP4 isn't that good enough? Is there a DHCP4 
option for v6 DNS addresses too?

Mike, not that I disagree about the silliness of not implementing DHCP6

Mark Delany wrote:

On 23Mar22, Owen DeLong via NANOG allegedly wrote:

...

I would not say that IPv6 has been and continues to be a failure Even if one might ask that question, what are the realistic alternatives?

1. Drop ipv6 and replace it with ipv4++ or ipv6-lite or whatever other protocol that magically creates a better and quicker transition?

2. Drop ipv6 and extend above the network layer for the forseeable future? By extend I mean things which only introduce ipv4-compatible changes: NATs, TURN, CDN at the edge, application overlays and other higher layer solutions.

3. Live with ipv6 and continue to engineer simpler, better, easier and no-brainer deployments?

I'll admit it risks being a "sunk cost falacy" argument to perpetuate ipv6, but are the alternatives so clear that we're really ready to drop ipv6

I most assuredly hope not. However this is not actually within any specific bodies absolute control. The overblown representation of the top down nature of internet design is a significant fallacy. If a vacuum persists and what fills that void is detrimental to IPv6 global deployment, it would be a significant setback. But the internet wont care. What you can do is try and preempt the vacuum. In my view that takes the form of a multi-pronged strategy. Do what it takes to keep IPv4 as usable as possible for as long as possible. By all means, continue to evangelize users and pressure vendors. But thats not enough. Make IPv6 more attractive, more utilitarian, more useful. Address and remove barriers and hurdles. And that means doing and accepting things that many have significant distaste for. Personally, that means that although I have long disliked proposals that keep moving to the left of the 128bit space, were I to believe it likely to increase deployment and momentum I would champion it in my own limited fashion much as I do 240/4.

...

so much as IPv6 has not yet achieved its goal. As someone previously mentioned, "legacy" support can have an extremely long tail which might superficially make "achieving a goal" look like a failure.

While true, thats not my concern. My concern is that continued dependence on functioning IPv4 by and large for the internet population has resulted in additional costs and constrains on the addresses required to utilize it. So long as that persists, so does the failure status of IPv6 towards the goal of alleviating it. And thats the goal that actually matters to the internet population at large.

Forget ss7 and SIP, what about 100LL vs unleaded petrol or 1/2" bolts vs 13mm bolts? Both must be 50 years in the making with many more years to come. The glacial grind of displacing legacy tech is hardly unique to network protocols.

In the grand scheme of things, the goal of replacing ipv4 with ipv6 has really only had a relatively short life-time compared to many other tech transitions. Perhaps it's time to adopt the patience of the physical world?

Mark.

I agree. But that means behavioral modification towards a much longer term outlook than has been in widespread evidence thus far. Joe

Owen DeLong wrote:

...

On Mar 24, 2022, at 03:36 , Joe Maimon <jmaimon@jmaimon.com> wrote:

In my view that takes the form of a multi-pronged strategy.

Do what it takes to keep IPv4 as usable as possible for as long as possible. I think this isn’t so much preempting the vacuum as trying to pretend we can survive on an hour of air for 20 years.

240/4 is way more effort than its proponents want to believe and even if it were reclassified effectively as GUA, it doesn’t buy all that much life for IPv4.

I think it should be reclassified from never going to be used into some part of the internet might actually do something with it. Its important that happens now, better late then never. Whether its GUA or not or a mix of whatever, whether it buys months or years will depend greatly on how its actually used if it is ever used. You may be right about not being worth it. More importantly, you may be wrong. IPv6 is replete with not only a plethora of wrong predictions, but the same ones over and over again. To be clear, the only effort asked from the unwilling is to support cutting the red tape frustrating the willing. A hearty round of knock yourself out from the right folk in the right place and time and we dont have to debate this particular point ever again. How are we to ever find out who is right if that never happens? That alone is enough reason for me.

...

Personally, that means that although I have long disliked proposals that keep moving to the left of the 128bit space, were I to believe it likely to increase deployment and momentum I would champion it in my own limited fashion much as I do 240/4. Not sure what you mean by “moving to the left of the 128 bit space”.

That Ipv6 address allocation schemes and proposals tended to enlarge over time, using up more bits heading from right to left.

We will obviously agree to disagree about 240/4 as we long have.

Owen

To the next time then. Joe

Owen DeLong wrote:

...

You may be right about not being worth it. More importantly, you may be wrong. IPv6 is replete with not only a plethora of wrong predictions, but the same ones over and over again. To be clear, the only effort asked from the unwilling is to support cutting the red tape frustrating the willing. A hearty round of knock yourself out from the right folk in the right place and time and we dont have to debate this particular point ever again. Certainly, if we continue to waste effort that is better spent deploying IPv6 on bandaids and hacks to make v4 last just a little longer, we will continue to fail and further delay IPv6 reaching a level of deployment that allows us to start turning down IPv4 and beginning to recognize the cost savings that come from moving forward.

...

How are we to ever find out who is right if that never happens? That alone is enough reason for me. The problem is that we’re not talking about parallel experiments. We’re talking about an optional activity which will inherently pull resources away from a necessary activity, thus delaying the necessary activity and becoming somewhat of a self-fulfilling prophecy. Hence I oppose this wasteful experiment in favor of doing what we all know eventually needs to be done.

I dont know what it will take to paint this nonsensical argument as any more patently ridiculous than has already been done. It bears no relationship to actual reality. However, hypothetically, lets say thats exactly how it works. Too Bad. You had your chance to deploy IPv6 before the pain and now you must tend to both protocols. Joe

On Mar 24, 2022, at 21:18 , James R Cutler <james.cutler@consultant.com> wrote:

On Mar 24, 2022, at 9:25 PM, Owen DeLong via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote:

...

I think that we’re still OK on allocation policies. What I’d like to see is an end to the IPv4-think in large ISPs, such as Comcast’s continued micro allocations to their customers.

What exactly is your definition of “micro allocations”? Is a prefix/56 a “micro allocation”? In over nine years of being an active forum participant and customer of Comcast, I can not recall the usage of the term.

They’re issuing /60s (maximum) to residential customers. And yes, a /56 is a micro allocation. /48 is the intended norm for IPv6 site assignments and is a perfectly reasonable prefix size for v6 delegation to a site. Owen

Dear Owen: 0)    You rapid fired a few posts in succession yesterday. Some are interesting and crucial views that I would like to follow-up on. I will start from quoting the earlier ones. I hope that I am picking up the correct leads. 1)    " ... 240/4 is way more effort than its proponents want to believe and even if it were reclassified effectively as GUA, it doesn’t buy all that much life for IPv4. ...   ":     Perhaps you have not bothered to scan through a two page whitepaper (URL below, again) that I submitted a week or so ago? It promises simple implementation and significant increase of assignable IPv4 addresses, even extendable to the similar size of IPv6 if we could forgo our mentality about the IP addresses as "Personal Properties", by switching to treat them as "Natural Resources". https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf 2)    " ...  so that content providers can start turning off v4 where it’s costing them money to support it. ....   " & "... Content providers turning off v4 face competition from content providers that don’t. ...  ":    These two statements appeared to come from two separate posting of yours. They seemed to be contradicting each other. Did I misread somehow? Now from the last post below: 3)    "  ... 240/4 is way more effort than its proponents want to believe and even if it were reclassified effectively as GUA, it doesn’t buy all that much life for IPv4....   ": Please see information provided by Pt. 1) above. 4)    " ... I think it should be reclassified from never going to be used into some part of the internet might actually do something with it. Its important that happens now, better late then never ... Please feel free to use it for router IDs in BGP and/or OSPF area numbers. :p ...    ":    I am in full agreement with you. Our proposal is the solution in Pt. 1) above. 5)    "  ...  if we continue to waste effort that is better spent deploying IPv6 on bandaids and hacks to make v4 last just a little longer, .... ":    This is not a productive opinion. Please do not forget that the Internet heavily promotes personal freedom. One can not force others to do something that they do not believe in. Stopping them from doing one thing does not automatically make them to do what you like. A project must have its own merits that attract contribution. The failure of the IPv6 actually started from when a decision was made to the effect of "not to emphasize backward compatibility with IPv4" which broke one of the golden rules in system engineering. Not recognizing such and focusing to find a way for remedying it, but continuing to force others to migrate to IPv6 camp with various tactics does not foster progress. 6)    "  ... The problem is that we’re not talking about parallel experiments. ... ": EzIP is a parallel experiment to the current Internet (not only IPv4, but also IPv6) operations, because its overlay architecture on the latter demarcates everything happening on it from the Internet. As long as packets exchanged between the two conform to the established Internet protocols, an EzIP deployment (called RAN - Regional Area Network) will appear as innocent as an ordinary private network. Regards, Abe (2022-03-25 12:24) On 2022-03-24 21:25, Owen DeLong via NANOG wrote:

...

On Mar 24, 2022, at 15:49, Joe Maimon<jmaimon@jmaimon.com> wrote:

Owen DeLong wrote:

...

...

On Mar 24, 2022, at 03:36 , Joe Maimon<jmaimon@jmaimon.com> wrote:

In my view that takes the form of a multi-pronged strategy.

Do what it takes to keep IPv4 as usable as possible for as long as possible. I think this isn’t so much preempting the vacuum as trying to pretend we can survive on an hour of air for 20 years.

240/4 is way more effort than its proponents want to believe and even if it were reclassified effectively as GUA, it doesn’t buy all that much life for IPv4. I think it should be reclassified from never going to be used into some part of the internet might actually do something with it. Its important that happens now, better late then never. Whether its GUA or not or a mix of whatever, whether it buys months or years will depend greatly on how its actually used if it is ever used. Please feel free to use it for router IDs in BGP and/or OSPF area numbers. :p

...

You may be right about not being worth it. More importantly, you may be wrong. IPv6 is replete with not only a plethora of wrong predictions, but the same ones over and over again. To be clear, the only effort asked from the unwilling is to support cutting the red tape frustrating the willing. A hearty round of knock yourself out from the right folk in the right place and time and we dont have to debate this particular point ever again. Certainly, if we continue to waste effort that is better spent deploying IPv6 on bandaids and hacks to make v4 last just a little longer, we will continue to fail and further delay IPv6 reaching a level of deployment that allows us to start turning down IPv4 and beginning to recognize the cost savings that come from moving forward.

...

How are we to ever find out who is right if that never happens? That alone is enough reason for me. The problem is that we’re not talking about parallel experiments. We’re talking about an optional activity which will inherently pull resources away from a necessary activity, thus delaying the necessary activity and becoming somewhat of a self-fulfilling prophecy. Hence I oppose this wasteful experiment in favor of doing what we all know eventually needs to be done.

...

...

...

Personally, that means that although I have long disliked proposals that keep moving to the left of the 128bit space, were I to believe it likely to increase deployment and momentum I would champion it in my own limited fashion much as I do 240/4. Not sure what you mean by “moving to the left of the 128 bit space”. That Ipv6 address allocation schemes and proposals tended to enlarge over time, using up more bits heading from right to left. Meh… I haven’t seen too much of that. I’ve been guilty of a certain amount of it, to be sure, but we’re only recently seeing the two largest RIRs start working through their second /12s even though it’s been years since I pushed for (and achieved) nibble-boundary round-ups as the norm in the ARIN region.

I think that we’re still OK on allocation policies. What I’d like to see is an end to the IPv4-think in large ISPs, such as Comcast’s continued micro allocations to their customers.

Owen

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

******  Resend to go through NANOG ****** On 2022-03-25 12:24, Abraham Y. Chen wrote:

Dear Owen:

0)    You rapid fired a few posts in succession yesterday. Some are interesting and crucial views that I would like to follow-up on. I will start from quoting the earlier ones. I hope that I am picking up the correct leads.

1)    " ... 240/4 is way more effort than its proponents want to believe and even if it were reclassified effectively as GUA, it doesn’t buy all that much life for IPv4. ...   ":     Perhaps you have not bothered to scan through a two page whitepaper (URL below, again) that I submitted a week or so ago? It promises simple implementation and significant increase of assignable IPv4 addresses, even extendable to the similar size of IPv6 if we could forgo our mentality about the IP addresses as "Personal Properties", by switching to treat them as "Natural Resources".

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)    " ...  so that content providers can start turning off v4 where it’s costing them money to support it. ....   " & "... Content providers turning off v4 face competition from content providers that don’t. ...  ":    These two statements appeared to come from two separate posting of yours. They seemed to be contradicting each other. Did I misread somehow?

Now from the last post below:

3)    "  ... 240/4 is way more effort than its proponents want to believe and even if it were reclassified effectively as GUA, it doesn’t buy all that much life for IPv4....   ": Please see information provided by Pt. 1) above.

4)    " ... I think it should be reclassified from never going to be used into some part of the internet might actually do something with it. Its important that happens now, better late then never ... Please feel free to use it for router IDs in BGP and/or OSPF area numbers. :p ...    ":    I am in full agreement with you. Our proposal is the solution in Pt. 1) above.

5)    "  ...  if we continue to waste effort that is better spent deploying IPv6 on bandaids and hacks to make v4 last just a little longer, .... ":    This is not a productive opinion. Please do not forget that the Internet heavily promotes personal freedom. One can not force others to do something that they do not believe in. Stopping them from doing one thing does not automatically make them to do what you like. A project must have its own merits that attract contribution. The failure of the IPv6 actually started from when a decision was made to the effect of "not to emphasize backward compatibility with IPv4" which broke one of the golden rules in system engineering. Not recognizing such and focusing to find a way for remedying it, but continuing to force others to migrate to IPv6 camp with various tactics does not foster progress.

6)    "  ... The problem is that we’re not talking about parallel experiments. ... ":    EzIP is a parallel experiment to the current Internet (not only IPv4, but also IPv6) operations, because its overlay architecture on the latter demarcates everything happening on it from the Internet. As long as packets exchanged between the two conform to the established Internet protocols, an EzIP deployment (called RAN - Regional Area Network) will appear as innocent as an ordinary private network.

Regards,

Abe (2022-03-25 12:24)

On 2022-03-24 21:25, Owen DeLong via NANOG wrote:

...

...

On Mar 24, 2022, at 15:49, Joe Maimon<jmaimon@jmaimon.com> wrote:

Owen DeLong wrote:

...

...

On Mar 24, 2022, at 03:36 , Joe Maimon<jmaimon@jmaimon.com> wrote:

In my view that takes the form of a multi-pronged strategy.

Do what it takes to keep IPv4 as usable as possible for as long as possible. I think this isn’t so much preempting the vacuum as trying to pretend we can survive on an hour of air for 20 years.

240/4 is way more effort than its proponents want to believe and even if it were reclassified effectively as GUA, it doesn’t buy all that much life for IPv4. I think it should be reclassified from never going to be used into some part of the internet might actually do something with it. Its important that happens now, better late then never. Whether its GUA or not or a mix of whatever, whether it buys months or years will depend greatly on how its actually used if it is ever used. Please feel free to use it for router IDs in BGP and/or OSPF area numbers. :p

...

You may be right about not being worth it. More importantly, you may be wrong. IPv6 is replete with not only a plethora of wrong predictions, but the same ones over and over again. To be clear, the only effort asked from the unwilling is to support cutting the red tape frustrating the willing. A hearty round of knock yourself out from the right folk in the right place and time and we dont have to debate this particular point ever again. Certainly, if we continue to waste effort that is better spent deploying IPv6 on bandaids and hacks to make v4 last just a little longer, we will continue to fail and further delay IPv6 reaching a level of deployment that allows us to start turning down IPv4 and beginning to recognize the cost savings that come from moving forward.

...

How are we to ever find out who is right if that never happens? That alone is enough reason for me. The problem is that we’re not talking about parallel experiments. We’re talking about an optional activity which will inherently pull resources away from a necessary activity, thus delaying the necessary activity and becoming somewhat of a self-fulfilling prophecy. Hence I oppose this wasteful experiment in favor of doing what we all know eventually needs to be done.

...

...

...

Personally, that means that although I have long disliked proposals that keep moving to the left of the 128bit space, were I to believe it likely to increase deployment and momentum I would champion it in my own limited fashion much as I do 240/4. Not sure what you mean by “moving to the left of the 128 bit space”. That Ipv6 address allocation schemes and proposals tended to enlarge over time, using up more bits heading from right to left. Meh… I haven’t seen too much of that. I’ve been guilty of a certain amount of it, to be sure, but we’re only recently seeing the two largest RIRs start working through their second /12s even though it’s been years since I pushed for (and achieved) nibble-boundary round-ups as the norm in the ARIN region.

I think that we’re still OK on allocation policies. What I’d like to see is an end to the IPv4-think in large ISPs, such as Comcast’s continued micro allocations to their customers.

Owen

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Hi, Owen: 0)    Re: Ur. Pt. 2): This topic is such a tongue-twister. Let's put it aside for now, until I can properly convey the EzIP concept and scheme to you. 00)    Re: Ur. Pt. 4):    Okay, I was concerned about how to decipher this cryptic exchange. So let's put it aside as well. 1)    Re: Ur. Pt. 1): Yes, you are correct that the EzIP network architecture looks like that of CG-NAT. In fact, it is exactly the same. This is actually the beauty of the EzIP solution. That is, without touching the hardware, by implementing the EzIP technique (*/disabling/* the program code that has been */disabling/* the use of the 240/4 netblock), an existing CG-NAT module becomes a RAN! As to universal peer-to-peer, where is any of such today? On the other hand, upon fully implemented the EzIP proposal (the second phase: making use of the Option Word in RFC791), an IoT in one RAN can directly reach a second IoT in another RAN world-wide. So that the original promise of the Internet will be finally fulfilled and for the long haul. 2)    Re: Ur. Pt. 3): Similarly, you probably only recognized the part that EzIP proposes to classify the 240/4 netblock as the fourth private address in RFC1918, but overlooked that such capacity will enable a RAN to cover a geographic area as big as Tokyo Metro, or 75% of smaller countries around the world, even before utilizing the conventional three private netblocks. This puts 240/4 into a different league from the other three conventional private netblocks, although all four have basically the same technical characteristics. Now, visualizing each RAN is tethered from the existing Internet core by one umbilical cord (one IPv4 address), it appears like a private network. So that each RAN can provide Internet services by utilizing existing technologies, while avoiding those undesired. Combining these RANs around the world, an */overlay/* layer of routers (SPRs) can operate in parallel to the current Internet. Under such a configuration, the latter no long is involved with daily local activities, but only carries inter-RAN traffic, very much like the division between national and international telephone networks. This creates quite a different operation landscape. Please have a look at slide # 11 of the below whitepaper for a rough breakdown of the available addresses under the EzIP scheme. Furthermore, if used diligently, (treating IP address as "*/natural resources/*" instead of "*/personal properties/*"), the assignable "EzIP addresses" can last quite awhile. https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf 3)    Re: Ur. Pts. 5) & 6):    I believe that there is a philosophic / logic baseline that we need to sort out, first. That is, we must keep in mind that the Internet community strongly promotes "*/personal freedom/*". Assuming that by stopping others from working on IPv4 will shift their energy to IPv6 is totally contradicting such a principle. A project attracts contributors by its own merits, not by relying on artificial barriers to the competitions. Based on my best understanding, IPv6 failed right after the decision of "not emphasizing the backward compatibility with IPv4". It broke one of the golden rules in the system engineering discipline. After nearly three decades, still evading such fact, but defusing IPv6 issues by various tactics is the real impedance to progress, not only to IPv4 but also to IPv6. Regards, Abe (2022-03-26 09:35 EDT) On 2022-03-25 22:17, Owen DeLong wrote:

...

On Mar 25, 2022, at 18:47 , Abraham Y. Chen <aychen@avinta.com> wrote:

******  Resend to go through NANOG ******

On 2022-03-25 12:24, Abraham Y. Chen wrote:

...

Dear Owen:

0) You rapid fired a few posts in succession yesterday. Some are interesting and crucial views that I would like to follow-up on. I will start from quoting the earlier ones. I hope that I am picking up the correct leads.

1) " ... 240/4 is way more effort than its proponents want to believe and even if it were reclassified effectively as GUA, it doesn’t buy all that much life for IPv4. ...   ":     Perhaps you have not bothered to scan through a two page whitepaper (URL below, again) that I submitted a week or so ago? It promises simple implementation and significant increase of assignable IPv4 addresses, even extendable to the similar size of IPv6 if we could forgo our mentality about the IP addresses as "Personal Properties", by switching to treat them as "Natural Resources".

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

It still looks like NAT to me.

NAT is a disgusting hack and destroys the universal peer to peer nature of the internet in favor of a consumer/provider model.

Your proposal perpetuates that problem.

...

...

2) " ...  so that content providers can start turning off v4 where it’s costing them money to support it. ....   " & "... Content providers turning off v4 face competition from content providers that don’t. ...  ":    These two statements appeared to come from two separate posting of yours. They seemed to be contradicting each other. Did I misread somehow?

No, it is not contradictory at all…

Content providers that have deployed IPv6 are eager to turn off IPv4 as soon as it won’t lose them customers. They are worried about losing customers because competition exists that might not turn off IPv4 at the same time they do. Thus, there is a need for customers to be IPv6 deployed before content providers can start turning off IPv4. Thus, the persistence of IPv4 in clients, especially enterprises, is costing content providers money.

...

...

Now from the last post below:

3) "  ... 240/4 is way more effort than its proponents want to believe and even if it were reclassified effectively as GUA, it doesn’t buy all that much life for IPv4....   ": Please see information provided by Pt. 1) above.

OK, so you want to extend RFC-1918 instead… Arguably even more worthless than reclassifying it as GUA. While it’s true that some very large deployments are short of RFC-1918 space, the reality is that the real shortage is in the GUA realm.

...

...

4) " ... I think it should be reclassified from never going to be used into some part of the internet might actually do something with it. Its important that happens now, better late then never ... Please feel free to use it for router IDs in BGP and/or OSPF area numbers. :p ...    ":    I am in full agreement with you. Our proposal is the solution in Pt. 1) above.

That’s not me. That’s Joe Maimon IIRC. My part was “Pleas feel free to use it for router IDs in BGP and/or OSPF area numbers. :p.

It was mostly a snarky comment since neither BGP Router IDs nor OSPF Area numbers are actually IP addresses.

...

...

5) "  ...  if we continue to waste effort that is better spent deploying IPv6 on bandaids and hacks to make v4 last just a little longer, .... ":    This is not a productive opinion. Please do not forget that the Internet heavily promotes personal freedom. One can not force others to do something that they do not believe in. Stopping them from doing one thing does not automatically make them to do what you like. A project must have its own merits that attract contribution. The failure of the IPv6 actually started from when a decision was made to the effect of "not to emphasize backward compatibility with IPv4" which broke one of the golden rules in system engineering. Not recognizing such and focusing to find a way for remedying it, but continuing to force others to migrate to IPv6 camp with various tactics does not foster progress.

We can agree to disagree about that… I think trying to continue to support IPv4 is not a productive opinion.

...

...

6) "  ... The problem is that we’re not talking about parallel experiments. ... ":    EzIP is a parallel experiment to the current Internet (not only IPv4, but also IPv6) operations, because its overlay architecture on the latter demarcates everything happening on it from the Internet. As long as packets exchanged between the two conform to the established Internet protocols, an EzIP deployment (called RAN - Regional Area Network) will appear as innocent as an ordinary private network.

Again, I disagree… You left out the relevant part of my quote where I stated that resources spent developing this mechanism are better used deploying IPv6.

Owen

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved that it's 'not that big a deal.', so I don't think he adequately grasps the scale of that challenge. On Sat, Mar 26, 2022 at 9:53 AM Paul Rolland <rol@witbe.net> wrote:

Hello,

On Sat, 26 Mar 2022 09:35:30 -0400 "Abraham Y. Chen" <aychen@avinta.com> wrote:

...

touching the hardware, by implementing the EzIP technique (*/disabling/* the program code that has been */disabling/* the use of the 240/4 netblock), an existing CG-NAT module becomes a RAN! As to universal

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the way you expect

Paul

----- On Mar 26, 2022, at 6:16 PM, Abraham Y. Chen aychen@avinta.com wrote:

Hi, Tom & Paul:

1) " ... hand waved ... ": Through my line of work, I was trained to behave exactly the opposite. I am surprised at you jumping to the conclusion, even before challenging me about where did I get my viewpoint from. The fact is, it has been clearly documented in our IETF draft for the last couple years (since Rev-06 on 2019 Dec. 1)! For your convenience, please see below a copy of the potential target code fragment and critique. It appears to me that our software member suggested to comment out only one line (1047).

Just because it is trivial to make the modification in a single, specific firmware for one particular device does not mean it is trivial to get it done on *billions* of devices. Even if each one was as trivial as your example, it would still be ludicrously difficult. Beyond that, I am still not understanding what you are actually trying to propose here. Your refusal to follow simple mailing list etiquette even after numerous requests makes it very difficult to decipher what you are saying. -Randy

Sent using a machine that autocorrects in interesting ways...

On Mar 27, 2022, at 12:18 PM, Abraham Y. Chen <aychen@avinta.com> wrote:

Honestly, I am still trying to figure out what is the "required" etiquette, since what I have received were mostly "complaints" not constructive "instructions" (i.e., how about a cheat sheet of what to do and what not to?).

I suspect there are two important rules. 1) every mailing list has a topic. Post on that topic. 2) a mailing list discussion is a conversation. We all get involved in conversations every day. Act as you would in polite conversation.

On Sat, Mar 26, 2022 at 12:37:59PM -0400, Tom Beecher wrote:

...

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved that it's 'not that big a deal.', so I don't think he adequately grasps the scale of that challenge.

It seems like it should only require changes on a few billion nodes, given the size of the IPv4 address space, right? Oh, wait, NAT... So I guess the question here is how do you plan to incentivize the patching of all these devices, many of which are legacy devices with no maintainer for the firmware/software, in roles where they may not be accessible, and protected by firewalls that understand Class E to be unusable space. I am unclear on the desirability of "fixing" the IPv4 network by touching lots of nodes, in a manner which will never be comprehensive, in order to free up a relatively small block of space. It's going to be crippled, less-valuable space. It seems to me like it'd be much more productive, if you're going to be touching gear, to move towards IPv6. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Tom Beecher <beecher@beecher.cc> wrote:

...

*/writing/* and */deploying/* the code that will allow the use of 240/4 the way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved that it's 'not that big a deal.', so I don't think he adequately grasps the scale of that challenge.

From multiple years of patching and testing, the IPv4 Unicast Extensions Project knows that 240/4 ALREADY WORKS in a large fraction of the Internet. Including all the Linux servers and desktops, all the Android phones and tablets, all the MacOS machines, all the iOS phones, many of the home wifi gateways. All the Ethernet switches. And some less popular stuff like routers from Cisco, Juniper, and OpenWRT. Most of these started working A DECADE AGO. If others grasp the scale of the challenge better than we do, I'm happy to learn from them.

A traceroute from my machine to 240.1.2.3 goes through six routers at my ISP before stopping (probably at the first default-route-free router). Today Google is documenting to its cloud customers that they should use 240/4 for internal networks. (Read draft-schoen-intarea-unicast-240 for the citation.) We have received inquiries from two other huge Internet companies, which are investigating or already using 240/4 as private IPv4 address space. In short, we are actually making it work, and writing a spec for what already works. Our detractors are arguing: not that it doesn't work, but that we should instead seek to accomplish somebody else's goals. John PS: Mr. Abraham Chen's effort is not related to ours. Our drafts are agnostic about what 240/4 should be used for after we enable it as ordinary unicast. His EzIP overlay network effort is one that I don't fully understand. What I do understand is that since his effort uses 240/4 addresses as the outer addresses in IPv4 packets, it couldn't work without reaching our goal first: allowing any site on the Internet to send unicast packets to or from 240.0.0.1 and having them arrive.

On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:

EzIP proposes to deploy 240/4 address based RANs, each tethering off the current Internet via one IPv4 public address.

So each RAN has no possibility of redundant connections? Nobody of scale would accept such a limitation. It also looks like an opportunity for telcos/governments to partition their part of the internet and impose whatever censorship they wish.

As such, the collection of RANs forms an overlay network layer wrapping around the current Internet core. Consequently, only the SPRs in the RAN need to be able to transport 240/4 addressed packets.

You previously described this as like connecting CG-NATs together via a VPN. I don't see why we'd want to add maintaining a global VPN to already difficult peering relationships. It could be used to exlude non EzIP club members.

This is why we talk about enabling new (but based on existing design) routers to use 240/4 netblock for serving as SPRs, but not perturbing any routers in the current Internet.

As it's a CG-NAT variant why are you delaying yourself by requiring new address space that will take a long time to become available? Why not use the already allocated space for CG-NAT? Sure it's only a /10 but that's an already (probably too) large RAN. It also seems unfeasibly optimistic that if the work was done globally to make 240/4 useable that they'd want to dedicate it to the as yet undeployed EzIP. You might stand more chance if you gained some critical mass using the existing available 100.64/10 & rfc1918 space, and then those that find they need more in one RAN will make the case for 240/4 when it becomes necessary for them. Is 240/4 special to EzIP such that alternative numbers may not be used?

I would like to share one intriguing graphics (see URL below) that is almost perfect for depicting the EzIP deployment configuration. Consider the blue sphere as the earth or the current Internet core and the golden colored land as the RANs. By connecting each continent, country or all the way down to a Region to the earth via one IPv4 address, we have the EzIP configuration. With this architecture, each RAN looks like a private network.

That sounds an entirely undesirable goal for the internet. brandon

Hi, Christian: 0)    Allow me following your "towers of babel world" metaphor to tell a short story. 1)    In the ancient days, peasants labored under the shadow of the Tower, following the rules of and paid tax to the Lord living in the Tower. In return, they expected protection from the Lord against harms. (Sometime ago, I read an archaeological article reporting certain evidence that the Load somewhere in England during medieval time might have been expected to protect his peasants from any harm, including even paid his life for famine.) 2)    In the modern world, the peasants still live around the Tower following the rules, paying taxes and expecting protection from the Lord, now represented by the government agencies such as local police, FCC, FTC, DoD, DHS, etc. 3)    In the Internet era, the peasants roam everywhere around the cyberspace freely enjoying the Internet way. However, their wealth is now being siphoned out to the invisible Lords (the multi-national businesses with virtual presence in each and every Tower). However, little can be expected in return when perpetrators attack, because no Lord assumes the responsibility, nor any can be held responsible. 4)    EzIP proposes an overlay cyberspace with geographic flavor to restore the society infrastructure back to Pt. 2) above, while providing the daily services of Pt. 3). It essentially offers a parallel Internet for the peasants who can again expect protection from their local government who collects taxes, while without losing the benefits of the digital revolution. 5)    The two cyberspaces are expected to coexist and none-interfering to each other. Peasants have the freedom of choice by living in either or try both then decide. The above is just a quick rough thought, far from polished. It is intended to be a preliminary framework so that we can hang some meat on it for starting meaningful discussions. Regards, Abe (2022-04-01 14:17) On 2022-03-27 11:03, Christian de Larrinaga wrote:

On 27 March 2022 15:53:25 Brandon Butterworth <brandon@rd.bbc.co.uk> wrote:

...

On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:

...

EzIP proposes to deploy 240/4 address based RANs, each tethering off the current Internet via one IPv4 public address.

So each RAN has no possibility of redundant connections? Nobody of scale would accept such a limitation. It also looks like an opportunity for telcos/governments to partition their part of the internet and impose whatever censorship they wish.

...

As such, the collection of RANs forms an overlay network layer wrapping around the current Internet core. Consequently, only the SPRs in the RAN need to be able to transport 240/4 addressed packets.

You previously described this as like connecting CG-NATs together via a VPN. I don't see why we'd want to add maintaining a global VPN to already difficult peering relationships. It could be used to exlude non EzIP club members.

...

This is why we talk about enabling new (but based on existing design) routers to use 240/4 netblock for serving as SPRs, but not perturbing any routers in the current Internet.

As it's a CG-NAT variant why are you delaying yourself by requiring new address space that will take a long time to become available? Why not use the already allocated space for CG-NAT? Sure it's only a /10 but that's an already (probably too) large RAN.

It also seems unfeasibly optimistic that if the work was done globally to make 240/4 useable that they'd want to dedicate it to the as yet undeployed EzIP. You might stand more chance if you gained some critical mass using the existing available 100.64/10 & rfc1918 space, and then those that find they need more in one RAN will make the case for 240/4 when it becomes necessary for them. Is 240/4 special to EzIP such that alternative numbers may not be used?

...

I would like to share one intriguing graphics (see URL below) that is almost perfect for depicting the EzIP deployment configuration. Consider the blue sphere as the earth or the current Internet core and the golden colored land as the RANs. By connecting each continent, country or all the way down to a Region to the earth via one IPv4 address, we have the EzIP configuration. With this architecture, each RAN looks like a private network.

That sounds an entirely undesirable goal for the internet.

brandon

It isn't the Internet. It's at best a very poorly connected spur gateway.

Too many today don't remember the towers of Babel world prior to the Internet. If they did they'd understand that building on this type of idea is like burying yourself.... And any customers so unwise to get involved

C

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Hi, Ant: 1)    " ...  darknet ...  ":    I am not aware of this terminology. Nonetheless, I believe that bringing in a not commonly known word into a discussion like this is just distraction tactic. 2)    " ...  progress ...  ":    EzIP proposes a parallel cyberspace to the current Internet which not only is none interfering to each other, but also promises to require bare minimum engineering efforts to deploy. This can settle the long debates on which way the Internet should go via true experiments. If this is not regarded as progress, I am not sure what qualifies so under your definition. Regards, Abe (2022-04-02 08:55) On 2022-04-02 00:21, ant+nanog.org@antiphase.net wrote:

On 1 Apr 2022, at 11:17, Abraham Y. Chen wrote:

...

4)    EzIP proposes an overlay cyberspace with geographic flavor to restore the society infrastructure back to Pt. 2) above, while providing the daily services of Pt. 3). It essentially offers a parallel Internet for the peasants who can again expect protection from their local government who collects taxes, while without losing the benefits of the digital revolution. So essentially a darknet whose implementation happens to be patent-encumbered by you. This doesn’t sound like progress to me.

Ant

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Your take on English history is a delightful fantasy but it is just that a delightful fantasy. Norman barons were not typically concerned with the health of their anglo saxon/british serfs / yoemen other than providing the required tithes. But taking you at what seems to be your intention. Speaking as a digital peasant I am not assured that my interests are protected from anybody by being told I have no direct access to people I want to communicate with but have to go through a third party. Any addressing model that terminates address space between me and someone I communicate with also terminates my communications and security and by so doing introduces a number of uncertainties potentially rather arbitrary to what would otherwise be under my direct policy domain. C "Abraham Y. Chen" <aychen@avinta.com> writes:

Hi, Christian:

0)    Allow me following your "towers of babel world" metaphor to tell a short story.

1)    In the ancient days, peasants labored under the shadow of the Tower, following the rules of and paid tax to the Lord living in the Tower. In return, they expected protection from the Lord against harms. (Sometime ago, I read an archaeological article reporting certain evidence that the Load somewhere in England during medieval time might have been expected to protect his peasants from any harm, including even paid his life for famine.)

2)    In the modern world, the peasants still live around the Tower following the rules, paying taxes and expecting protection from the Lord, now represented by the government agencies such as local police, FCC, FTC, DoD, DHS, etc.

3)    In the Internet era, the peasants roam everywhere around the cyberspace freely enjoying the Internet way. However, their wealth is now being siphoned out to the invisible Lords (the multi-national businesses with virtual presence in each and every Tower). However, little can be expected in return when perpetrators attack, because no Lord assumes the responsibility, nor any can be held responsible.

4)    EzIP proposes an overlay cyberspace with geographic flavor to restore the society infrastructure back to Pt. 2) above, while providing the daily services of Pt. 3). It essentially offers a parallel Internet for the peasants who can again expect protection from their local government who collects taxes, while without losing the benefits of the digital revolution.

5)    The two cyberspaces are expected to coexist and none-interfering to each other. Peasants have the freedom of choice by living in either or try both then decide.

The above is just a quick rough thought, far from polished. It is intended to be a preliminary framework so that we can hang some meat on it for starting meaningful discussions.

Regards,

Abe (2022-04-01 14:17)

On 2022-03-27 11:03, Christian de Larrinaga wrote:

...

On 27 March 2022 15:53:25 Brandon Butterworth <brandon@rd.bbc.co.uk> wrote:

...

On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:

...

EzIP proposes to deploy 240/4 address based RANs, each tethering off the current Internet via one IPv4 public address.

So each RAN has no possibility of redundant connections? Nobody of scale would accept such a limitation. It also looks like an opportunity for telcos/governments to partition their part of the internet and impose whatever censorship they wish.

...

As such, the collection of RANs forms an overlay network layer wrapping around the current Internet core. Consequently, only the SPRs in the RAN need to be able to transport 240/4 addressed packets.

You previously described this as like connecting CG-NATs together via a VPN. I don't see why we'd want to add maintaining a global VPN to already difficult peering relationships. It could be used to exlude non EzIP club members.

...

This is why we talk about enabling new (but based on existing design) routers to use 240/4 netblock for serving as SPRs, but not perturbing any routers in the current Internet.

As it's a CG-NAT variant why are you delaying yourself by requiring new address space that will take a long time to become available? Why not use the already allocated space for CG-NAT? Sure it's only a /10 but that's an already (probably too) large RAN.

It also seems unfeasibly optimistic that if the work was done globally to make 240/4 useable that they'd want to dedicate it to the as yet undeployed EzIP. You might stand more chance if you gained some critical mass using the existing available 100.64/10 & rfc1918 space, and then those that find they need more in one RAN will make the case for 240/4 when it becomes necessary for them. Is 240/4 special to EzIP such that alternative numbers may not be used?

...

I would like to share one intriguing graphics (see URL below) that is almost perfect for depicting the EzIP deployment configuration. Consider the blue sphere as the earth or the current Internet core and the golden colored land as the RANs. By connecting each continent, country or all the way down to a Region to the earth via one IPv4 address, we have the EzIP configuration. With this architecture, each RAN looks like a private network.

That sounds an entirely undesirable goal for the internet.

brandon

It isn't the Internet. It's at best a very poorly connected spur gateway.

Too many today don't remember the towers of Babel world prior to the Internet. If they did they'd understand that building on this type of idea is like burying yourself.... And any customers so unwise to get involved

C

-- christian de larrinaga https://firsthand.net

Hi, Brandon: 1)    "So each RAN has no possibility of redundant connections?  ..  ":    There is difference between "via one IPv4 public address" and "wide bandwidth or multiple channels". The former is called "numbering plan". The latter is part of "traffic engineering". The former defines the configuration / architecture of the latter, but not restricts its capability. One simple analogy is that a corporation headquarters publishes only one (representative) telephone number. But, everyone knows that there are multiple physical channels to carry the simultaneous conversations. So, we discuss about network architecture here. Then, the implementation engineering will take care of the details. 2)    " It also looks like an opportunity for telcos/governments to partition their part of the internet and impose whatever censorship they wish. ...  ":    The EzIP scheme provides an alternative to the current "Internet way" operation model and can operate in parallel while none-interfering to each other. There is no intention for EzIP to replace the current Internet. The hope is to let the two models operate in real time for the consumer to make the informed choice, as in a free market. 3)    " You previously described this as like connecting CG-NATs together via a VPN. ...   ":    I do not believe that I have ever mentioned VPN in any of our literature, nor correspondence. I would appreciate learning where did you find such a connection. 4)    " As it's a CG-NAT variant why are you delaying yourself by requiring new address space that will take a long time to become available?    ": As it has become evident recently through various posting, the 240/4 netblock has been used "behind-the-scene" by many projects without the explicit permission by ICANN. Since packets with 240/4 addressing get dropped by existing routers, it actually makes the deployment of the new project easier. EzIP can be deployed in the same fashion as well. However, with the Unicast Extension Project became known, we would like to go along with their efforts to make the EzIP process more "Kosher". 5)    "... Why not use the already allocated space for CG-NAT? Sure it's only a /10 but that's an already (probably too) large RAN....    ":    The CG-NAT netblock of /10 is only one fourth of the largest private netblock 10/8. So, it is not big enough for the next level of challenge. Making use of the 240/4 netblock allows EzIP to serve a large enough geographical area, so that a true "Regional" Area Network characteristic may be achieved. A RAN can serve a population of upto 39M, even before employing the three conventional private netblocks. So, it is possible to experiment the wish of the "Country" networks idea proposed by ITU about one decade ago. Whether it is better or worse than the current Internet, EzIP provides a separate test bed for such, instead of verbal debates forever. 6)    " It also seems unfeasibly optimistic that if the work was done globally to make 240/4 useable that they'd want to dedicate it to the as yet undeployed EzIP. ...  ":    As have been hinted a couple times already on this forum, the ideal EzIP initial deployment beds are the existing CG-NAT modules. All we need to do is to enable the routers in a CG-NAT module to route 240/4 netblock and retire the 100.64/10 netblock. Since every customer premises can have a static 240/4 address, the DHCP process in the CG-NAT can fade out. The current communication between this CG-NAT with the Internet core remains unchanged. This process can be done gradually, one CG-NAT module at a time. No one outside of each of such tranistin will even notice something has happened. There is no need to do this globally in one shot, at all. 7)    "Is 240/4 special to EzIP such that alternative numbers may not be used?   " No, nothing is special here. The only reason that 240/4 is attractive is because it is big, continuous as well as being "Reserved for Future use" for so long. It is like a never-never land, fresh enough to do something really grand and for the long term. 8)    " That sounds an entirely undesirable goal for the internet.    ":    As I state above, EzIP offers a configuration for experimenting a (or more) parallel Internet(s). they will not interfere the current Internet, nor one another. So, what is your concern or reservation? Regards, Abe (2022-03-27 16:35) On 2022-03-27 10:49, Brandon Butterworth wrote:

On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:

...

EzIP proposes to deploy 240/4 address based RANs, each tethering off the current Internet via one IPv4 public address. So each RAN has no possibility of redundant connections? Nobody of scale would accept such a limitation. It also looks like an opportunity for telcos/governments to partition their part of the internet and impose whatever censorship they wish.

...

As such, the collection of RANs forms an overlay network layer wrapping around the current Internet core. Consequently, only the SPRs in the RAN need to be able to transport 240/4 addressed packets. You previously described this as like connecting CG-NATs together via a VPN. I don't see why we'd want to add maintaining a global VPN to already difficult peering relationships. It could be used to exlude non EzIP club members.

...

This is why we talk about enabling new (but based on existing design) routers to use 240/4 netblock for serving as SPRs, but not perturbing any routers in the current Internet. As it's a CG-NAT variant why are you delaying yourself by requiring new address space that will take a long time to become available? Why not use the already allocated space for CG-NAT? Sure it's only a /10 but that's an already (probably too) large RAN.

It also seems unfeasibly optimistic that if the work was done globally to make 240/4 useable that they'd want to dedicate it to the as yet undeployed EzIP. You might stand more chance if you gained some critical mass using the existing available 100.64/10 & rfc1918 space, and then those that find they need more in one RAN will make the case for 240/4 when it becomes necessary for them. Is 240/4 special to EzIP such that alternative numbers may not be used?

...

I would like to share one intriguing graphics (see URL below) that is almost perfect for depicting the EzIP deployment configuration. Consider the blue sphere as the earth or the current Internet core and the golden colored land as the RANs. By connecting each continent, country or all the way down to a Region to the earth via one IPv4 address, we have the EzIP configuration. With this architecture, each RAN looks like a private network. That sounds an entirely undesirable goal for the internet.

brandon

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On Sat, Mar 26, 2022, 21:42 John Gilmore <gnu@toad.com> wrote:

Today Google is documenting to its cloud customers that they should use 240/4 for internal networks. (Read draft-schoen-intarea-unicast-240 for the citation.) We have received inquiries from two other huge Internet companies, which are investigating or already using 240/4 as private IPv4 address space.

I think the advice in the draft, and on the quoted page of Google cloud docs is that you can use whatever address space you want for your voc network. I think it also says that choosing poorly could make portions if the internet unreachable. I don't see that the docs specify usage of 240/4 though.

Joshua Mallad wrote:

I am growing extremely frustrated by the lack of available internet address space.

Then, let's have NAT with 32bit port numbers.

How many times are you going to extend and hack away at IPv4,

Perhaps, only once, which means NAT. Anyway, it is a lot less than hacks to try to have IPv6 with IPv4. Masataka Ohta

A traceroute from my machine to 240.1.2.3 goes through six routers at my ISP before stopping (probably at the first default-route-free router).

My experience is the opposite. My home edge router (dd-wrt) will pass it, but nothing in my ISP's network will. $DayJob networks aren't worth checking, as I know I have 224/3 bogonized. I'd be curious to see the data you guys have collected on what it has been confirmed to work on if that's available somewhere. ( More for curiosity's sake ; I still think that making 224/3 universally available isn't worth the effort it would take to make it happen. ) On Sat, Mar 26, 2022 at 9:42 PM John Gilmore <gnu@toad.com> wrote:

...

...

*/writing/* and */deploying/* the code that will allow the use of 240/4 the way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved

Tom Beecher <beecher@beecher.cc> wrote: that

...

it's 'not that big a deal.', so I don't think he adequately grasps the scale of that challenge.

From multiple years of patching and testing, the IPv4 Unicast Extensions Project knows that 240/4 ALREADY WORKS in a large fraction of the Internet. Including all the Linux servers and desktops, all the Android phones and tablets, all the MacOS machines, all the iOS phones, many of the home wifi gateways. All the Ethernet switches. And some less popular stuff like routers from Cisco, Juniper, and OpenWRT. Most of these started working A DECADE AGO. If others grasp the scale of the challenge better than we do, I'm happy to learn from them.

A traceroute from my machine to 240.1.2.3 goes through six routers at my ISP before stopping (probably at the first default-route-free router).

Today Google is documenting to its cloud customers that they should use 240/4 for internal networks. (Read draft-schoen-intarea-unicast-240 for the citation.) We have received inquiries from two other huge Internet companies, which are investigating or already using 240/4 as private IPv4 address space.

In short, we are actually making it work, and writing a spec for what already works. Our detractors are arguing: not that it doesn't work, but that we should instead seek to accomplish somebody else's goals.

John

PS: Mr. Abraham Chen's effort is not related to ours. Our drafts are agnostic about what 240/4 should be used for after we enable it as ordinary unicast. His EzIP overlay network effort is one that I don't fully understand. What I do understand is that since his effort uses 240/4 addresses as the outer addresses in IPv4 packets, it couldn't work without reaching our goal first: allowing any site on the Internet to send unicast packets to or from 240.0.0.1 and having them arrive.

On Wed, 30 Mar 2022 04:47:08 -0700 John Gilmore <gnu@toad.com> wrote:

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

The draft touches on IANA considerations, but this seems inadequate to make any more progress and gain wider acceptance. It seems to me there has been compelling arguments made about the ability to rx, tx, and relay packets with these addresses, but the real challenge remains, how should they be allocated? The document should probably request that they be changed from reserved to experimental explicitly. Suggesting the IETF/IANA just figure out what to do with them later seems unsatisfying. Perhaps the equivalent of an IAB-style workshop report or position paper that goes into potential allocation choices and effects in detail is worthwhile? I'd imagine you'd get lots of interesting presentations on a possible allocation strategies and challenges if you decide to organize something like this. I'd like to see some options for the IANA/IETF. Let's see someone dissect what if anything RIRs should get and what the effect of different policies for the new blocks might be. Let's hear about some interesting new special-use ideas. I'd love to see someone suggest a spectrum-like auction to the highest bidder and get doused with rotten fruit... etc :-) John

On Mar 26, 2022, at 09:37 , Tom Beecher <beecher@beecher.cc> wrote:

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the way you expect

While Mr. Chen may have considered that, he has repeatedly hand waved that it's 'not that big a deal.', so I don't think he adequately grasps the scale of that challenge.

It’s certainly clear that he does not understand that in terms of cost-benefit ratio, the benefit of deploying his idea divided by the cost is a significantly lower number (in my estimation) than the much larger benefit of deploying IPv6 divided by the rather limited remaining costs involved in doing so. Owen

On Sat, Mar 26, 2022 at 9:53 AM Paul Rolland <rol@witbe.net <mailto:rol@witbe.net>> wrote: Hello,

On Sat, 26 Mar 2022 09:35:30 -0400 "Abraham Y. Chen" <aychen@avinta.com <mailto:aychen@avinta.com>> wrote:

...

touching the hardware, by implementing the EzIP technique (*/disabling/* the program code that has been */disabling/* the use of the 240/4 netblock), an existing CG-NAT module becomes a RAN! As to universal

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the way you expect

Paul

It was quite frustrating since we did not have the background in networking software

You clearly still do not, if you sincerely believe that commenting out a single function in every vendor software implementation is all that it would take. No need to respond ; I will be filtering all future messages from you to /dev/null . Good luck with your efforts. On Sat, Mar 26, 2022 at 12:42 PM Abraham Y. Chen <aychen@avinta.com> wrote:

Hi, Paul:

1) " ... may be in fact: /writing/* and */deploying/* the code ... ": Having no idea why and how the 240/4 netblock became so mysteriously kept away from being used while the IPv4 was officially already on its way to "Sun Set", we started the conventional approach as you stated. It was quite frustrating since we did not have the background in networking software. One day, we came across a short program code fragment that did the function of *disabling* 240/4 addressed IP packets. It is the "there exists an example" moment for us, like proofing a mathematics theorem. After all, there was no magic separating 240/4 from the rest of the IPv4 address pool to start with. It cleared our mind about this particular task. Now, we only cite this reference to challenge those software engineers who may state that using the 240/4 in their code is a lot more involved. .... Q.E.D. 😉

Regards,

Abe (2022-03-26 12:37 EDT)

On 2022-03-26 09:52, Paul Rolland wrote:

Hello,

On Sat, 26 Mar 2022 09:35:30 -0400 "Abraham Y. Chen" <aychen@avinta.com> <aychen@avinta.com> wrote:

touching the hardware, by implementing the EzIP technique (*/disabling/* the program code that has been */disabling/* the use of the 240/4 netblock), an existing CG-NAT module becomes a RAN! As to universal

Have you ever considered that this may be in fact:

*/writing/* and */deploying/* the code that will allow the use of 240/4 the way you expect

Paul

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> <#m_-7532339818749475379_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>