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.