Unicast Use of the Formerly Reserved 127/8
ietf.org
ietf.org
Was/Is there an overabundance of IPv4 space that was reserved or allocated in silly ways? Yes. But we've got IPv6 now. It works, we know it works. Does IPv6 require some changes in assumption? Yes, but you start clean with those. You can test really quickly if IPv6 works or not, make sure your IP parsing tools and ETL work... it's not a huge deal once your network supports it (which for most people, it is already).
However, changing assumptions around IPv4 addresses that have been baked into software, hardware and everything in between for the last 40 years? Ouch.
Just look at Cloudflare and 1.0.0.0/24 network. Gigabits of junk traffic, why? Because people had spent a long time assuming that it'd never be used. https://www.zdnet.com/article/1-1-1-1-cloudflares-new-dns-at...
Imagine what that would look like if it was say... 127.127.127.127 or any popular various in the 127/8 space. They'd not only be able to receive huge amounts of what should have been private traffic... a malicious party could also SEND you huge amounts of traffic that your systems, today, assume is perfectly safe and internal only whitelist goodness.
I'd guess if this goes through, a lot of companies, for safety sake, will simply blackhole 127/8 and 0/8 at the edge. Simple and effective... except for all the poor users/services who end up using those IP's and can't get to half the internet.
If I had to pick one proposal I'd say that one is the most "bang for the buck" and probably the only one worth implementing. The others don't represent enough addresses to be worth doing - for the same reason trying to take addresses away from early adopters who got Class A blocks doesn't make sense: any individual block is "only" 16 million addresses so even if you could take them all back (you can't) put together they are smaller than this single /4 being proposed. The other proposals similarly represent fairly small allocations (eg /8) or are scattered among all networks (the .0 multicast address) so they won't make much of a difference.
But making 268 million new addresses available? That seems worth doing!
I would argue that this is harmful. IPv4 addresses becoming expensive is what's finally convincing the bean counters to care about IPv6 adoption. The IPv4 market has effects analogous to a carbon tax on climate change.
Imagine how quickly we'd roll out IPv6 if IPv4 net owners had to start paying a small yearly fee which would be collected in a big fund that ISPs and other infrastructure providers could request grants from to finance their IPv6 transition.
If 240./4 become available, ICANN should sell cheaper (or free) for relatively new service operators especially in developing world, rather than tech giants in the US.
As I mentioned below, this is just one of four proposals that we're making at IETF about reclaiming unused IPv4 address space. The other three proposals are
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
In each case, the address space in question was reserved a long time ago (during the 1980s) for reasons that have not proven necessary or that are no longer applicable.
It is indeed a big undertaking to change this behavior everywhere, but we propose that it will be a gradual process. It turns out that 240/4 is already widely supported (implementers liked the idea when it was previously proposed at IETF in 2008), while we've also gotten patches into Linux for the 0/8 and lowest address behavior, and now in FreeBSD for the lowest address behavior as well. (The lowest address was originally reserved for an "alternative broadcast address" because 4.2BSD chose it as the segment-directed broadcast address in 1983, before there was a standard to say which address to use for this purpose.)
There are lots of other complexities and history that I'm happy to talk about if people are interested.
The amount of IPv4 space still "reserved for future use" in 240/4 is 2²⁸ addresses, or 1/16 of all of IPv4!
Edit: people who are especially interested in this topic can also watch me presenting on this for 15 minutes at IETF112 last week.
Please don't do this.
1. You're using a labor intensive bandaid instead of solving the fundamental underlying issue. Apply this energy to IPv6 adoption rather than building a faster horse.
2. You're going to patch OS's, but the net is powered by a bunch of old unmaintained gear and reality will not match your expectations. Look at the number of vulnerable routers in developing countries for an example of unmaintained gear.
3. The problems around what you're doing are going to manifest in destructive ways. Primarily users of the new block being unreachable, and users of the new block being DDoS'd when they are reachable.
Furthermore, I don't think this brief draft fully explores the consequences of making this change. It would require real-world testing of a lot of gear in the wild, in combination with backbone router behavior, to fully understand the consequences of doing this. The proposal shifts the responsibility of doing that testing, or accepting the consequences, onto operational staff and teams, which is unfair and creates a lot of work and late nights for those teams.
I'd also point out there is a non-zero risk that the global intelligence community will take an interest in acquiring, or commandeering, some of this address space to capture the junk traffic it will receive once live.
This isn't unused address space. It is, and should remain, unusable address space.
Regards,
Mark Maunder.
Just as a heads up, zero in the last octet results in general reachability problems. We used x.y.z.0 as a vip at Facebook^WMeta for a while, but learned the hard way that some people can't reach those ips.
Some additional info from RIPE: https://labs.ripe.net/author/stephane_bortzmeyer/all-ip-addr...
http://ec2-reachability.amazonaws.com/
which puts many of the test hosts on .0 addresses.
There was also a NANOG thread talking about this phenomenon.
Decades-old standards do call for interoperability with a distant host whose address ends with a zero octet, so in theory there should be some interest toward cleaning this up on that basis alone.
If you have some more data or examples or suggestions for where to find them, I'd be happy to hear about it.
RIPE Atlas can be useful for testing (my node just hit its 5th birthday!), but this might be something better tested with random clients. If you can convince someone running a speed test site to include a .0 test, that may be a way to get a little more coverage; or if you have budget, you might be able to make something work with web ads that beacons to a .0 and a .something else, and count the returns, etc.
EDIT: I hadn't seen the EC2 reachability test; it's got some nice test addresses like 100.24.0.0 and 107.22.255.255, so that seems pretty comprehensive. It would be interesting if someone at AWS can share statistics on if there are significantly fewer images loaded from .0/.255 addresses than otherwise; and if they can narrow that down by AS or otherwise. Publicly would be great for my knowledge, but at least sharing with the ietf would be useful for decision making.
Agreed. I think D-Link devices were some of the most common we saw.
I'll be honest, I have misgivings about this one.
Mainly: 1. Old Operating system configurations -> if this is solved with routing changes well great! 2. Poorly coded programs leaking data -> this one is the main point why I think this is a bad idea: 127.X.X.X has always been the bastion of inside MY computer and nowhere else.
I get why this is an idea, but shouldn't we create a new IP system that people actually want to use?
And for the record, yes I know IPv6 is a thing, but it has been a LOOOOOOOOOOOOOOONG time and we still aren't using it.
Maybe we should make IPv8 which is compatible with IPv4, and has sane notation that I can actually make sense of.
Anyway good luck with your proposal.
It's my understanding that IPv6 is essentially that, and not just a move to a 128-bit address space
And if you need to change it, why keep all the broken parts of ipv4, if you can fix them (atleast partially), like we did in ipv6?
I'm serious. This is great work, very practical with little downside.
After 10 years of headlines that we have "run out" of IPv4, the reality is that free IPv4 is gone, but there is a real market for IPv4 (and that means there is still availability).
One question I've had is around DoD ranges. I haven't followed this closely but they seemed to be sitting on excessive quantities.
The unfortunate reality is that given the crazy IPv6 model and approach IPv4 is going to be with us a for a few more years.
Another idea I had was a a $2/year fee per IP fee, this would make sitting on large blocks as a speculation exercise less profitable.
They have 14 /8 blocks though - wow.
I worked at an ISP in a previous job where we ran out of RFC1918 space, and were squatting on UK MoD/DoD/other IP space for internal traffic because we simply had no more IP's to assign within RFC1918.
It was a bad situation when one of those ranges we were squatting on suddenly became used and customers were unable to reach certain services...
https://www.iana.org/assignments/ipv4-address-space/ipv4-add...
it looks like 6/8, 11/8, 21/8, 22/8, 26/8, 28/8, 29/8, 30/8, 33/8, and 55/8 are allocated to organizations that are part of DoD. That comes to ten /8 allocations. Am I missing some?
Dang.
Even folks like google with more money then god and more experts by far than anyone else likely has had some struggles getting their GCP offering alone fully IPv6 enabled.
After enough years I've learned that anyone who says IPv6 is simple probably hasn't actually tried rolling it out?
Note I haven't explored IPv6 in Azure, perhaps Microsoft has had an easier time going full native IPv6 in their offering there.
Or what about getting 1 or even a few static IPs from your ISP? Oh right - also a nightmare. There apparently are both plenty of IPv6 IPs but at least in the US can't even get 5 static ones for home use.
I've got a static /48 from my consumer ISP here -- it sounds like your complaint about that is more about US ISPs than IPv6.
Also, most ISPs (probably not the phone carriers) when giving you IPv6 give you a /64, so you get 2^64 (18,446,744,073,709,551,616) addresses. Which if you're anti-corporation, gives you a lot more room to play with than a single IP that you'll need to NAT behind.
CONSUMER gear should be getting at least /56 to the internal network, and Business grade should probably get at least /52. Which is almost what RIPE recommends (up to /48 for business customers, and /56 for normal users). https://www.ripe.net/publications/docs/ripe-690
A couple weeks ago I was setting up a new home Internet connection with an add-on /29 and spent a little time trying to find out WHY the lowest address was reserved, since every address is precious at that scale, and didn't turn out anything satisfactory. So thanks for that timely nugget of knowledge.
The amount of not fully compatible software with potential security implications this produces is outright insane.
Is IPv4 spare: Yes.
But there is NAT or IPv6.
So the only reason for that IMHO high risk proposal is companies not getting their shit together in adapting a standard which was introduced ~25!! years ago. (I'm looking at you cloud provider without proper IPv6 support.)
Also, what would be the security implications of this? The best I can come up with is networks that treat these addresses as internal and services inside trust them by default, but such networks wouldn't allow this traffic from the WAN side anyway, right?
Not quite, all you need is to make sure the proxy/CDN is dual stack, like what this IPv6-only hosting service did: https://www.mythic-beasts.com/order/rpi/
Cloudflare, for example, does this for free: https://community.cloudflare.com/t/proxy-ipv4-visitors-to-ip...
The "proxy" can outsourced or manged on-perm and does not have to be shared with anyone. This "proxy" may or may not be a L7 proxy that only understands HTTP.
I run my own proxy for HTTP(S), SSH, SMTP and DNS. It took me about 1 hr to set it up. Only 4 IPv4 address are used for my whole stack, the rest are all IPv6-only.
We do use 127.#.x.x on both client and server-side for IP-ifying IIoT sensor and controllers for reverse-proxying; where the second octet signifies device type and we use a whole bunch of them.
I will object to this everywhere that I can. This is just plain wrong to assume one can just take the space back.
I also got your e-mail that you sent to me and my co-authors.
People might be confused by the "ietf.org" in the URL, but this document is a draft, with the status of a proposal, not an IETF standard. Anyone can propose an Internet-Draft at IETF. Each of our drafts refers to "formerly reserved" address space because that will be the status of the address space if that draft is adopted.
Hearing about existing uses of all of the categories of address space that we are proposing to unreserve is useful feedback to inform the conversation. For example, we are also proposing to unreserve 240/4. There are existing unofficial private uses of 240/4. We know a little bit about them, and we would love to know more about them.
Unlike the prior attempts to unreserve 240/4 at IETF back in 2008, our drafts not only do not take a position on an allocation procedure or timeline, but are also silent on whether the proposed unreserved blocks should be used as public or private IPv4 address space. A possible outcome for 127/8 would be to formally designate it as a new kind of private address space (which is no longer assumed to have host scope). That outcome might be compatible with uses like yours and might even be useful because it would bring other devices' behavior more in line with your use (I don't know if that's the case offhand, because I don't know whether your setup sends packets with these addresses over the wire, or just inside of tunnels).
When we propose a change like this, or when anyone proposes a change to protocols at IETF, we are asking for feedback and also for more information about existing use cases that are affected, positively or negatively, by the proposal. We might not abandon the proposal on the basis of negative impacts (for example, there is also a negative impact to the reference implementation of ntpd, which uses 127.x.y.0 to communicate with drivers, but we believe that it's easy to change this in ntpd since other implementations don't use the same mechanism), but we would at least consider modifying it, and information about specific impacts could also inform IETF's conversation about the proposal.
We (and lots of other people) have also proposed OS changes in advance of standards changes, but there, too, we are mindful of not wanting to break existing uses, and there, too, knowing about existing uses is helpful. Overall, I think your claim that we "assume one can just take the space back" is too strong.
127.127.x.y, for what it's worth (cf. any of the individual "Type n" reference clock drivers' documentation pages linked from [0]).
> ... but we believe that it's easy to change this in ntpd since other implementations don't use the same mechanism
How easy do you believe it is to change (update) all of the dozens or possibly even hundreds of models of "embedded devices" (i.e., so-called "appliances" and such) built on or around ntpd that are deployed throughout the world but upgraded only rarely, if ever?
(ntpd (i.e., the reference implementation) is slowly dying anyways, but that's beside the point.)
One of the few benefits I can see from this proposal is that someone -- or a handful of someones, perhaps -- will make a nice sum of cash when they sell their future allocations (from 127/8) to AWS.
With my network engineer hat on, I'd also be against this proposal and would rather see the resources spent migrating to IPv6 instead.
---
https://github.com/WordPress/WordPress/blob/9d4d3f8fba13be09...
Time has taught us that the mass adoption of IPv6 will not happen until it becomes a painful necessity, so there’ll probably many more years of desperate measures like these to come.
This is going to be a huge PITA for network and security people because of all the apps designed as if the local-ness of 127/8 was carved in stone.
So that means lots of connections on localhost, but you run into difficulties with managing ports unless you listen on multiple ips. Strategically picking the IPs to listen to helps reduce lock contention in the tcp stack as well. IIRC, I think we used 127.0.X.1 (which would be compatible with this proposal), but I no longer have access to the specifics.
The single loopback address of IPv6 is kind of insufficient, but there's not a whole lot of need for IPv6 over localhost, so if I ran into limits, I'd just use IPv4, or even use one of the IPv4 in IPv6 space mappings with IPv4 loopback addresses.
OTOH, if they're looking at opening up 127/8, why not also open up 0/8 (other than 0/24) and the class E 240/4 (other than 255.255.255.0/24)? There's some use of class E addresses[1], but I don't think it's that much more of a disruption than 127/8.
[1] Cloudflare uses them as Pseudo addresses for IPv6 transition, and I think I've seen that elsewhere too. https://blog.cloudflare.com/supporting-the-transition-to-ipv...
That's exactly what we're proposing! This draft is just one of four drafts. The other three are
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
This psychotic idea requires you to touch every stack out there. If you're going to touch every stack out there, then JUST DEPLOY IPV6 ALREADY.
But nearly "every stack" already supports IPv6 at a software level. Most of them have for more than a decade.
I'd agree that, given a choice between implementing software support for any of our proposals in some platform and implementing software support for IPv6 in the same platform, it would be obvious that the latter should be a higher priority. But I've been trying to find platforms to which this would actually be a relevant consideration. So far it seems like the answer might be "a few CPE routers, and a few IoT software stacks". If anyone knows of more than this, I'd be glad to hear about it.
More generally, I don't understand a way in which the behavior of "stacks" that could conceivably be updated is an important barrier to IPv6 adoption. Every device on my LAN, except the printer, already supports IPv6 well. I think my router does too. My ISP doesn't. We can't fix that with software upgrades.
But we can fix that by not taking measures to increase the supply of IPv4 addresses. Scarcity makes IPv4 expensive, which then creates market pressure to deploy IPv6 sooner.
For example, your ISP might notice that they hold valuable IPv4 assets, and migrate their network to IPv6+CGNATv4 in order to sell some of them off.
I'm of the general opinion that doing so would be a really bad idea. Let's focus our efforts on v6, not on efforts to delay v6.
What is the strategy? IPv6.
Why does this disincentivize implementing the strategy? Because it prolongs the life of the dead-end incumbent.
This is like a design for a more efficient coal power plant. It may be ingenious but it’s still funnelling investment away from the actual goal.
If this is to make it suitable for unicast use over the internet, how long is it expected before infrastructure is going to work with that, and why is it better to force this sort of externality on people rather than just moving to IPv6?
Making 0/8 "just work" took an hour and some testing. Ripping out the check for that reservation saved a nanosecond. And: 240/4 had been working for a decade, and nobody noticed.
What I mentally see as a possible use for 127/8 (with 127/16 still held in reserve) - is the really painfully untransparent string of vm -> container -> OS -> offload engine that we have little insight into today.
It seems kind of silly to undergo this endeavor, instead of adopting IPv6. We are simply staving off the inevitable with these extensions people keep proposing.
I guess the best thing to do would be to somehow limit ISPs in how many IPv4s they can purchase while letting everyone else use the newly-abundant addresses, but I don't think the legal structure for that even exists.
ISPs don't need more v4 addresses. If anything, they need fewer of them.
As for security issues, I think they could be shaken out with a transition period. In the first phase, ISPs would treat any attempt to use 127.{1 through 255}.x.x would be a hard error instead of a loopback connection, and none of the addresses would be assigned. So anyone using these addresses and expecting loopback would start seeing errors.
In the second phase, some subset of the space would be made available for assignment and the majority of it would still be a hard error.
Finally the whole thing could be opened up. At that point, we might find that some old devices won't connect to servers that have one of the new addresses assigned.
For an IoT device, probably no problem, as long as the host it 'phones home' to is in the legacy IP space.
Old Android devices that no longer get updates might be unable to connect to servers that use the freed up space.
Those addresses will never actually work globally. Not really. Che long tail in really long.
And they buy what, two months?
Years ago the rate was one /8 per three months IIRC.
Also I've seen those addresses used in Telco gear.
Who would want these addresses?
This also applies to 240/4. It's much less work to fix the networks to support IPv6 than it is to fix them to support class E. And so much easier to know that it works.
There are literally billions of devices (from enterprise routers to cheap crappy CPEs) that will never get update, and which have some sort of bogon filtering enabled, blocking the forwarding for the whole 127/8 range. Having a server there, means a lot of customers won't be able to reach it, and having end users in that range, means that a lot of servers won't be accessible.
127.0.0.0/8 is just there.