The IPv4 Cleanup Project
github.com
github.com
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.
https://mailman.nanog.org/pipermail/nanog/2021-November/2164...
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.
This whole IPv4 address mining thing is only relevant because updating is hard.
...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).
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.
* 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.
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.
Besides, since XP doesn't install IPv6 support by default (and these people never update), we should ditch IPv6 too?
No one wants to be bound by 20 year old never updated installs of ancient OSs, so let's not.
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.
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!
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.
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.
I'd be interested in the CF example if there is a doc.
I recall a lot of use in routers as well, but haven't personally used those setups.
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.
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
https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios...
This should also be a candidate for careful extrapolation:
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 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.
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.
It's not the opposing side's fault if your solution is practically infeasible and wasteful.
(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.
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.
Statefull firewalls still exist with IPv6, so by default connections from the general Internal cannot connect to your 'internal' systems.
Hole punching still needs to be done with UPNP/PCP
* http://upnp.org/specs/arch/UPnP-arch-AnnexAIPv6-v1.pdf
* https://en.wikipedia.org/wiki/Port_Control_Protocol
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.
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.
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).
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.
+1
> Yes you can traverse NAT
Not always. My ISP uses CGNAT, which means I have absolutely no straightforward way to break out.
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.
IPv6 is IT's esperanto.
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)
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.
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.
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.
The truth is that if you are not tunneling over some kind of VPN or using onion routing your IP is public, period.
NAT is not a security mechanism. most consumer routers seem to block any incoming traffic from the outside world by default anyways.
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.
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...
It also means that you never experience port exhaustion on large networks, which is a problem for large IPv4 NAT deployments.
If you think NAT gave you any privacy benefits... at best it made for easy "household mapping" of people.
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.
Of course, firewalls are usually configured to prevent that. By default, on a home router.
But changing roles in the firewall is simpler without the need for port forwarding.
And at least my own home router does indeed use the same configuration interface for both IPv4 and IPv6.
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.
One of our drafts was posted and discussed on HN two days ago
https://news.ycombinator.com/item?id=29246420
and as I mentioned in that thread, the complete set of four drafts is
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
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.
This smells of engineers saying “why not just do Y so we get X?” without realizing that in the real world, X is not an achievable state.
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 :)
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).
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.
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).
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 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.
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..
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.
1. https://lostintransit.se/2020/05/22/its-2020-and-androids-ip...
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
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.
I think there is proof of the opposite in how people host giant torrents without much issues, some buy seed boxes, their friends use it too.
Any attempt to keep IPv4 alive is not a net win. It's another few trillion down the drain.
The worst part is that now it's not just baked into the network layer, it's baked into security assumptions as well. What a mess.
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.
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.
Reliability would have been horrendous. Stuff would disappear forever much more than it does now. It would have been slow because of limited upstream.
It would have also killed the bandwidth of people not hosting themselves if they were on DOCSIS? ( cable modems ).
Still people are generally not NATed on a home/business connection. NAT is not the problem.
Why would you want to do NAT in IPv6? You can do all the things you mentioned with IPv6 without NAT.
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.
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.
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.
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.
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 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?
RFC4941 or similar privacy extension stuff might explain this.
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.
In my previous company of 250+ people only 2 had iphones.
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.
For a lot of folks, for internal purposes, OSPF would also work pretty well (or IS-IS).
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.
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
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.
If suddenly everybody has an ipv6 accessible device, there will be sooo many hacks
Not really though? Just because the router no longer does NAT doesn’t mean it’s no longer a firewall.
There is nothing to test either because this is exactly how SOHO routers have been working for decades.
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.
What are we supposed to do until IPv6 adoption reaches 100%? Just say that only existing v4 holders can have dual stack sites?
also, i lost 8 kilos by both eating and exercising less, so your metaphor isn't even true