11 ms·
Allow 0.0.0.0/8 as a valid address range
- digitalsushi 7y agoI could actually see us successfully inventing, and implementing, a multiverse concept for ipv4 to make these 32 bit addresses last another 40 years, as opposed to throwing these non-upgradable, hardcoded v4 devices out. And this is from a pure v6 evangelist. I'm complaining, not being optimistic.
- cicloid 7y agowow; that is actually one of those comments of the internet that makes you think. The thing here is cross universe communication and legacy hardware/software stacks. This sounds like a great mental exercise.
- solotronics 7y agoIf only this already existed: https://tools.ietf.org/html/rfc1918 https://tools.ietf.org/html/rfc1918
- skissane 7y agoA sort of "multiverse" concept can already be useful for IPv4 private addresses. I have to deal with multiple environments which all internally have the same 10.x.y.z addresses. So, 10.1.2.3 can be two different instances depending on whether I am connecting to environment 1 or environment 2. In practice, the distinction is based on which SSH jumphost I am tunnelling through.
- deleted 7y ago[deleted]
- justinsaccount 7y agosure, just prepend every address with some more bits to indicate which multiverse it's from. while you are at it you might as well add a lot of bits, say, 96 of them.
- hatsunearu 7y agoIPV6 is probably the worst "upgrade" to have ever rolled out and graced our world with its stinky existence. It's been a decade and IPv6 has barely entered the zeitgeist of the common internet user.
- sigstoat 7y agoi don't know what's in the "zeitgiest of the common internet user" but i'm pretty sure IPv4 isn't in there either. besides, https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
- easytiger 7y ago> It's been a decade and IPv6 has barely entered the zeitgeist of the common internet user. It has not been a decade! I remember printing out the draft spec in the late 1990s thinking that I have to get ahead of this curve. Twenty years in the making. I recall at the time thinking initially that the obscure nomenclature for addressing would be annoying, but that it clearly would be fine. What do I know. In 2010 hackernews luminaries predicted the ipv6 momentum singlularity here: https://news.ycombinator.com/item?id=1236048 https://news.ycombinator.com/item?id=1236048 The fact of the matter is very very large private corporate networks do not need more addressing space. ISPs use CGnats. Most home broadband routers|modems are junk. It is just a mess
- throwawaycert 7y agoMore than a quarter of Google's traffic today is IPv6. So apparently ISP's representing a quarter of their traffic don't consider the marketing oxymoron that is "carrier grade nat" an adequate substitute for IPv6...
- criley2 7y ago"as opposed to throwing these non-upgradable, hardcoded v4 devices out" Prepending bits wasn't a solution for the problem he discussed.
- 7y ago
- TylerE 7y agoIsn't that pretty much what we're already doing, since almost every device exists behind some kind of NAT?
- pushpop 7y agoAlso VLANs can create a “multiverse” of IPv4 addresses behind a single NAT. But since VLANs are a layer 2 concept it means you can in theory use them with IPv6 as well (albeit I’ve never personally tested that theory)
- wging 7y agoAre you describing something different from NAT?
- digitalsushi 7y agoYes, but I didn't imagine it very deeply; NAT is rather like a PBX, which rather necessarily provides only a subset of mappings to the Internet. (I suppose it is a math exercise what the perfect NAT would be, if the Internet were exactly two NATted networks facing each other). When I said invent, I was supposing we do invent one little extra bit to IPv4, wherein we default to this IPv4 Internet, but we could somehow specify another "universe" and simply have another entire IPv4 network, ad nauseum. Some proprietary routing topography would presumably exist as an inner layer, providing decades of new complexities, masking the implementation for naive ipv4 stacks that couldn't be updated. Those, could continue to exist unawares and perhaps very disjoint between "universes". Anyways, I am not an Internet architect, and this idea is entirely foolhardy since we have a perfectly good IPv6 universe to move into, one that barely has unpacked the moving boxes from the previous. I suppose all I meant, is that we might invest some more energy in IPv4 before we're really done with it.
- paulie_a 7y agoHardcoded ipv4 non upgradeable devices should be trashed. They should be actively blocked or redirected to a site that offers quality hardware (Cisco need not apply)
- paulie_a 7y agoPlease explain why I was downvoted? I'd actually like to hear why non upgradeable hardware with hardcoded ips are ok? Hell the equipment probably has hardcoded creds that are part of critical infrastructure too.
- LilBytes 7y agoWhy not start with the why of your own argument?
- paulie_a 7y agoBecause it's lazy development and 30 decade old throw away equipment that is essentially worthless should be fostered still. Rip the band-aid off and replace crappy hardware that managed to make the rest of connections terrible for everyone else My argument is to trash crappy equipment.
- kolinko 7y agoThe downvotes may be due to a way you formulate your arguments. Some people may see them as lacking in empathy and arrogant. You didn’t seem to take into consideration all the places where 30-year old equipment is still good, the reasons for why stuff is not uogradeable, nor people who cannot afford spending $100 for the new stuff.
- ggm 7y agoMakes sense. Also 240.0.0.0/4. small focussed change in code. getting the IANA process worked out with the IAB is going to take a bit more work. (from the experience with 240/4 where I tried with some others to author a draft)
- _eht 7y agoWhat are some resources to help support this concept move along?
- dtaht 7y agoDrop myself and the other project members a line and see the unicast extensions project on github. It is a trivial number of patches to enable all the open source code in the world to work.
- rixrax 7y agoWhile at it, I feel like we could also squeeze the 224.0.0.0–239.255.255.255 multicast range to maybe 224.0.0.0/8 if not tighter. For reference here is a list of reserved ipv4 addresses[0]. [0] https://en.m.wikipedia.org/wiki/Reserved_IP_addresses https://en.m.wikipedia.org/wiki/Reserved_IP_addresses
- Aloha 7y agoThis would break a ton of existing applications
- simcop2387 7y agoThis can't be done, there's a number of devices out there that do multicast on fixed multicast IPs and so doing this would break them. In particular I've got a series of HDMI<=>IP devices that forcefully go to 239.255.42.[42..141] depending on their settings.
- Dylan16807 7y agoI wonder, though, how many of those fixed multicast IPs are outside of both 224/8 and 239/8.
- vesche 7y agoThis would be really neat. However, it might confuse or complicate some tools output (like netstat) that use the standard 0.0.0.0:80 style listening notation. That is if 0.0.0.0 becomes a valid address.
- floatingatoll 7y agoIt excludes 0.0.0.0/32, which is what “0.0.0.0” is when shown as a bare IP, so that will only be a complication if some tools (surely some do) assume that 0.0.0.0/32 is equal to anything in range 0.0.0.0/8.
- emersion 7y agoNo, 0.0.0.0 will still be reserved. >0.0.0.0/32 is still prohibited, of course.
- vesche 7y agoGotcha! I skimmed too fast. I'm all for it then.
- plange 7y agoFrom the commit message: > 0.0.0.0/32 is still prohibited, of course.
- OJFord 7y agoThe \*.0/32 is always excluded from usable address range anyway.
- Avamander 7y agoI see those bits being used in production happen but I seriously do not like the idea of giving IPv4 even more time.
- msbarnett 7y agoA single /8 isn’t going to meaningfully impact the exhaustion issues IPv4 faces. I believe it was APNIC a couple of years ago who said they were already facing allocation requests equivalent to an /8 a month. It’s part of the reason hand-wringing over some of the “wasteful” /8s that were handed out to organizations in the early days is largely pointless. Even if you could get those orgs to consolidate and give back large useable ranges in those blocks, there’s simply not enough there to meaningfully change the long term mismatch between demand and supply.
- eeeeeeeeeeeee 7y agoThis /8 won’t make a dent in that problem. Until every single device is capable of IPv6, IPv4 will continue to persist.
- OJFord 7y agoThis is a fantastic commit, contents aside, it's a great demo: the diff's tiny; the message is so much longer, and explains why the diff's there with even (very) historical context.
- edwintorok 7y agoUnfortunately IANA disagrees, it says it is still reserved: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml https://www.iana.org/assignments/iana-ipv4-special-registry/... "0.0.0.0/8 "This host on this network" [RFC1122], Section 3.2.1.3 1981-09 N/A True False False False True" The referenced RFC is the same one as in the commit message but different section 3.2.1.3 vs 3.2.2.7. Shouldn't IANA have lifted (or indicated its intention to lift) the reservation before the kernel change?
- azernik 7y agoGiven the seniority of the author and committer in the networking world, I assume that they're operating under the knowledge that IANA's reservation is being reconsidered.
- dtaht 7y agoWe have had many talks at many levels over the years. This is an attempt to break the logjam of finger pointing that ensued. We expect wide adoption of this and other ipv4 related patches over the next few years across the open source stacks... and then a standards dialog can take place. John Gilmore (creator of the unicast extensions project) was the co-inventor of bootp in 85, which is what made using 0.0.0.0/8 feasible, then. The fact that it's been feasible since and no movement in the standards orgs to fix it, has kind of been a record long wait from bug fix to deployment in both our cases.
- floatingatoll 7y agoIt’s reserved as a source, not as a destination, based on the table linked there anyways. Which implies some interesting things that aren’t as simple as “0/8 is reserved”.
- maltalex 7y agoI imagine this could break some existing code. Especially if IANA starts to actually allocate addresses from the 0.0.0.0/8 range. Luckily, this doesn't change the fact that 0.0.0.0/8 is still reserved by RFC8190[0] [0]: https://tools.ietf.org/html/rfc8190 https://tools.ietf.org/html/rfc8190
- anonymousiam 7y agoBy "this", I assume that you mean if people start using the 0.x.x.x block. My first read of your comment interpreted "this" to mean the new patch, which in fact makes Linux accept and work with this previously unusable block.
- gruez 7y ago>Especially if IANA starts to actually allocate addresses from the 0.0.0.0/8 range. Who's going to want to use that block? Given how many legacy devices are there on the web, it's probably not going to be reachable for a sizeable chunk of the internet.
- kabwj 7y agoThat’s the same thing they said about addresses in bogons ranges and eventually we succeeded in using them.
- exabrial 7y agoI still am under the opinion of srv records were widely used the ipv4 shortage could be delayed a very long time.
- inopinatus 7y agoI agree, and I and many others raised it repeatedly with the HTTP2 editors/mailing list in particular, who sadly murdered that proposal because they believe in their god-given right to squat the A record for their protocol. I believe the failure to address DNS considerations in the HTTP standard has driven a large part of ongoing IPv4 exhaustion.
- zonidjan 7y agoWhile I agree that HTTP (and everything else) should support SRV records, they wouldn't do anything for IPv4 exhaustion.
- inopinatus 7y agoI beg to differ. Having run LIRs and with friends at RIRs I know for certain that many large IPv4 allocation requests were justified on the basis of needing separate addresses for websites. Policy may be tighter now than it’s ever been, but the lack of aggregation due to well-known-port fixation drove and continues to drive unnecessary assignments.
- swinglock 7y agoShouldn't the HTTP 1.1 Host header invalidate that argument?
- inopinatus 7y agoMany people expected as much, but in practice not nearly to the extent that was desired, partly because SSL was a problem until SNI came along (and that far too late) and also because it comes after the TCP handshake, which precludes a whole class of traffic routing and service options. Fine for low-end shared hosting, not fine for many other applications.
- tobis87 7y agoTalk from the author: https://www.netdevconf.org/0x13/session.html?talk-ipv4-unicast-expansions https://www.netdevconf.org/0x13/session.html?talk-ipv4-unica...
- dtaht 7y agoThx for the pointers to the work and talks!
- unethical_ban 7y agoUnrelated to code, but related to IP space - there are at least two "reserved IP spaces" that look like they are completely usable by private networks, not included in RFC1918. 198.18.0.0/15, reserved for benchmarking devices across subnetworks. 100.64.0.0/10, reserved for carrier-grade NAT. This one might have the higher chance of a collision depending on your use case or if it's part of a VPN pool. Several ISPs I have tested all drop them when you traceroute. So if your organization can't switch to IPv6 internally and has performed horrible IPAM on RFC1918, here is a last chance... don't screw it up.
- zonidjan 7y agoYou could also (ab)use the TEST-NET ranges as private address space.
- jlgaddis 7y agoI've been (ab)using 198.18/15 (also reserved, cf. RFC2544) at home for years. It works just as any other network would and is a perfect solution for me. (Previously, I abused TEST-NET-2 and TEST-NET-3 and both of those worked fine as well.)
- inopinatus 7y agoIANA’s special-purpose address registries are the canonical reference. https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml https://www.iana.org/assignments/iana-ipv4-special-registry/... https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml https://www.iana.org/assignments/iana-ipv6-special-registry/...
- mindslight 7y agoIMO, device addresses are irrelevant - the real pressure is whether end users can get at least one public IP. NAT is actually a security feature. Not because it necessitates a stateful firewall (as is often believed), but rather because it hides specific client host addresses from servers. The last thing anybody should want is to leak even more information to the surveillance companies. The problems of IPv6's larger address space can be mitigated similarly to v4 while retaining some advantage - for example NAT onto random "host" address for 16+64 bits of saddr+sport rather than just 16 of sport. The point is that a flat address space isn't the RPC-panacea it was when protocols like "active FTP" were invented. In the modern world, blithely taking one's supposed L2 address and stuffing it into a higher level PDU is basically a layering violation.
- lathiat 7y agoAn inbound firewall for all traffic has exactly the same security level as NAT. There's a very small argument for privacy but (a) we have privacy addresses and (b) even behind NAT many of your devices are probably already identifiable in many other fingerprinted ways that obscuring the address for this sake would be pointless
- emmelaich 7y agoI wouldn't say _exactly_ the same security level. https://samy.pl/pwnat/ https://samy.pl/pwnat/ > pwnat, pronounced "poe-nat", is a tool that allows any number of clients behind NATs to communicate with a server behind a separate NAT with no port forwarding no DMZ setup, and no 3rd party involvement. The server does not need to know anything about the clients trying to connect.
- mindslight 7y ago> exactly the same security level as NAT. > There's a very small argument for privacy You can't say it has the "same security", while also saying there is a "small" difference. Privacy is an integral part of security, especially for natural persons. > we have privacy addresses AFAIK "privacy extensions" merely pick a random host address rather than naively using the ethernet MAC (!!). This still allows identifying discrete hosts. The NAT scheme I described is strictly better than this. So yes, I can envision an IPv6 future where we have convenient global addresses for incoming traffic, but outgoing traffic gets NATted to a single address (single probability distribution, really). It's just not going to be a return to the trustful 1970's air-out-your-genitals simplicity that is widely envisioned. > behind NAT many of your devices are probably already identifiable in many other fingerprinted ways that obscuring the address for this sake would be pointless Those other ways are also security vulnerabilities. We shouldn't excuse vulnerabilities because other vulnerabilities exist, especially in the direction of the foundation. While it is appropriate for a higher protocol to simply accept a weakness of a lower layer that it is built on, going the other way is unjustifiably throwing in the towel.
- buzzert 7y agoI wonder if there are any secret computers on zeronet!
- dingo_bat 7y agoI want my public ip to be 0.0.0.1. How cool it would be to be the first computer on the internet? Of course 0.0.0.0 would have been ideal but that's still reserved.
- tobis87 7y agoProposed draft: https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt https://raw.githubusercontent.com/dtaht/unicast-extensions/m...
- tobis87 7y agoThis even proposes the use of the zero node address in each network or subnet (6.1)
- p1mrx 7y agoThis will break code that uses (e.g.) 0.0.0.1 as a "fail address": $ telnet 0.0.0.1 22 Trying 0.0.0.1... telnet: Unable to connect to remote host: Invalid argument It's nice because the connect() syscall fails immediately, instead of sending packets and waiting for a timeout. 0.0.0.0 is not a suitable replacement, because it's interpreted as 127.0.0.1: $ telnet 0.0.0.0 22 Trying 0.0.0.0... Connected to 0.0.0.0. Escape character is '^]'. SSH-2.0-OpenSSH_7.9p1 Debian-10 Doesn't the kernel have a policy of not breaking userspace, even if the behavior is undocumented?
- zonidjan 7y agoWhy would code detect a failure and then use a fake address to cause an error, instead of just erroring?
- p1mrx 7y agoThe address may not be controlled by the code in question. Think /etc/hosts, command line flags, and config files, where you want some condition to trigger an error.
- herpderperator 7y agoIf you ask me, 0.0.0.0 should not be interpreted as 127.0.0.1. Yes, I know programs like ping interpret it this way as well. I just think it's ridiculous.
- silverwind 7y agoAgree that the bug is in userspace. Unless there is a RFC that says "0.0.0.0 shall be interpreted as 127.0.0.1", it's just super-weird that it even does that.
- p_l 7y agoSo, some software actually parses 0/8 as localhost? This explains so many broken tutorials..
- IshKebab 7y ago
- rurcliped 7y agoWordPress doesn't allow 0.0.0.0/8 in some contexts, as an attempt to block some types of SSRF: https://github.com/WordPress/WordPress/blob/abcbee954f4d8baa5aff2df566a942c1b48ca2d7/wp-includes/http.php#L563 https://github.com/WordPress/WordPress/blob/abcbee954f4d8baa... If allocations in 0.0.0.0/8 happen someday, users will probably see similar misfeatures in many applications.
- pledess 7y agorejecting all of 0.0.0.0/8 was their CVE-2016-2222 fix
- icedchai 7y agoThis gives us only another 16.7 million more IPs and will have tons of compatibility issues with older systems. Re-purposing the old "class E" space (240.0.0.0/4) would have similar problems. IMHO, it is too late for these hacks. We need to embrace IPv6. I've been running it for almost 10 years now...
- guenthert 7y agoAnd I've been disabling it on every system I get superuser privileges on for as long ... I can't be bothered maintaining two sets of routes, two sets of firewall tables and for the life of me can't remember IPv6 addresses. My toaster doesn't need to talk to your fridge.
- icedchai 7y agoPeople were saying the same thing during the multi-protocol days (x.25, DECNet, AppleTalk, Novell IPX...) They couldn't be bothered to learn this crazy Internet thing. IPv6 is the future.
- dtaht 7y agoI am pleased to see no one coming at us with pitchforks and torches ablaze. 240/4 already works in many idea also. 127 and 225/8-232/8 can be reallocated as unicast also.
- rphlx 7y agoAFAICT the risk/reward for this change (and others along the same line) is poor, because like it or not, as a factual matter, there are many tens or hundreds of millions of notionally "open source" devices that will never get an updated Linux/BSD/... kernel. Most of them are probably Android phones but there is also a giant tail of consumer routers, EOL'd network equipment, etc. A lot of this stuff will stay in use until total HW failure, which may be a decade, two decades or more. There are of course also many closed-source products that will never get a TCP/IP stack update. I haven't tested it but I doubt Win7 will ever be able to reach 0.1.2.3 over the public internet. Even if that's a bogus example, you get the idea: millions of dollars worth of old closed source gear out there where it's impossible for the owner to patch the TCP/IP stack. As a result, to prevent strange connectivity problems on 0.X% of their connections, almost everyone will pay (and, if needed, significantly bid up) the ~$20/yr "normal" IPv4 address cost to get an existing "non-reclaimed" IPv4 address instead of taking a gamble on one of these new ones that will definitely have problems with many other hosts. In short I don't see a voluntary rational buyer or user until the IPv4 market rises 10X+ and probably more like 100X+; until then they seem like more of a liability than an asset given how annoyingly long it will take to retire (or somehow otherwise ensure that you'll never need to talk with) non-updatable IPv4 hosts. Not that I like this, or am trying to defend or justify it, but I think it is an accurate assessment. TLDR: pretty much everyone will actively avoid these addrs given that millions of hosts will never be able to reach them.
- dtaht 7y agoThis work is a fallout of the conclusion of this report: https://www.internetgovernance.org/2019/02/20/report-on-ipv6-get-ready-for-a-mixed-internet-world/ https://www.internetgovernance.org/2019/02/20/report-on-ipv6... "legacy IPv4 will coexist with IPv6 indefinitely" which was referenced in the original talk, and I wish more "just deploy ipv6" advocates would read. I have worked very hard on making ipv6 deployable (notably in the cerowrt project) and came to the conclusion after reading that that if we wanted sustained internet innovation we needed to expand and improve ipv4, also. Thus 240/4, 0/8, 225/8-231/8 (pending) and yes, even a large portion of 127 and a push to clean up other problems in ipv4 in general.