Unicast Use of the Formerly Reserved 127/8 | Hacker News Reader

Unicast Use of the Formerly Reserved 127/8

datatracker.ietf.org

7 pointsgreyface-7 comments

Oof, remember all the complaints about broken things when ".dev" became a valid TLD? And that was never specified as something you could rely on.

Use of 127/8 goes back at least 27 years to RFC1700 [1], maybe earlier.

Just let IPv4 run out, force ISPs stuck in the past to upgrade hardware and let us finally move on.

[1] https://datatracker.ietf.org/doc/html/rfc1700: Page 4 "Internal host loopback address. Should never appear outside a host."

Nobody is going to want address space that might not be reachable through paths that contain older equipment that might blackhole traffic to it.

Am I overestimating the potential problem ? or maybe these addresses just going to be held back while the new standard gets adopted ?

Yeah - on one hand you would need to use this "quickly" to help with IPv4 exhaustion before it becomes irrelevant. On the other hand (as you said) trying this too quickly will just mean poor routability.

From the draft:

  The Internet community can use network probing
  with any of several measurement-oriented platforms to investigate how
  usable these addresses are at any particular point in time, as well
  as to localize medium-to-large-scale routing problems. [...]
  Any network operator to whom such addresses are made available by a future
  allocation will have to examine the situation in detail to determine
  how well its interoperability requirements will be met.

---

I now also see my comment above is quite negative. Don't get me wrong, the proposal seems technically neat and well researched. However I just don't see it as practical, and even if it was I wouldn't like it to happen and just delay the inevitable pain.

A host nowadays consists of one or more vms, piled on top of a container, piled on top of a hypervisor.

I'd support this for optional private deploy where you get to control and manage what was already using that space and conflicts are a local thing to deal with. I can't say I'm in support of the chaos that is expecting billions of internet endpoints to stay out of space that was permanently reserved for other use and expecting anything useful to come out of of the rubble. 1.1.1.0/24 was bad enough and that didn't even have the same standing or blast radius as 127/8 sans 127/16.

I've seen lots of 127/8 use for "next hop self" tunneling on network gear and of course lots of 127/8 use for local communication. You'd have better luck getting people to finish going to IPv6 than convincing everyone to change 20 year old configurations to new ones so someone else can deploy new stuff in the old space.

It's also interesting all 3 chose to represent themselves as being under the sole backing group of "IPv4 Unicast Extensions Project". I'm not sure if they either couldn't find support or didn't seek it such as with previous RFC's by the offers (e.g. stuff around bufferbloat). Either way it's disappointing to see standards track RFCs that haven't first sought/demonstrated wider opinion and support.

We have been at this, technically, for years and has been discussed in multiple forums prior to now. It's a done project for me (my primary focus is bufferbloat), as all the technical work I could do is complete and the core patches for 240/4, and 0/8 and zeroth in the linux kernel and BSD. The internet drafts are now submitted for consideration for standards track. If they fail to gain support, the existing and future usages of these ipv4 spaces will remain unstandardized.

Their reasoning that this is feasible is presupposed by the concept that “automated updates are commonplace”. As if there aren’t literal mountains of IOT and just plain internet devices that will never ever ever get updates.

Reply on news.ycombinator.com