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.)
As the lead investigator of the EzIP Project, I would like to formally introduce our solution by bringing your attention to an overview whitepaper:
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.
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:
WebSite:
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?
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.
<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.
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.
Reallocating 240/4 as unpurposed unicast address space would allow
some standards-compliant uses to become practical before others. A few
quite quickly.
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.
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? This
year it was more than last year and next year it'll probably be more
than this year. The more precise predictions all seem to have fallen
flat.
It appears that William Herrin <bill@herrin.us> said:
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.
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? This
year it was more than last year and next year it’ll probably be more
than this year. The more precise predictions all seem to have fallen
flat.
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.
Oh you too? I got that response all the time. Then I when I press,
they usually say they've had one, two, three, maybe four others ask over
some really long period of time. The good news is most hosting
providers I've dealt with in the past few years have v6 support now.
Those that don't seem to be in the minority now from what I can tell.
When I was a college DJ, the older people used to tell me for each
phone call I get into the show figure you have about 100 listeners.
I'm sure that was a WAG, but I bet there is some 1 to x ratio of others
out there that just aren't calling about IPv6.
<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>
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?
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 agree. There is a great deal of unused or underused v4 space that increasing prices have found and even if the long term cost of setting up v6 is lower, it's more than the short term cost to buy another v4 block.
This still doesn't mean that screwing around with 240/4 or, an even worse 127/8 minus 127/24, is a good idea.
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
FWIW, I also don't think that repurposing 240/4 is a good idea.
As people will be aware, we have a different draft on this issue, so
I'm also going to pipe up here.
(Our draft offers no specific plan for exactly how to use the address
space, arguing that the most important short-term priority is to ensure
that implementations stop rejecting it, rather than to decide on a policy
for how or when it can be allocated. For example, it might turn out that
debogonization appears too daunting a task, in which case there might be
a consensus to make it into official private address space in the future.)
To be useful it would require that every host on the Internet update
its network stack,
Most hosts other than Windows already made this change following the
previous proposal in 2008. So we mostly have to get Windows to make the
change now.
Routers are a more complicated question, and we would love people to help
us obtain some concrete data about this.
which would take on the order of a decade, to free up some space that
would likely be depleted in a year or two.
When I presented about this at NANOG 84 and APRICOT recently, I noted
that a lot of people's intuitions about rapid exhaustion of IPv4
resources come from RIR allocations that were done with nominal fees.
But blocks that became available and were sold for market rates seemed
to last longer. We think that, if it does become feasible to allocate
historically-reserved space for public Internet use, market-based
allocations like auction mechanisms (which can potentially also be done
by RIRs) will make people more cautious in their appetite for number
resources, while also preventing the price of those resources from rising
as quickly as it otherwise would.
Someone asked a question about how long we thought it would take for
that depletion to occur, and I passed it on to Lee Howard (on account
of his experience in the IPv4 secondary markets). I think I remember
that his answer was "about seven years" -- I should double-check that
it wasn't six years or eight years. I understood the question I was
passing on to be something like "how long will these resources last,
assuming RIRs allocate them by selling them in a series of auctions or
selling them into existing address space markets as though they were
newly-recovered previously-allocated address space?".
It's basically the same amount of work as getting everything to work
on IPv6.
That's challenging to quantify, but in any case it doesn't appear to be
_the same work_ or, necessarily, _work by the same people_. For
example, Windows already supports IPv6 quite well, but doesn't support
unicast 240/4 at all. My Linux laptop supports both well, but my ISP
doesn't give me native IPv6. (I don't know yet whether or not my ISP
would have to make changes to support native 240/4, although I look
forward to finding out!)
I don't want people to work to support 240/4 (and other address ranges
we've proposed unreserving) at the expense of supporting IPv6. I agree
with the consensus that implementers and operators ought to support
IPv6. Still, I haven't seen why one can be expected to substitute for
or compete with the other, unless one envisions a very direct conflict
between improving IPv4 support or services and improving IPv6 support
or services.
We also have a new draft (published yesterday) more directly on point
about that issue...
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.
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.
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.
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.
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.
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.
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.
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.
>
> 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.
>
> draft-schoen-intarea-unicast-127-04 - Unicast Use of the Formerly Special-Cased 127/8
>
> 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.
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.
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:
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.
1) First, logistics: Since I have been waiting for the moderation of my first posting on NANOG, could I assume that you are sending me this personal eMail as a Moderator?
2) Perhaps the material provided in my writing was not sufficient, you seem to be expressing concerns from other perspectives. As concisely characterized by one of the "Internet fathers", the EzIP is an overlay network relative to the current Internet. As such, the EzIP deployment is pretty much independent of the hurdles that the current Internet equipment or convention may impose on it. That is, we can start the EzIP deployment leaving everything in the current Internet alone. This is because each EzIP deployment module, called RAN (Regional Area Network) is tethered via one IPv4 public address onto the Internet core. Since each RAN appears to be a private network, it can be set up according to its own requirements. That is, each RAN can make use of any desired IPv4 technology, while leaving others aside. As long as the packets on that single access path between the RAN and the Internet conform to the Internet conventions, the deployment of the EzIP proposal should work.
3) " ... if you plan on endpoint computers (such as those in homes) to use the 240/4 netblock. ... ": No, we do not. As presented by the RAN demonstration cited by the whitepaper, one of the primary criteria of the EzIP proposal is not to affect the current private network setups. Although, other than Windows OS based products, there are more and more IoTs do support 240/4 netblock. Even some Internet routers appear to do so, as well.
4) " ... DD-WRT project? ... ": EzIP does not have any ambition to alter or replace the existing Internet equipment in any sense. Fortunately, we can deploy our solution without such complication due to the overlay characteristics. Our main goal is to demonstrate that "*/there exists/*" one feasible configuration that can operate EzIP in parallel to the existing Internet for providing equivalent services. From such a skeletal reference, one can expand to larger deployments, as well as put on desired features and capabilities. For example, we have utilized OpenWrt 19.07.3 to demonstrate the feasibility of the EzIP scheme. Since the enabling technique is "disabling the program code that has been disabling the use of the 240/4 netblock", any other projects such as DD-WRT can replicate it just as well, if so inclined.
5) "... Firewalls ... NIST ... ": Since EzIP is only identifying the additional address resources from the "Reserve" and suggesting how to use it, I am not clear why high level functionalities such as security related firewall tasks get involved here. Do NIST Guidelines specify blocking any packet with the 240/4 netblock address? I failed to spot such. Since there is no natural division between the 240/4 netblock from the rest of IPv4 address pool, I can't see any reason to single this netblock out in the firewall related tasks anyway. Do you know the reason why? I would appreciate very much if you could elaborate your concerns.
6) By the way, the EzIP's RAN is actually very much the same as CG-NAT or CDN, architecturally. The only difference is that EzIP Project manged to identify a larger usable address pool enabling the practice of static addressing to simplify operation logistics, mitigate cyber insecurity, etc.