Hacker News new | past | comments | ask | show | jobs | submit login
Unicast Use of the Formerly Reserved 127/8 (ietf.org)
75 points by todsacerdoti on Nov 16, 2021 | hide | past | favorite | 85 comments



While I appreciate the concept behind this. It's all just slapping duct tape on a sinking ship rather than stepping over to the brand shiny new ship thats right next to us.

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.


Well the 240/4 block does represent around 6.7% of the total IPv4 address space (268 million addresses) and is already supported by almost every OS except Windows. That's a significant chunk of addresses that can buy some breathing room for cases where IPv4 addresses are truly necessary while greatly reducing or possibly eliminating a market for selling such addresses for a time - a positive in my view.

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!


> while greatly reducing or possibly eliminating a market for selling such addresses for a time

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.


The difference with a tax of course is that the money goes into the pockets of traders instead of anyone who, well, does anything beneficial. A tax not only makes bad behavior expensive, but funds remediation efforts (a carbon tax usually funds renewables research, for example).

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.


Agreed. This is just a mitigation so it should mitigate correct problem. IMO it's a problem that new service operators can't get enough IPv4 addresses for cheaper. It's inequality.

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.


APNIC actually provide discounts if you are from a developing economy. However, in practice, I see huge amounts of abuse from this, people registering space for half the price then immediately leasing it for out of country use, etc.


Hey, I'm the lead author of this draft!

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.

https://youtu.be/cqPVdBvgiXI?t=409


This is a bad idea. In the way of background, I worked as an ops engineer (MCSE and CNE) in the early to mid 90s migrating from IPX to TCP/IP. Then as a developer from 1998. Then as a tech entrepreneur from 2003 onwards. I've created highly scalable and very popular applications and am currently the CEO of Defiant Inc which is a cybersecurity company that employs 40 and protects over 4 million websites.

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.


> draft-schoen-intarea-unicast-lowest-address-00

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


Thanks! I've done my own testing more recently with the same RIPE Atlas infrastructure and the results were more encouraging. A good test for this is the AWS EC2 reachability test

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.


My anecdote is much older, but problems with reachability on .0 addresses was reported at Yahoo as well; I think .255s also had issues, so even in wider than /24 subnets, vips would not be assigned with last octet 0 or 255. From what I recall, it seemed to be CPE like modems and sometimes wireless routers that were blocking packets to (or sometimes from) the .0 and .255 addresses, usually under the guise of security; but it didn't seem to be ISP routers, or at least not often.

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.


> it seemed to be CPE like modems and sometimes wireless routers that were blocking packets

Agreed. I think D-Link devices were some of the most common we saw.


Hi,

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.


I honestly don't know why we don't just have "IPv5" which adds an octet to the front of IPv4. Everything on the internet now would be 0.a.b.c.d and everything else would use 1-255.a.b.c.d


Because that's basically what v6 did. It just added enough octets that we don't need to turn around and do it again immediately afterwards, since deploying new L3 protocols is hard enough as it is without needing to do it twice.


That doesn't solve the fundamental problem of IPv6 adoption: _all_ equipment along a network path needs to be updated to be compatible with the new addresses for them to be usable.


Yeah, and if we're going to be changing all of the equipment, why not take the time to smooth over some of the other known warts besides address space?

It's my understanding that IPv6 is essentially that, and not just a move to a 128-bit address space


This means changing every piece of network equipment everywhere.

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?


Fantastic.

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.


It's also possible that DoD is using its ranges but not publicly announcing routes to them.


Which would be a good situation for private address ranges.

They have 14 /8 blocks though - wow.


It's much easier and nicer to use globally unique addressing if you've got it than to set up multiple NAT's just to allow different sites to re-use the same private IP space.

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


Let's see, according to

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. I thought as one of my last actions as the DISA.MIL Technical POC in 1995, I had successfully turned 22/ back into the NIC, so that it could be re-assigned to someone else who needed it. When we swept that address space repeatedly, we sure didn’t see anyone actually using it.

Dang.


At current prices .mil selling off 22/8 would net them at least 2 F-22s. Not quite the same as selling off tsla stock, but...


There's nothing crazy about v6's model -- or at least nothing that isn't also crazy in v4, since v6 uses almost exactly the same networking model that v4 does.


