3 ms·

Unicast Use of the Formerly Reserved 127/8

7 points by greyface- 5y ago

progbits 5y ago
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 https://datatracker.ietf.org/doc/html/rfc1700: Page 4 "Internal host loopback address. Should never appear outside a host."
- danw1979 5y ago
  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 ?
  - progbits 5y ago
    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.
- dtaht 5y ago
  A host nowadays consists of one or more vms, piled on top of a container, piled on top of a hypervisor.
zamadatix 5y ago
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.
- dtaht 5y ago
  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.
op00to 5y ago
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.

7 points by greyface- 5y ago

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 https://datatracker.ietf.org/doc/html/rfc1700: Page 4 "Internal host loopback address. Should never appear outside a host."

danw1979 5y ago
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 ?
- progbits 5y ago
  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.
dtaht 5y ago
A host nowadays consists of one or more vms, piled on top of a container, piled on top of a hypervisor.

zamadatix 5y ago

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.

dtaht 5y ago
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.

op00to 5y ago

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.