Why would anyone even bother. All the scripts and programs that were hardcoded to treat 127/8 as loopback and 0/8 as various default routes would need to be changed and more importantly, verified. You wouldn't want anything that's hardcode bind to, say, 127.48.47.218 as localhost to suddenly be routable from the internet.
I vaguely recall Cloudflare uses a huge chunk of 127/8 as internal loopback addresses for their edge servers. Without Cloudflare's support this proposal is DOA.
John Gilmore (who founded this project and whom I've been consulting for on it) has talked about this in the current NANOG mailing list thread about our proposals. He has several posts there, but the most relevant to your specific comments is probably
Let me perface this by saying thank you for being sincere and civil, because what I am about type might not be up to the standard you established.
I read that email and there's a serious tons of hand waving and 'dude, trust me.'
I am going to ignore "would be useful to a lot of people -- hundreds of millions of people who you may never know." There's no example use case of who the hundreds of millions of people might be, and how this proposal would benefit them. What are the benefits that the existing CG-NAT and ipv6 couldn't provide?
I am also going to ignore "one-line patches is almost risk-free." Sure if all the software in the world is only Linux/Windows/BSD TCP/IP stack and no one build anything on top of the stacks, then the patch would indeed be only 'one -line'.
What I really have a problem is 'simply include them in new releases of the various operating systems and router OS's that implement the Internet protocols.' I work for a _major_ hardware firewall company, and it is ridiculous the amount of effort we would put on our customers to upgrade their firmware. There are still hardware that run with 15 year old firmware (with all the accumulated CVEs). You are telling me it's easy to convince these people to upgrade their stuff? Are you serious??? 'People naturally upgrade their OS's every few years." Oh I guess we can ignore all the IoTs and middle-boxes on the interweb then.
"We have tested major routers, and none so far require software updates to enable most of these addresses." As mentioned I work for a firewall company. I just logged into a sample firewall under my control- yes the configuration is doable. But in enterprise, everything needs to be rigorously tested or else the sysadmin's not gonna touch it. The sysadmins are certainly not going to waste a few weeks of their lives testing things that might bring down their entire network, and would only benefit the select few who managed to grab ahold of the new IPs.
It's late at night and I don't want to continue. So here.
Adding on to this, the claims seem actively contradictory: it wants us to feel for the millions of people who never got IP addresses (they were late to the internet for whatever reason) but also thinks that they will upgrade on the drop of a hat. Like, these people are using Windows XP and Android KitKat: that’s all they can afford. It seems wrong to present this change as being for them and in the next ask for them to do something that is out of their reach.
> People who use Windows XP and Android KitKat today can't connect to most sites anyway due to TLS 1.2
...if they use the Windows built-in SSL stack. For instance, Firefox has always used its own SSL stack (NSS) everywhere; and AFAIK, the last version of Firefox which was compatible with these systems already worked fine with TLS 1.2. The same for root certificates: Firefox uses its own CA roots (from NSS).
Firefox stopped supporting XP since Firefox 52.9 ESR which did not have finalized TLS 1.3 support. That's kicking the can down the road a bit longer than TLS 1.2, but not much longer.
See my comment in the other thread. Basically, Windows XP / Windows Server 2003 and other OSes of that vintage still probably drive a good portion of industrial machines. For example a new and modern dentist office, with top of the line equipment had to buy a used panoramic x-ray machine. It makes sharp images, it runs on a separate network and only talks to the NAS - so it is quite decoupled. It works really well but it runs Windows XP. I noticed when I was there, that is how I know all this.
In this case, the unicast extension doesn't really apply but it could be other Windows XP machines connect e.g. over a VPN somewhere perhaps in the public cloud. The machine doesn't listen on any port on the public IPs it has... until one day, it can't connect to the VPN endpoint for some reason, because it is in the 0/8 or 127/8 range or whatever.
You have to consider it, it is still millions of devices potentially flooding the new addresses, causing major security holes in legacy networks and a lot of maintenance burden. It is a dream/ nightmare come true for support companies and contractors depending on who you support.
These XP/2003 devices should be isolated behind a million firewalls and perferably not connected to the internet at all. If these devices can't route to some portion of the net which they shouldn't have been connected to in the first place, that's hardly a loss.
* Personally I think 240/4 is very reasonable since it was always reserved, 0/8 is doable but would require effort enough people might not want to do, and 127/8 is hardcoded in too many places and isn't doable. IPv6 is the future, but it isn't justified to make things now worse to make deployment faster (it won't be). IPv6 will win by default anyway.
I am absolutely with you. At least unsupported Windows versions should be eradicated where at all possible. Sadly, this isn't the reality we live in as I described at length.
Only including 240/4 and parts of the multicast space perhaps in the unicast extension would most likely minimize the impact to potential legacy use-cases and setups and be the 80/20 kind of compromise.
In practice, VMs on PCs for non-technical personnel are a major pain. All kinds of stuff breaks in curious ways e.g. the pass-through of the protocol or the specific interface might not work reliably, there is a custom setup to support, some pop-up causes the windows to overlap in a way that makes it hard for the medical personnel to get going quickly yadayada. Yes, you can do snapshots and other stuff.
Also, the technicians setting this up are usually not trained in IT DevOps/ broad sysadmin tasks so much as in the setup of special medical devices. They also tend to cost a small fortune, because again, they are certified to work on those machines costing on the order $100000 when used and multiple that when new and there might be a handful of them for the whole region. In this particular case, as a patient you also don't want more x-rays than you absolutely need to get. Doing a panoramic x-ray multiple times because e.g. of some software failure could breach some daily/ monthly whatever irradiation limits so you would need another appointment etc. Not something you want to go through as a responsible doctor because of some custom setup.
I get it, I am also enthusiastic about Windows never touching bare metal if at all possible for long running professional stuff precisely because of snapshots and e.g. the possibility to cut the network remotely and bring it back up if needed. But I also come in contact with non-technical folks that don't want to risk stuff, deal with more stuff than they already deal with etc. I respect that, it is an approach that works for them.
I think that if Microsoft ever does decide to support this extension there'll be a patch for all supported versions including via ESU - just like all supported relevant MS products got a TLS 1.2 patch, even the embedded Windows XP (POSReady 2009) got a TLS 1.2 patch.
> What are the benefits that the existing CG-NAT and ipv6 couldn't provide?
CG-NAT is nasty: you can't be reached from the Internet and (this is the more important thing) IP-based rate limiting or activity tracking (think of stuff like Wikipedia and anonymous edits) don't work any more.
IPv6 adoption has been ... sluggish by any measure, I remember playing around with sixxs ~2010ish, and there still are providers that don't hand out native IPv6!
> and there still are providers that don't hand out native IPv6!
There's still a lot of Linux' that can't handle IPv6 handed out by their ISP as well, for example systemd-networkd got working PD support that's at best a few years old (so only in the latest LTS releases of Ubuntu for ex.).
I think we're now at the hardest 20% to fix and deploy, that 20% includes humans as well.
He is thoughtful and states his case well, but these two assertions make no sense alongside one another:
But it would be useful to a lot of people -- hundreds of millions of people who you may never know.
Microsoft Windows is the biggest laggard; they drop any packet whose destination OR SOURCE address is in 240/4.
We can assume he's not talking about mobile users: they can and usually do get IPv6 addresses. We can assume he's not talking about all the endless servers and so on talking to one another, those aren't "people." He's talking about hundreds of millions of PC users.
Hundreds of millions of PC users, except Windows users. How is that going to work?
It'd be fun and ironic to pick on Microsoft for adhering too closely to established open standards, but unless I'm missing something here, they've got a veto over implementation of these ideas.
Routing (static or dynamic routes depending on the network setup), firewall + /etc/hosts depending on what you try to do exactly. There would probably be some guidance on how to support the old behaviour consistently in legacy networks.
Lots of 127/8 outside of 127.0.0.1, both for development (running multiple services on conflicting ports) as well as for production use (either due to port conflicts, or simply ease of use if you stick to default port when, for example, setting up multiple DNS servers (to separate recursive resolver and authoritative server).
I recall a lot of use in routers as well, but haven't personally used those setups.
a ton of routers (think, high end access or core platforms) use "unroutable" ip space for internal communication between different systems in the router.
These are hardcoded addresses used in the backplane of the system, and changing them would be incredibly difficult because usually:
- these routers have multiple forwarding and control plane systems for redundancy purposes, and upgrading them all at the same time is usually not feasible. (remember, these system are build redundantly because you want no downtime on a core router).
- Some of these prefixes are used for constructs inside the routers (virtual interfaces between forwarding planes for instance). This might be called ugly, but it is the way it is. and changing that is near impossible.
This reminds me of how RFC1918 address space is supposed to be "never connected to internet" (including NAT, because when it was written NAT would have violated basic host requirements).
And some computers abused the hell of it, for example Digital/Compaq Alpha EV7 "Marvel" line, where each processor had its own address in 10/8 subnet and essentially equivalent of BMC controlled the computer through 10mbit ethernet linking all components
A very good overview, aside from these proposals, of the problems that internet addressing has developed over the years was also presented at the same working group meeting.
There's no chance in hell class E, 127/8 or even 0/8 will work within 20 years.
The effort is doomed.
If you thought it was a lot of work to upgrade to IPv6, forget about it.
- Hey ISP or cloud provider, do you want some of that sweet sweet class E?
- Will users be able to connect to it?
- Nah. Well, some will. As long as you're happy with people spending the next 20 years complaining about how "your servers are always broken", you can have some addresses.
It's a complete waste of effort that should instead be spent adding support for IPv6.
Spend huge effort on something temporary throw-away, or on something long term? The temporary thing will take at least as long to implement, and you will never know if you're actually done or not.
It's really interest, I think it's partly this attitude by the IPv6 folks that have stymied IPv6 adoption.
It's this - you are an idiot, this is a waste etc. The reality, out of the millions of users of IPv4 space, some will find some use for 0/8. Will it be worth as much as other IPv4? Maybe not. But hard to imagine it being worth zero.
The other piece, if IPv6 is so great - then this does nothing to stop the rapid adoption of IPv6 by both the major players (cloud providers) and small players.
> It's really interest, I think it's partly this attitude by the IPv6 folks that have stymied IPv6 adoption.
If you don't like the answer the doctor gives you, the answer isn't to stop going to the doctor.
> It's this - you are an idiot
I didn't attack the person. Please stop misrepresenting me. You are the one getting personal here.
> The reality, out of the millions of users of IPv4 space, some will find some use for 0/8.
Who? Really. Who?
To be even more specific: Who, who today is hungry for public IPv4 space, and doesn't really care if it's publicly usable or not?
> Will it be worth as much as other IPv4? Maybe not.
You're missing the point. Something that's "kinda broken forever" is much worse than not having it at all, when there is an alternative.
If you can't get IPv4 for your cloud service, then you price the working addresses such that avoiding waste is a thing.
> But hard to imagine it being worth zero.
No, not zero. Just a worse value proposition than switching to IPv6, with a "good and working IPv4" proxy path in the mean time.
> The other piece, if IPv6 is so great - then this does nothing to stop the rapid adoption of IPv6 by both the major players (cloud providers) and small players.
I'm not competing. I'm saying it's a bad solution, and there's a better solution out there that's cheaper, more effective, and more long term.
This proposal an investment in throwaway work, and I would recommend that nobody adopt it.
Also note that at the rate addreses were allocated when we ran out, they were going at an /8 per 3 weeks. This is a huge investment to buy a month or two before we're right back in exactly the same spot? Clearly a bad idea.
Client side: NAT. Solved.
Server side: Who in their right mind would use 127/8 on their server? IPv4 is just not that expensive.
Anything extending the life of IPv4 is actively harmful.
(Like I said last time this was posted.)
The most important problem with IPv4 is that it mandates 1:N NAT configurations that break direct connectivity between devices on the Internet. Yes you can traverse NAT but it's an ugly and often unreliable hack. This of course is because the address space is too small for everything to have an IP, whether global or 1:1 NATed.
Difficult peer to peer connectivity means everything has to have a server. You can't just write communication apps that... communicate. The added cost here is enormous both in money and in privacy/security.
IPv4 is also too small for private networks. Corporate networks are often full of hideous hacks like multiple NATs that negotiate interoperability between networks with overlapping 10.x address spaces, "theft" of unused IPv4 space such as US DoD addresses, etc.
> The most important problem with IPv4 is that it mandates 1:N NAT configurations that break direct connectivity between devices on the Internet.
Honestly, I don't think direct peer-to-peer connectivity will come back even after everything swutched to IPv6.
There is enough dangerous stuff out there that will actively try to exploit any device that is reachable on the internet that you usually don't want to have your devices reachable if you could avoid it in any way.
NATs have become de-facto firewalls, but in that property, they're quite important.
The advantage of IPv6 is that you no longer have to have things like STUN, TURN, etc. (Remember Skype super-nodes?)
Your client knows its own IP(v6) address, gets the IP address of the other end, and then tells your firewall to allow connections between just those two addresses. Once your session is done the ACL is deleted and you're completely default-blocked from the outside again.
Modern P2P does not generally consist of hanging your whole system online with its pants down. They're specialized protocols with authentication, and Rust and Go are popular in the space because they are safe languages.
The problem is how consumer internet connections should be configured.
If you're an ISP, your choices are basically just that: Expose user networks fully and trust that all users have enough expert knowledge to put up their own firewalls - or put up a common firewall for all users.
Right now, the default is option #2. Unfortunately, this means that the ISP will configure the firewall to support the most common use case - which for consumer internet right now is a user without any technical knowledge who just wants to browse the web. So outgoing connections only, it is.
Switching to option #1 would mean that the networks of all users are exposed, whether they want to use P2P or not. And for anyone who is not an expert, this would mean exactly that: hanging your whole system online with its pants down.
What we'd really need is an ISP who lets you configure exceptions in the ISP's firewall yourself. However, this would mean significantly more effort for both the ISP and the user. I think it's unlikely, an ISP would offer such a feature without charging extra for it - and even if they were, it would mean that P2P software would still not work out of the box but would need configuration on the user's side.
To sum up: Right now, I don't see how P2P software is usable for non-expert users without opening up glaring security holes.
With "security holes", I mean everything else that runs on the user's network. The P2P software itself can be perfectly secure, but that doesn't matter if the cheap IoT device on the same LAN has a well-known RCE vulnerability and the vendor doesn't bother to patch it.
This all assumes an ISP who is fully on your side and doesn't have business interests on its own - such as actively blocking consumers from running servers at home because they also sell dedicated servers in a separate business unit.
What I can see as a pragmatic way forward is more along the lines of WebRTC and ICE: Make direct connections if possible, use a TURN relay server otherwise.
It sucks that you still need a control server to coordinate matchmaking between peers. I wonder if we could have something like "(almost-)serverless WebRTC" in the future, where we can exchange the control information through other means - e.g. QR codes, bluteooth, emails, etc.
I also really hope, we get back more LAN-only devices in the IoT space. Currently, it seems insane that my smart light switch has to talk to half a dozen cloud servers to activate my smart lightbulb half a meter away.
> If you're an ISP, your choices are basically just that: Expose user networks fully and trust that all users have enough expert knowledge to put up their own firewalls - or put up a common firewall for all users.
This is a false dichotomy.
Given that ISPs now overwhelmingly give you some router to plug stuff into, they can very easily have an opt-out firewall configured on the box they give you. That is in fact what i have seen most ISPs do. The incentives for network filtering etc have nothing to do with "protecting the user", this is both easy to do and actually done, frequently the right way (with user-controlled fw).
There are protocols to ask the CPE (which is where the firewall usually is) to temporarily open a specific inbound port to a specific host, like UPnP, and many P2P software already know how to use it. So you can have a "deny inbound by default with state tracking" firewall, while still allowing P2P software to work without relay servers and similar tricks.
the role of ISPs are not to act as your firewall. that's your routers job. NAT does nothing to increase that security realistically since most routers are closed by default to inbound connections.
NAT as security is purely in the corporation realm of usefulness and afaik IP6 supports NAT just fine. it just wouldn't be a fundamental requirement for the internet to even exist.
> I'm confused why people are willing to develop hacks on top of hacks just to avoid using IPv6. It is really elegantly designed
As you can see, It's because not many people understand IPv6.
Also there are many devices that would stop working. There is no clear path for adoption, everything is "switch and let's see if it breaks". Many systems are legacy systems. Banks still run old IBM mainframes and you would need to think about it when migrating to IPv6.
ISP's are unwilling to implement it as there are not so many qualified workers that even understand IPv6, big companies like Google straight refuse to fully implement DHCPv6 and so on.
> Banks still run old IBM mainframes and you would need to think about it when migrating to IPv6.
Mainframes are a _lot_ more maintained than you think they are, but overall this is a bit of a weird statement as Mainframes talk TCP/IP for compatability reasons anyway, Mainframes talk amongst themselves using a protocol called SNA/APPN. (Which, can be encapsulated in arbitrary IP frames, but is not required and doesn't require support of the mainframe)
IBM Mainframes, for various reasons including how IBM structured the pricing tend to run pretty recent versions of software.
In case of IPv6, all supported OS versions work with v6, the limits involved are also somewhat no longer valid outside of very locked down intranet-only setups.
Also IPv6 was officially ratified 2 years after all IPv4s were exhausted. IPv6 was designed in 1998 when total number of internet connected devices is estimated to be equal roughly our daily increase of internet connected devices.
I'm not a network engineer. But I've yet to see a good way to protect ipv6 network. I don't want my local webserver develop on to be exposed to the internet. It's my understanding that default router configuration will do just that.
I don't see a good way to deal with privacy issues. Ipv6 essentially gives a unique identifier for every computer in the household by default.
You'd setup your firewall to protect your IPv6 network. This policy says do this, firewall defaults to no traffic pass. Same as you have now.
IPv6 privacy extension (been around for many many years, and default on at least MacOS and others for many iterations), gives you a new IPv6 address every time period, and rotates through them transparently.
just want to make it clear, usually you are assigned a prefix which you can announce to your network and then nodes will pick random addresses from that prefix. its still easy to determine the packets came from your network just not clear from which device exactly much like current NAT setups lets say...
... unless your ISP would change your prefix regularly (like every day), like it's now the case for those who have a public dynamic IPv4. If they give you a static IPv6 prefix, it's like giving you a static IPv4 now, i.e. something ISPs would probably want to monetize as a premium service. So I'm pretty sure we'll end up with regularly changing prefixes... which is probably good for privacy.
In most countries, the ISP is legally obliged to keep records at which point in time has a customer had an address. Usually a court can order an ISP to hand over those records. In other cases, the police, secret service, copyright lawyers etc. can talk directly to the ISP.
Sure, but keeping logs for legal reasons doesn't mean transmitting those logs to all the web sites you visit. I think the point here was untrackability by websites rather than pure anonymity.
In general, the level of privacy/ anonymity should be pretty similar with IPv4 or IPv6 in the real world. You will be better off at some hacky, local IPv4-only ISP behind a huge "CG"NAT because they may not keep all the records or not for so long or whatever. You might be better off at a large mobile provider with IPv4 as a service over an IPv6 network, because the prefixes can change often and IPv4 is again basically a huge gateway hiding you to some degree. If you really need to be as anonymous as possible to most services online, use TOR or a series of VPNs/ SSH tunnels in different countries or whatever and a number of other anonymizing tools, browser plugins etc. Having IPv4 or IPv6 will not play a role as people usually leave huge amounts of traces all over the place.
For websites, for all these reasons, it is way more interesting to fingerprint you with multiple different aspects of your online presence. E.g. look here: https://amiunique.org/ or here: https://robinlinus.github.io/socialmedia-leak/
For most people and websites, IPv4 vs IPv6 for fingerprinting isn't very interesting because websites have better means and people usually don't really know/ care and most ISPs think they have a great business model handing out dynamic prefixes/ IPs and combining all that with CGNAT or NAT64/ DS-Lite or other gateways. Privacy extensions and local NATs of various kinds also don't help in having more visibility into that chaos. Actually, in my experience, most tracking currently is really, really dumb to such a degree, that I cannot be reliably tracked even if I want to (e.g. when using navigation like Waze) because for some reason, the app cannot get my position using GPS even after tens of minutes. The app still hasn't figured out, I live somewhere else now and hasn't offered me a new home address. It also doesn't recognize any pattern in my routine quite obviously. That would actually kind of be the point of the app, wouldn't it - it would make it more comfortable for me and it could serve me much better targeted adds, e.g. for good coffee in the morning? I also don't get very meaningful suggestions or adds for anything and I only use an add-block plugin. For those reasons, I don't think most websites are able to track me effectively and I don't worry about law enforcement much - I am not a journalist, nor a dissident, nor have I done anything in regards interesting to law enforcement or such.
I think, we all should worry a bit less and focus on fixing stuff all over the place so that tracking is more easily detectable and can be mostly disabled in such a way as to not hinder useful functionality. IPv4 and IPv6 as currently deployed are mostly "boring" in a good way. IPv6 tends to work just fine in places that want to make it work. So for most things, talking IPv4 vs IPv6 is like vim vs emacs or some other endless and rather pointless discussions. Not very informative or useful. We should be using what makes sense. IPv6 starts to make sense in most places, because it becomes easier to set up each day and IPv4 becomes more expensive to maintain. The real problems of IT are really elsewhere now and they are so plentiful.
You would laugh, but just doubling the amount of RAM in the computer today is an undertaking. You cannot get RAM with the same frequency and timing as is built into a computer just a few years old. Higher speed RAM doesn't "just work". No, you have to update the BIOS/ UEFI because they have support for newer RAM standards as it turns out and set the frequency by hand to enforce a downclock of the newer RAM - not really something a regular user would know how to do at all. All of this just adds up and the IT field is so complex nobody can reliably navigate it nor give any dependable estimates about anything. You have similar things way up the stack. Just try updating dependencies in a project (mentioned at length on the front page just a few days ago https://news.ycombinator.com/item?id=29106159). If engineers have to solve stuff, that should have taken 10 minutes for 2 hours instead, we have a major problem - we are just not getting stuff done, because we have been let down by otherwise solid assumptions.
Things in IPv6 land can have multiple IP addresses - you can have a fixed address or use a fixed link-local address for an entry DNS if you're not using something like multicast DNS, but it can still initiate connections using a privacy extension address.
Even now I doubt many home users have a local dns server for reaching their printer by name. I think Windows uses NetBIOS for this purpose, which should work fine over IPv6 too.
Some models of home routers do run an internal DNS server which makes things accessible under a subdomain with whatever name you've set for that device in the router's configuration.
I'm not trying to be aggressive here. But what's the actual end user difference between NAT and firewalled ipv6 for me and my local network then? I assume I could route now than one addresses for a specific port. On the other hand I have to pay for domain record to access my local resource without a struggle.
Should I use ipv6 at home when my doesn't have one?
I honestly struggle to find good information on the protocol that's decades old. It's either to deep for me to care for my needs or too shallow to understand why and how should I just it. Scaremongering is what I find on the internet. And no real benefits for me to update my hardware or find ISP that has ipv6.
I can kind of relate to the feeling of IPv6 being "new and scary" to back in 1995 when I barely grasped IPv4 routing... everything becomes clear eventually with experience and exposure... hopefully eventually I'll understand more IPv6 concepts with time. I "want to believe". :)
But I do fully get that firewall without NAT is perfectly fine (great) in an IPv6 world - but may be necessary in simpler multi-ISP routing scenarios...
The difference is that traversal protocols like UDP hole punching work deterministically almost 100% of the time in an IPv6 environment but are flaky in an IPv4 NAT environment.
It also means that you never experience port exhaustion on large networks, which is a problem for large IPv4 NAT deployments.
I haven't seen a single IPv6 network configured to behave like that by default. Just because it has a globally unique address doesn't mean it's reachable.
New home routers (the kind that ISPs give out to clients) with IPv6 support include default deny firewall on externally-initiated connections, precisely for that reason.
If you think NAT gave you any privacy benefits... at best it made for easy "household mapping" of people.
> IPv4 is also too small for private networks. Corporate networks are often full of hideous hacks like multiple NATs that negotiate interoperability between networks with overlapping 10.x address spaces, "theft" of unused IPv4 space such as US DoD addresses, etc.
IPv4 is perfectly adequate as long as you're the only one using the e. g. 10.0.0.0/8 range. I don't think that overlapping private networks were ever designed into the use case.
Rendezvous across a firewall is easy in the absence of 1:N IPv4 NAT. You just do an exchange like NAT traversal but it always works. Administratively opening a port is also easy.
Is it? Okay, so you don't have to specify the external-to-internal port mapping (and routers might offer you a default of external port = internal port anyway), but other than that it still seems like more or less the same procedure to me.
And at least my own home router does indeed use the same configuration interface for both IPv4 and IPv6.
If you have more than one device which needs similar external access, you won't have to use a non-standard port.
I have three devices at home which I'd like SSH access to. Because I only have IPv4, two of them aren't on port 22, and sometimes the non-default ports I've chosen are blocked by hotel Wifi etc.
Similarly, I'd like two different webservers to be available, but I can only have one on my single port 80.
For the more typical user, it can mean only one person playing a particular game etc.
Yes, that is of course a benefit, but what I was trying to get at was that you'd still have to dig around within the router config, so it'd still not quite be the radically easy, absolutely hassle-free peer-to-peer communication world.
NOBODY will like this idea, but if you really want to keep using IPv4, then:
If the goal is to stick with ipv4 because it is easier then I think you would get more traction if you could convince governments to work with ARIN / RIPE / AFRINIC / etc... to do eminent domain forced consolidation and buy-back of horded IP space. Give companies, organizations, government DISA, DoD, Military and others a year to consolidate their actual usage into smaller CIDR blocks, then governments buy back the unused space at market value. I am not a fan of eminent domain but this would be a valid use of it and could actually happen, accepting there would be a myriad of law suits, stalling tactics and so on. Provide some incentive for people to willingly consolidate in a timely manor such as paying a higher market value for those that get on board early.
As crazy and possibly unethical as that suggestion may be, I think it would at least get some momentum and you could possibly gain more than 419M IP's and have less network fragmentation. As a bonus, no need to update router firmware, IoT firmware, operating systems, application configurations, firewall OS, firewall rules and so on.
I don't understand why two EFF-adjacent personalities have an interest in making more v4 addresses available which will ultimately end up in the hands of giant ISPs and corporations.
This illustrates as I've said how out of touch IPv6 folks are.
The demand for IPv4 is incredible right now. The value of a /8 went from $0 to close to a billion dollars.
The claim that new IPv4 space has no value is ridiculous. These ranges don't have to be perfect.
I think IPv6 folks just don't understand how high the demand for IPv4 is, it's gone UP since IPv6 came out and folks have realized IPv6 is going to be much much harder to adopt then expected. And this proposal does nothing to stop IPv6. You know your IPv6 proposal is bad when it depends on stopping others from improving alternatives :)
The amount of money this IPv4 space is valued at now - while astronomical in comparison to past pricing, sure - might as well be $0 when you compare it to the colossal expenses in both funds and manpower to update literally decades of now-critical infrastructure that treated this address space as sacred.
Galaxy brain magnitude of difference here.
This analysis strikes me as exactly the same type of MBA-rot that chases quarterly earning reports over long-term business health. This sale benefits, in real terms, zero people, while imposing costs on almost every single existing user (whether they realize it or not).
> The claim that new IPv4 space has no value is ridiculous. These ranges don't have to be perfect.
yes, they do have to be perfect, because having a range which is not usuable by a part of the networks and devices that make up the internet drastically decreases their value.
The reason IPv4 space is so valuable is because migrating to ipv6 still has a higher friction then ponying up money for additional ipv4 space. It will be a matter of time before this changes and implementing ipv6 is far easier in comparison.
Out of curiosity, where are you finding these prices? (I know there are "brokers" (?), just haven't used them, so not sure if some are better than others.)
ipv6 no doubt was designed without the mistakes that ipv4 learned the hard way. Everything from getting rid of useless (and dangerous) flags, to flow identification, is beautifully designed.
But, there is absolutely 0 reason for Google, Facebook, etc to know how many devices are operating in your home, or which ones they are communicating with. And before the army of drones screams "ipv6 privacy extensions", the battle has already been lost. Unless every request to Google, Facebook, etc was made with a unique ipv6 address, you cannot assume the same level of privacy that an ipv4 NAT provides. Ipv4 makes Google, Faceebook jump through extraordinary hoops to track you and monetize your personal and private life. Ipv6 makes these things trivial (coincidently, both of those companies are pushing ipv6 the hardest despite owning huge swaths of ipv4 space).
> But, there is absolutely 0 reason for Google, Facebook, etc to know how many devices are operating in your home
Considering every request going to their servers likely already contains a cookie that identifies them entirely it's extremely likely they already have this information.
If you participate in facebook etc apps and services at all they have far more insidious and effective tracking and NAT isn't hiding you at all. Additionally the idea that it is granting you any measure of privacy is only true if you're behind a giant translation block with tens of thousands of unrelated people and a broad enough public range that connection correlation becomes impractical, compressing a single family or roommates behind a single public IP that changes maybe every few weeks accomplishes very little if anything.
If you need anonymity that much for whatever purpose, depending on v4 NAT is dangerous at best and you should be looking into anonymous proxies or VPN providers (that also mask ipv6), Onion routing, etc.
There’s a lot less effort required to update an existing IPv4 system to accept a few more ranges than to entirely rearchitect a network to work with IPv6.
Plus there’s a lot of energy in this world to do both without one taking away effort from the other.
But as to the actual proposition, I would rather the 240/4 space was changed to RFC1918 private space, or at least half of it.
I for one am not looking forward to all the frankenbugs when new stuff on those IPs talk to old stuff (middle and endboxes)...
The great part about IPv6 in that regard is that you are either capable or not, not mostly compatible as an older client would be with this "ipv4+" thingy..
IPv6 implementors are inconsistent in what they support. Eg Android and it not supporting DHCPv6 [1].
Also NAT in IPv6 is not as widely supported as it is in IPv4 (and yes NAT can and is used for reasons other than security, such as policy based routing and routers with multiple disparate WANs like Fibre and Cellular).
Plus there will always be someone somewhere with a middlebox, be it IPv4 or IPv6.
NAT is the worst thing that could have happened to Internet.
Without NAT people would have been able to host their own blogs, pages, photos decades ago from their home. We could have had far more decentralized applications than we have today and would have prevented this walled garden mess of Internet.
The ability to address any system on the Internet with it's unique IP is what original Internet was supposed to be. NAT was temporary solution to address the issue of limited IPs but now that is single protocol that is preventing the migration to IPv6
I don't know why this is being down voted. The entire modern bullshit Internet exists because of NAT. We can't host stuff ourselves and have to use some central system. Since nothing is free, the provider has to inject more and more ads everywhere.
Because it implies that it is the single reason that people don't host their own sites anymore, when in reality people don't because it is generally too difficult, expensive, unreliable and redundant to do so.
Almost nobody wants to host their own social media or messenger site and if you did your friends wouldn't use it too.
Besides, anyone who currently wants to do so can get a cheap VPS for dollars a month.
Around here (USA) ISPs still give publically routables IPs to customers, and the customer is responsible for running their own NAT if they want to have multiple devices on their network. Most routers support port forwarding, which allows those households to have publically routable TCP or UDP ports on any device within the network. In theory UPNP allows devices to set this up seemlessly.
It has become less common with the rise of clouds. But it used to be common for multiplayer games to be done by one player setting up their instance as a server.
I wouldn’t put CGNAT and general NAT in the same basket.
My ISP and every ISP I’ve used since the 90s has given me a public IP, only exception is my cellular links which are CGNAT’d. I’ve got no problems hosting stuff with my current connection, while my LAN devices are on RFC1918 address space.
No, the things I mentioned cannot be done easily with IPv6. You cannot easily switch a router from using one WAN to another (with different IPs) without requiring IPv6 clients having to obtain new addresses via SLAAC (and hence downtime), or use NAT (which is what IPv4 does, but not well supported in IPv6).
You cannot easily have 2-3 levels of networks where router3 is attached to the lan of router2 which is attached to the lan of router1, which has internet access. This is because DHCP-PD is not well supported (see Comcast) or the prefix delegated is insufficiently sized (a /56 minimum should be standard but some will give a /60 or worse, just a /64!). This is bread and butter to do in IPv4.
You sound like you know what you're talking about, which makes me a bit confused because you appear to be misinformed here.
Your router will advertise new routes immediately when it's given a new WAN address, there's no downtime incurred explicitly from IPv6 in that scenario: local connections will still route until the timeout anyway.
SLAAC issues (and can issue) more than a single IP per device, leading to interesting bugs like the ones Sam Bowne talks about in windows.[0]
Changing a WAN interface _does_ incur downtime on ipv4 too, unless you're assigning virtual NICs and then failing over: which IPv6 would support in identical ways.
Yes sorry I should have been clearer, it’s the connections from clients having to timeout and re-establish upon IP change that is the issue. Specifically where those packets might be going over a SD-WAN type solution where a WAN change is non-disruptive to SD-WAN destine traffic. It relies on clients having NAT addresses and using those addresses for Internet destination addresses (not just private space).
Another issue with SLAAC/lack of NAT on the LAN clients is you can’t do policy based routing on the router, eg I’ve got a fast fibre but it’s costly to use, I’ve also got a cheap and cheerful cable/DSL line that I use for backups and FTP. I want to route all requests to my backup service (which has a domain that resolves to a public IPv6 address) via the cable/DSL and everything else via Fibre. Easy to do on IPv4.
But, nothing you said is inherent to NAT, you should read up a bit more on iBPF for the latter and the former works exactly the same way on v6 as v4. Static routing is not really a thing unless you’re a really bad network admin- for sure your ISP wont be doing static routing to your home.
Can you talk about this some more? Also do you mean eBPF or iBPF or iBGP? If it's BGP that's just too complicated/expensive for a lot of the small businesses I deal with.
Policy routing works exactly the same on IPv6 as on IPv4. People misusing NAT or internal addresses to handle policy routing are the problem.
I've no idea why SLAAC would prevent you from doing policy routing - the prefix is deterministic.
In IPv4 I presume you guessed who each host is by some sort of DHCP registration. For IPv6 you would use either NDP, or perhaps even way more secure SEND enhancement with PKI instead.
Of course static assignment still just works, including in NDP/SEND. (e.g. by MAC address or per link)
RIPng/OSPFv3/IS-IS/EIGRP can also tell other hosts which route you prefer packets to return by with better granularity and dynamically. This works even better with v6 since global addresses are always available.
The above doesn’t work if you are dealing with client devices that don’t support routing protocols (Ie phones, laptops, tablets, CCTV systems, PCs etc - everything except routers and servers) and especially with BYOD devices.
Also perhaps I missed something in your reply, but policy based routing - the definition I have of it - encompasses more than routing different subnets via different WANs. Ie routing based on destination port, IP DSCP flags, WAN utilisation etc rather than just by source.
And as I’ve mentioned elsewhere, the cost and complexity of running routing protocols is a non-starter for many small and/or low margin businesses. Think retail or fast food or fuel etc.
> You cannot easily switch a router from using one WAN to another.
You cannot easily do that with NAT either.
Every single one of your TCP sessions will die, and likely every session going over UDP as well. Unless you're talking some special protocol specifically designed to handle clients changing IPs.
Your machine may not notice, but the machines responding to your packets sure will.
First - you can't actually get static IPv6 despite the claims that there is plenty of it as a home user in the US. This static IPv6 for everyone is basically a total lie.
It's super simple with IPv4 to setup an internal network with known hosts / DHCP lease reservations if needed / dns etc, and have all that stay totally unchanged as the WAN link bounces around. If you are supporting a bunch of users (who yes, will configure a printer using the printers IP etc) then this makes like simple. You can do this at home too easily etc.
There is a weird myopia in the IPv6 world about use cases for IP. It's like they just ignored what people need and want, and went a totally different direction.
We need IPv4+ with another octet and be done with this :)
I'm serious, anyone interested in trying to push this. Keep everything the same except with another octet at the front?
Problem is, the device doesn't have to know, which address is the working one - e.g. which prefix is working on the upstream. It might break connections etc.
A solution of course could be to have NAT66 and I really mean address translation not masquerading/ port translation here - as such, much easier to do as it is a 1:1 mapping or to get provider independent space or become a LIR and have two providers announce your space with respective BGP configuration for failover.
It is a solvable problem but isn't much guidance and experience with this at smaller companies that might not want to run BGP or go through hoops to get PI space etc.
And you are right BGP is a non-starter for smaller sites, especially where cellular is involved. Often small site businesses just need a backup internet connection to access the web and emails, which doesn’t need the overhead of BGP. Also there is a non-trivial cost to using BGP (equipment, expertise, and ISP will charge more for the privilege) which for smaller business doesn’t make economic sense.
At this point Google's refusal to implement DHCPv6 is well documented and is being brought up in a lot of arguments. Easy solution: if you need DHCPv6 you don't deploy Android devices and move on.
That's not how it works. For BYOD or home use, the device is always more important than the network. You can't just tell somebody "lol, Android not supported". Most of the phones out there are Androids, and not everyone prefers iOS even without the extra cost attached to an Apple phone.
DHCPv6 isn't mandatory to use IPv6, and SLAAC works fine in those cases (and neither are mandatory actually, can't be). This isn't related to IPv6 overall.
The IPv4 systems that need to be updated - the hosts - will not be. Not in a year, not in ten years. This plan is a non starter.
v4 should, at this point, basically exist as fallback prefixes for the devices that will hang around the next 30 Y without proper v6 support etc.
Routing in the small is not hard. I am absolutely baffled that people are claiming BGP is some kind of super hard thing to deal with. BGP has a ton of problems and lots of ugly duct tape (rpki, etc.) that is just done poorly but it isn’t hard.
> There’s a lot less effort required to update an existing IPv4 system to accept a few more ranges than to entirely rearchitect a network to work with IPv6.
I'm not so sure, actually.
It's still a case of literally billions of devices that just plain need to be replaced.
Not to mention millions(?) of multimillion dollar routers that need to be scrapped, even though they handle IPv4 and IPv6 in silicon just fine.
> But as to the actual proposition, I would rather the 240/4 space was changed to RFC1918 private space, or at least half of it.
Nobody's stopping you. It'll never be usable on the Internet anyway.
It’s probably easier to add some more addresses than to switch to IPv6 but I hope you agree that switching to IPv6 ultimately is inevitable. And then you are comparing the optional costs of adding that small number of addresses against the switch costs that you are going to incur anyway.
IPv6 has been around since the mid-late 90s, it’s an incredibly slow migration as a lot of things were just not thought through. Yes the switch will eventually happen, but we’re already talking decades, which is a lot of time to unlock a few IPv4 subnets while we wait.
I am a bit sad that what I felt was the proposal of most immediate benefit to the internet was not the one that got all the attention. That one is here:
There is some merit to having more IPv4 space e.g. for new players trying to start a business or for IPv6 transition technologies, where you need at least some IPv4 space e.g. for the NAT64 gateway. This should be considered in the application process for the space, if the unicast extension will be widely supported technically.
The real question here is, whether Microsoft will patch Windows to support the unicast extension. More specifically, which versions and whether it will include Windows XP/ Windows Server 2003/ 7/ Windows Server 2008 and various Windows CE versions. I would say, there are so many WinXP/WS2003 machines in industrial networks still, that not having a patch enabling support might be a major blocker. In some cases, you just cannot replace the operating system without also replacing the machine it is driving.
Yes, more or cheaper IPv4 space will prolong the pain of having two protocols one of which is the default but has inherent problems in terms of scalability (IPv4).
There might also be some damage from changing 0/8 and 127/8 to be global unicast and carving out 0.0.0.0/32 and 127.0/16 for their current usage. Also the lower address as alternative broadcast to unicast switchover could be "fun" in some networks. The reality is, ransomware and other attacks are quite common and creating new doors into legacy networks with less than ideal maintenance through changing rules should be evaluated. I don't think the typical water treatment plant, hospital, pharmacy or an aluminum smelter follow even major RFCs closely.
I know, I have discovered (and fixed) the 1/8 blackhole problem in a subsidiary at my previous job. I would need to really check 0/8 and 127/8 there to verify they are ready for the unicast extension as well. That company had an IT department and the IT worked reasonably well there but there were some very specific constraints such as Windows NT driving some industrial machines. This wasn't the common case, but it wasn't the only "special" host on the network. In such places, such changes perhaps don't need to be implemented, but you never know, when the inconsistency will bite you.
Who's going to configure this properly? Some apps will need to punch holes in the firewall.. It simply hasn't been tested enough. Especially in home / small office situations.
What even is there to configure? An IPv6-capable SOHO router ships with a “forward only related, established” config by default, to put it in IPTables terms. Most of the time, you won’t even have the option to disable this entirely.
There is nothing to test either because this is exactly how SOHO routers have been working for decades.
Just like weight loss can't be done with just diet or just exercise, promoting IPv6 isn't the only answer. We need proposals like this and we need to take on the engineering work to make class-E v4 accessible until 100% of the population has v6 connectivity.
So the answer is pills that can damage your health while having no long-lasting benefit?
One other hidden cost - all the body of knowledge (courses, tutorials, books, blog posts, etc) that we have accumulated over the years for IPv4 would now start being slightly incorrect and misleading. That's no longer the IPv4 that we know - it's rather something like IPv4.5.
Instead of inventing new IPv4 mutations and pouring energy into getting them adopted across the Internet, causing incompatibilities and countless lost hours of debugging, adopt IPv6 instead.
Why would anyone even bother. All the scripts and programs that were hardcoded to treat 127/8 as loopback and 0/8 as various default routes would need to be changed and more importantly, verified. You wouldn't want anything that's hardcode bind to, say, 127.48.47.218 as localhost to suddenly be routable from the internet.
I vaguely recall Cloudflare uses a huge chunk of 127/8 as internal loopback addresses for their edge servers. Without Cloudflare's support this proposal is DOA.