Have you tried implementing ipv6 in a medium to larger network?

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 didn't say it was simple, just no harder than v4. In many ways it's easier in practice because you don't need to also use NAT on top.

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.


I admire your optimism about how quickly this could be reliably routable on the Internet. Unless by “gradual” you meant 20-50 years.


Does this work help humanity or corporations? Could a large portion be given to the commons instead of sold to the highest bidder? Could we reinvent what the internet means and use this capacity for public and shared municipalities ran by the people for the people?


Not in any way that IPv6 doesn't. Most internet users are using their phones these days, and most carriers (at least in the US) give you a IPv6 address. And more and more ISPs are getting their heads out of their collective butts about getting IPv6 support now that it's getting expensive to buy IPv4 addresses.

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.


Why can't they give me a proper /56 so I have at least 256 addresses to play with on the part that's intended to be used for prefix delegation? Even Comcast Business allocates a /56 but the stupid modems they require you to lease to use that service reserve 4 more bits of that so you only really get to operation on a /60.

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


/64 is actually pretty useless since you can't automatically allocate anything smaller than that. If I want to give each host on my net a bunch of addresses (maybe /72) I have to do that manually - DHCPv6/RA/whatever will straight up refuse to allocate anything smaller.


You sure DHCP can’t do that? That surprises me given how many options it has. Maybe your server implementation just can’t.


the zeroth draft gives folk with an allocation a free new IP address.


So what you're saying is that the IPV4 internet has been placed under Business Rescue and as a result we're legally required to squeeze out every last drop of usable addresses.


> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...

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.


Please no.

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


Are cloud providers really an issue here? If you as a service provider want IPv6 and your hosting provider doesn't support it, you can relatively easily switch. But if your users don't have IPv6 (and many don't), you're basically screwed - you can't change your users' ISPs and they certainly won't either.

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?


> if your users don't have IPv6 (and many don't), you're basically screwed

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


You're making a lot of assumptions about people's stacks. Not everyone is running behind a third-party proxy. There are many reasons not to do so and many aren't up for debate (like regulation compliance). And that's ignoring the fact that most protocols aren't like HTTP and don't know a thing about hostnames, so the only way for a "gateway" to exists is using different ports - something that isn't always possible and may require a lot of work to adapt to.


I only said this "proxy" need to be dual-stacked. This "proxy" or "gateway" or whatever refers to the public facing part of the their stack -- if they don't have a public facing part then they don't have this problem.

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.


NO! Please do not distract people from converting to IPv6.

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.


Hi Cetin,

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.


> ... there is also a negative impact to the reference implementation of ntpd, which uses 127.x.y.0 to communicate with drivers ...

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.

---

[0]: https://doc.ntp.org/archives/4.2.8-series/refclock/


It's common for outbound traffic to 127/8 to be blocked, at the application layer, to prevent SSRF. For example, in WordPress:

https://github.com/WordPress/WordPress/blob/9d4d3f8fba13be09...


There are so many embedded systems that assume so much about 127/8. I don’t understand what industry is driving this that can’t simply look to ipv6…


More desparate measures to stave off the inevitable IPv4 address shortage.

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.


Contrary to probably most people, I've actually got experience using a lot more than 127.0.0.1. I needed to support an HTTPS service built as a TLS terminating proxy plus an HTTP server on the same machine, the HTTP server didn't understand unix sockets, and the required max connections goal was 1 million; it would have probably been faster and more effective to teach the http server how to do unix sockets or how to do TLS efficiently, but there was organizational opposition to both at the time. Of course, both are now options.

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


> 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, but I don't think it's that much more of a disruption than 127/8.

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


For IPv6 you could always generate a ULA and you'd have enough IP's to assign to a loopback interface to last you multiple lifetimes. The fact that ::1 is the only loopback address is not really an issue.


Isn't it a little early for April Fools?

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.


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


Your ISP isn't going to change its ingress or egress filtering of 127/8 either. Not in any reasonable amount of time.


> My ISP doesn't [support IPv6]. 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.


But you can slow it down by making more v4 address space available.

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.


I think the author deserves credit for engaging civilly and productively with critics in this thread, but I personally believe that no matter how solid the engineering, the solution must still be subordinate to strategy, and any initiative that disincentivizes implementing that strategy is harmful.

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.


