Won't happen in my lifetime
I'm 49.
In the World of Tomorrow that's always 10 years away, Linux dominates the desktop, quantum computers control the fusion reactors, and all Android phones receive regular system updates. And the internet runs on IPv6. This sort of talk irks IPv6 stans, mostly because it's true. They are serious-minded, far-seeing, sober …
I'm also 49, I've worked in IT for 27 years (developer, networking, now a global CTO) and I agree. The IETF needs to fall on its sword and accept that it has failed.
Look at the failings of IPv4, look at the barriers to adoption of IPv6, and find some middle ground. IPv6 throws the baby out wit the bathwater.
Take NAT for example. Yes, people see it as a challenge. But it's great for having simple firewall rules, where the default is to disallow all inbound traffic.
Take addressing. Anyone in IT can easily remember IP addresses as they walk from one end of the office to the other; IPv6 address blocks are longer, with hex, and are just less memorable.
Take the concept of all devices having a public IP address. Maybe I don't want that?
I'm not posting this as an AC, and I'm happy to be shot down. But I don't think I'm wrong. If IPv6 brought enough advantages, the challenges would be overcome, people would find a way. But there are very few advantages at the "IT department level" and the "end user level", so there's simply no appetite for the effort.
I think you've got the point exactly with the IT Department and end user levels. And both may very well be the points where IPv6 will see adoption rate rise later on: end users migrate in their flocs to big everything-as-a-service providers (Google, Apple, Microsoft) and care less and less about the raw infrastructure, as everything to the smallest smart whitch in the closet is set up through an app, not manually. End users are migrating from IPv4 not to IPv6 but to QR codes. Smaller IT departments look much the same, difference being in what's deployed but not how. A willingly implemented NAT solution may become a thing (Internet-facing network port being configured for IPv6 and everything behind it running on IPv4, including the DMZ, with some good old port translation thrown in the mix).
Maybe we are now just waiting for people to stop giving a damn about how the Internet is run and stop taking part in its operations, so that the ten to twenty remainig big guys can do their thing.
Internet-facing network port being configured for IPv6 and everything behind it running on IPv4
As a very (very) small-time admin of a very, very small network (in the grand scheme of things) I think this might just be the easy way out. There is absolutely no compelling reason to convert my LAN to IPv6, particularly as a pure v6 network would break quite a lot of kit which will never be v6 capable. There are plenty of v4 addresses available for any conceivable LAN use, and as pointed out NAT is a really simple first line of defence.
So it's down to DNS then I suppose. If some internal kit is IPv4 only, how does that address a v6-only internet? I have absolutely no experience in this area, but could some kind of "reverse" NAT work too?
Speaking personally, v6 addresses are just impossible to remember, even if you can "filter out" the common parts. I have a very "regular" LAN IPv4 addressing scheme and I don't always need to look up the address of a bit of kit I need to contact in the database, which makes things a lot quicker!
M.
Sort of this already exists, it's only not been talked about much, I think. Every company in Europe with internal IT I know of uses some sort of MITM solution (Sophos UTM being the favourite), they already decrypt tls connections (and issue their own certificates on the fly, signed by their own local CA). The integrated solutions tend to be quite complex and resource hungry, adding a DNS/IP translation would mean little overhead on top of what's already approved, installed and running.
IPv6 does make a well working DNS solution much needed. Using IP addresses directly should be already frowned upon, anyway, but as an emergency solution when DNS doesn't work. Assigning easy to remember IP addresses to the few critical devices is the way to go.
> Using IP addresses directly should be already frowned upon
I'm a sysadmin, not networking, so can only speak as to what our network admins want from us.
Our network team when setting up load balancer VIPs always want IP addresses for the destination hosts the load balancer is balancing, or IP addresses for firewall rules, IPSEC and so on. Part of that might be because DNS isn't managed by them, it's managed by the Windows team since it's (I believe) built into AD, therefore sometimes we have IP addresses weeks before we have DNS entries (not all servers are Windows servers that get automatically put into the AD-based DNS system).
And when troubleshooting complex systems internet -> gateway -> NAT (for security) -> load balancers -> firewall -> ESBs -> load balancers -> firewall -> servers it's often just easier to go by IP to avoid extra steps in getting IP logs from network devices/appliances and converting them to DNS names then back again for the next hop.
That you have to work often at the IP level doesn't mean you need to access your firewall/load balancer/whatever by IP instead of hostname. A fully working DNS will also act as your IP addresses database, when needed.
"therefore sometimes we have IP addresses weeks before we have DNS entries"
That is an issue of your process. We don't have, for example a "WIndows" or "Linux" team - as long as the network is an hybrid one, sysadmin have to be able to work on both at least for common tasks. We have AD experts for complex configuration, but not for DHCP/DNS management.
Sure, and it's not like v6 stops you from doing that.
Put your router at <prefix>::1, DNS at <prefix>::53... that's pretty memorable. You'll remember your prefix easily enough after a while, or you can just look at `ipconfig`/`ifconfig` and copy it from there if you need to.
Also, having v6 doesn't mean you don't have v4, so nothing stops you from connecting over v4 to fix your DNS server -- unless you break your v4 somehow, in which case having v6 as an alternative is handy.
Our network team when setting up load balancer VIPs always want IP addresses for the destination hosts the load balancer is balancing, or IP addresses for firewall rules, IPSEC and so on.
Same in pretty much every company I've worked for. And same for my home network.
Networking works on addresses natively. Using names would require reverse lookup on every rule (or worst case packet). Sure you could no doubt cache the results. It would still require that internal lookup.
Also we all know DNS is spoofable, would you really want to trust your firewall (or even routing) on potentially compromised information?
Add in a few more LB’s and Firewalls and I’d say we worked in the same place.
Networks work on MAC addresses and IP addresses. Names must be converted to IP’s so that devices on the network can respond with their MAC’s to enable the data packets to be forwarded.
Remember the phone directories? They enabled looking up a name and getting the number to phone. That’s effectively what DNS does.
NAT does not provide security, it hinders it because you have to correlate logs containing multiple different addresses, and thus keep a LOT more logs.
A stateful firewall provides security, and works better without the added complexity/overhead of NAT.
Also if you do use DNS names in your firewall rules, that just means the firewall will perform a dns lookup once and create the ip-based ruleset based on the results of the lookup. It doesn't do a DNS lookup for every packet.
There is no reason IPv6 cannot be manually assigned (and it would typically be for servers and networking devices) and you can use whatever addressing schema you want.
You can get a single large IPv6 block, whereas any org of significant size probably has multiple disparate ipv4 blocks all over the place. You have a single static prefix, split out your vlans from that, and then you can assign the hosts ::1 ::2 ::3 etc if you want.
IPv6 is easier in many ways and removes a lot of headaches, those tho think it's not have generally only glanced at it but haven't made the effort to learn about it properly.
NAT was not intended as a security feature. However, it's an undeniable truth that the IPv4 NAT defaults of "nothing is addressable from the internet" has certain security advantages relative to IPv6's "everything is addressable on the internet unless you correctly configure your stateful IPv6 firewall"
Since the average home user doesn't even change default passwords etc having their TV, smart fridge and smart light bulbs addressable on the internet becomes a bit of a hazard.
"Since the average home user doesn't even change default passwords etc having their TV, smart fridge and smart light bulbs addressable on the internet becomes a bit of a hazard."
This is what a firewall does. All domestic routers/firewalls default to refusing incoming connections, so nothing can be reached from outside. Besides trying to find devices on IPv6 addresses takes a lot more effort due to the shear number of addresses.
I'm constantly getting hit with all manor of probes and hack attempts on my IPv4 address as is everyone, yet nothing on my IPv6 address.
Obscurity is the issue, IPv4 is Ubiquitous, IPv6 is niche, why go to the effort of scanning IPv6 space when there's plenty of low hanging fruit available on the easy to use v4 space.
It's the same reason there used not to be malware for mac, but as it became more prevalent, there is more profit in it.
v6 is just the DIAMETER to v4s RADIUS, both the first two are better protocols, but the second two are in use, people don't like change, and several features have been backported to make them last longer.
IPv4 addresses aren't exhausted, just their allocation is. a good 90% of them just aren't seen on the internet.
TBF if the internet core was run on v6 with BGP and everyone used NAT and RFC1918 addresses internally, there is no need for the added complexity of v6 inside an organisation
the NHS internally uses the RFC 1918 class A space and it hasn't exhausted it yet.
with proper use of NAT and CIDR and a re-allocation of unused addresses, v4 can last for a long while yet.
IMHO when they designed v6 they went overboard on the address space, there are enough v6 addresses for every atom of every person on earth to have 7
It's not really niche when it has almost two billion users. v6 is just hard to scan because it's so huge. Exhaustively scanning one /64 requires something like a million terabytes of traffic. If you're on a regular, slow 10 Gbit/s link that'll max it out for thousands of years.
(Obviously there are methods of finding hosts that aren't exhaustive scans... and people do use them on v6. You just won't see a constant stream of opportunistic scan attempts on every single address for every minute of every day.)
IPv4 addresses aren't exhausted, just their allocation is. a good 90% of them just aren't seen on the internet.
When we say exhausted, we mean that people have to take measures to conserve addresses due to not being able to get enough of them. The beginning stages of exhaustion happen when people start needing to do that. We're deep, deep into it for v4.
Also, due to the way hierarchical aggregation and routing works, most individual IP addresses don't end up assigned to actual end devices, so "I haven't seen any internet traffic from 90% of addresses" doesn't mean that v4 is only 10% used.
I'm also going to point out that there are more individual devices than there are v4 addresses, so there's not going to be enough no matter how you slice them.
TBF if the internet core was run on v6 with BGP and everyone used NAT and RFC1918 addresses internally, there is no need for the added complexity of v6 inside an organisation
You mean the reduced complexity... and you would in fact need it, since v4 doesn't handle more than 32 address bits.
the NHS internally uses the RFC 1918 class A space and it hasn't exhausted it yet.
But the fact that they're using it at all is an indication that v4 is insufficient. Why go to all the added complication otherwise?
IMHO when they designed v6 they went overboard on the address space
Absolutely! Overboard is good. We want to have more address space than we can use, because the alternative is that we'll end up using it and will need to deploy another extension. As you might have noticed, that's a very difficult, expensive, long and drawn-out process that we really only want to do once.
As you might have noticed, that's a very difficult, expensive, long and drawn-out process that we really only want to do once.
It's very difficult because it tosses out all of the ipv4 knowledge base of everybody involved and replaces it with something that builds on none of that knowledge, and works against what people know and want.
It's expensive because everybody needs extensive retraining from the existing ipv4 mindset of having to NAPT addresses to learning how to mitigate against security holes created by ipv6 attempting to make everything addressable on the internet by default.
I'm ignoring equipment replacement on the basis that it's all replaced on a 3-5 year schedule anyway. The deployment process is therefore long and drawn out because of the two problems above, so the problem is entirely self inflicted as practically every bit of equipment involved has been replaced at least 4 times in the last 20 years and so would have been capable of running it if it wasn't actually to peoples detriment.
If there was a new IP protocol that basically copied the IPv4 concepts and structure and did nothing but add an extra couple of coulons in ipvNext then the rollout would be almost painfully swift because there is no training required as everybody knows what it's going to do which reduces the issue down to writing the code and waiting for it to be deployed. (which will naturally happen within 5 years of the code being written due to normal equipment replacement)
This immediately moves from ipv4's 254*254*254*254= 4.1 billion addresses to 254*254*254*254*254*254= 268 trillion, 535 billion addresses with zero user opposition.
As we've gotten used to being stingy with handing out ipv4 addresses then moving from 4 billion to 268 and a half trillion addresses (an address space increase of ~6,713,275%) will last effectively forever if the same policies as to handing out addresses from ipv4 carries over. Even if you assigned a top level block to each country then you'd still have one trillion, 57 billion addresses for each country with a spare 59 blocks that size spare. Even for China that'd give ~704 IP addresses per person, which appears to be sufficient for any rational purpose.
You the other reason to make the address space so huge: sparse routing, which helps speed up turnover time when it comes to routing. One reason IPv4 routing is becoming such a pain is because you can't use geographic or tree-based routing optimization since two nearby IPv4 addresses may not correspond physically. With IPv6 having up to 64 bits in the front half to work with, they can split things more finely and still be able to do optimal binary routing searches. Wouldn't you like a little less lag in your Internet?
It doesn't toss that knowledge out. Most aspects of v6 function exactly the same as v4, just with longer addresses.
The extensive retraining for security shouldn't be that extensive -- if you know how to secure a v4 network, then you already know how to secure a v6 one, so just do that. No retraining needed. Not having to put NAT on top is a simplification that makes everything easier.
As for using 48-bit addresses... it wouldn't be enough. We don't want to be spending all this effort deploying a new protocol that's still so small that we need to continue being stingy. It would also require doing all of the same things that we've needed to do to deploy v6, and would have the same compatibility properties as v6 does, so it wouldn't help on those fronts.
If there was a new IP protocol that basically copied the IPv4 concepts and structure and did nothing but add an extra couple of coulons in ipvNext then the rollout would be almost painfully swift because there is no training required as everybody knows what it's going to do which reduces the issue down to writing the code and waiting for it to be deployed. (which will naturally happen within 5 years of the code being written due to normal equipment replacement)
If they literally just swapped ipv4 addressing for ipv6 ( you can’t just swap the address part in an ipv4 packet with ipv6 as a lot of hardware / software and acceleration requires knowing where in the bit stream the addresses and ports reside) it would have been adopted a decade or more ago. They put too many barriers in the way and tried to convince the world that what they perceived as problems where engineered out in ipv6. The truth is that how people used ipv4 matured far ahead of ipv6 and the ipv6 solutions for the ipv4 problems where suddenly outdated and lacking finesse.
They put too many barriers
There really are very few barriers, and for most users changes like doing ND with multicast instead of ARP with broadcast are invisible. A lot of the complaints I read in these threads boil down to "it's not identical to what I know and learning who to handle the letters a-f is too hard. OK, I suppose some people are also thinking that it takes an extra keystroke to do a : instead of a . - but then using hex instead of decimal will save keystrokes.
I'll be blunt - and I don't care that I'll get downvotes for saying it - but learning IPv6 is no harder than learning IPv4. That it seems harder is (for most people) simply down to the fact that they have already learned (enough of) IPv4 and so learning for IPv6 is extra compared to what they have already done.
As an analogy, I could say that German is a much harder language than English - for me it is, but then English is my native language, while German is something I sort of learned at school. For someone born and brought up in Germany, I imagine English is considered a harder language - and if you take a step back and look at them, English is a far more complicated language to learn.
I'll be blunt - and I don't care that I'll get downvotes for saying it - but learning IPv6 is no harder than learning IPv4.
That’s a bold quote for someone who doesn’t understand why networks should be carved into small broadcast domains and why routing between subnets isn’t hard or complex.
There are a number of key differences between ipv4 and v6, aside from the address space and numbering, that complicate any transition.
These differences where baked into the ipv6 standard and argued over for decades, some of those differences have been relented (NAT, DHCPv6, privacy extensions etc etc), more need to do so.
Depending on your gear, you may not be configuring them separately, but they work the same in v6 without NAT. The basic stateful firewall rule defaults to block all inbound traffic not associated with an existing connection initiated from the local network.
NAT only means they have to guess what the local address scheme is, or listen for a leaked address. That won't take long if starts with 192.168 :) Try port scanning a v6 block, it will take a while and probably flag your firewall/IDS too.
Not to say there aren't potential deal breakers waiting. Just don't let fear of losing the protection that NAT offered care you.
Setting up IPv6 SHOULDN'T be as hard as it is. Your local router should be able to pick up the advertisements and handle issuing and managing everything. In most cases it does not, and you have to configure everything manually, to the point of typing IP and MAC addresses manually, because some dunce JavaScripted Ctl-C and Ctl-V out of existence.
All that is just inconvenience though, for us the deal breaker is that we can't deliver the expected performance to our users as far as load balancing and failovers on multiple internet connections. You can bodge something with an outside host or pay a CDN like cloudflare to give you with a provider independent address block that can fail over or load balance.
But if you do that you could also just use Wireguard on IPv4 and get to the same place in a few hours, and probably not be paying aother private company every month to boot.
The last thing I want is "advertisements" clogging up my bandwidth and capturing my network. I'm still chasing down modern Apple notebooks that are spamming me with NETBIOS. And DHCP mostly works -- although I've experienced the common problem of ISP DHCP leakage at router restart -- but I have no desire to move any of my servers / utilities to dynamic IP.
And NAT is a stateful firewall. It's a stateful firewall that also does address translation and port randomization. You may argue that NAT 'really does not prevent fires from moving from one part of a building to another", but that's a sophomoric semantic argument.
NAT isn't a stateful firewall. Stateful NAT requires state tracking and so do stateful firewalls, so they're often implemented together (e.g. netfilter on Linux), but that doesn't mean that NAT is a firewall.
NAT rewrites the apparent source address of outbound connections. That's all it does; it doesn't decide which packets to drop or not drop.
NAT decides to drop incoming packets that aren't matched by outgoing connections, and it maintains state in order to do so.
'Stateful firewalls" are doors in the firewall. "Stateless" firewalls are windows.
The idea that a firewall should be equally effective from both sides has merit, but it's not a universal rule for any firewall, real or metaphorical.
The assertion that it's not a real firewall if it doesn't have doors and windows is just tiresome.
No, it doesn't. All it does to incoming packets is rewrite their dest address header, and only if they match a connection that's being NATed (or a static port forwarding rule); it doesn't decide whether or not to drop incoming packets.
NAT is not specifically for security, it is also useful for privacy-related concerns. With 1-N NAT (rather than N-N) the outside world sees a single IP address regardless of how many devices are behind that address.
Even with IPv6 there may be reasons I do not want the outside world to "know" how many devices traffic is to/from or being able to (easily) distinguish between internal devices and so NAT66 has a place.
Also IPv6 has NPT (Network Prefix Translation) which is N-N NAT, useful if you are a "small" organisation (i.e. without PI address space and BGP) with more than a single Internet connection as this can map each of the Internet connections' external address prefixes to/from an internal (ULA) prefix.
NAT is not a firewall. It just happens to make it hard to originate connections from 'outside'. Any competent end-user router should have a default-deny rule on the Internet connection for both IPv4 and IPv6: if you want incoming connections you can then choose what to allow (and it will be much easier on IPv6 than on v4 single-address NAT).
IPv6 has client privacy built in. Most end-user devices have this turned on by default, so they choose a new random address to originate connections from every few minutes (tunable parameter). Every IPv6 subnet has 64 bits of address space so there is LOTS of space to hide in :-) Obviously you don't do this for servers, and probably not for corporate desktops either.
Hiding multiple hosts behind a single address is only a hindrance...
With IPv6 you are only trackable to the /64 which is equivalent to a single ipv4 address, the addresses inside are random. Only you know what's inside, an external party can see multiple random addresses but has no idea what they are.
On the other hand if you get an abuse report that one of your devices is infected with malware and is spamming it's much easier to track down temporary address usage rather than logging every packet going through a nat gateway. In either case only you can do that - an external party can't get that info, but one requires considerably more effort/cost on your part.
@pavel petrman
"I think you've got the point exactly with the IT Department and end user levels."
I think you've seen the future, and it's the same one I've been seeing for years. The Interweb is dead, what will emerge in the next few years will largely be dominated by the mobile computing ecosystem (which also means it won't be a Wintel-centric world any more).
We shouldn't mourn the loss of Wintel, we should mourn the loss of data sharing and interoperability caused by the fragmentation of the Internerd into a set of interconnected boxes working with un-interoperable walled gardens.
So do I offer you an upvote or a downvote...
You should want that. The reason Facebook, Twitter, TikTok and so on have massive amounts of power today is because IPv6 hasn't been adopted, devices don't have a public IP address and peer-to-peer networking is impossible.
Hand me a global internet where every device has a public IP address and tomorrow I'll give you a social network where you actually connect with your friends instead of connecting to Facebook. Until then, any attempt to build it will drown in user complaints that it doesn't work. Or doesn't work on some of their devices. Or doesn't work when they're at work or at their friends' house. Or doesn't work when they roam onto the wrong mobile network. Actually, none of those things; the complaint will be that it just doesn't work because the average consumer has no idea how to figure out that it's related to any of those things and shouldn't have to care.
>peer-to-peer networking is impossible
Much is made of peer-to-peer, don't remember there being a lot it in the pre-NAT era.
But I doubt it will work in the IPv6 era either to any great extent because as others have pointed out the IPv6 address isn't intended for humans.
So for peer-to-peer to take off it needs a human friendly addressing scheme and translation service, which as we know involves a third-party and probably won't look very different to what a user see's today:
<app handle><subscriber id>
"I overlooked those few years when PC's were directly connected (via a modem) to the WWW, rather than through a router/modem"
Few years? You mean from 1992 (when Demon launched dialup), through 2000 (when BT *started* to offer limited ADSL availability), and then probably at least another 5 years after that before large numbers of people were on ADSL? So at least 13 years you mean...
There well may still be some small number of people out there on dialup to this very day...
The reason you can't connect directly to other hosts has more to do with firewalling than NAT. Piercing NAT from inside a firewall is a solved problem. BitTorrent proved that decades ago.
Their are a dozen P2P file sharing networks and P2P Facebook knock-offs. Several of them make onboarding new users pretty painless. They have failed to set the world not for technical reasons, but for humans ones.
Facebook and google have market share, mind share, and user inertia. Even a free, easy to use service that is BETTER will fail unless it can outspend both of them. An added issue it that without the (Hard, expensive, intractable) problem of content moderation solved, any free or egalitarian p2p network gets blitzed by terrorists, hate groups and spammers.
Once they set up shop, no one else want's to hang out there anymore.
But even if you sort those issues out, you're still gonna get Zucked and run into the ground by a couple billion $ signs.
Piercing NAT from inside a firewall is a solved problem. BitTorrent proved that decades ago.
No, it proved that some of the time, with sufficient wasted effort from devs, the borkage of NAT could be worked around. If it was "so solved" - why then do (did) clients have so many NAT related settings ? Why were support forums full of threads about getting the client working properly/at all ? Why support pages/thread about how to manually configure port forwarding in your router and matching the settings in your client (because that is the ONLY way to guarantee full operability with other clients) ?
Looking back, a not inconsiderable portion of my time has been spent dealing with problems caused solely by NAT. The problem was not so much solved as worked around by a great deal of effort that would have been better spent on other things. E.g. if the devs hadn't had to deal with NAT, they'd have had that time to write better software, code features, ...
CGNAT is worse and will be coming to more and more users over time.
because IPv6 hasn't been adopted, devices don't have a public IP address and peer-to-peer networking is impossible.
Eactly, people need to be careful what they wish for. Over the last twenty years or so network services that were open and decentralised have been replaced by centralised services. So things like Messenger are proprietary and harvested for advertising. This is even truer for ancillary functions (cloud print, Ring style doorbells) which end up inevitably going through commercial services because of the lack of end-to-end connectivity. There's always plenty of anguish ahere about dependence on such services, that is only really tenable if you are willing to opt for resolution of the core issue.
Aside from end to end connectivity NAT brings pletny of other issues - yes, performance has been both cited and challenged here but it's difficult to even conceive of a hardware routing backplane that can handle NAT. From a user perspective how many network forums have been utterly ruined by random teens asking "how can I set my NAT type to moderate?" or similar every two minutes?
As for security, of course that is a consideration. IPv4 or IPv6 doesn't change that. NAT doesn't somehow hide the nodes on your private network - assertions of the contary lull users into a false sense of security. In reality this simply trusts your ISP to keep your LAN secure.
News flash - if your ISP routes a packet to you with a destination address in your private address range it gets routed to that private node even though it originated on the WAN side. That is precisely how NAT is supposed to work.
I've said before if you want to see mass adoption of IPv6 the way to do it is to prent it as the "easy" option when setting up the likes of Playstation and Xbox. End-to-end connectivity with no messing around with NAT settings. If you want to use IPv4 these are the hoops you have to jump through, which is in reality no more than you have at present. ISPs would be falling over themselves to roll out support. Perhaps then we'd have networking like it was orignally intended and not this crippled world where bodges are presented as "features".
"As for security, of course that is a consideration. IPv4 or IPv6 doesn't change that. NAT doesn't somehow hide the nodes on your private network - assertions of the contary lull users into a false sense of security. In reality this simply trusts your ISP to keep your LAN secure."
Well, it depends. NAT does not 'hide' your internal machine. It's not obscurity or invisibility. It adds an extra 16 bits (the port number) to the address of a single system, while effectively blocking all of the rest of the ports to that system.
So there is no 'hiding'. Via the (normally ISP grade DHCP for home users) router IP address, someone on the internet, with the DHCP information from the ISP can identify where the system with the NAT'd address is. To identify the exact machine you will also need the ephemeral address/port table from the firewall, which may no longer exist if you try to retrospectively try to find the system, but it is possible to approximately locate the system.
But what you gloss over is that trying to directly talk unsolicited to a specific non-NATd port on the 'hidden' machine will fail. This is the security you get with NAT. It's not magic, and it's not invisibility, but it is some security.
Want to probe one of the SMB ports on the hidden machine? You can't. The port (the SMB one on the firewall or broadband router) will probably either be closed, or possibly be redirected somewhere completely unexpected (altough even that's unlikely, given that NAT only forwards inbound packets on established connections). I think that you've forgotten the 'established' part. Trying to get to a system on the internal side using the address and port number of an established NAT connection, but from a different system on the Internet will fail. It's not a general port-forwarding route (and it's certainly not PnP routing).
What it allows is the end user to mostly forget packet ingress security. Do you remember when systems attached directly to the Internet using a modem or USB router? If you didn't have a 'personal firewall' installed on it, you would probably end up with some successful direct attack on your system. Since NAT became the norm, this level of concern mostly went away. This is not a trivial level of security.
Where raw IPv6 changes this is that the internal system is directly identifiable from it's address (even temporary IPv6 private address parts will tend to persist for long periods of time). An IPv6 boundary router will still be able (and should for security) to do port filtering to prevent packet ingress to specific servers, but it does little or nothing at all to hide a system.
“ News flash - if your ISP routes a packet to you with a destination address in your private address range it gets routed to that private node even though it originated on the WAN side. That is precisely how NAT is supposed to work.”
If 1million domestic users are using private addresses, aka rfc 1918 addresses, how does an isp know which of those million customers to send that traffic too?
ISPs drop private addresses.
Nat uses the outbound initiated src port dst ip & dst port combo to know which internal ip to route traffic back to.
If the src port overlaps it uses a different one.
Consider nat like a dynamic firewall, it does not permit unsolicited inbound.
There are probably millions of devices with up address 10.0.0.1, 10.0.0.2 and so on. One of them on your network. Your isp can’t rout information to it, because it doesn’t know _whose_ private network it is. Only your own router can, it knows 10.0.3.19 is a device on your own network. Never goes to the isp.
To be more accurate, your ISP can't route anything to that network because they're not connected directly to that network. To get a packet to your network, the ISP has to send it to your router first, and then your router passes it on.
You should realize, however, that your ISP can do that. They can send whatever packets they like to your router, and they can put 10.0.3.19 in the dest header of those packets if they want, and your router will happily route it onto your network. NATing your outbound connections won't stop these inbound connections either, although a firewall configured to block inbound connections will.
Also, this behavior is exactly the same regardless of what network range you're on. It would work the same even if only one machine had 10.0.0.1. It would work in any network range, v4 or v6, not just the RFC1918 ones.
"News flash - if your ISP routes a packet to you with a destination address in your private address range it gets routed to that private node even though it originated on the WAN side. That is precisely how NAT is supposed to work."
Nope. Your ISP routes a packet destined to your single public IP address and then your NAT gateway (typically your router) then maps that (plus the destination port) to your relevant internal private address and port, rewrites the packet accordingly and forwards it on internally.
Unless your comment was written assuming that the NAT gateway/router was supplied by your ISP. Even then your ISP still routes to the public address managed by the NAT gateway, not to the private address - only the NAT gateway has a mapping table to match that to the relevant private address and dest port number.
Not quite..
There will be no route to the internal address range from the outside by default because the isp's routers don't hold such a route entry. But there is nothing stopping a rogue isp (or compromised router, or compromised other customer device in some cases depending on network setup) from inserting a route to your "internal" address space via the external address of your router and then sending traffic that way.
It can work the other way too, supposedly "private" address space at the isp often ends up being routable from their customers' machines.
You would need a compromised router, and even then, if the ISP tried to advertise a route for one of the recognised private address ranges (10.*, 192.168.* etc.), it would probably at the minimum be ignored by their upstream provider or peer ISPs, or at worst, get that ISP blacklisted for breaking all the rules for addresses in private network ranges.
Routers running NAT will not forward any packets inbound unless they have an entry in their NAT translation table to allow packets. And this will be for "established" connections only (the From address and port must match the table entry that was made when the "outbound" connection was set up).
From a NAT perspective, everything else will be dropped.
But that is not to say that a router can't have other port forwarding rules beside NAT. For example, many have what they refer to as a "DMZ" route (although not really a DMZ) that forwards either specific ports, or in some cases, all packets not matching other rules, to a single IP address on the internal network. This allows you to put another firewall inside the router to provide alternate and possibly more controllable packet filtering (for many years, I had a Smoothwall instance to do just that).
Of course the joker in the pack is uPNP, which is always turned off in my network, because it has the potential to break all of your carefully crafted firewall security.
You would need a compromised router...
Routers running NAT will not forward any packets inbound unless they have an entry in their NAT translation table to allow packets.
No and no. Any router will route across NAT in the circumstances described. By design. The A in NAT stands for address, the inbound interface is not a consideration. The packet hits the routing table and gets routed accordingly, where it came from is irrelevant to the routing logic. From the routing table it may or may not get bounced to NAT when leaving the router, but that won't happen if the destination is a local subnet. That packet sent to 192.168..., 10.... Etc gets forwarded with no consideration of where it came from.
If you don't believe me try it, you can do this with any home router with a WAN side ethernet port, a pair of Linux systems back to back, or even something like Packet Tracer.
I won't get started on what is meant by an "inbound" interface - the very concept is meaningless outside the realm of domestic and toy networking. Just do some reading and find out how this stuff works. If you regard NAT as some form of firewall you are in reality outsourcing responsibility for security to your ISP and potentially other service providers.
To elaborate, ALL the NAT part of the stack does is translate packets as to their sources and destinations. Outgoing packets get rewritten as coming from the Internet-facing port, and incoming packets gets rewritten as going to one of an internal host according to its internal rules; if could be from an existing outgoing connection or towards a port with a known rule. If it happens to receive a packet directed to an internal address already, it wouldn't have a rule in place to change it, so would pass it along unchanged.
Everything you attribute to the NAT about dropping packets and so on happens at the firewall, which is deeper in the stack versus the NAT. It's the firewall that would receive a packet with an internal IP destination (it probably wouldn't come from the greater Internet since it's likely to get dropped as invalid, but the ISP itself would have nothing between it and you), not recognize it as part of an existing connection, and drop it. And the reason this works is because the firewall can keep track of the connections in progress (thanks to things like forwarding rules).
And in your IPV6 P2P social media.
They will ask why can't I see my friends post. Turns out their phone has been turned off because they are in a theater (or they are out of range) and you have to wait until they are out of the theater before you can connect to them
I fully support.
Not only that but the original IPv6 developers did not see the need for enterprise multihoming, until 2009 there simply was no equivalent of IPv4 PI (Provider Independent) address blocks. Combined with how painful public DNS change propagation was back then, IPv6 at the time could not provide network-level disaster recovery and was a huge ISP lock-in. Also, by the time IPV6 was well supported in hardware, exposing the internal network to the Internet was no longer in vogue. So migration to IPv6 was simply not worth the effort.
Nowadays IPv6 is mostly on par with IPv4 feature-wise (if one is good at remembering very long numbers). It also means that running dual-stack in the internal network does not make any sense, while implementing and operating IPv4 is still much more simple. I do have a client who are running out of RFC1918 even with VRFs and address reuse but it's a really, really big one.
For the Internet-facing services dual-stack is fine to maximize reachability.
One of the main arguments was about IPv6 faster to switch in hardware, well IPv4 is still switched just fine and SDNs are happy to hear that.
Take the concept of all devices having a public IP address.
Hmm ...
All devices?
Maybe I don't want that?
You'd be quite right if you don't.
I understand why the usual crowd (governments, CIAs/NSA's, Apple, MS, Google, Facebook, YouTube, etc.) may want it that way.
But I don't see the need for all my devices to have a public IP address.
So no, I for one don't like that at all.
Things are bad enough as they are.
O.
While long lived addresses present some privacy challenges, that isn't just an IPv6 problem. Even NAT isn't bulletproof, and most of the tracking that is happening isn't IP level.
For the connections that would be protected at all by NAT, it actually isn't as big a gap as people think.
Stateful firewalling protects both v4 and v6. In v4 with NAT, an attacker has to guess at a private address range potentially. There are three of those reserved, or you are NATing one public address to another.
In v6, behind the same statefull firewall, you can issue whatever address to whatever device you want, for as long or as short a time as you want. The address range of the block is public information, but the address space is vast. That means a few things.
First is that port and session tracking on v4 reveals alot, and other forms of tracking much more, about indidual end points activity. Rolling over v4 or v6 addresses still wrecks your open sessions, so you have to set a reasonable lease time on either. On v6 an attacker then has to track and correlate potentially billions of addresses, and a linear scan of those addresses isn't any easier than guessing port and sequence numbers from a NATed v4 session.
For any real security/privacy you need at least SSL, secure DNS, and probably a VPN anyway, so v4 or v6 are a wash there as well.
The problems with v6 when it first "launched" were huge. SLAAC was supposed to make the address length go away, but leaked MAC addesses making cross network tracking automatic. After what 3 decades of being punched in the face over the security and privacy issues, most of that has been fixed. Now security and privacy are mostly about planning your implantation properly and then doing the heavy lifting. That is where I have to take stick to the hardware vendors again.
Right now all the core services for these things are rightly running in different environments in most biz outfits. Separation of functions to limit damage is right there with separation of privileges to manage access. As most of us are still stuck at the command line to configure any complex changes to network gear from the big C on our switches and routers, and the GUIs in most firewalls are stuck in the 90's. Nothing talks to anything else, even though LLDP/CDP/SNMP etc have been around forever.
In a less insane world I wouldn't have to type in the WAN link info to the firewall, or the firewall info to the switches. That's true for v4 too, but we all just rolled are eyes and hammered out CONF TERM or whatever and rolled our eyed.
We also made a ton of fat finger errors and brain farts collectively as an industry(and many of us as indivduals). So it would be great if the gear didn't force me to retype all of this garbage every time I touch a device config. So it would help us for both v4 and v6. In a sane world an out of the box default setup would walk you through creating an IPv4 LAN NATed 4to6 to randomized addresses in your v6 blocks, with all the firewall rules added, all the DNS entries mapped, and all your inbound services mapped to pools of v6 addresses for each of your internet connections. Right now I have to make every one of these changes by hand. In some cases like my firewall, I may have to paste the same info in 3 or 4 times to create both firewall and routing rules, address matching objects, etc.
“ In v4 with NAT, an attacker has to guess at a private address range potentially. There are three of those reserved, or you are NATing one public address to another.”
Most uses of nat is for proxying non internet routable private IP’s behind a single public ip.
I’m guessing you are nanashi
Take the concept of all devices having a public IP address. Maybe I don't want that?
Its unclear what you think won't happen in your lifetime:
If the question is whether IPv4 will be turned off and not used anywhere then that seems unlikely.
If the question is whether the majority of public internet traffic runs over IPv6, then I suspect that is quite likely to happen over the next 10 years.
If you look at Google's IPv6 traffic over the last 10 years then it has gone from 0.4% in Jan 2012 to approx 36-38% in Jan 2022. Perhaps further growth will be slower, but it still seems likely that in 10 years time we will be at 65-70+% of Internet traffic reaching Google being over IPv6.
In terms of IETF, they work by rough consensus, so it would need an individual to submit a draft that states that IPv6 is a failure and that the IETF should work on an alternative internet protocol instead. Several individuals have tried (and some entities are trying to build "NewIP") but so far they seem to be a long way from gathering the sort of consensus that they would need to progress that work within the IETF, partly because it isn't clear what they are really trying to build or what problem they are really trying to solve.
You don't think going from 0.4% of the Internet’s client base to 38% over those ten years means anything?
At that rate, we'll be at 50% in three years. Predicting 10 years for something that ends up taking 13 years is pretty good going for long-term time estimates like this.
Most of the growth in IPv6 on the internet is corporate traffic where large companies have adopted it so their users get it whether they want it or not, and parts of the world where IPv4 scarcity is a real problem so they had no choice but to adopt IPv6 as their population starting coming online.
If you look at the adoption rate for the consumer population of the US and Europe you'd see very little progress being made. Where they are using it is ISPs that have deployed IPv6 including providing hardware to their customers so they are using both IPv4/IPv6 so they are accessing Google via IPv6 without even knowing it. None of them can convert to IPv6 only though because they'd lose access to many sites. Like for instance is wordle's site on IPv6? If not, even the people who are on IPv6 are using IPv4 to access it...
Untill recently you couldn't get consumer IPv6 in the UK. My ISP still doesn't support it so I'm using a 6-in-4 tunnel [free from Hurricane Electric if you want to play too].
As the ISPs have to pay for IPv4 allocations for their customers - if they can get them at all - it will be driven by ISPs providing it to their customers.
The real fun is going to be when ISP have to choose between pushing consumers to IPv6 only or implementing CGNAT. And most people won't care unless their favorite sites are still IPv4 only [cough. Register. cough.]
And the "Big 3" cloud providers still only offer partial IPv6 services to their customers too, so it's not fair to only blame BT & friends.
"Untill recently you couldn't get consumer IPv6 in the UK."
At least a couple of ISPs have offered it for 5+ years (indeed probably far longer).
"And the "Big 3" cloud providers still only offer partial IPv6 services to their customers too"
At long last AWS in November finally offered IPv6 for EC2 VPcs, and quite a few other services. No idea about the other 2 providers.
As the ISPs have to pay for IPv4 allocations for their customers - if they can get them at all - it will be driven by ISPs providing it to their customers.
Irrelevant. The ISPs in the US and EU have sufficient IPv4 address space, and the market is already saturated so there is little room left for further growth thus little need for larger IPv4 address space.
The entrenched players like it this way because they can use this as another barrier to entry, as a new ISP that lacks IPv4 address space needs to acquire it somehow before they can expand into new markets. So they have no reason to push IPv6 adoption and make things easier for smaller, hungrier competitors.
Well... it's worth noting that they don't really have sufficient address space. It's almost impossible to get more than one v4 IP from most ISPs, yet almost everybody has an entire network of devices that they want to attach to the internet, not just one single device.
I imagine larger and larger ISPs are going to end up moving to CGNAT too, since AWS and friends are always in the market for more v4 space, so even getting one single v4 address is going to get harder and harder. This is already happening frequently in Germany and some nearby countries, and I don't see any reason for it to only happen there.
I had native IPv6 in the UK in 2007. There were a handful of smaller ISPs providing it back then, some a bit earlier than what i had.
BT had a free tunnel service way back in 2000 too.
Now BT and Sky provide IPv6 by default and have done for 5+ years, EE and Three do on mobile, and there are still a whole bunch of smaller providers offering it.
Some of the newer providers are using CGNAT, all mobile operators use CGNAT, in many developing countries CGNAT is your only option unless you want to pay massively higher prices for a business service.
I fully agree and have said so much on this very forum.
IPv6 is a failure because
"IPv6 made two very important, interlinked assumptions from the outset: that the world would need more than the four billion addresses IPv4 could support, and that this plus a lot of less important factors justified an incompatible new stack that fixed everything. The first was correct, but irrelevant, and that made the second just plain wrong."
the last sentence says it perfectly. The IPv6 addresses are overly complicated for the sake of being overly complicated, a far easier to read, human-parsable format could have easily been selected (add more tuples? No! Of course not, too easy! We'll remake the entire address paradigm with colons and hex, because we're engineers!!)
And, especially in today's world, who in their right mind wants their IoT device to be directly addressable on the internet with its own 'front door'? Not anyone in their right mind, thank you very much.
> We'll remake the entire address paradigm with colons and hex, because we're engineers!!
They didn't remake the entire address paradigm. The addresses are still a block of binary and they're allocated and routed in the exact same way as v4, they're just 128 bits instead of 32.
Writing them in hex is to make them easier (not harder) to deal with: without it, the addresses would look something like "32.1.13.184.133.163.0.0.0.0.138.46.3.112.115.52", which is even more unwieldy, and subnetting when your numbers are written in decimal is much more of a pain than when they're in hex.
Using colons is to disambiguate v6 addresses from hostnames. Otherwise, an address ending in e.g. ".be" would look like a hostname under Belgium's ccTLD.
> And, especially in today's world, who in their right mind wants their IoT device to be directly addressable on the internet with its own 'front door'? Not anyone in their right mind, thank you very much.
If you're going to use a door analogy, get it right: it's like having a front door inside a gated compound. You've got the front door keeping people out, but they can't even get onto the grounds without going through security at the outer gate.
Note that the security of your house depends on the front door and the gate, not on whether your house has a number on the door. Removing the number just makes it harder for you to use the post system, which is unhelpful (because what's the point in an IoT device that can't communicate anywhere?).
The "I can't remember it because hex" is simply bogus. The address space is far, far bigger and that's the whole damn point.
Here's three options for 128 bits. Which is easiest?
2001:0db8:0000:0000:0000:8a2e:0370:7334
2001:db8::8a2e:370:7334
32.01.13.184.0.0.0.0.0.0.138.46.3.112.115.52
There are other possible human encodings, but at the end of the day 128bits is a long number in any representation. Most humans aren't going to remember that no matter what you do.
This post has been deleted by its author
But, for argument's sake, they could have created a shortened version, such as
32.01.13.184:0:0.0.138.46.3.112.115.52
But the discussion includes topics such as: they could possibly have created "tiers" where the least significant digits in the IPv6 address, that is the 4 octets currently in IPv4's length, could be used for intranetting exclusively.
A large part of the problem why a large majority of people simply don't want to bother with IPv6 is that you must swallow the entire contraption part-and-parcel; even a small home network needs to deal with a 128-bit IP length and configurations. I would say that, according to the rates of IPv6 adoption beyond mobile networks (read: pitiful), the entire world said "Thanks, but I've got better things to do".
How many home users even touch their router that they're given by their provider?
If the provider enables IPv6 it's completely transparent to the end user.
Now that I understand IPv6, it's as easy for me to deal with as IPv4. Was there some things that I had to get used to? Sure. Is it an impossible mountain to climb, absolutely not.
> that is the 4 octets currently in IPv4's length, could be used for intranetting exclusively.
They basically did.
When you understand standard subnetting like having a /64 as a minimum assignment, and having a /56 or /60 assigned to a home, and a /48 is assigned to a building, then everything starts falling into place pretty quickly.
The problem with people adopting IPv6 is that people think of it like IPv4. I've got my personal environments IPv6 enabled now, and it's made my life simpler.
I've just got to train the other network admins at my work and we'll start IPv6 enabling our core. There's no reason why we shouldn't do this that I can see.
I’ve got myself an Apple Airport router for home, together with an openreach modem. Both dirt cheap on eBay, and a lot more stable than my BT home hub.
Turns out it doesn’t support ipv6. Turns out I never noticed. Could anyone tell me what difference it makes to me? Any ipv6 only websites that I cannot reach?
... who in their right mind wants their IoT device to be directly addressable on the internet with its own 'front door'?
First, I would not let one of those IoT devices into my network.
I have not seen one that is not a solution for a problem that does not exist or is firmly lodged within the OEM's marketing droids' febrile imagination.
But you are quite right.
That was exactly my point. (see above)
O.
Snake said:
The IPv6 addresses are overly complicated for the sake of being overly complicated, a far easier to read, human-parsable format could have easily been selected (add more tuples? No! Of course not, too easy! We'll remake the entire address paradigm with colons and hex, because we're engineers!!)
If non-engineers have to deal with numeric IP addresses of either sort then someone has messed up badly. DNS, DHCP, and IPv6 autoconfiguration should hide all of that - and in almost all end-user networks they do it perfectly.
Hex is easier to remember for very large values.
Expanding the address space was essential to do, 128-bit was chosen to be future proof rather than just kicking the can down the road and having to migrate again a few years down the line.
Addresses like 42540766480197409204035921055779438319 would be much worse and harder to remember than 2001:db8:dead::beef.
IPv4 can also be expressed in hex, IPv6 can be expressed in other ways too. The fact that it's not commonly done is because those ways are worse.
Using . as a separator conflicts with DNS, thus : was chosen.
Having a single IPv6 prefix for your entire organisation vs a bunch of disparate IPv4 blocks actually makes things much easier.
An honest and common opinion Jim - and one I have a lot of sympathy with too. But it will happen, IMHO the drivers will be:
o The cost of getting public IPv4 addresses as demand continues to grow (all available address are now allocated to somebody - we're now living off recycling)
o Networks are getting bigger as we add ever more connected things
o Networks are getting more complex, segmenting off applications or even bits of applications from each other means huge numbers of subnets, and devices having multiple addresses too.
o The tools to setup and manage IPv6 will get there. Even consumer broadband routers are getting the capability configure it simply enough.
IPv6 addresses are simple enough really - and everything is a /64 subnet so no more messing with subnet masks (unless you want to break things) - it really doesn't take long to learn something like 2001:db8:1234:0001 which is all you need for networks, and as somebody else pointed out, if you need to allocate host IP you can make life really easy on yourself if you want full control eg ::53 for DNS, ::1 for gateway, ::cffe for your coffee machine.
Simple firewall rules? NAT makes you lazy. How hard is something like below, which should be a default anyway:
IN PERMIT ESTABLISHED
IN ...
IN DENY ALL-OTHERS
OUT PERMIT ALL
Just because something has a publicly routable address, doesn't mean it has to be publicly accessible.
People are finding a way, but right now I think it's still at the pain in the ::a55 level. But then wasn't it the same with IPX/SPX, AppleTalk, NetBEUI and ye old IPv4 at one time too?
No, probably, it won't.
Most IPv6 supporters are speaking from the viewpoint of being sysops for large network implementations. For them, IPv6 may either make sense, or is only part of the technical package of products and paradigms that they deal with on a daily basis.
The entire IPv6 contingent - from the network devs who thought the protocol up, to the vast majority of supporters - don't bother to consider the admin responsibilities of the SOHO market.
For SOHO, IPv6 is not only utter and complete overkill, it is also creates a level of network complication that is not worth the effort.
Does anyone in the sysops community even bother to consider how a SOHO self-admin will deal with a network when the assumption of "IPv6-made-simple" via DNS for some reason doesn't work? How much JOY pinging an unresponsive IPv6 printer will be when the DNS / UNC systems don't want to respond?
How manually creating and / or re-configuring an IP printer port will be, especially if the IPv6 prefix is derived from the ISP prefix address which gets changed every time the network gets reprovisioned? Like in this discussion, also as noted by actual users?
https://www.6connect.com/blog/is-your-isp-constantly-changing-the-delegated-ipv6-prefix-on-your-cpe-router/
Does any high-level sysop actually know that many Windows printer drivers that connect to a network printer actually expects a static address and cannot reconfigure themselves on the fly? That, once the IP address of the printer changes, the Windows IP network port is broken and must manually be either reconfigured OR deleted, remade, and the printer redirected? And doing this on IPv6 will be such a nice joy, especially using current system design?
And what SOHO sysop wants to deal with the 128-bit IP during this? It already can be either confusing, the printer stopped working and they can't understand why, to frustrating.
I know that not all sysops understand this because I had to support this very topic for my boss after his wife called their high-level sysop relative...who couldn't figure out how to get the printer back online. So, after that, she called me. I completely knew the problem, talked it out over the phone (with her reciting the IPv4 address after I instruct her how to access it on the printer's control panel), and then mentioned "This is what happens when you call a sysop for a Windows problem". They have completely different problems, completely different levels of solutions.
Having her read an IPv6 address over the phone, running a ping via phone instructions, then inputting that same IPv6 address into the Windows printer port setup? Confirming setup in the Windows print server dialogs before running the first test?
Errr, yeah o_O
I'm sorry if I sound overly condescending. But sysops and network developers are doing the same thing to the average user, building something completely unnecessary and then telling every average user that they are the problem when they don't commit to their creations.
It looks as if IPv6 was a poor solution to some, but not all, network problems.
Okay, let's consider the SOHO market.
v6 is obviously overkill here, like it is everywhere. That's a good thing -- you don't want underkill, because that's just another way of saying "not sufficient". It doesn't create much network complication though; v6 networks are simple, unlike in v4 where the combination of RFC1918, NAT, split horizon DNS, VPNs and RFC1918 clashes makes a massive mess.
If your DNS is broken, you fix your DNS. Maintaining working DNS is just part of the basic responsibilities for anyone running a network, SOHO or not.
As for your printers, you probably don't need to access them from outside your network, so you could reasonably stick them on a ULA prefix, meaning they could have a static IP like "fd00::10". That's shorter than almost all v4 addresses. It's not like reading a full, unabbreviable v6 address is that difficult (about the length of four v4 addresses), but you don't even have to do that much.
Also! Having v6 doesn't mean you don't have v4, so what's stopping you from connecting to your printers over v4 if it's really such a big deal?
It feels like you're just listing excuses to justify failing to keep up with moving Internet tech.
You don't even need hand-managed DNS in most SOHO networks. Multicast service location has been built into printers etc for years, so just connect the printer and wait for it to show up in your print menu...
OK I will admit to having 'proper' DNS for my SOHO setup, but that is because our business is network management and we need it for other reasons.
You haven't tried to get MFDs from Epson and Canon and HP to have their scanner sections show up. Hint: it's usually trivial to get the printer section to show. Getting the scanner to work can be a pain and a half. One particular Canon device (since junked with extreme prejudice) refused to have the scanner section show up... on Windows machines... if the MFD was connected by 802.11 wireless (wireless n or lower, the MFD had 802.11n built in) but would work with Macs with wireless or Ethernet, and would work with Windows systems with Ethernet. I ended up stopping trying to argue with the thing and connecting using Ethernet, until other problems forced a replacement, which was with a much better behaved Brother.
> Does any high-level sysop actually know that many Windows printer drivers that connect to a network printer actually expects a static address and cannot reconfigure themselves on the fly?
You're talking about the SOHO market? Nothing recent that I've seen.
My printer will use IPv4 or IPv6 and is automatically discovered by Windows, I've changed providers (And subsequently changed IPv6 blocks) and I haven't touched a thing and my printer continues to work.
Oh, it's worse than that, especially for certain older printers and multifunction devices. The old MFDs on my home network _both_ do not support IPv6 in any way. I would have to either connect by USB, and there's a reason why I got network devices, or would have to rig something with IPv4-to-IPv6 and make it work consistently (the keyword being 'consistently') or I would not be able to print or scan. The scanner sections of both MFDs in particular hate messing with the IP. As is, everything works. Why should I buy new devices and reconfigure my entire network just to run IPv6? I have some other older hardware which, in theory, works with IPv6. I really don't want to put that to the test.
I reconfigured my local net to use something other than the default 192.168.1.x Class C net. (I used a Class B private net and reserved IPs for all legitimate devices...) This means that someone trying to access my net will quickly discover that there are lower-hanging fruit elsewhere. Yes, if I add a new device I have to go to a little trouble. No, I don't add new devices that often, and the fact that I have to go to a bit of trouble helps ensure that any device I add is actually required. Hint: smart TVs and other IoT crap are not actually required; if necessary they may be placed on an entirely different network than my home net, denying Samsung & Co. snooping privileges. I am uncertain on how to set up an IPv6 net to lock out IoT crap and other undesirables.
NAT does not make firewall rules simpler, it makes them more complex - now you have two sets of addresses to worry about and logs to correlate between them, and this often results in errors and/or security problems cropping up.
Firewalls already ship in a deny by default state, you have to add allow rules.
Addressing doesn't scale... It might work for a tiny network, but on a network of any scale ipv6 is much better unless you have totally screwed up your addressing plan.
Consider for instance zoom:
https://support.zoom.us/hc/en-us/articles/201362683-Zoom-network-firewall-or-proxy-server-settings
100+ ipv4 ranges, or a single large ipv6 range.
or consider an ISP such as Sky:
https://bgp.he.net/AS5607
a single large IPv6 address block which covers all their infrastructure and customers, vs a bunch of disparate ipv4 blocks all over the shop.
With IPv6 you have flexibility to develop a proper logical addressing plan for your organisation, microsoft wrote a good document about this...
You have a single address prefix for the company - eg 2001:db8::/32
Then you split down according to location, to vlan etc, so your office vlan might be 2001:db8:100:22::/64... If you use a logical addressing plan you can already calculate the first half of the address based on where the system is located.
The second half can be statically assigned, can be made memorable, can be auto generated - the choice is yours.
IPv6 brings many advantages, but people are resistant to change, dont want to learn anything new, and many of the advantages are only realised once everyone else is onboard too. Tech companies like microsoft and facebook have migrated to ipv6-only networks and pushed backwards compatibility legacy ipv4 to the border.
A lot of it is inertia, if you are willing to learn ipv6 properly then you realise that it will save you a lot of hassle associated with ipv4. If you don't learn then you don't know any better, and are used to all the painful kludgy workarounds.
From an end user perspective there are advantages too, but there is no marketing so users don't demand it. If the providers which already had IPv6 started promoting it to users they would pick up a lot of customers from those that don't until they were forced to follow along too. Users will ask for newer/better technology if they are aware it exists, even if they don't understand why it's better.
your office vlan might be 2001:db8:100:22::/64
Forgive my ignorance, but can anyone explain why isn't it written with leading zeroes, i.e. 2001:0db8:0100:0022::/64? It would make it much more regular to read...
...I'm beginning to regret not investing in one of these IPv6 buddy keypads which up until now would have been most useful for entering MAC addresses but obviously really comes into its own with IPv6! They seem to have closed up shop (link is to cache on the Wayback Machine).
M.
"Forgive my ignorance, but can anyone explain why isn't it written with leading zeroes, i.e. 2001:0db8:0100:0022::/64? It would make it much more regular to read..."
Actually, there's nothing stopping you. Just that for most people, leading zeroes are harder to read, not easier. Maybe you routinely read your addresses with a monospaced font so read for alignment. Anyway, your suggestion is actually perfectly valid, as is entering the address in decimal octet format.
I think you're right, other than the easily remembered IP address bit. Increasing the address space to 128-bit is going to make it hard to remember regardless of format.
They just simply made too many changes and made it cumbersome. Maybe an IPv5 that just increased the address space would have worked better?
And you just missed the entire point. Hint: you might be able to find the OS grid reference for my house, but you'd have to go to a bit of trouble to look it up, and that grid reference would be _all_ that you know about it unless you do considerably more research. Meanwhile, you can get my IPv6 address (if I had one, I'm at the office now and none of the office machines have IPv6 addresses for security reasons) just by my visiting a web site or sending an email. It is trivial to determine all kinds of things about whatever machine is at that IP while staying halfway around the world; you can't walk into my house and eat my porridge without getting actual physical access. (And without getting past my dogs. And the Attack Cat. But that's another matter.) You can access the machine remotely. You can't eat the porridge remotely. You can see the IP4 address of the router, but that's all. And the router can be, and is, configured to lock annoyances out.
The simplest way of preventing someone from using IPv6 to violate my privacy is to not have IPv6 turned on. With IPv4 and NAT, I set one set of locks, on the router. With IPv6, I have to set locks on every single device in the building. At home that's multiple computers, printers, cell phones, tablets, and more. At the office, that's computers (lots of them) and printers/MFDs and lots and lots of other things. Explain to me why it's better to have to set locks on dozens to hundreds or even thousands of things than it is to set locks on one or two things?
"IPv6 puts every IP live on the Internet. So how do you put locks on the router so that you prevent that? Seriously. That's a major reason why I don't put IPv6 on my net."
They still have to go through your router, don't they? The router still has a firewall on it, doesn't it? Even for IPv6?
It's just like with your house. Lock the front door. Now how do they get through to your stuff?
Err… the point made by the previous persons who don’t run IPv6 is that _all IPs are routable over the Internet_. Exactly how does your router prevent this? With IPv4 and NAT, it’s trivial to set up a net which is not routable over the Internet. Devices on that net can’t be seen on the Internet without going to a lot of trouble. Devices on a IPv6 net are visible by default. How do you make them not visible? It’s a simple question. I find it interesting that two IPv6 partisans in a row have dodged it.
v6 networks aren't automatically routable. It's the router that does the routing, and the router can choose not to route or to drop whatever traffic it likes.
To be clear, that means you don't need NAT to set up a non-routable network. (And, er, you generally don't want a non-routable network anyway; most people want their network to be connected to the Iinternet. Otherwise you won't be able to reach any websites, services etc that are on it.)
If you want internet connectivity but don't want random people connecting to your machines, a default-deny inbound firewall is the way to go, and has been since forever, including in v4.
I didn't dodge the question in my previous post. Nobody asked about routability, and I did answer the question about "locks" (which I took to mean access control).
But I _do_ want my personal devices to be not visible on the Internet. This is one thing that those who like IPv6 always seem to fail to understand: I, and many, many, MANY others, do not want to have our devices visible on the Internet. Being on a non-routable, orivate, network wusing NAT (or something else, I don't care) is a Good Ting(™). It's literally what we want. That way the router is the only thing exposed to the Internet, and outsiders can't tell if I have one device, 50 devices, or 500 devices, they just see the one IP. (They might be able to guess that I have more than one device by looking at how much bandwidthI use, but even that isn't certain, not in these days of streaming everything.) It's literally none of their business what I have on my personal network. I like that. IPv6 destroys that... and it get even some control back I would have to reconfigure my router and buy new hardware. Not to mention that some of my existing hardware is NOT compatible with IPv6, and so would have to be replaced. I would literally have to spend more money, time, and effort, to get a network which can still be seen by outsiders.Going to IPv6 gains me nothing, as every site I wanmt to go to, on my local net and on the Internet, is either IPv4 or double-stacked and therefore reachable by IPv4. I fail to see why going to a lot of trouble and expense to set up IPv6, either at home or the office, is a good idea.
Now, if there was a compelling reason to use IPv6, such as some site which I must use which is IPv6 only, then there might be a reason. This is quite unlikely; most sites are run by people who know that they will lose business/visits/whatever if they went IPv6 only. At leasy most sites I care about know this; if there are sites which are IPv6-only, frankly I don't go there and simply don't care about them.
The time may come when I'm forced to go IPv6, but it will not be at any time soon. Not unless I can easily and inexpensively set up private networks to which some random stranger on the Internet cannot access without going to a lot of trouble. And my existing hardware had better work with the net, or someone will have to give me a good reason to junk working equipment.
You have not done this.
And, oh... I have a perfectly adequate hardware firewall at work. I don't have one at home and see absolutely no reason to get one just to use IPv6. A firewall plus NAT is, in my opinion at least, better than a firewall by itself. IPv6 is actively hostile to NAT. Those who like IPv6 need to convince me that getting rid of NAT is a good thing. So far this has not happened, and I doubt that it ever will.
Sounds to me like your best solution in this case would be to buy a cheap WiFi hotspot (secondhand, maybe) and just never hook up the WAN end of it. That would make it just about physically impossible for things you don't want to see the Internet to see the Internet. At that point, you wouldn't really care what version of IP is running as you'll have truly isolated those devices. Anything that requires phoning home, you're probably much better off replacing it with something that doesn't do it. If that's not an option, you can always go without; it's pick-your-poison time.
And before you demand that your devices be able to see the Internet without the Internet being able to see it, the answer is increasingly going to be, "No way; price of admission." So it's either going to be bend over or throw up your arms and go, "Stop the Internet! I wanna get off!"
Perhaps not now, but even you'll either be dragged kicking and screaming or you'll probably come back swearing and shooting. Think overlay area codes and ten-digit dialing. It's coming whether I like it or not. At some point, some next big thing will discover itself unable to get a foot in the proverbial door because the incumbents hog all the IPv4 like digital Scrooges. Do you really want to trust the future of the Internet to the incumbent Scrooges?
It is quite unlikely that anything would lead me to allow the IPs on my private networks to be visible on the Internet. If necessary I would set up two nets: a private net running on a Class B or C IPv4 private net range, and a public net of one machine which is visible on the Internet, and which cannot see the private net. Or at least can't see the private net without going to a lot of trouble. This would give me one IP which is visible on the Internet, which is what I have now. Also, as cell devices usually have IPv6 around here when connected to cell data services, I could use cell devices. Oh. Wait. Both T-Mobile and AT&T have problems with VPNs, including Apple's Private Relay and Cloudflare's 1.1.1.1. It's almost as if some people don't respect other people's privacy. No doubt Ipv6 partisans would agree with AT&T and T-Mobile. I'm looking for new cellcos. (I have a 'ticket' out with T-Mobile about this issue, and have had one since 11 Jan. So far it is not resolved, and I'm not holding my breath while waiting.) Apparently Verizon, despite its other failings, don't block VPNs. They may be getting new customers.
And, frankly, I don't care about 'the next big thing'. Their problems are their own, and not mine. And your attitude towards the 'incumbent Scrooges' would be a lot less hypocritical if you weren't trying to force me, and everyone else, to reveal every IP on our private networks to the world. All I ask is that I can keep my private net private; those who love IPv6 absolutely positively refuse to allow this. Unless and until I can keep my private IPs private on Ipv6 with the same ease that I can with IPv4, I will not be moving to IPv6.
"Oh. Wait. Both T-Mobile and AT&T have problems with VPNs, including Apple's Private Relay and Cloudflare's 1.1.1.1."
That's weird. Because I use T-Mobile, and I have no trouble connecting to VPNs. I use OpenVPN and connect to servers I personally set up and obtained the necessary configurations. The only times I have trouble getting through are (a) network trouble, which is outside the scope of OpenVPN, and (b) forgetting to turn off Blokada first (since it has to use the VPN interface to work).
v6 isn't forcing you; it's allowing you (compared to v4, which generally forces NAT). You can still do everything you do on v4. v6 also has privacy extensions to mask your IPs without causing the problems NAT causes. They use a different method (masking the IP with a different, random IP+port instead of a different, fixed IP+random port) but it achieves the same general goal.
I think you're worried about something totally unimportant here. Your browser is a far bigger risk to everything than people seeing your IPs (without even being able to connect to them!) is. But v6 has your back anyway.
Amazing. It seems that the final answer that those who are IPv6 partisans have is to insult those who see no reason to install it. That’ll make converts, boyo.
And all because the guys behind IPv6 insisted that all IPs be visible to everyone all the time.
Boyo, any site which locks out connections from IPv4 sites will simply not get any business from a very large fraction of the Internet. Sites which don’t insist on IPv6 purity will get business from the _entire_ Internet. Economics alone will ensure that the vast majority of sites that IPv6 refuseniks want to visit will accept connections from us dinosaurs.
It sounds like you want to use a proxy server to reach the internet, not routing. v6 won't stop you doing that. Even if you route, it has privacy extensions, which masks the number of devices you have.
You can easily set up a private network which a random stranger on the internet can't access. Routers will typically do that by default, so it's no harder than just plugging them in and using them.
You'll be replacing your hardware at some point or another. Just make sure that the replacements support v6 when you do, and you'll get v6 support along with the upgrade that you were paying for anyway.
It seems like most of your issues aren't really an issue.
It's interesting that you think v6 is actively hostile to NAT. The only thing v6 does against NAT is to give you enough address space to not need to use it. Apparently you won't use NAT unless forced into doing so...? But that's inconsistent with the rest of your post.
The same way you do it in v4? You put a firewall on the router that rejects inbound connections by default. It's the exact same firewall you already need on v4 to be secure, so you already know how to do it.
If you're using iptables, it looks something like this:
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i lan0 -j ACCEPT
-A FORWARD -j DROP
And in case you're wondering about IoT and other "creep factor" devices phoning home, locate and relegate those devices to a subnet of your choice (with a /64 to work with in most cases, it should be easy) and then just make a firewall rule to reject outgoing connections from that subnet.
You do that, and many IoT devices won't work. Most of them work by calling back to a known system on the Internet as a command and control server, and then sit waiting for instructions. You then connect to that internet server with an app on your mobile phone or something similar every time you want to control the device.
The same is basically true of internet printers.
(Please note, I am aware that some smart devices work without calling home, but you generally have to have some form of controller installed on your network. I'm also aware of that abomination uPNP)
That means the device requires phoning home just to work. In which case, it's going to fall on you to decide whether or not to use the device on your home network because it's likely going to tie any kind of telemetrics to its basic use. A savvier user would replace such a device with something else.
Why would networking be the exception? The tech world is full of examples of great solutions failing while terrible ones prosper. Python and Java are great examples, Windows and MacOS too, x86 just won't die, the list goes on. The problem is the people in tech, not the tech. Look at the way cloud architectures have devolved from scalable, self managing beauty to essentially a more expensive on-prem design with firewalls and network appliances to manage.
Let's be honest though, it's not just tech people, it's people. In a global pandemic you still see a majority not washing their hands after using a public toilet. We deserve everything we get.
I was amused by a poster I saw in a retail outlet in Spain featuring cartoon depictions of the right (i.e acceptable) and wrong (i.e. not acceptable) ways to wear a mask. The cartoon character getting it wrong looked totally gormless. Strangely, in real life they do too.
-A.
Masks are primarily to filter exhalations
which is why I get frustrated at some people who insist on having the very highest levels of face-hugging protection, but use those masks which have an exit valve. They are totally defeating one part of the equation. Potentially making it worse by having stuff exit the mask through a single small valve and presumably therefore at higher speed. I understand it makes masks more bearable for specs-wearers but as normal masks in normal use seem to be of marginal benefit anyway, why make them worse?
I use one of those... the vent is situated on the mask on the far side of the N95 filter.
The pressure profile inside the mask is not symmetrical throughout the breathing cycle.
What the one-way valve does is to stop the sudden, short, peak of much higher pressure forcing the edge of the mask away from the face so the breath can escape round the edges thereby NOT going through the filter. There is also only a double layer of cloth across the cheek parts, whereas there's a triple layer and a filter over the nose and mouth parts. The vent bypasses only the outer double layer in the area of the filter - there's no way for the breath to exit the mask without going through either a layer of cloth and a high-efficiency filter or two layers of cloth (in reality the single layer of cloth and the N95 filter are by far the lowest resistance path, so that's the way the overwhelming majority of the out breathing goes).
As one breathes in, the mask material is deformed as it is sucked closer to the face and the air comes through both the triple layer of cloth and the N95 filter.
OK, the exact details of how the vents work vary from design to design.
I was talking about specifically the design of the three I use (they're the same, I wash them in rotation and replace the filters once a week).
Some masks that I have seen, that I don't use, don't have a filter over the vent - like the ones intended to stop sawdust coming in. They're not appropriate. and indeed useless for disease control. But you can't generalise to all vented masks.
C isn't terrible in any way at all, it's great for people who understand how the machine works. It's somewhat challenging for people who don't understand how the machine works, and just want to display a cat picture, but that's why Python and Java exist, because those who understand are vastly outnumbered by the others
The tech world is full of examples of great solutions failing while terrible ones prosper.
This is normal for human systems. It's a combination of 'I just want it to work now' and sadly effective marketing.
An alternative would be wait for the perfect XXXX before we do anything. But if we did that we'd have a very different world. Imagine what the world would be like if we'd chosen never to burn fossil fuels because of the impact on the climate. And that's not entirely hypothetical. Way back in the early days there were quite a few people who were concerned about the consequences.
Sometimes, heck most of the time, you have a problem that needs a solution. Any solution. Time and tide waits for no man and it certainly doesn't wait for someone to produce the perfect widget.
NAT is not just the darling of mobile telco gateways. Clouds love it too, for example Microsoft has begun peddling Vnet NAT for Azure because it "simplifies outbound Internet connectivity for virtual networks". This appears to be telling us that NAT is fulfilling some important additional network function that we cannot live without.
So why not roll NAT up into the IP standard? There was a time when I could phone a colleague by dialling their full ISDN phone number followed by their extension, all in a single frenzy of button-pushing, and then wait for the connection to worm its way through. The system was left to worry about which numbers were to be processed by which switches. Do the same with IP/NAT. Call it CIP (cascading IP) or XNAT (eXtensible NAT) or something like that, or just IPv10.
What would actually be much harder to implement than IPv6 leading to even more problems.
Clouds do it, as the cost of an IPv4 address is rather high compared to the cost of running a VM. If your customers allow you to get away with having their servers behind NAT, that can greatly increase your profits.
"Clouds do it, as the cost of an IPv4 address is rather high compared to the cost of running a VM. If your customers allow you to get away with having their servers behind NAT, that can greatly increase your profits."
And that's exactly the point. There are use cases out there where consumers of IP connections find IPv6 to fall short on their needs. No v6 shenanigans are ever going to do other than piss them off and make them look elsewhere.
Yeah, but it's kind of misleading to frame it that way as a bunch of NAT is already baked into v6. 426 and 624 are sorted, as are tunneling and a bunch of other stuff.
The point being that a ton of those services using server side IPv4 vNAT to enable load balancers and stuff can drop a whole service layer for IPv6 native traffic with smart routing. 626 nat doesn't bring as much to the table in terms of pain management compared to addressing the reliance on slow DNS/BGP propigation and the huge security issues they present.
That said I think the holy war against NAT was one of the big faceplants. The core of the problem was that under IPv4 you didn't know what traffic had been NATed or not (or how many layers if NAT it went through - the horror). So they tried to wish it away entirely. The then realized that IPv4 traffic MUST have a way to talk to an IPv6 address and they had to put it back in in a limited scope.
Instead what if they had defined a well structured designation in the traffic stream to declare traffic was NATed and how to handle it? Anything else that hits the outside of the firewall gets dumped. That could have been used for both versions 4 and 6. And despite the holy crusade against NAT, any IPv6 enabled host is either dual stack, or dealing with 624 NAT translation, which would be less of a PITA if NAT was a well formed service that was clearly designated in the headers somewhere. Ditto for a bunch of the MTU and windowing issues that slow down connections are require complicated and unreliable guesswork to handle.
But the IPv6 team punted on all of this so they could work in isolation on their addressing and routing problems and declare all the rest of this mess out of scope or some other teams problem. As a result they were still cleaning up howlers a decade after the first world IPv6 day. Until we get a better coordinated roll out plan it will hover where it is now. IPv4 for the majority of fixed endpoints, and IPv6 for big pools like mobile devices, large enterprises, and to provide dual stack access to services.
Looking at the anonymous edits at Wikipedia, more than half comes from IPv6 addresses, see here https://en.wikipedia.org/wiki/Special:RecentChanges?userExpLevel=unregistered&hidebots=1&hidecategorization=1&hideWikibase=1&limit=500&days=7&urlversion=2
You didn't parse out the part where IPv6 takes precedence if a host has both IPv4 and IPv6 addresses. So those stats have both dual stack and IPv6 native traffic.
I have seen plenty of carriers issuing BOTH for personal/home connections here stateside, as they have been twisting their arms pretty hard, but I still had to ask for an IPv6 handoff for our business fiber lines
The cable modem backup DOES have both, which means without additional routing all my hosts would default to using the slowest connection as their primary default route. They would also be on one broadcast domain, which they would share with the chatter from ever mDNS spewing piece of IoT crap on the network. That is a whole different set of problems though.
A possible reason for this is that home users who want to edit are stuck behind NAT, so if one jackass starts making joke/vandalistic edits, everyone who shares that IP address will get blocked. I don't think that you can draw many inferences from the stat you posted.
"solving IPv4's undeniable routing, addressing, security and performance problems at the unprecedented scale it was being asked to support."
That's a tired and incorrect statement. IPv6 did none of that, apart from the longer addresses.
Routing? There was an original hare-brained idea to allocate addresses for "tier 1" and "tier 2" ISPs in a way that would reduce the number of core routes. It was never going to work because it did not acknowledge the commercial realities of how networks interconnect and the financial relationships between them, and hence it was binned early on.
Security? IPv6 mandated that devices must be "IPSEC capable". This doesn't change the fact that (a) IPv4 devices can be "IPSEC capable" too, and (b) without a keying infrastructure, it's never used.
Performance? The removal of IP fragmentation is the only thing I can see that might possibly go in that direction, but IPv4 stacks all implement PMTU these days anyway. Otherwise, the larger headers of IPv6 give a small (~2%) performance degradation in normal use, compared to IPv4.
IPv6 didn't solve any of the IPv4 problems that needed fixing, like multi-homing: every BGP multi-homed network still appears as a separate route in the global routing tables.
IPv6 also needlessly changed a bunch of things that didn't need changing. Replacing ARP with NDP? Replacing DHCP with SLAAC? These were ideas from academics. They didn't realise the privacy implications of SLAAC, so then had to invent randomly-changing privacy addresses. In the real world, there are good reasons why networks need DHCP, and so DHCPv6 came along, meaning we now have two different ways of assigning addresses (except Android still doesn't implement DHCPv6).
But the biggest problem is the lack of interoperability. If you can't build an IPv6 network and see the whole world of IPv4 content, this means you have to build an IPv4 network as well (i.e. dual stack). In that case, it's cheaper and simpler to build and manage an IPv4-only network, so that's what most people do.
Ultimately, we still really could use the longer addresses, and the pain is felt acutely at the side of access ISPs (those who provide end-user connections). But the pain isn't felt at the content provider side: they've been sharing IPv4 addresses for years, via virtual hosting, reverse proxies, and CDNs.
The sad thing is, content providers *could* make their content available over IPv6 with little effort. However many can't be bothered, because the whole world can view their content via IPv4 anyway. That is: all eyeballs are either IPv4-only or IPv4+IPv6 dual stack.
The one thing that might push this is if and when China goes IPv6 single-stack: content providers will lose a large chunk of their global audience if they don't keep up. OTOH, by that point, China might not be trading with the rest of the world anyway.
Many fail to understand when IPv6 was designed. The first RFC is date December 1995 - meaning development started well before. The actual internet didn't exist then. The first DHCP RFC is dated October 1993 - DHCP was far from being an established service then, and inter-router links far slower.
Interoperability was not an issue back then. The internet was far smaller, and already switched from NCP to TCP/IP years before. In those time, TCP/IP itself was not still an established protocol outside the internet - many LANs were running on other protocols.
The real issue is IPv6 wasn't updated quickly enough as the internet quickly changed. And of course the stubborn self-interest of Google to avoid its devices being centrally assigned an IP (and thereby managed...) does not help at all.
"they've been sharing IPv4 addresses for years, via virtual hosting, reverse proxies"
And that's a bunch of workarounds that actually makes everything more difficult to manage. Being able to assign a separate IP to each website even on a single server simplifies a lot of things.
"In that case, it's cheaper and simpler to build and manage an IPv4-only network"
Today is no longer simpler nor cheaper - depends on how many IPv4 addresses you need. There are technologies to access IPv4 networks from IPv6 - and that's what new ISP are using as they cannot obtain enough IPv4 blocks for their customers.
"Many fail to understand when IPv6 was designed. The first RFC is date December 1995 - meaning development started well before. The actual internet didn't exist then. [...]"
The Internet existed long before IPv6.
I was using the Internet back in the 1980s, and remember first experimenting with internal webstuff (text only) in the early 1990s.
Can you understand what the "actual internet" mean?
The internet before IPv6 first RFC was still mostly a network among universities, research centers, and a few large corporations, mostly in the US, and with almost zero commercial value. The web didn't come until 1993. It was a quite different landscape compared to what we see today.
Could those who worked on IPv6 on those days envision what it would have become ten year later? They could not, maybe they could have, but it wasn't easy at all to believe and predict that in twenty years "internet" would have become a world network deeply interwoven with people daily life.
You've been one of the few lucky people who had early access. For most, until the late 1990s/early 2000 internet was beyond their grasp. They did not have nor the devices nor the connectivity to access it.
I'm probably older than you and could not access the internet until the late 1990s. You can brag you early internet access as much as you like, but the fact that in the first half of 1990s things were far different than today is a fact, and that it inevitably reflected into the IPv6 design.
Not understanding it is quite childish and show that many old people become usually as stupid as kids. Especially, they become fearful of any changes that require them to adapt, and dream of "the old good times". Some others are able to put things in perspective, and move on.
If IPv6 was being designed today probably it would be quite different, and probably Google and Facebook will want a unique personal identifier in each packet.
Until you explained what your personal definition of the "actual internet" was, no, I didn't know what you meant by the "actual internet"; and, clearly neither did that other commentard.
And I as far as I might understand now what you meant, I think "actual internet" is not a good descriptor of it; and I think your phrasing is quite likely to give rise to similar confusions rather frequently.
You all can't spot the difference between 1995 and 2020? Your horizons have to be very, very small indeed, and memory already failing. Time for retirement, I guess.
Which very well explain why you all hate IPv6. Keep on dabbling in your small networks, and fear anything that didn't exist yet in the 1970s, graybeards. Becoming old before becoming wise is always a problem for many.
IPv4 to IPv6 is similar to Python 2.x to Python 3.x.
Some breaking changes are required. However, then there are a lot changes that just seemed like a good idea at the time, making is hard to support both at the same time.
Python 3.x had weird changes that were not back ported to Python 2.x. IPv6 has weird things that make it more incompatible with IPv4.
What is bad with IPv6 is even when it became clear that there would not be a quick transition, nobody cared about how IPv6 was needlessly incompatible with IPv4.
For example, DHCPv6 cannot provide the host with a default router. This is obviously not a hard feature to add, but it was flat out denied when requested. There is obvously also the issue that DHCPv6 is not required, so Android leaves it out.
Why is fragmentation in IPv6 different? It made sense at the time. But why was it never brought back in line with IPv4?
Ultimately, should cannot make IPv6 compatible with IPv4. So discussion often starts with that and then fails. You can however reduce friction, and that doesn't happen. Too many vocal IPv6 fans in the IETF refuse to make changes to IPv6 to make it look more like IPv4.
However, in the end, people are just looking for an upgrade path that is zero effort. In any well maintained network, running dual stack costs hardly any extra effort. All the people who are hand coding firewall access rights, or are manually verifying reachabiliy of service should modernize a bit.
Many ISP have migrated from dial-up to ADSL (which has ATM) to VDSL (ethernet) to fiber (GPON), yet cannot handle IPv6.
Or content has moved from on-prem to the cloud, but cannot handle IPv6.
Yes, IPv6 can be annoyingly different from IPv4. But it is only an annoyance. Supporting both at the same time is absolutely no problem at all.
The web didn't come until 1993
The internet != 'the web', TBL took an existing markup language (SGML) and distilled it down to HTML and wrote the first webservers. There were already services that ran over the Internet (NNTP/WAIS/SMTP/Gopher et. al) that saw a fair amount of use.
Of course, most of those protocols involved an amount of thought by the users and didn't have a point-'n-drool interface so it didn't have the widespread usage like today. Also there wasn't any sort of mobile usage - wifi and mobiles were not yet invented..
But dial-up connectivity had been available since at least the late 1980's - first to BBS's (I was using Almac in the early 80's) to services like AOL and Compuserve - all of which allowed access to the fledgling Internet once they realised that there was a desire for people to do so. So your assertion that 'For most, until the late 1990s/early 2000 internet was beyond their grasp' is simply not true.
>Many fail to understand when IPv6 was designed. The first RFC is date December 1995 - meaning development started well before. The actual internet didn't exist then.
So this thing I used to download books, music and videos from and kill my time in chat rooms, IRC and (in 1996) ICQ was not "the actual internet"? It was "the true Internet" then! (technically it was called a modem).
>Interoperability was not an issue back then...
Lol that's the best joke I heard today.
>>"they've been sharing IPv4 addresses for years, via virtual hosting, reverse proxies"
>And that's a bunch of workarounds that actually makes everything more difficult to manage. Being able to assign a separate IP to each website even on a single server simplifies a lot of things.
Being able to assign multiple website names to a pool of reverse proxies is a godsend that simplifies a lot of things.
>>"In that case, it's cheaper and simpler to build and manage an IPv4-only network"
>Today is no longer simpler nor cheaper - depends on how many IPv4 addresses you need...
Let's say I need 16 million. I heard the US Army still hoard 14 /8s, maybe ask them politely? Or better, I can simply use 10.0.0.0/8 as most people happily do.
Sure, you were doing in 1994 what people are doing today? C'mon. Which video and music were you downloading, and at which speed? Even MPEG standards and MP3s where in their beginnings. Most software still came on floppies because not many had a CD-ROM - or even an audio card.
And still, even if you were one who could, you were among the **few** who could. While IRC was not the **actual** internet.
"Lol that's the best joke I heard today."
If it was, they would have developed something different. Was TCP/IP interoperable with NCP? No, it wasn't, they replaced it on "flag day" and it was OK. People had to replace their DECNet, IPX, AppleTalk, etc. networks with TCP/IP, since it wasn't interoperable with their existing networks, and never was designed to be.
"is a godsend that simplifies a lot of things."
Sure, far better than using an IP for each site, right?
"Let's say I need 16 million. I heard the US Army still hoard 14 /8s, "
Sure ask them some, and let's tell us what they answer you. Or ask Apple a share of its /8...
"Or better, I can simply use 10.0.0.0/8 as most people happily do."
As public addresses? Good luck.
>Which video and music were you downloading, and at which speed?
1995? Ghost in the Shell, Neon Genesis Evangelion in *.viv and *.rm. And people were driving the actual cars 100 years ago.
And Mark saw all that Internet He had made, and behold, it was very good. And there was Tuesday evening, not even 10 p.m and he was a little intoxicated, the year 2003.
Grow up mate, the Internet was so good before Mark and not the cesspool he left after. People loved it.
OK, you've now told the world you were among those who could and had your bragging rights fulfilled (still DVDs to rip came only in 1996, as V.90 modems...) - do you believe everybody else could like today? How many devices were connected in 1995, and how many today? Who could run services from a single 33kpbs modem on a single telephone line?
Sure, some people had cars in the 1920s - do you believe **mostly everybody** had a car in the 1920s, like today? Would yo be surprised that there are still many places in the world were people don't and can't driver/own a car? And still, there are better chances they have an internet connected device.
And, no, people weren't driving actual cars in the 1920. Different cars (do you need to set ignition time today?) - different roads (no **highways**, not even asphalt, often....), often different rules. When Eisenhower made a coast-to-coast travel with the Army, he understood how much outdated US roads were.
But yes, with people like you we would still have 1920s cars and no highways, because fear of changes. But hey, you live probably in US, the world outside is just made of barbarians, right? You believe you have enough IPv4, so the others can f**k off, right?
Grow up, and look at the future. It could be far different from what you imagine....
"The first RFC is date December 1995 - meaning development started well before. The actual internet didn't exist then."
The Internet most certainly did exist then, speaking as someone who ran a commercial Internet provider in early 1994 (complete with dialup/ISDN/leased line access and hosted websites).
Indeed in the USA NFSnet (the non-commercial backbone across the States) effectively ceased to exist in 1991 or 1992 when ANS was allowed to carry commercial traffic (ANScore) as the US Gov simply started paying them for transit rather than to actually "own" a backbone.
Routing? There was an original hare-brained idea to allocate addresses for "tier 1" and "tier 2" ISPs in a way that would reduce the number of core routes.
That goes back to ARPANET. Prior to ~1993 the internet was academic (not commercial) and so things like CIDR didn't need to exist at the time.
But the biggest problem is the lack of interoperability. If you can't build an IPv6 network and see the whole world of IPv4 content
But you can, there's plenty of solutions like NAT64, 6to4 etc. The problem they needed to solve is how to get traffic back form an IPv4 only device to an IPv6 one.
CIDR was part of IPv6 from day 1. The tier 1, tier 2, thing was a completely new invention for IPv6 that had no parallel in the IPv4 world. It was meant to keep the size of the default free routing table (in BGP) small. In the end, the (IPv4) operators said no way, and refused to implement it. Then the IETF backed down, there was already a formal split with IETF designing protocols and operator running networks.
> But the biggest problem is the lack of interoperability. If you can't build an IPv6 network and see the whole world of IPv4 content, this means you have to build an IPv4 network as well (i.e. dual stack)
It doesn't lack interoperability. I'm posting from a v6-only machine, to this v4-only site, and it's working fine.
If the biggest problem in v6 is one that doesn't exist, then doesn't that mean it's doing a pretty good job?
I do think that building single-stack IPv6 access networks is the only way out of this quagmire. The vast majority see no benefit in deploying dual-stack when single-stack IPv4 is simpler by definition; single-stack IPv6 could compete.
However, in order to interoperate between IPv6 and IPv4, you need a NAT64 gateway (or its equivalent, e.g. CLAT+PLAT).
In principle, NAT64 is no worse than NAT44. But the critical thing is, you still need an IPv4 address on the outside for it to work at all. So either your ISP has to give you an IPv4 address, in which case you're back to square one; or your ISP has to provide you access to a NAT64 gateway, which is basically the same as CGN. Plus, NAT64 depends on DNS interception, which may stop working if DNSSEC and/or DoH become more widely deployed.
If we mandate that all operating systems have CLATs in them, and all ISPs provide discoverable PLATs for their customers, we *might* just get there. But Apple for one are anti-CLAT, which forces us back to either NAT64/DNS64 or dual-stack with NAT44.
Finally, if governments are able to legislate that websites must provide accessible content for people with disabilities, they could also mandate that websites must be accessible over IPv6. Right now, the front page of the BBC website is still not IPv6-accessible. Nor is theregister.com, FWIW. Glass houses?
Unless you are really good at converting numbers from decimal and binary and back, IPv4 is much harder.
With IPv6 you no longer have to have inconvenient things like /26 networks, you can put the division between the network and the host addresses at convenient 4 or 16 bit boundaries.
Also most people don't have enough IPv4 space to even give every building its own address, let alone each VLAN... unless of course you are talking about LAN. In that case it doesn't really matter if you use IPv4, NetBIOS or IPv6, or any mixture of them.
If you are a programmer, you should also be pretty good at converting hex to binary. If you're a network engineer, you should learn it; all the programmers did and it didn't take very long. You probably know it already anyway. It's not difficult to recognize a prefix if you use it a lot.
The only difference is that the prefix is longer. If you want to allocate addresses within your own network so that you can remember which VLAN that means, you can do that perfectly well (in fact, more easily) with V6 addresses.
However, you are right that spotting that it is one of your own addresses is harder - the prefix to remember is longer than it is in the V4 case.
IPv6 works (well, assuming you have no vendor bugs and a helpful ISP to hand), and does solve all the technical hurdles it was meant to.
The problem is it very much looks like it was developed in a lab by very clever people under perfect network conditions, with scant regard to how people do things in the real world due to a lack of knowledge, budget constraints, or complete apathy.
Compared to the simpler, backwards compatible option of dropping a few extra octets onto IPv4 to solve the address shortage, it may be a case that IPv6 let perfect be the enemy of good.
No-one's arguing IPv6 won't eventually be the dominant protocol: We're too far down that road, and too much has been invested into it, and again, it does actually work and solve these issues. But until you *Have* to use it, you may as well plod on with IPv4 which can do everything you need it to, and let the bleeding edge companies (And server to server traffic) work out the kinks for you, then worry and spend on it when you need to.
I've tried on and off every few years to get a Dual Stack link to the outside world on my home network; every time, I got so far down that path before hitting a roadblock (Flaky ISP Support, router support, router bugs, Happy Eyeball issues), before stopping and seeing I'd be spending a lot of time and money to make things technically better, but not letting me do anything new, and shelving the attempt again.
Point of order guv. Any adjustment to the IPv4 addressing involves needing a new IPvWhatever stack. Just no additional space to pad out the addresses.
But yeah, point well made about the perfect being the enemy of the good. The time to nip Ipv4 in the bud was much earlier on, 4 billion (theoretical) addresses and the usable ones nearly full? Too much inertia now.
Agree with you there: I wasn't clear with what I meant.
IPv6 could have "just" been IPv4, but with eight/ten/twelve octets, saving all the current IPv6 bells and whistles for optional extensions, IPv8, or something else entirely.
Yes, everyone would have needed new routers and edge gear still, but it would have been a much simpler drop in replacement, with backwards compatibility baked in to handle legacy four octet traffic - I can't see any way that would not have been adopted much faster than the current IPv6.
Again to stress: All this IPv6 stuff is great, especially if you're a carrier or work at a national/international scale, but it's undeniable it's made deployment more drawn out and complex than a drop in upgrade, and means SMB management and budgets can just be vaguely aware of it until it hits critical mass.
Too late now? Not really.
Most devices people are using today will be replaced within 5 years; if those new devices were to FINALLY ship with IPv6 support by default, we'd make progress. But as long as there are ISPs out there trying to deal with piles of devices that they own, no progress will be made. It is that ISP infrastructure holding things back, for the most part, not the devices nor the technology.
"Most devices people are using today will be replaced within 5 years"
NO, they won't. There is virtually zero chance that's going to happen. I'm typing this on a computer that's already a decade old. My newest computer is getting close to 5, and it's not going anywhere anytime soon. Nothing short of a nuclear war will cause "most" devices people are using today to turn into e-waste in the next 5 years.
What you're describing is a tech company's wet dream, not reality.
Effectively, they will. You keep your computers around a while, right? So do I. The way I do this, and likely the way you do, is by using software that runs well with limited resources but is still new, such as modern versions of Linux. Which bring modern networking systems with them. Modern BSD, Windows, and Mac OS does that too. If you're keeping your software updated, then you've already replaced the outdated stuff that can't handle changes in networking. If you're running your old computer with old software, Windows 7 has IPV6 support as well. Computers have supported IPV6 for quite a while.
The stuff that doesn't is usually either old phones or cheap IoT junk. That stuff does tend to fail or become unsupported more quickly. People replace phones when those phones don't run apps anymore, and if that doesn't happen, they will when the screen breaks and they can't replace it or the battery has aged so much that the system shuts down unexpectedly. The nontechnical public also tend to discard computers more frequently than we do* as they are unable or unwilling to take some of the steps we take to maintain their usefulness. There are certainly devices that live on far longer than their manufacturer predicted, but people get updated equipment and software without us having to do it for them.
* The family member that still has the Windows 98 box excluded, as they probably don't know how to connect to the internet anymore but are still paying some ISP for it.
All these years later and they're still arguing and trying to get people to use it. Yet even shiny new stuff mostly ignores it.
They built a solution that's too complex to use and aims for a utopian ideal of all those billions of devices existing in a nice flat world where everything is individually addressable - and we know that isn't how the world works and never will be.
It might be antique but IPv4 is good enough and it works so it'll stay for most things forever.
Yet even shiny new stuff mostly ignores it.
You need to check your shiny new stuff.
All devices I have here (an ancient iPad, an elderly Android phone, half a dozen PCs, and a Mac) have IPv6 addresses, and - as far as I can tell - use them when connecting to servers that support IPv6.
A very quick test suggests around 50%-60% of websites I regularly use support IPv6 - including, of course, my own company's site.
Free rein to the marketing department only ever leads to disaster. This is a self-evident truth.
Similarly, free rein to the engineers can lead to disaster. IPv6 is the evidence that it can happen.
Both need someone from the real world to ask the important "What if?" and "Why?" and "are you a f*çXing idiot?" questions.
Actually, only the incumbents don't - mostly, the old telephone companies. Those who could request millions of IPs in the early days of the Internet, and have enough IPv4 for their needs.
Newer one may have not enough. When Sky (Comcast) entered the ISP market here in Italy, it had to borrow IPv4 from Sky UK to start, now they have been returned, some have been bought from India - but the network is being run as a native IPv6 one using MAP-T to allow IPv4 connectivity, there was little choice.
Vodafone Italia is activating CG-NAT to users because it has no longer enough IPv4 available - even using local NAT. Rumors say it will be forced to roll out IPv6 soon. Only TIM and Wind3 (born from the merger of Wind and H3G) have enough IPv4 available - and will try to exploit that "treasure" as much as they can.
All new entries here have to resort too to some form of CG-NAT - with all the downsides for users - to allow IPv4 connectivity. RIPE no longer assigns blocks large enough, and buying them on the market is expensive.
Even users start to feel the downsides of NATs - especially CG-NAT - as other services that aren't NAT friendly at all expand, not only gamers, but for example as VoIP becomes more common, and you may not want to use the ISP service only, and its CPE.
The only real downside of IPv6 roll outs is most IPv6 are doing it the very wrong way. /64 prefixes, dynamic prefixes, CPE that can't perform prefix delegation even when larger prefix are assigned. All of that will make customers' "network lives" miserable when they find they can't create subnets and/or assign static IPs without resorting to ugly workarounds.
Moslty because ISPs graybeards can't update their skills and reconfigure devices correctly.
This is the comment people should be reading.
People who are saying the issues above are not important are saying so because they don't actually understand the issues involved, what IPv6 can deliver & how it works, and that all these work-arounds are making things worse, not better. Especially when it comes to /64 or crippled /60 and the inability to configure subnets. The biggest indicator that someone is talking bolleaux is when you hear them say "there are not enough IPv6 addresses to issue more than a /60 to residential subscribers"... showing they are just trying to translate their IPv4 understanding on top of IPv6. In reality IPv6 is much less intimidating and difficult than many people imagine - any ISP with half a brain would adopt it ASAP, it's actually in their longer terms interests to do so. Some of this suggests to me part of the problem is that they are doing this deliberately in a rather sad and misguided attempt to maintain an unnecessary and harmful degree of control over end users.
IPV6 does make a difference since so many providers phone companies and also fibre ISP like Hyperoptic hide their users behind CGNAT which means home and business devices cannot be reached from the internet with IPv4. An annoying "security feature". Pay for IPv4 fixed does not do much when the better option is free.
IPv6 fixed routable IPs ranges are allocated direct to the router. Once set pinholes on the router we can have multiple devices using the same port. Many servers running https. Magic. Impossible with IPv4.
So with IPv6 we don't have to pay for a fixed IP or for an IP outside CGNAT to be reachable.
Use the IPv6. if you have to use IPv4 it is easy to map IPv4 address to a IPv6 with the SOCAT command running on an external machine, but back to just one port available.
I suspect there is rush for IPv6 as its adoption could destroy too many business models if every man and his dog can run their own servers with their 1GB fibre connections or contribute to distributed networks solutions and even earn a little from their spare internet capacity.
Gerry
What we have seen in the last 20 years or so is a shift, first from the Internet to the web, then from a decentralized web everyone can participate easily, to a small web of large platforms.
Essentially the Internet for most users is now just like 1990s "Online Services". Instead of AOL Keywords you have Google search words. Everything discourages you from making your own website.
What we should do now is to find new exciting ways to use end-to-end networks. New services which do not need centralized components.
Imagine, for example, an instant messaging protocol running on IPv6. In order to connect to another user, you both scan a QR code displayed by the other user. This way each side gets the public key of the other side, as well as the current IPv6 address. Regularly (e.g. every n minutes) the devices send pings to each other, updating their IP-address if they changed. In case a connection is lost, one could add a re-establishment protocol via SMS.
Most users are on home routers or cell phones . Cell phones just use what the phone companies supplies. The user has no interest in how it works. Small business and home users are satisified with IPv4. If you can not get adoption after all this time, you need to address why people do not want to move. IPv6 is just too complicated for the typical use case. You may need it for the Internet of Trash. But I do NOT want my light bulbs on the same network as PC and printer. The home NATing router is great protection. I do not care if the uplink is IPv6. But in my house - IPv4 is just easier.
Well, maybe not the light bulbs and all that... though they tend to communicate with some non-IP protocol back to a hub, and I WANT that hub to be on my home network, and have an IP address, and have a decent API with user-generatable authentication methods so that I can still use the kit I've invested in when the parent company has done yet another TITSUP* and their app no longer works.
"The Internet of Things" Start Up Perished.
v6 is not actually at all complicated; v4 tends to be more complicated in practice since you're stuck with also using NAT with it.
The "home NATing router" might be great protection, but none of that protection comes from NAT -- if you don't understand that, then that's a good demonstration of how complicated it is.
"none of that protection comes from NAT -- if you don't understand that, then that's a good demonstration of how complicated it is."
Hey, look, there's that throwaway line again!
Except it's 100% pure unadulterated BULLSHIT.
The reality is that NAT is actually pretty good protection from outside attacks. Want to get to a LAN address from the outside? You've got to pwn the router first. Otherwise, you simply CANNOT route to the internal address from the outside world.
But ok, smart guy. Go ahead and explain how you'd do it. I've got a printer sitting on my LAN, internal address is 10.0.0.234. It has no IPv6 address, nor any firewall protection beyond a NAT router, and it's set to the default password. Tell me how you'd attack it from some random IPv4 address on the internet. Go on, tell me how.
The actual reality is that NAT does nothing to inbound connections. NAT changes the apparent source address of outbound connections; it does nothing to inbound ones. You can't call that "pretty good protection". It's no protection.
For your printer, it's possible to connect to it from outside your network by creating a v4 packet with the destination address set to "10.0.0.234" and sending it to your router. NAT won't block it.
I'd think a packet bearing a destination address in a private ip block would have trouble getting routed over the internet. Moreover, any decent NAT implementation is likely to take a dim view on (drop) packets coming in from the WAN interface with a LAN destination address.
I'd think a packet bearing a destination address in a private ip block would have trouble getting routed over the internet.
Of course, but we're talking about NAT here, not private IP blocks.
Moreover, any decent NAT implementation is likely to take a dim view on (drop) packets coming in from the WAN interface with a LAN destination address.
That would be a firewall, not NAT. NAT implementations don't drop packets, they just rewrite the src or dest headers.
That would be a firewall, not NAT. NAT implementations don't drop packets, they just rewrite the src or dest headers.
And what is a router going to rewrite the DST address as? The router isn't going to just pick a random host on the LAN and send it the packet on the off-chance. The router has no idea what to do with an incoming packet for a conversation that it isn't tracking. The only thing it can do is drop the packet.
I think you're splitting hairs here. You can call it a firewall if you want but everyone else would call it the obvious implementation of NAT. There is simply no way you can launch an attack against my 192.168.1.106 from outside my LAN. You can subvert a connection that I have established but until I establish one there's nothing you can do.
No, it knows what to do with inbound packets: it delivers them to whatever IP is in the "dest" header, or perhaps forwards them on to another router to handle. If it's tracking the connection that the packet belongs to, then it'll rewrite the header first and then deliver it, but if it's not tracking the connection it'll just deliver it to whatever IP is already there.
There is simply no way you can launch an attack against my 192.168.1.106 from outside my LAN
Uh, yes there is. I just explained how to do it in a post up this thread.
NAT won't stop connections to 192.168.1.106 from outside your LAN, and if you think it does then that's because you've gotten confused about what NAT does and doesn't do.
NAT rewrites the apparent source address of outbound connections. An inbound connection is not an outbound connection, hence NAT does nothing to it. That means inbound connections will either be possible, or not, depending on the behavior of the parts of your network which aren't NAT.
NAT rewrites the apparent source address of outbound connections. An inbound connection is not an outbound connection, hence NAT does nothing to it.
Wrong. What NAT does is make your entire LAN appear to be a single host to the WAN. Everything trying to communicate with me does so by specifying my public IP address. Thus NAT has to modify the headers both inbound and outbound.
When 192.168.1.106 sends a packet the router changes the source address to be the public address of the router and updates its internal table of connection mappings then sends it out to the WAN.
When the router receives a packet from the WAN one of three things is done with it depending on the target address 'type':
* Private IP address - Dropped immediately. Least-wise I doubt anyone has ever implemented a NAT system that did anything other than immediately drop the packet since by definition it is invalid.
* Public IP address - if it doesn't match the router's, drop it.
* Public IP address - if it matches the router's then look in the connection mapping table for a match. If found change the destination address to be the private address of the initiating host and send the packet onto the LAN. If no match found in the table, give up and drop the packet.
Wrong. What NAT does is make your entire LAN appear to be a single host to the WAN.
No, it's right. Your description is more of a high level "here's a rough idea of what it does", not a low-level description of how it actually goes about doing it. Those low-level details matter.
* Private IP address - Dropped immediately. Least-wise I doubt anyone has ever implemented a NAT system that did anything other than immediately drop the packet since by definition it is invalid.
You should test! Linux accepts the packet. So does every other NAT that I'm aware of the behavior of (I haven't tested everything).
* Public IP address - if it doesn't match the router's, drop it.
That's not accurate. It'll go through the router's routing tables like normal.
* Public IP address - if it matches the router's then look in the connection mapping table for a match. If found change the destination address to be the private address of the initiating host and send the packet onto the LAN. If no match found in the table, give up and drop the packet.
Also not accurate. If there's no match in the table, it doesn't drop the packet, it just... doesn't change the address. The packet then gets delivered to whatever IP it was already addressed to.
To be clear, it's extremely common to deploy a firewall that does do the various drops you're describing here. It's common precisely because NAT won't do it. The CPE you're running in your house almost certainly does drop this stuff, because it has both NAT (for v4) and a firewall.
I'm simply pointing out that it's not NAT that's doing the dropping.
This post has been deleted by its author
“ For your printer, it's possible to connect to it from outside your network by creating a v4 packet with the destination address set to "10.0.0.234" and sending it to your router. NAT won't block it.”
Nat will block it because If there is no entry in the nat table it can’t route the incoming initiated connection to the correct internal rfc1918 address.
You can’t directly route to rfc1918 addresses across the internet.
Of the billions of systems that have 10.x addresses behind nat how do you know which router to send your rfc1918 traffic too?
ISP’s drop traffic with rfc 1918 dst IP’s.
Also how do you send something to your router from the internet with an additional dst ip? TCP packets have just 1 dst ip.
No, NAT won't block it. NAT doesn't route anything. All it does is rewrite the src or dest headers on packets; any firewalling or routing is handled by the rest of the networking stack. You don't need a state table entry for basic routing to work.
You can’t directly route to rfc1918 addresses across the internet.
Correct.
Of the billions of systems that have 10.x addresses behind nat how do you know which router to send your rfc1918 traffic too?
If I want to access a network behind your router, then I send the traffic to your router.
ISP’s drop traffic with rfc 1918 dst IP’s.
They should do, at least.
Also how do you send something to your router from the internet with an additional dst ip? TCP packets have just 1 dst ip.
You don't. The TCP packet's dst address would be set to 10.0.0.234.
Because that's RFC1918, the only way to get it to your router would be to have a machine on your immediate upstream network, configured with a route for 10.0.0.234 via your router.
When the packet arrives at your router, it won't match a NAT state table entry, so NAT won't touch the dest IP. Your router will then follow its routing table entries and route it to your local network.
NanashiNo, NAT won't block it. NAT doesn't route anything. All it does is rewrite the src or dest headers on packets; any firewalling or routing is handled by the rest of the networking stack. You don't need a state table entry for basic routing to work.
You can’t directly route to rfc1918 addresses across the internet.
Correct.
Of the billions of systems that have 10.x addresses behind nat how do you know which router to send your rfc1918 traffic too?
If I want to access a network behind your router, then I send the traffic to your router.
ISP’s drop traffic with rfc 1918 dst IP’s.
They should do, at least.
Also how do you send something to your router from the internet with an additional dst ip? TCP packets have just 1 dst ip.
You don't. The TCP packet's dst address would be set to 10.0.0.234.
Because that's RFC1918, the only way to get it to your router would be to have a machine on your immediate upstream network, configured with a route for 10.0.0.234 via your router.
When the packet arrives at your router, it won't match a NAT state table entry, so NAT won't touch the dest IP. Your router will then follow its routing table entries and route it to your local network.
You clearly don’t understand how networking actually works which feeds into your misguided thoughts on nat.
There is so much wrong with what you wrote.
An ipv4 packet has these fields amongst others. src-ip, src-port, dst-ip, dst-port.
If I want to get to your 10.x address from my public 9.30.1.30 address how do I put that in the ipv4 packet? You put the dst-ip in the dst-ip header but how does my isp or any intermediary know to send my ipv4 packet to the public ip of your router and not to literally anyone of millions of other public IP’s of end point routers for onward routing? The answer is my isp or any intermediaries can’t hence why there is an rfc for isp’s to not route rfc1918 addresses.
If you have port forwarding on your router, let’s say it’s 7.7.7.20 port 20 forwarding to 10.0.0.50 port 443, I can put that 7.7.7.20 in the dst field of the header and every router between my computer and your dst will know exactly what to do to get my connection to you.
NAT is exactly like that port forwarding but dynamic in that when your 10.0.0.60 device wants to connect to my 9.50.9.50 your router makes a note of the src-ip (10.0.0.60), src-port (let’s say it’s 2020), dst-ip (9.50.9.50), dst-port (443) and rewrites the src ip & port for the routers public ip & possibly a new random port, nothing along the path will know about 10.0.0.60. My server will return traffic with your public ip and src-port in the dst fields. Your router checks it’s nat table for incoming connections with your public ip and port in the dst field and my public ip 9.50.9.50 & port 443 as the src, when it finds a match it rewrites the dst details to be 10.0.0.60 port 2020 and forwards to that machine.
NAT MUST be stateful, it keeps track of connections, removing closed, old, & dead ones.
If you nat then you have a stateful dynamic firewall.
Firewalls don’t need to track state but they are more useful when they do, you don’t want an attacker reusing an old session. NAT is therefore far better than a basic firewall
Before moaning about NAT and singing ipv6’s praises it’s helpful if you understand how networking actually works and actually how nat works.
If I want to get to your 10.x address from my public 9.30.1.30 address how do I put that in the ipv4 packet?
You put the 10.x address in the dest field, like I said.
You put the dst-ip in the dst-ip header but how does my isp or any intermediary know to send my ipv4 packet to the public ip of your router and not to literally anyone of millions of other public IP’s of end point routers for onward routing?
They don't. Like I said! You'd need to be on the immediate upstream network to arrange for a packet with an RFC1918 address to arrive at your router's WAN interface.
NAT is exactly like that port forwarding but dynamic [...] and forwards to that machine.
Okay, so, here's the big question: what exactly happens when a packet arrives at the WAN interface and it doesn't match an active NAT state table entry?
I've tested this, multiple times. The answer is that the packet is routed based on whatever IP is already in the packet. If that IP is the router's IP, then the packet is delivered to the router itself. If the IP is from the LAN-side network, then the packet is routed to the LAN network.
To be clear, the packet is not dropped, not unless you also configure a firewall that rejects new inbound connections.
If you think I'm wrong about this, then please explain why I see it happen when I test.
NAT MUST be stateful, it keeps track of connections, removing closed, old, & dead ones.
Stateless forms of NAT do exist, but okay, the form of NAT that we're talking about here is indeed stateful. But...
If you nat then you have a stateful dynamic firewall.
As I've said multiple times, no, you don't. You don't automatically get a firewall along with NAT. It's usually very easy to get one, and they're commonly configured together, but they're still separate things.
You can test this yourself if you want. Just set a test network up in a few VMs and watch the behavior. You'll see it matches what I've been describing the whole time.
You really don’t get it.
Maybe get a pencil and paper and work it out.
Some great articles on the net on how packets traverse networks.
https://www.washingtonpost.com/graphics/national/security-of-the-internet/bgp/
https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=03c598ea-e171-47c9-8035-753ccd8bb36e&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments
I’m sure you can find some videos of the szz as me.
Neither of those articles are relevant. They're talking about how packets go over the internet, whereas I'm talking about NAT. The question isn't "how do I get a packet to your router", it's "what does NAT on your router do to the packets that arrive at it".
The answer to that question is that the destination address (for a packet coming in from the WAN) is looked up in the NAT state tables, and if an entry exists then the address is rewritten per the state entry, and if no entry exists then it's not rewritten.
Notice that nowhere in the answer is "the packet is dropped". That's because NAT won't drop the packet. Again, this is something that I've tested on real networks, and it works like I'm saying it does, not like you're saying it does. And, again, you can test it yourself if you don't believe me.
The fact that we can get this deep into a reply chain and people still can't get their heads around "NAT doesn't drop packets" just goes to show how badly people understand its behavior.
Notice that nowhere in the answer is "the packet is dropped". That's because NAT won't drop the packet. Again, this is something that I've tested on real networks, and it works like I'm saying it does, not like you're saying it does. And, again, you can test it yourself if you don't believe me.
so you admit now that the only way to reach your network from across the internet is to have your public ip in the dst field of the packet, & you now acknowledge that the router must check the nat table for a corresponding entry to know which internal host to forward the traffic to. Now, the final hurdle for you, how can the router forward the packet to an internal host if it has no corresponding nat entry that matches the src-ip, src-port, dst-ip, dst-port details in the packet......
to save on gears grinding, the answer is that it can't forward something it has corresponding entry for as it won't know which internal host to rewrite the dst-ip & dst-port details to. if it can't forward it it can't keep it forever so it drops it.
The fact that we can get this deep into a reply chain and people still can't get their heads around "NAT doesn't drop packets" just goes to show how badly people understand its behavior.
that is the only accurate thing you've contributed to this discussion.
you now acknowledge that the router must check the nat table for a corresponding entry to know which internal host to forward the traffic to.
Not quite. The router has to check the NAT table to see if the dst header on an incoming packet needs rewriting. If it does, it's rewritten, otherwise it's not rewritten. Actually routing the packet is done separately, by the not NAT parts of the router.
Now, the final hurdle for you, how can the router forward the packet to an internal host if it has no corresponding nat entry that matches the src-ip, src-port, dst-ip, dst-port details in the packet......
Easy: it looks at the dst IP header of the packet. Same way any router does it.
to save on gears grinding, the answer is that it can't forward something it has corresponding entry for as it won't know which internal host to rewrite the dst-ip & dst-port details to.
It can, because rewriting isn't necessary to forward a packet.
If the dst IP header of an incoming packet contains an IP from the network range on your LAN after NAT has rewritten the header, your router will route it onto the LAN.
If the dst IP header of an incoming packet already contains an IP from the network range on your LAN when it arrives at the router... your router will still route it to the LAN. It doesn't care whether the NAT stage rewrote the header or not.
"Not quite. The router has to check the NAT table to see if the dst header on an incoming packet needs rewriting. If it does, it's rewritten, otherwise it's not rewritten. Actually routing the packet is done separately, by the not NAT parts of the router."
I think the bigger question being overlooked is, "How does a packet with a RFC1918 destination address get to your router from the outside in the first place?" Under RFC1918, if the ISP gets a packet with that address, it's supposed to have a rule to drop it, meaning it doesn't send it on to your home router, meaning the home router never sees it. Furthermore, given the destination address is not intended for public use, how would the ISP know where to send this packet if most of its customers are using such addresses for their internal use? It'd be like the postman getting a card address to house #10 with no street designation. There are only two ways in from where I sit. Either the ISP lets it go through, knowing which one of its customers is the intended target (meaning the ISP is rogue), or the packet got injected somewhere between the ISP and the home router, implying an Evil Tech. Either way, you have bigger problems at that point.
Going further, what needs to be understood is that the NAT part of the network stack and the Firewall part of the network stack are two distinct components. Think the UNIX philosophy: each of them only does ONE thing. Basically, the NAT only performs translations. It keeps tabs and so on, but only for that, while the firewall keeps its own rules for accepting and rejecting packets it gets. Thing is, outgoing packets get sent to the NAT if sent to something like the FORWARD rule, whereas incoming packets had been massaged by the NAT beforehand. Sometimes they're rolled into the same thing, but for the sake of the argument, think of them like two different things...especially since each one could be interchanged with different components.
If you don't want your light bulbs on the same network as PC and printer then you should be screaming for IPv6 and "network coloring" (think automatic sub-net), not making a case against IPv6.
And IPv6 is not too complicated - the vast majority of home users will not have to do anything at all if carriers provide properly configured CPE. In some respects it can appear more complicated (SLAAC can appear scary to people), but in others it is less complicated (no NAT).
> "In my house IPv4 NAT is just easier"
Outside readers of TheRegister who configures NAT or IPv4 or IPv6 in their house... People get IPv6 in their house when their ISP turns it on because it runs out of IPv4 address = the problem IPv6 was meant to solve all along. They use the default IPv6 firewall settings provided by their ISP that give them the same protection than IPv4 NAT - without the P2P limitations of CGNAT.
Everyone gets IPv6 on their mobile phone for the same reason.
Big companies who can afford it turn off IPv4 because it simplifies things and saves them money in the longer run.
Small businesses will be last to switch if ever - who cares. Life goes on.
In my area of the world, Australia, more ISPs are running out of IPv4 addresses, thus placing folk on CGNAT. I assume that will eventually spread to everywhere with IPv4 address exhaustion.
I am vaguely computer literate, I can set up and run minor servers from home on IPv4. But on CGNAT, I can't. At my level of comprehension, the workarounds seem to require me to give others unnecessary info about my users, not a good thing.
To me, IPv6 has more security implications for my users in being traced more easily. On IPv4 with dynamic IP addresses, my users can't be easily traced by foreign powers. But IPv6 addressing seems to be able to nail you easily.
Really, I would love to be able to have fairly secure IPv6 privacy. I just don't see how. I would love to see some approaches that a non professional can use to do it properly.
If someone can point to resources which show I can do decent privacy on IPv6, I would embrace IPv6.
To run some minor server from your home you still need a static IPv4 which still allows tracking. Sure, you can use some DDNS server - you're still giving the DDNS provider the history of your IP changes (are you sure that is not sold to someone?), and you may not be able to reach your network if the DDNS system has issues.
With IPv6, your clients have 2^64 IPs to choose from for each /64 prefix. A good DHCPv6/SLAAC implementation will exploit it to give clients "random" addresses each time, making a single client hard to track. The prefix can still be tracked, but that's not much different from a static public IPv4 address.
Anyway, your internet activities contains a lot of data that can be used for "fingerprint" the client unless you just send some random packets.
"my users can't be easily traced by foreign powers"
"Foreign powers"? Do them include the worst commercial data hoarder? Because it's funny when people fear their are tracked by CIA, MI5, Mossad, FSB and forget they are routinely tracked by Google, Facebook, Microsoft, Amazon, Apple... which controlling OS and applications doesn't really need the source IP to know which client is which "product". And they can still need to give access to some "foreign powers".
What security/privacy implications are you even talking about? The situation is no worse on v6 than it is on v4: prefixes are either dynamic or static (mostly dynamic, like v4) and host IDs are randomized and changed frequently (so you can't track individual hosts on a network, like on v4 behind NAT).
v6 doesn't let people "nail you easily"... or at least, any easier than v4 does, because tracking on the internet is already pervasive on v4, but let's just ignore that part.
The privacy concern is why I make sure to disable IPv6 on all kit. Automatic fiddling with the local part of the address doesn't cut it as the network part may well be static and Google etc. are certainly smart enough to figure this out; with IPv4 I can at least force a new dynamic address on a regular basis by presenting a different MAC for the ISP's DHCP server or hide behind CGNAT. Come to think of it, CGNAT or a similar arrangement should really be the legally mandated default for consumer connections, especially with IPv6.
I've been running dual stack on my home network for at least 5 years now and my ISP (Comcast) resolves IPv6 first. If I ssh to a remote PC on my network by hostname it is resolved to the IPv6 address not the v4 and all but a few very old IOT devices are dual stack. T-Mobile USA is all dual stack and I'm pretty sure all the VoIP traffic is IPv6. Honestly other than having to use hostnames for devices instead of memorizing static 192.168.1.0 addresses it really hasn't been much of an issue.
Yeah, I discovered hostname resolution used it by default a few years ago when one of my applications started failing to connect to another machine on my local network. The issue was down to my networking library not supporting it correctly. (Something I fixed in about 10 minutes.)
The problem with complaining about IPv6 is what else are we all supposed to do? Bodging v4 would just fix for a short while and/or would also break all clients for little gain. IPv4 with CGNAT will only buy so much time. Consider:
1/ Some mobile networks already have used up all the 10.0.0.0/8 space for the mobiles on their networks. Splitting this apart to multiple 10.0.0.0 network is very hard to manage!
2/ For busy networks we are already burning through port numbers for all these outbound services, this is a fundamental limitation of any NAT.
3/ Already an IPv4 address costs more than an computer to connect to it. That's ridiculous.
So either we all switch to IPv6 or it has be something else entirely. IPv4 just isn't going to cut it forever
Signing up to the various registries as a member and making a request for a carrier independent IPv6 address block isn't free either. $1400, yearly, plus $1000 fee to ripe. How many quintillion IP ranges can they hand out? How much revenue would that generate? More than the money in the world.
Ok, managing this isn't free, and that cost has to be met somehow. But that price is frankly ridiculous.
I know someone is going to say, "but you never change your ISP that often, just use one of theirs". Well, from time to time my ISP does go down. So, I fall back to routing through a tethered 3g connection (or something g, nowdays). A different ISP. So, all my headers are wrong.
I'll take one very finest of your IPv6 address ranges, please. ISP independent for me thanks. Sorry, how much?
"You can't request IPv6 PI assignments directly from the RIPE NCC. Instead, you will need to find a RIPE NCC member to request it on your behalf" The cost depends on what the "sponsoring LIR" charges you. You don't need to become a RIPE member.
https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/how-to-request-an-ipv6-pi-assignment
Still someone upstream has to router your prefix - and if you just switch to a "tethered" 3g connection I guess you don't know what you're talking about. Fault tolerance with multiple routes on different links for the same prefix is a bit more complex to setup than using a "tethered " phone.
"Hey boss! D'you mind signing this blank cheque? I want to set up IPv6 throughout the organisation."
"Oh, right. Will it be faster?"
"No."
"Will it be cheaper?"
"Actually, no. On the contrary, we'll have to rip and replace a load of networking kit and reconfigure everything."
"So that'll mean an outage?"
"Well, yeah. Every device on the network will have to be reconfigured. Servers, PCs, telephony, the lot."
"You're fired!"
I'd fire you too with answers like that!
It's measurably faster (https://www.youtube.com/watch?v=76XbdedSrww), it's cheaper (no NAT, no split horizon DNS, no RFC1918 clashes, easier-to-understand network...) and it can be deployed incrementally and without outages.
If you need to replace networking gear at this point, either you're running stuff from 2005 still (so it's due for replacement anyway) or you bought v4-only hardware recently, which is your fault.
It sounds like you just don't know what you're doing. That's not v6's fault.
Unfortunately the group who devised IPv6 threw everything (including a few kitchen sinks!!) into the mix and expected it to fly.
A sensible alternative would have been to just extend the addressing from 32 bits to 64 bits with a direct map from IPv4 address aaa.bbb.ccc.ddd to IPv6 address 0.0.0.0.aaa.bbb.ccc.ddd . This would still have been enough for every human being on the planet to have had over a hundred million IP addresses!! - instead IPv6 would allow each atom in every human being on the planet to have over a million IPv6 addresses!!! (WHY ????)
One obvious (to everyone except the IPv6 designers) result is that routing in IPv6 is a nightmare needing far bigger routing tables than IPv4.
The designers of IPv6 seemed to want to include all the rubbish that made the OSI network model unwanted and then add several dump trucks of its own rubbish to make the result even worse.
Do NOT allow theorists to design systems !!!
Icon for the designers of IPv6 ======>
(the icons unhappy, WTF?, D'oh. pissed off, and Eat this are also appropriate)
v6 is 128 bits because 64 isn't enough. EUI-64 addresses are 64 bits, and IP provides hierarchical allocation and aggregation on top of that, so it needs to be bigger than 64 bits. The next power of two up is 128.
Also, you might have noticed that deploying a new IP protocol is an extremely disruptive and expensive operation. We really don't want to have to do it again.
> A sensible alternative would have been to just extend the addressing from 32 bits to 64 bits with a direct map from IPv4 address aaa.bbb.ccc.ddd to IPv6 address 0.0.0.0.aaa.bbb.ccc.ddd
Ah, yes, but... how would this help? Even if you have a direct map, v4 hosts still couldn't talk to v6. In fact v6 already has a block allocated to this -- it's ::/96, allowing for ::aaa.bbb.ccc.ddd, exactly as you suggested. It's just not useful.
> One obvious (to everyone except the IPv6 designers) result is that routing in IPv6 is a nightmare needing far bigger routing tables than IPv4.
How is it a nightmare? v6 routing tables are much smaller than v4, due to the sheer size of the address space, which allows for significant aggregation. It's not hard to find ISPs with 500 v4 announcements and one single v6 announcement, covering the same network.
I'm also not sure about this "kitchen sinks" bit.
I think we should be glad the design of v6 was left to people who understood what they were talking about, not the many people in these comments who have no idea what the technical requirements are or how to meet them.
Here in the UK, the big providers have all hoarded IPv4 addresses, and if you start a business and want a good sized block, you need to buy them.
This gives the old guard a competitive advantage, so it's not in their interest to promote IPv6 adoption.
Where it suits them, you'll see IPv6 usage. BT and Sky now have it enabled by default on consumer services. Some mobile phone operators use it, they have so many attached devices that rfc1918 addresses were exhausted on a national scale.
The world needs more than 4 billion IP addresses is correct and highly relevant. All the IPv4 addresses have been allocated, in some regions a long time ago, others more recently. If you want to get a new allocation now you have to justify your need and if approved you join a queue to get one. Have a look at the regional registries if you want to know their processes.
And just tinkering with IPv4 doesn't work. Changing the IPv4 header to allow a bigger address space can go two ways:
o Use a header extension or similar for the bigger addresses. Which is slower to process and means it's no longer IPv4 and anything which doesn't know about the header won't get the address right and won't handle the packet properly
o Use bigger fields for source and destination which is just as quick to process but no longer IPv4 and anything which doesn't know how about the header format won't be able to hand the packet properly.
So either way, once you've decided the only approach is to play with the packet header - and that's a fairly fundamental bit of the protocol, you're into new protocol version territory. And at that point, everything else came up for grabs and the IETF decided to simplify things from 14 fields down to just 8 and take a good hard look at what's really needed.
Now whether all the choices made 25 years ago were all good choices in retrospect is another question. The same can be asked about IPv4 too. The extra bits of both protocol suites have evolved - can you imagine anyone today doing IPv4 without DHCP? Do you remember when APIPA first came in and broke things? Same for avahi/mDNS appearing and breaking things?
So the question then becomes how do you manage a transition to IPv6 once you've got the inertial of billions of users dragging you back? Isn't it any surprise that without a global benevolent dictator we're in an extended halfway state, and most likely will be for some time yet we reach the point that IPv4 naturally fades into obsolescence? Users certainly aren't going to care as long as they can get their daily fix of web trivia.
Or a lot of people have got to get their heads around a bunch of new acronyms (NAT64, CLAT/PLAT and worse) and how to deploy them securely and reliably and without spending money or breaking things along the way. Suddenly dual-stack doesn't seem too bad eh?
The first network I build ran on NETBIOS/NetBEUI, and then moved to IPX/SPX a few months later. At a subsequent employer I inherited an IPX/SPX network and and had to deploy IPv4 as dual-stack, with every PC and laptop having a static IP "for security" (and the fact that we didn't have a DHCP server even if I could BOFH the security guy). It was a challenge, but it worked. And only a few developers noticed (and even fewer said thanks).
Technology changes. I'd like to think that if IP is still in use in another 50 years time, my grand kids won't be worrying about how to upgrade the entire solar system to a 512-bit address space.
The least we could do in the mean time is make sure any device or application that talks IP supports both IPv4 and IPv6 so we can make the transition as gracefully as possible without having to maintain legacy IPv4 networking for those few vitals boxes of kit that still need it. That is probably as likely to happen as making sure all such devices are relatively secure and easy to repair or recycle.
"Changing the IPv4 header to allow a bigger address space"
That's called IPv6. Once you change the IPv4 header, it's neither forwards nor backwards compatible. So you get a dual stack model, designed for an indefinite period of coexistence. That's always been the design goal for IPv6 and it's working just fine. Usage is around 38% and regularly increasing (says Google.)
Announcement of the death of iPv4 remembers me the announcement of the death of the PC. Announced each year for the last 20 years but never happening.
The author is right: if IPv6 was the solution, it would have been adopted long ago. Real life shows it wasn't. There it demonstrates its usefulness is unproven.
@Nanashi
Quote: "...You'll still be the one to decide whether those devices are reachable or not...."
Ah.....that's what people said about my smartphone. Then someone SMARTER at NSO wrote Pegasus!!!
Another quote: (William Burroughs) "The paranoid is a person who knows a little about what is going on."
IPv6 for common-or-garden networking is ... well ... just another thing. Once you get used to it, the hex notation becomes memorable in its own way.
I agree with the article author in that there's little that jumps out as a compelling reason to make the move - but that's perhaps a good thing. For common use cases, there's nothing in IPv6 to scare the horses.
The biggest issues I've had with IPv6 so far have been crappy software apps that freak out when a DNS entry ONLY resolves to an IPv6 address (i.e. not expecting 0 IPv4 addresses). Everything else, from network firewalling to VPN to DNS to server setup has been frankly a non-event, which is just what I want.
I'm sure I'm not running anywhere near as complex a network as some of the other illustrious commenters on this page, so I'm not going to say the transition is without any effort. But even if you don't need to, I would encourage you to start running IPv6 on top of your existing IPv4 network, just to build familiarity. And more widespread adoption may encourage more application frameworks (*cough* Node.js *cough*) to fix their broken software.
"I agree with the article author in that there's little that jumps out as a compelling reason to make the move "
IPv4 NAT breaks a bunch of things in minor ways. Mostly you won't notice it if you're behind a NAT gateway
IPv4 NAT behind IPv4 NAT breaks a LOT of things in MAJOR ways and is a pain int he arse
CGNAT breaks even MORE things in even MORE major ways
Entire countries are setup like this, particularly in Southeast Asia.
At one point all of Vietnam was behind one /24. Myanmar has 60 million people behind a /19
Just because "It works for you" doesn't mean that IPv4 and the kludges that go with it to kweep it running aren't a clusterfuck on steroids. It just means you don't see the shitshow and endless platespinning that's going on behind the scenes to keep everything running
IPv6 really _is_ easier
Almost everybody in my organization hopes or hoped that they could retire before touching IPV6.
In larger enterprise-networks, NAT becomes a serious problem. And of course, people having barely a grasp of IPV4 after a decade in IT would now need to start over.
In any larger organization, you'll also need some soft of IPAM or even better an integrated DDI solution (most have skipped that because for V4, you can somehow muddle through).
IPv4 is a routing protocol. It was intended to be sparse
IPv6 is a routing protocol, it is intended to be sparse
Just because IPv4 allowed 4 billion possible addresses doesn't mean it was INTENDED to have them. It was a red/black tree thing
We have had to layer hideous layers of complexity onto the Internet in order to eke out the usability of every bit of IPv4 numbering that was never intended to be used
The protocol itself was only intended to be in play for about 5 years. It was a self-described "hacky kludge" to keep things going
Packing 1 billion devices into IP v4 space (let alone the current 8-12 billion) was a classic illustraion of the phrase "Just because you CAN, doesn't mean you SHOULD"
"Packing 1 billion devices into IP v4 space (let alone the current 8-12 billion) was a classic illustraion of the phrase "Just because you CAN, doesn't mean you SHOULD""
I'm reminded of another phrase: "If you build it, they will come." You see it all the time with roads. Especially for something available to the public, it seems no matter how much capacity one adds, the public finds a way to use it up. It's a mug's game, really. Limits are needed, but no one likes them.
What baffles me the most in IPv6 is this:
- the designers set up a big 128 bits address space
- it took them, what, 30 years to think it would be a good idea to encapsulate the tiny 32 bits IPv4 space, for, ... you know, compatibility
Had it been done before, v6 would it be the doomed kid it now is ...
PS: I doubt there is even one ISP with IPv6 in my country, France.
" it took them, what, 30 years " IPv4 was encapsulated from the outset
The problem is and was that the only overall solution is dual-stacking. It's not as if we hadn't done THAT multiple times before and it wasn't difficult
I had worse times dealing with $LARGE_ORGANISATIONS which had decided that they were never going to connect to the Internet, so pulled IP ranges out of their arses, then had to renumber their entire networks a couple of decades later
One lot who didn't - but tried to NAT themselves instead - phoned me up in a panic one day thinking they'd been hacked by UCLA - who happened to use the same 128.* IP range the organisation had taken for internal use. They resisted renumbering for more than a decade and came up with a lot of creative excuses for why they couldn't provide live Internet access to staff.