Router problematic ranges - 127/8 and 224/4

[dfawcus]

A number of routers "know" that all of 224/4 is multicast, and have this burnt in to silicon. If packets with such a source are received, they may well be dropped. Similarly if packets with such a destination are received over ethernet in unicast frames, they may well be dropped.

Likewise a lot have hardcoded the "illegal" nature of 127/8, and currently drop packets to/from such ranges - again some of this is burnt in to silicon.

Also some cisco devices, switches I think, use (or used) sub-ranges of 127/8 to number links for internal connectivity, possibly in management VRFs. This could be seen in the output of some of the "show" commands. This was "safe" as long as such were filtered out when seen over the wire.

Now these devices may no longer be currently shipped (I don't know), but these two ranges would probably take a long time to become usable in practice, as for many users traffic to/from such ranges will simply be dropped.

Hence even if free'd up, few people would want addresses in those "unusable" ranges. Or maybe they might not become usable before IPv4 dies.

[dtaht]

dfawcus notifications@github.com writes:

Delighted to see some feedback on this!

A number of routers "know" that all of 224/4 is multicast, and have this burnt in to silicon.

We would like to know of more routers that have this burnt into silicon. So far we have not found any. Firmware and bogon files, yes. Do you have a specific example we could acquire?

If packets with such a source are received, they may well be dropped. Similarly if packets with such a destination are received over ethernet in unicast frames, they may well be dropped.

Likewise a lot have hardcoded the "illegal" nature of 127/8, and currently drop packets to/from such ranges - again some of this is burnt in to silicon.

Still in the search for specific examples.

Also some cisco devices, switches I think, use (or used) sub-ranges of 127/8 to number links for internal connectivity, possibly in management VRFs. This could be seen in the output of some of the "show" commands. This was "safe" as long as such were filtered out when seen over the wire.

Yes, a use for 127 seems to be in formalizing this usage.

Now these devices may no longer be currently shipped (I don't know), but these two ranges would probably take a long time to become usable in practice, as for many users traffic to/from such ranges will simply be dropped.

Tend to agree. My own "best" use case for the 225/8 through 231/8 spaces include a drive to make a larger CGNAT space, which would then drive changes to allow the other ranges to be used conventionally, over time.

230/7, perhaps, for that.

This would muck with traceroute for devices attempting to traceroute without support but would otherwise be invisible along networks like this, with only a limited number of devices needed to support it at all.

We don't expect this to be anything less than a 5-7 year plan.

And in the case of overlay'd or SDN networks, these addresses already "just work" on amazon AWS.

Hence even if free'd up, few people would want addresses in those "unusable" ranges. Or maybe they might not become usable before IPv4 dies.

What's your best estimate for ipv4's death? We've tried very hard to get more people to read the icann report cited on the first two slides of this:

https://github.com/dtaht/unicast-extensions/blob/master/docs/IPv4%20Unicast%20Extensions3.pdf

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[uzlonewolf]

We've tried very hard to get more people to read the icann report cited on the first two slides of this

Repeating a lie over and over does not make it true. That "quote" you have on the 2nd slide cannot even be found in the cited report. In fact the actual report says:

Another issue that emerged from our modeling exercise was that once the IPv6-only traffic ratio among IPv6 deployers reaches a certain level, their IPv4 address requirements start to decline. These operators can therefore release IPv4 address resources into the market that would alleviate shortages and facilitate continued low levels of growth for legacy IPv4 networks.

As more and more IPv6 is deployed, the huge cloud service providers which host most of the publicly-available content will require fewer and fewer IPv4 addresses, leaving them available for end-user networks who need them to access legacy applications. This shift of traffic to IPv6 also means CGNAT has an easier time handling the remaining users which again lessens the demand for IPv4 addresses. If companies would stop going "but we have plenty of IPv4 addresses and so we don't need to deploy IPv6!" and actually deploy IPv6 instead the demand for IPv4 addresses would shrink and this effort wouldn't be needed.

[dtaht]

I am glad you read the report and are willing to discuss it. The second quote came from the igf summary.

There are nuances, let me give three responses.

As more and more IPv6 is deployed, the huge cloud service providers which host most of the >publicly-available content will require fewer and fewer IPv4 addresses, leaving them available for >end-user networks who need them to access legacy applications.

0) Needing fewer and fewer IPv4 addresses in the face of a growing internet is a bit unproven. We certainly are doing a much better job of reallocation since we ran out. Of course with ugly things like double or worse nat, cgns, dslite, etc, etc.

1) There is zero sign that any cloud provider will ever be willing to give or sell anything back. A monopoly position is better to have in any game theory model. Certainly most current class A holders have not been running to the auction table either. I do kind of expect market forces to rise to the point where we see effective shifts here.

2) I'm not (speaking for myself only) hugely fond of handing all control of the ipv4 supply to the cloudy providers. I'd rather be enabling new service entrants and transport ISPs to still interconnect with the rest of the internet. 0/8 (for example) is more ipv4 addresses than google, facebook, and amazon, combined.

This shift of traffic to IPv6 also means CGNAT has an easier time handling the remaining users which again lessens the demand for IPv4 addresses.

I'm not huge on cgnat either! I'd like more globally routable real IPv4 addesses.

If companies would stop going "but we have plenty of IPv4 addresses and so >we don't need to deploy IPv6!" and actually deploy IPv6 instead the demand for IPv4 addresses >would shrink and this effort wouldn't be needed.

This a 20 year old argument. I'd really like those making it, to work harder on deploying ipv6 to the edge and on more embedded devices. Notably all kinds of tools still need love - dns especially - to IPv6 a usable reality in the home and small business. We'd worked really hard in the cerowrt project to turn a bunch of ietf specs into a deployable reality, and those changes fed back into openwrt, and from there 10s of millions of edge devices now have pretty usable ipv6, but since then investment into useful stuff has lagged.

Personally, I find it tremendously annoying and disabling that I still, after years of trying, cannot get a static ipv6 address range from my provider, and that netflix started blocking my 10+ year old hurricane tunnels that I had deployed, forcing me to entirely disable ipv6 across my campus last year. I have no good, reliable method of dynamically assigning the addresses I get from comcast , still.

My complaint is not really relevant of course to "making more ipv4 addresses" - the amount of effort required is trivial, the effect on long term supply potentially helpful, and that's why we're doing it. Cynically, IF this project becomes a thing, I figure it will drive adoption of newer OSes that ALSO have better IPv6 support, which will accellerate IPv6 adoption.

One of the other things in the report of note is that ipv6 transition puts the burden of the transition all on the transitioner.

[cwawak]

Re: routers that treat 127/8 specially,this report shows a list of historical vulnerabilities for residential routers. Netgear has 300+ models with vulnerabilities. Is Netgear engineering updates for hundreds of CVEs on hundreds of models of routers years after release? My personal experience of abandoned support for routers says they are not. So there will be some subset of devices on the internet that will break with this change IF these routers don’t handle the changes well.

Has there been testing with old routers to see what happens if changes are made to 127/8?

If these old routers truly don’t care about 127/8, then there’s no valid reason to maintain the space other than “that’s how it’s been”. If, however, these old routers freak out at this new space being used, it will be far more complex to break the network and open the addresses up.

[MDJRosenau]

Still in the search for specific examples.

Take the Ethernet IC (with built-in IP stack) on the Arduino Ethernet shield. Afaik such ICs do not support software updates.

We don't expect this to be anything less than a 5-7 year plan.

IPv6 is mandatory for 11 years now and many servers and many internet accesses still do not support it. I see absolutely no reason why your proposal should take less time.

Today, many server operators and internet access providers do not support IPv6 although it is mandatory for more than 10 years now. They would not support 240/4 (nor 127.128/9 ...) for 11 and more years with exactly the same excuses!

And you cannot use an IPv4 address which is detected as "invalid" by all other computers in the internet!

And implementing your proposal would probably cause problems because there are programs that use some not-registered address in the range 224/4 for multicast (I have written such programs myself). And it is very probable that there are also programs using addresses in 127/8 (but outside 127.0/16) or 240/4 in a way not intended by the RFCs.

If one old program (old means: no more updates are provided) is sending multicast messages to 230.1.2.3 every 5 seconds and this program is still used by 10.000 people, the user of the now-unicast address 230.1.2.3 receives 2000 unwanted UDP packets per second.

I'm not huge on cgnat either! I'd like more globally routable real IPv4 addesses.

But 600 million addresses would not be enough to get rid of CGNAT:

Maybe each of the 5 RIRs would get 120 of the 600 million new addresses. 120 million would not be enough to get rid of CGNAT in the RIPE area (Europe and western Asia).