I can empathize and see the motivation behind the intention but question the feasibility. If it has taken this long to partially implement ipv6 and other IP implementations like ipv10 [1] are suggested as workarounds, then making the existing 127/8 routable would be a herculean task that I can not even imagine being accomplished in the foreseeable future. There are hundreds of thousands of hardware and software stacks that make heavy use of the loopback network and not just 127.0.0.1. Some modern operating systems do have flags registry/sysctl that enable routing 127/8 with the primary use being the likes of GRE tunnels, name spaces for pods/containers/openstack, etc.. The software stacks on top of that will require changes, configurations will require changes, network gear will require changes, all the ISP's would have to agree to this. This may seem simpler than ipv6 but I would suggest it is not at all. I can think of simpler solutions but nobody would like the fallout from them.

[1] - https://news.ycombinator.com/item?id=15190097


This really seems to gloss right over the idea that pieces of software use this space internally. ntpd still uses pseudo-addresses in 127.127.0.0/16 to configure refclock addresses.

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?


We should really be spending more effort on making IPv6 ubiquitous and less effort on making it easier or cheaper to keep using IPv4.


I'd like that too, having spent decades on 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.


Is it working, or is it mostly working with weird silent edge cases? (E.g. someone's secondary equipment has a hard-coded route for that prefix; the next router passes it on to the right place so no harm done, except if the routes shift in a particular configuration and then you get routing loops).


I note the 240/4 and 0/8 and especially zeroth ideas are the more viable of this bunch.

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.


When kube-proxy for IPVS tried to use 127/8 for network traffic it went all kinds of bad. I realize that this doesn't make as wide ranging of a change, but 127/8 is hardcoded in a lot of different places. It is going to take a LONG time before all those devices are updated.

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.


Nobody said "instead of". Until end users all have IPv6 at home and work, every provider of any kind of service (be it a website or whatever else) needs IPv4 addresses. Due to the shortage, that has become incredibly expensive, creating a huge inequality/barrier to entry. This is simply an attempt to provide enough supply to level the playing field while ISPs get their shit together and provide IPv6 to their users.

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.


We've already gone to an absolutely massive amount of effort to provide enough supply for a transition. What did we do with it? We squandered it.

ISPs don't need more v4 addresses. If anything, they need fewer of them.


Yes, exactly, ISPs need fewer, but the rest of us need more while they roll it out. Hosting things on IPv6 only is simply not an option yet if you need to reach customers.


This produces 16.7 million new IPv4 addresses. Won't save the world but it is something.

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.


Not worth it.

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.


Wow, I can't type. "The long tail is really long".

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.


It was up to about one /8 per three weeks just before we ran out, and I can't imagine there isn't a huge amount of built-up demand after 10 years of no new allocations at the top.


Who'd want an ip from this range?

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.


Dupe (or at least "should merge with the comments from") https://news.ycombinator.com/item?id=29245466 the URLs are different but they are both referring to the same document just different formattings of.


Getting more IPv6 loopback addresses would be nice in exchange. Every now and then it's useful to have more than one.


Generate a ULA range using the formula in the RFC, and you'll have your very own unique /48 you may do with as you please that is not routed anywhere and won't step on anyones toes even in the future.


That requires manually adding an ULA range to the lo interface. Having something standardized that will be available by default would make things much easier since you don't have to touch the system configuration from your application. It may be easy enough in a container where you have namespaced root/CAP_NET_ADMIN but you can't always assume that.

127.0.0.0/8 is just there.


You would need to manually add IP's to the loopback interface as well before you could use them to bind to, at least on anything outside of Linux where apparently all of 127/8 is directly useable without an alias required.


I haven’t seen mentioned on here yet that the majority (?) of modern Linux installations which use systemd have resolved listening on 127.0.0.53, which surprised me when I learned it recently.


Anything to extend the life of IPv4 is actively harmful.


Who gets the newly available address space?


Probably gets chunked out by RIRs (RIPE, ARIN,...), and given out to LIRS (technically telcos) in small chunks


Nope.


Why?


Having a mix of hardware and software which some was updated to know about it and some wasn't isn't just a nightmare in debugging usage but has potential security implications. Like you slipping through the firewall because 127._ is not blocked but the OS now sees it as outbound addresses.





Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: