It'll happen two years after
The year of Linux on the desktop
IPv4 is here to stay with us for a good few years yet, reckons the the Réseaux IP Européens Network Coordination Centre's (RIPE NCC) public policy manager, eight years after IPv6 was supposed to replace it. Marco Hogewoning, public policy for the Amsterdam, Netherlands-based European regional internet registry, told The …
One reason why IPv6 hasn't exactly taken the world by storm is its not a very good solution to the problem of extending the address range of the Internet. It certainly is a solution, it gives everyone a huge address space to work with, but the baggage that comes with this version of the IP protocol makes it messy to implement compared to the rather thin, almost elegant, IPv4 original.
We're told that we absolutely have to move to IPv6 because of the Internet of Things -- billions of device that all have to communicate with each other. There may be a rationale for this but I suspect its more to do with marketing strategies than sound engineering practice.
"We're told that we absolutely have to move to IPv6 because of the Internet of Things -- billions of device that all have to communicate with each other."
Explain to me again why I would want my garbage disposal to be able to talk to a garage door opener in Bangkok. Or to anybody else for that matter. I'm a bit hazy on that point.
Come to that, I'm pretty sure I don't want the electronic junk around here talking to or being talked to by ANYONE without adult supervision. And I sure as hell don't want it loading "improved" software or firmware on its own recognizance.
IPv4 provides only around 2 billion IP addresses. There are 7 billion people in the world. Do the maths.
Over time, it is likely that the majority of us will have, at the very least, a smartphone of some kind, if not one or more other internet-connected computers. Yes, NAT can help, but it is a bit of a kludge.
"If the only problem is lack of address space, why not simply add another dot and three more digits?"
You forgot the :-) icon.
Even adding one binary digit to the address length breaks all IPv4 protocol stacks. Adding 96 bits is a pragmatic choice, but in either case every single app, computer and router in the world needs an upgrade. That's why it's taking a while. We're above 30% now.
It's not really that 'different' though. Fundamentally it is a few more digits. Actually quite a few - 96.
For better human recognition, the expanded address range is usually represented in hex rather than decimal, but IPv4 addresses can be shown in hex and vice versa.
Given that network stacks need to be rewritten to accommodate this expanded address range (eg allocating more RAM for addressing and thus packet headers...), it's useful to change the display convention so people can differentiate between legacy and updated versions.
Given that that's all happening, you may as well add the other extra features that IPv6 provides.
Change the thinking around... another option would've been to make each byte bigger - say 10 bits, which would increase the address space 256-fold (IPv4 address being 4 bytes this would be going from 32 bits to 40 bits). How simple would that solution be???
Except it really IS that different. Everything about it is different.
It was mostly designed to solve a problem no one had or wanted solved. And it does that badly.
The only thing ipv6 should have done was increase the address space - AND NOTHING MORE. That was the problem, and all the rest of the baggage that v6 brings with it is actively contributing to lack of adoption, because NOBODY WANTS THAT GARBAGE.
At this point we need an ipv7 that replaces ipv6 and is simply ipv4 with a 64-bit address space.
That's pretty much all it does. Almost everything else works the same way v4 does. Routing works the same way, address assignment works the same, DNS works the same, it works over the same L2 links that v4 does, TCP, UDP and other L4 protocols work the same, link-local addresses are in v4, and v4 even had router advertisements already before v6 was out... what's actually different?
There's NDP instead of ARP, but they work the same general way, except broadcast is removed in favor of multicast. v4 already has multicast so if anything this is actually a simplification. SLAAC is new, but that's really simple. I'm struggling to think of anything else.
> At this point we need an ipv7 that replaces ipv6 and is simply ipv4 with a 64-bit address space.
That's one of the last things we need. 64 bits would be insufficient, and expanding the address space from 32 bits to 64 bits has all of the exact same problems that expanding it to 128 bits does, so it wouldn't actually help you any. You'd just be throwing away 20 years of software support and deployment to restart from scratch with something that's going to have the same trouble deploying, which doesn't seem like it would help much to me.
sharing similar capability is not the same - it's still different.
yes, adding extra octets WILL break things, but it's just a matter of doing some relatively minor alterations to existing code rather than rewriting everything from scratch.no one complained when ASN length was increased because it was a simple change that could be coded relatively quickly and easily and consumers noticed no difference in how things worked.
it would give you the option to include all existing addresses (e.g. 220.127.116.11 becomes 0.0.1.2.3.4) and routing tables can expect that. interfaces to old equipment that can't be upgraded can sit behind a very simple translator that changes 0.0.1.2.3.4 to 18.104.22.168 and blocks anything outside 0.0.*
one of the most unexpected outcomes of NAT was how much people actually like it. much harder to target something that isn't addressable. clearly the designers of ipv6 were under the impression every device would need a server running on the same port. in reality, since select/poll/epoll came about all of these devices are just clients instead of servers.
Yes, and that's exactly what we did, except it doesn't seem to have stopped people from complaining about how massive the differences are and how we should've done the things we did do...
You don't need to rewrite your software from scratch to support v6. It's just some relatively minor alterations, and those alterations are exactly the same as the ones we'd have to make if we only added the 16 bits you seem to be suggesting we should've added -- which, incidentally, would be by far insufficient for the internet and would lead to needing to replace the IP protocol a second time. Surely it's better to add enough addresses the first time around?
v6 also does the "all existing addresses sit inside the new address space" thing, and it can do the simple translator thing you describe. Again, it already does the things you're saying it should've done.
ASN length was a different beast, because we didn't have hard-coded 16-bit ASN fields in every piece of network-capable software and hardware on the planet. The vast majority of network devices don't know or care about AS numbers at all. It's not relevant to the challenges posed by upgrading the IP layer.
> ... and those alterations are exactly the same as the ones we'd have to make if we only added the 16 bits you seem to be suggesting we should've added -- which, incidentally, would be by far insufficient for the internet and would lead to needing to replace the IP protocol a second time.
Well there are ~10^14 48-bit addresses. That's of the order of 10,000 addresses for every person living on the planet. That would surely be an adequate number of them.
But, just in case, we could have expanded to 64-bit addresses. There are ~10^19 of these - around a(n American) billion per living person. That would certainly suffice up until the Sun turns into a red giant and starts boiling off the Earth's oceans.
But, no. The IPv6 designers went for 128-bit addresses. Why?
Because it's the smallest power of two that's bigger than 64.
The point of L3 is to provide a layer of routing and aggregation on top of L2. Routing and aggregation consumes address space. L2 is 64 bits for new protocols, so L3 needs to be bigger than 64 bits. The next power of two up is 128, so here we are at 128 bits.
We could perhaps have gone for 80 or 96 bits, but can you imagine the sheer amount of wailing and teeth gnashing that a non-power-of-two bit length would've caused?
“ Because it's the smallest power of two that's bigger than 64.”
The reason addresses are 32, 64, 128 bits is because of processing efficiency.
If CPU’s back then where 20 bit, the ipv4 address space would likely had been 40bit.
Back when ipv4 was created 32 bits was exactly 2 16 bit cpu cycles. Any scheme that used bit values not an exact multiple of the cpu would be inefficient.
64 bits was 4 x 16 bit cycles, 2 x 32 bit or 1 x current 64 bit.
One reason why you can’t just add an octet or 2 is you’ll be wasting cpu cycles and may as well consume the full compute space or multiple off. Cheap compute (Think domestic broadband routers given away to subscribers) running as efficiently as possible powered the early internet and ensured its success. The less cycles required to process a packet, the quicker it goes on it’s way, the faster the service etc etc.
Early computing and networking was built on efficiency. Today we rely on excess.
"That's of the order of 10,000 addresses for every person living on the planet. That would surely be an adequate number of them."
"640kB ought to be enough for everyone - we're only using 64kB now!"
"Oh look, if we give every building in town a sequential number as they're built, we can write it all out in one line!" (incidentally this IS how buildings are addressed in Japan and it makes for merry hell trying to find anything when walking down the streets)
IP addressing gives LOCATION and ROUTING details as well as a unique address.
I cannot emphasis this enough: IPv4 IS MEANT TO BE SPARSE - all Internet addressing is - because it's supposed to be a red/black style routing table
The sparseness of IPv6 is careful and deliberate. It's a feature, not a drawback. Think of it as street addressing, not a series of pigeonholes
The tradeoff is vastly reduced computational load on routers across the Internet. It turns out that numbers and sparseness is something that computers are good at and who cares if www.google.com is 22.214.171.124 or 2a00:1450:4009:806::2004? You don't go to site by IP address anyway
Um, not really.
IPV4 with two more octets would have met the need for more space admirably, and address representations would still be human sized. Job done in six months, hardware manufacturers could have had samples out in a few more, and we could be using it.
Instead of which, we got a weird-ass new addressing scheme which is not sysadmin friendly at all, and the names of most of the supporting protocols changed as well, merely for the sheer love of being dicks. (And because of a truly, horribly mistaken belief that every endpoint should be publically visible on the internet to every other. NAT: it ain't a kludge, it's a vital security tool.)
48 bits won't be enough in the long run (possibly not even in the short run), and even if it was, deploying an address family that used 48-bit addresses would take the same amount of work that deploying v6 is taking. The work isn't proportional to the number of bits! You need to do the same amount of work to deploy any address family with a bigger address size.
NAT isn't a vital security tool. It provides no security, so it isn't a security tool, and if it's not a security tool then it certainly can't be a vital one. If anything, NAT complicates your network and thus makes it harder to secure.
>The work isn't proportional to the number of bits!
But it is directly related to the number of systems and entities involved. The IPv6 nutters couldn't see this and so instead of grasping the moment and do what was suggested and which would have been simple and possible in circa 1994, went all ivory tower and so the opportunity was missed.
Here in 2020 any change to IPv4 addressing is going to be a major undertaking and the least costly does seem to be to utilize the IPv6 backbone that has been quietly rolled out across many telcos and ISPs; whether it is fit for the usage styles of the present day is another matter...
"IPv6 nutters"? "Ivory tower"? Are we really going there? Again?
The people who designed v6 knew full well what would be involved. We ended up with what we did because there wasn't any other way to do it. v4 doesn't support addresses bigger than 32 bits, and fixing that involves replacing the IP stack with one that does support bigger addresses, and then plumbing that support through to everything that deals with IP addresses.
There's simply no way around this. You have to touch every system, because v4 is the layer of the internet that touches every system. The only methods that would help (things like 6to4, NAT64 etc) were used for v6.
Designing something that takes into account the limitations of the existing technology and of what can be done... is the exact opposite of an ivory tower.
If you're looking for people in ivory towers, perhaps you should look at the people who insist there's a way to make v4 somehow be forwards-compatible with bigger addresses without making any changes to v4 or any v4 devices. The people who are ignoring how both v4 and v6 work. Those are the people who are ignoring reality.
Incidentally, if you do have a way of designing a new protocol that's easier to deploy than v6 is, then feel free to prove me wrong by posting it -- so long as a) it actually works, and b) it's not something that v6 already does, because if it doesn't meet those two requirements it's just going to be another in the long list of dumb suggestions that don't actually help.
"perhaps you should look at the people who insist there's a way to make v4 somehow be forwards-compatible with bigger addresses without making any changes to v4 or any v4 devices. "
These are of course the same kinds of people who believe in Mauve Unicorns in Sunlit Uplands and Empire 2.0
Arguing with religious zealotry against IPv6 is on par with playing chess with a pigeon. The pigeon puffs its chest out, knocks all the pieces over shits all over the board and struts around as if it's won
if you had Ipv8 with a 48bit address, with NAT and dual stack at each organisation boundary, there are very few orgs that use more than an IPv4 /8 internally, and they can switch to v8 internally.
Address exhaustion was not the issue v6 was supposed to solve, it was the lack of AS numbers, v4 hardware and base BGP only supports 16-bit AS numbers which we ran out of in about 2015, wheras to support 32-bit AS numbers you need bigger buffers and registers, that then IPv6 was invented for.
the v6 address space is excessive, it has 7 addresses for every atom in every human on the planet
NATdoes provide security in so far as the machines behind it are not directly addressable from outside, and configured correctly, people only have access to specific services on specific devices
If your attempt to fit the internet into 48 bits requires reaching for NAT, then 48 bits is too small. And in any case switching to this 48-bit address internally would involve the same amount of work that switching to v6 internally does.
Address exhaustion is exactly what v6 was designed to solve. "Expanded Addressing Capabilities" from 32 to 128 bits is the very first thing listed in the introduction of RFC 1883. AS numbers are an entirely unrelated issue. In fact your whole second paragraph is so silly that it reads as a deliberate troll.
Excessive is good! We want the address space to be too big, because the alternative is for it to be too small. The costs of the L3 address space being too small far, far outweigh the cost of the extra 32 or so bits in v6 (bits which, I note, are also used to increase security in a few places).
NAT does not itself make your internal machines unaddressable, and even a correct configuration will not prevent access to internal machines. Firewalls prevent access to machines, not NAT. In fact, if you have inbound port forwards configured then it lowers security compared to not having it by reducing the search space for servers -- instead of searching the entire subnet, you only have to search for open ports on the router of the subnet, which makes port scanning substantially easier. In the case of v6 it reduces a port scan of an entire network from requiring exabytes of traffic down to just a few megabytes.
>NAT: it ain't a kludge, it's a vital security tool.
NO! NAT is an abomination. The very concept of NAT breaks so many protocols in unnecessary ways.
Duplicate addressing is a stupid thing to implement. Ignoring internet access, merging two medium-sized companies' private address space is a massively expensive project which can take years to complete.
For the classic usage of NAT, the logic of not having inbound sessions is just as easy to implement with IPv6 as it is with IPv4 NAT. You have a session state table and you block everything not initiated from one particular interface / IP range. Changing the IP address and port numbers are just an additional steps.
There is no belief that every endpoint _should_ be visible but there is a belief that making any endpoint visible when required should not be difficult.
I have a "fixed" wireless broadband connection on 5g with 70mb/s+ throughput. Before I had this "internet connection" I used to run a mail server for my company's domain. This is no longer possible because of CGNAT. I can't have an inbound mail connection and without an inbound connection for domain verification I can't get TLS certificates. There are no cables to my location and not a single ISP provides non-NAT'd wireless links because of the horribly mistaken belief that no endpoint needs to be publicly visible on the internet. The amount of spam coming through my new hosted provider is many times what I had before.
There are some "huh?" things in IPv6 which make packet tracing difficult. That was a mistake. However, the NDP multicast thing is basically what evpns pretty much have to retrofit to ipv4. It allows larger, flatter networks. I suspect with automation and SDN we'll end up pushing security policy to the endpoints in corporate networks and use ip networks to locate hosts geographically rather than as logical subdivisions.
The main issue is the additional cost of maintaining ipv6 and ipv4 requires vision. I think I'd be looking at moving things to IPv6 only where possible and keeping ipv4 at the edge. It may need a bit of effort to link up things which can't use ipv6, but its probably better to do that than trying to maintain two schemas throughout.
"merging two medium-sized companies' private address space is a massively expensive project which can take years to complete"
try migrating a an existing network to IPv6 then, even more problematic.
"It allows larger, flatter networks."
How are large flat networks advantageous? We've spent decades moving away from flat and into hierarchical for many many reasons and you want to go back to flat networks and the massive security fail they are. imagine a company with a giant flat network and 1 machine gets compromised? through some vlans in and some acl's and youve made the infiltrators tasks much harder.
>I have a "fixed" wireless broadband connection on 5g with 70mb/s+ throughput. Before I had this "internet connection" I used to run a mail server for my company's domain. This is no longer possible because of CGNAT.
This is business usage, you can buy 5G SIMs with fix public IP addresses - although I admit they aren't cheap.
Alternatively there are solutions that work very well over mobile networks that use CGNAT, such as A&A's L2TP-VPN offering. [Note: Satisifed customer of A&A's L2TP-VPN service].
But before you pan mobile networks usage of IPv4 CGNAT, I suggest you take a good look at their IPv6 service, it isn't wonderful...
>NAT: it ain't a kludge, it's a vital security tool.
>> NO! NAT is an abomination. The very concept of NAT breaks so many protocols in unnecessary ways.
I'm one of the people who PIONEERED the use of NAT in enduser networks and this assessment of NAT is 100% correct.
We knew and discussed its shortcomings then. It was a kludge rolled out with intention to solve a very limited range of problems and it's been beaten into an eldrich horror over time.
We even tested multiple levels of NAT ans realised it was an utter clucsterfuck. Whoever came up with CGNAT needs to be flayed - alive and slowly.
"IPV4 with two more octets would have met the need for more space admirably"
Which completely misses the point that IP addressing is part of a routing/addressing protocol, NOT a series of pigeonholes
2 octets would require exactly as much pain and suffering in redeployment as 48 or 64 or 96, so do it once and do it RIGHT
Virtually all the arguments about not deploying IPv6 boil down to "Ohhhh noes, It's too haaaaaaaard, I don't want to understand itttttttt, You're being meaaaannnn to meeee!!! WAAAAAH"
And the irony is that virtually every single whinger came along to the Internet long _AFTER_ IPv6 was developed
"except broadcast is removed in favor of multicast"
With very good reason. Broadcast packets caused _EVERYTHING_ on the lan to have to stop and listen
That's why NetBEUI only works ok when there are only 10 or fewer machines on the network. Back in the day you could SEE when someone else was doing file transfers as your desktop would slow to a crawl as the computer processed and dumped the wire broadcast packets
That would... not be simple. Or rather, it displays a complete misunderstanding of how v4 addresses work. Addresses in v4 aren't 4 bytes, they're 4 octets (32 bits). Bytes don't have to be 8 bits long, but v4 addresses are a fixed 32 bits regardless of the byte length of your computer's architecture. (It has to be this way because IP is used to talk between computer systems that use different byte lengths.)
You could design a protocol that used 40 bit addresses if you wanted, but it would end up looking very much like v6. In particular it'd have all of the same problems deploying as v6 would, because its 40 bit addresses are longer than v4's 32-bit addresses and that's where all the problems come from in the first place. You'd still have to patch all OSs and software to handle the new address length, upgrade legacy devices, update DHCP, DNS etc etc etc.
On top of that, 40 bits is woefully insufficient even for today's internet, let alone the future internet. After you finished deploying your 40-bit address family, you'd have to turn around and do it all again to increase the address size further. It'd be a complete waste of effort since you'd be back to doing v6 anyway.
So... no, that wouldn't even be a solution, let alone a simple one.
Now this is all IMHO:
IMHO IPv6's problem isn't necessarily that the address is longer, is that they also went hex with the digits.
An IPv6 address that could have used a different format, say:
would, again IMHO, certainly have been more embraced than:
and this, to add insult to [human memory of procedures and parsing] injury, can even be shortened to
Now, let us not add in UNC paths, just to create an even bigger disaster, to create an example such as
IT IS (almost) A HUMAN UNREADABLE MESS.
They did NOT have to do this. They could have stuck with the 'octet' human-parsable form but switch the digits to hexadecimal, or simply added on to the number of octets in current decimal form.
But they didn't do that. They (seemed) to say "To hell with humans remembering IP addresses, everything will be DHCP anyway!" and changed both simultaneously. And then expect both commercial AND home users to adopt this far, far, far more complex to read and remember (and, therefore, far, far more complex to administrate) addressing scheme - even if, in many usage instances, such a large address [space] is complete and utter overkill. Mr. and Mrs. Average Public doesn't need, and didn't want, a 128-bit address to remember their home WiFi router, home computer, maybe a tablet and smart TV, by.
The idiot engineers at IEFT saw a problem and, instead of being pragmatic and/or practical and consider a variety of usages, plus human ability to accommodate this, they beat the problem with a 10kg mallet, minced it with a woodchipper, hit it with a flamethrower, buried it 20 feet under, encased it in rebar, covered it with concrete...and then poured a new A-road over the spot just in case you may ever, ever, think about going back and viewing that spot again.
Mr. and Mrs. Average Public aren't expected to deal with IPs. They're expected to use hostnames, which by the way also use the letters in the range g to z as well as numbers and yet we don't complain about how hard those are to use.
Mr. and Mrs. Average Public don't need or want a 128-bit address on their machines. They just want their machines to work; the 128-bit addresses are just part of the technical details for how we engineers make that happen, rather than something that the end-user cares about. All of this is by design.
The format you suggest can't accommodate v6's address space, so it wouldn't even be an option. At least the "idiot engineers at IEFT" understood the limits of what it and isn't possible.
"Mr. and Mrs. Average Public aren't expected to deal with IPs. They're expected to use hostnames"
Say WHAT?? Kindly tell me what series of home IP WiFi routers deals exclusively with hostnames rather than describe all connected devices, both in DHCP assignments and log entries, by IPv4 addresses. And what home WiFi router doesn't have IPv4 settings for WAN setup, LAN setup, the aforementioned DHCP server, DDNS, and other features.
At the very minimum Mr/Mrs Average Public needs to monitor their computer system to make sure that they have a valid IP address after connecting up to their new WiFi router. At the worst, Mr/Mrs Average Public will need to dig into those router configuration pages, almost every one speaking IP addresses, to find out & fix what is going wrong with their system. Log on to a web help forum and you'll get assistance on reading those configuration pages, what the DHCP, WAN, etc, is doing (and noting those IP's), and getting it back up and running.
So now Mr/Mrs AP needs to remember, or at least be able to recognize, that 2001:0db8:85a3:0000:0000:8a2e:0370:7334 is their local computer's IP if/when they hit those configuration pages. And make sure that other local network devices are correctly talking to one another by checking and/or confirming their associated 128-bit hexadecimal (not recognizable to non-techies) IP. For *us* 0db8:85a3 makes sense; to Mr/Mrs AP, what in the world does that mean?? They only know 0 to 9.
Watch the phone calls for help from your family and friends absolutely skyrocket when they have to deal with IPv6 address and the router configurations thereto. Internet forums will light up in a nightmare of "WTF does this mean!", ISP help lines will see greatly increased requests, etc. For the average person IPv6 is just overly complicated - but, again, engineers, when not babysat by 'normal' people, don't have a problem with that. They just see a solution, even if overly complex, and everyone else will suck it up and accept the new Status Quo of Modernity.
Are you seriously arguing that most members of the public don't know the alphabet? I'm reasonably sure literacy rates are higher than that, and in any case someone who doesn't know the alphabet isn't going to be reading through their router admin pages.
Most people don't monitor for valid IPs when setting a new router up. They plug it in, turn it on, connect their devices and just use it. Most people are so unfamiliar with networking that v4 confuses them too. It's not going to be any worse with v6, and in fact the general lack of NAT will make it easier to understand and configure than v4 where NAT is a de-facto requirement.
>and in fact the general lack of NAT will make it easier to understand and configure than v4 where NAT is a de-facto requirement.
@Nanashi - I suggest you need to get out and interact more with normal members of the public.
A typical domestic/consumer IPv4 router is a simple plug-and-play device that not only works out of the box but also through the NAT/firewall provides some level of security for poorly configured/secured devices on the home network. ie. in the default out-of-the-box state none of the devices behind the router are visible to services such Shodan. IPv6 has to achieve the same level of out-of-the-box usefulness and security before it can go anywhere near the typical home.
Thanks for the suggestion... although I'm not entirely sure what I'd discover that could change anything I've said.
v6 is already in many typical homes. It got there by having the same level of out-of-the-box usefulness and security as v4 does.
NAT and firewalls are two separate things. NAT doesn't provide any level of security for poorly configured/secured devices on the home network, but the firewall does and that's how home routers secure the network behind them, on both v4 and v6. We're already at the point you're saying we need to be at.
"the NAT/firewall provides some level of security for poorly configured/secured devices on the home network"
Again: NAT pioneer here - NAT PROVIDES NO SECURITY and we saw shitloads of NAT customers get compromised via various means before firewalls and router security became the norm.
Do NOT conflate firewalling and NAT. The fact that you think over-the-counter consumer IPv6 routers don't provide firewalling and network security shows how seriously out of touch with the real world you actually are.
Virtually all of them mirror network security settings at IPv4 and IPv6 as well as completely preventing external IPv6 from touching internal IPv6 systems unless holes are specifically opened
Go back to playing with your unicorns and let the competent people deal with network issues because anyone taking your advice is going to be royally PWNED
" IPv6's problem isn't necessarily that the address is longer, is that they also went hex with the digits."
for the very simple reason that addresses like 126.96.36.199.188.8.131.52.184.108.40.206.220.127.116.11 are stupidly long and can be shortened by compressing strings of zeros
And yes, THAT'S what current 32-bit dotted quad format would look like if "merely" extended to 128 bits. It's unwiely as all hell to type
2001:0db8:85a3::8a2e:0370:7334 is easiyish for humans to remember (admins, the ones who have to remember this shit on a day to day basis - pattern reocgnition kicks in)
2001:0db8:85a3:0000:0000:8a2e:0370:7334 is hard enough.
18.104.22.168.22.214.171.124.0.0.138.46.03.112.115.52 is going to give most people nightmares and you are NOT going to get granny or anyone else to type either of those in on a support call anyway.
But they didn't need the 128-bit address space; they wanted to grant the 128-bit address space. That's the difference.
Now I've never studied the network stacks in depth, so most likely I have NO idea what I'm talking about from this point on. So excuse me for being optimistic if I'm way off base:
IMHO if they would have stuck with decimal rather than change to hexidecimal, they probably could have made the system backwards compatible in a way by allowing a prefix / suffix of double colons, that is the IPv6 equivalent of ' :: :: '.
So only use the most or least-significant 32-bit digits and default with a mask for the balance of the address. The mask could have been programmable and changeable in consumer routers: set the 'Ignore digits" mask once, it 'tacks' it on to your common, old-fashioned in-house-only IPv4 addresses, and creates an psuedo IPv6-compabile address for your private network. This way you could finally kill off IPv4 stacks but still have non-techie-friendly IPv4-style private in-house addresses, if in "looks only" anyway. Mr/Mrs Average Public would only have to deal with the old-fashioned 32-bit within their configuration screens, as all devices on their LAN would use the mask, which would essentially be transparent to them.
But again, IEFT didn't do that did they? They decided it was All or Nothing, Or Way or Nothing at All. It was a bunch of shit-for-brains engineers who overdeveloped a solution, under the guise of both Overkill (We won't have to do this again if we overbuild it to the maximum NOW!) and Elitism (We understand it; everyone else will toe the line we designate even if they don't). And now the entire world is dragging its feet on implementing IPv6 - why?? Because fundamentally the delay and footdragging proves that nobody really likes it.
You are way off base. IP addresses are a sequence of bits. Decimal vs hexdecimal is purely for the textual representation, and has no bearing whatsoever on the packet format. So no, you couldn't have made the system backwards compatible by writing the addresses differently. The suggestion is entirely nonsensical.
In fairness, you did mention that you might not know what you're talking about. But for some reason that didn't stop you from calling the IETF a "bunch of shit-for-brains engineers". Here we have the Dunning-Kruger effect at its finest.
IPv6 is backwards compatible, by the way. Unfortunately v4 isn't forwards-compatible with larger address spaces which limits what you can do, but v6 supports all of the forms of backwards compatibility that are actually compatible with the design of v4.
Wait, are you telling me that it would be impossible to apply a bitmask of a 128-bit datagram to get 32 bits? That's...ridiculous.
"IPv4 and IPv6 addresses are not compatible. [NRO chairmain Axel] Pawlik said it was technically feasible to make the two types of IP address talk to each other, but it would be best for companies and ISPs to switch to IPv6 as soon as possible, to keep networks stable and avoid complexity when IPv4 addresses run out.”
I know what you are saying: due to IPv6's datagram structural differences, it wouldn't work. But many of these changes were a choice, as shown by the quote. Theoretically they could have retained the IPv4 address compatibility but they seemed to have consciously chosen not to.
And that's my point.
And my point is that that's not the case. Like I said, v6 is already backwards compatible. For example, with NAT64 you can talk to a.b.c.d by sending v6 packets to 64:ff9b::a.b.c.d. You can also map the v4 space into any arbitrary /96, so you could for example map your RFC1918 space into 2001:db8:4242::192.168.1.x to allow inbound connections over v6 to your v4-only LAN devices.
None of this saves you from deploying v6 on your network though.
Some of the header changes were a choice (a choice which, I note, was done to reduce the overall header length and complexity), but it's impossible to avoid changes to the header format because the v4 header only allocates 32 bits to src and dest addresses. Changing the header is a requirement, not a choice. The header format can be translated anyway, so the additional changes don't introduce any more problems than we already had.
> IPv6 is backwards compatible
I didn't want to get in this discussion but IPv6 is not backwards compatible and it is not "just a few more bits" as you keep parroting on this thread.
It is a different design, with different architecture, different capabilities and with an entirely different wire format.
Please give due thought to the option of staying silent and looking like a fool.
It's roughly the same design and architecture as v4, it just has longer addresses. There are some differences in the details but the overall design and architecture is unchanged. If you understand v4 then most of your knowledge of how it works can be transferred directly to v6.
v6 has many, many backwards compatibility methods. You can run both v4 and v6 side by side on the same networks. You've got NAT64, DS-lite, 6to4, Teredo and a number of other ways to provide v6 connectivity over v4 and connectivity to v4 hosts from v6. How can you say it's not backwards compatible when you have a whole host of backwards compatibility methods to use?
I'm considering the option of staying silent, but how is that going to help when people are spreading so much ignorant misinformation? I'd like to correct their misunderstandings, and I'd definitely like to stop the misinformation from spreading, and I don't see how I can do that by staying silent.
"...Now I've never studied the network stacks in depth, so most likely I have NO idea what I'm talking about from this point on...."
Then DON'T!!! This site is full of comments from people who have no idea what they are talking about... and their comments are generally sh*t.
> for the very simple reason that addresses like 126.96.36.199.188.8.131.52.184.108.40.206.220.127.116.11 are stupidly long
No, no, no!!!
Morse-coded binary, mate:
----- .---- .---- .---- .---- ----- .---- .---- ----- .---- .---- .---- .---- ----- .---- .---- .---- .---- .---- ----- .---- ----- .---- ----- .---- .---- .---- ----- .---- ----- .---- ----- ----- .---- .---- .---- .---- ----- .---- .---- ----- .---- .---- .---- .---- ----- .---- .---- .---- .---- .---- ----- .---- ----- .---- ----- .---- .---- .---- ----- .---- ----- .---- ----- ----- .---- .---- .---- .---- ----- .---- .---- ----- .---- .---- .---- .---- ----- .---- .---- .---- .---- .---- ----- .---- ----- .---- ----- .---- .---- .---- ----- .---- ----- .---- ----- ----- .---- .---- .---- .---- ----- .---- .---- ----- .---- .---- .---- .---- ----- .---- .---- .---- .---- .---- ----- .---- ----- .---- ----- .---- .---- .---- ----- .---- ----- .---- -----
Separate the men from the boys and all,
The hex is just there to shrink the length of the addresses - there are plenty of times we see v4 addresses in hex.
I think the real problem is that they broke the rule that incremental change is easier to achieve, even if it is less efficient.
They could have added some sort of multicast router solicitation / NDP / SLAAC to "ipv4.2"
Maybe they should have made host/ip mapping collection and forwarding mandatory for all routers, so DNS is always there, even for poxy little home networks.
Get people used to the concepts and benefits before hitting them with an incompatible address space and the logic problem of picking which network you're going to favour.
IT IS (almost) A HUMAN UNREADABLE MESS.
really? as humanly unreadable as 18.104.22.168.22.214.171.124.0.0.138.46.126.96.36.199 ?
which is what it would be using the classic notation you started with - and skipped over just how unreadable it really is
(Hint, that looks disgustingly like X.400 (or SNMP MIBS) which everyone HATED due to its cumbersome nature)
Humans are really bad at handling more than about 6-8 digits at once. This is WHY the CCITT standards attempt to limit phone numbers to 11 digits AND break them into groups
We don't stack up every phone number in any country in sequential access and UNLIKE phone numbers, it's bloody hard to add extra digits later (it's bloody hard in side the phone number routing systems to add extra digits too, which is why country/area/district/local codes have fixed lengths despite what humans might see)
In the case above, if you were to compare this with telephone codes
2001:0db8 = +44
85a3:0:0 = 20
0:0 = 8
0370 = 128
7334 = 4567
I'm sure you'd rather have +44-20-8128-4567 and be able to tell at a glance that it's in outer london UK than to have to dial 606084237921354623 for your neighbour on one side and 8272904627629921 for the neighbour on the other side every time you pick up the phone
IPv6 IS CREATED FOR EFFICIENT PACKET ROUTING, not about stuffing as many IP addresses as possible into the available space.
Anyone who fails to realise that falls into the same trap that turned IPv4 from a packet routing system into a tangled address mess and is responsible for the clusterfuckage of allocations we now see where companies are paying stupid money to get IP addresses
And if you're in east/SE asia, there are countries like Vietnam with a single /22 allocated for THE ENTIRE COUNTRY - NAT works "okish" for a couple of machines behind a modem, but not for several MILLION people behind each IP
"Addresses in v4 aren't 4 bytes, they're 4 octets (32 bits). Bytes don't have to be 8 bits long"
In the very early days a byte wasn't always 8 bits but it is standardised that way now & as such an ipv4 address is 4 bytes.
IP's are 4 bytes to be efficient for processing by the 8 & 16 bit & 32 bit cpu architectures of the time. a 40 bit address scheme would have been great on cpu's that used 10 bit bytes instead of 8 bits etc etc, but stupidly wasteful on a system based on 8bits or multiples of.
They're not 4 bytes though, they're 4 octets. For computing architectures with 8-bit bytes, which is indeed common today, that's exactly equal to the length of 4 bytes, but that doesn't mean that the length of an IP address will change if you change the length of your bytes.
I was replying to a suggestion to change the size of a byte in order to get more addresses. Not only is this a non-trivial change to make, it wouldn't change the length of v4 addresses. (And even if it did, your bigger addresses would have the exact same compatibility problems with existing machines that v6 does...)
"Why _should_ this be different?"
Because a phone number is, by design, an open-ended sequence of digits (like a DNS name, though I think that, too, has a limit of 63 characters that hardly anyone runs into) whereas an IPv4 address is, by design, exactly four bytes.
It's different because the telephone network was designed around variable-length phone numbers from the start, whereas v4 was designed around a fixed address length.
As such, it's easy to make phone numbers longer but it's much harder to make IP addresses longer. Should it be this way? There's not much point discussing that now; it is this way. If you have complaints, take them to the people who designed v4.
Phone numbers are varying length because the phone numbering system is heirarchical -- phones were leaves on a tree that had branches distributed by geography. A phone exchange can deduce from the number sequence whether a requested leaf is on the same part of the tree that the requestor is on, eliminating the need to input a full number. (NAT uses the same philosophy.) With the rise in mobile users (and the collapse in toll charges) phones numbers no longer are a reliable indicator of the geographical location of the phone but that's more to do with phone numbers being a sort of fiction, the actual number of a mobile phone is a long hexadecimal number that's globally unique to the device.
As someone who's had to implement stacks I have an inherent dislike of network packets that are not regularly sized, it makes efficient implementation messy, if not impossible. The IPv6 header is a mess if its fully implemented with the extensions, its the sort of thing that looks nice in a bit of software designed to prove a concept but its a nightmare for anyone who needs to implement pedal to the metal speeds and cut through routing. Its been mentioned that some networks get around the issue by only partially implementing the protocol but what good is that? Years after its supposed to be finished, a done deal, its only selectively implemented.
Still, as they say, "It all makes work for the working person to do......"
"It wasn't a joke. Ipv6 requires a complete rewrite. Ipv4.1 would be a lesser rewrite."
Going from 32 to 128 bits is a complete rewrite. Going from 32 to 40 bits is ALSO a complete rewrite
There is no way to shoehorn longer addresses into IPv4 address space. Do it once, not every 30 years
" Ipv4.1 would be a lesser rewrite."
Until it isn't - and the rewrite is not the issue as you need to do that anyway.
IPv6 is "IPv4 expanded" at its core. The extra features are all optional despite the whingers claiming otherwise
The Elephant int he room is that it doesn't matter HOW large the address space is, moving off IPv4 requires dual stacking and transition periods.
Doing it only ONCE is preferable to having to look at having to repeat the process every 15 years or less
1: IPv4 was GOING to use 128bit addressing until Vint Cerf was browbeaten into using 32 bits as IPv4 was a kludge solution only intended to be used for 5 years in a population of a few hundred machines
2: IPv4 is actually a ROUTING protocol. The first 2 octets were intended to indicate site and department, in a red/black tree type manner (in a manner akin to "country, city, district, street address", A.B.C.D was "A=site, B=department, C=subdepartment, D=address)
Because it was sparse, when a "shortage" loomed in the late 1980s, extra address space was able to be shoehorned out of it by throwing out the routing intentions but it quickly turned into spaghetti-infused custard
3: IPv6 restores that routing protocol and means you can (mostly) get rid of most of the messy shit of OSPF/BGP/EIGRP, etc etc etc. In the core of the Internet this is hugely important as IPv4 routing granularity has had to be pruned down simply to stop routers shitting themselves - and that means that if you have a portable /24, you tend to find it's not portable at all due to the smallest prefix being accepted at most BGP4 tier1 interfaces being /18 - it also means you find your /24's traffic being routed over paths you weren't expecting, subjected to arbitrary interference by non-contracted parties
IPv6 still uses 16 bit ports at host level
Any arguments about NAT providing enduser security are proof that the poster is still of shit and has no idea what they're talking about. These fuckwits are the same kinds of twats who think multiple levels of NAT or CGNAT are a good idea
I'm one of the people who pioneered enduser dialup NAT back in the very early 1990s.
Security wasn't even a consideration when it was rolled out - all we were looking for was a way of being able to support multiple users on the end of a modem without having to play complex/expensive routing games on the dialup server (most of which would provide a single IP - ONLY - in any case)
In my case the main motivating factor (in a university town) was enabling student flats to put a bunch of people through one connection and not have 4 people tying up 4 different lines most of the evening.
The customers loved it because they could pool costs and not pay for 4-6 analogue phone lines into their flats, or avoid fighting over whose turn it was to use the modem line.
Yes, it was a kludge - with a very specific purpose. It's been used and abused out of all recognisable shape since then and if we'd had any idea at the time of the clusterfuckage we were unleashing we'd have burned the idea at midnight whilst summoning eldrich gods to deal with further deployments
" IPv4 still works because a lot of workarounds were implemented to make the original design work "
Starting with kludging the original design which used the first octet as a routing indicator (That's what "Class A" actually meant) and the second octet for departmental subrouting within the organisation and the 3rd octet for further routing leaving surprisingly FEW addresses for actual machines.
IPv6 takes the same policy and BOTH of them took that policy from telephone system routing, but in a fixed address mask (country/area/routing/indivual codes)
The original phone systems were analog and taking extra levels of decoders on wes relatively straighforward. It only took 30 years of concerted effort afterwards to agree on a target of 12-digit limits on phone numbers and another 30 years to actually ACHIEVE it (which was promptly undone by various entities)
If you look at IPv6 address you'll see it looks like red/black trees. So did IPv4 originally. So do telephone networks to some approximation. Sparseness in the high level address space is a GOOD thing. It's supposed to be that way for very good reasons.
One reason why IPv6 hasn't exactly taken the world by storm is its not a very good solution to the problem of extending the address range of the Internet.
I'm sure there is a term for this kind of argument. It's like waiting for a bus but having a reason for igoring every one that comes along. Sometimes perfection isn't possible. IPv6 isn't perfect but it's the best solution we have and some of the problems associated with IPv4 are only going to get worse the longer it takes to transition.
The main reason that adoption has been so slow is that in countries, particularly the US, that dominate much of the practical aspects of the internet, a lot of these problems don't exist. The US has so many IPv4 addresses that it really doesn't understand what the fuss is about. Add to this that IPv4 is "good enough" so neither network operators or users have an incentive to change. Ideally, of course, users should never notice the change.
Governments could improve matters by requiring devices be able to support IPv6 in order to gain certification or connect to an interchange and I think we'll see more of this.
"I'm sure there is a term for this kind of argument. It's like waiting for a bus but having a reason for igoring every one that comes along. "
"Passing up lifeboat seats on the Titanic" comes to mind.
IPv4 is so badly beaten well past its design intentions that the surprise at the moment is that it works at all. It was on the verge of unusability when I first got on the 'net 30 years ago and has been saved by some very cleaver people rearranging deckchairs behind the scenes across the entire internet a number of times but eventually there just AREN'T anymore pigeonholes left to stuff the bit into - and those folk have been telling us that would happen every time they made those emergency changes. Now we're a bit past that point, with shared pigeonholes (party lines) happening and many people around the world are having to put up with the fustercluck of CGNAT
When we came up with NAT as a solution in the mid 1990s it was a messy kludge to get a couple or three computers behind a dialup connected simultaneously, not (tens of) thousands of the bloody things - and I'm not exaggerating the scale of this. There are entire asian countries of 30+ million people operating on less than a /16
There are entire asian countries of 30+ million people operating on less than a /16
Good job that they don't get to vote on technical standards, isn't it!
In places where IPv4 works without too many problems (North America, Europe), it's obvious that moving to IPv6 is going to involve buying and configuring new kit and creating a 4to6 and 6to4 gateways. But it's okay to expect developing countries to do all that. Or better still sell them our old kit and some CGNAT stuff! Or they can go straight to IPv6 and give us their surplus IPv4 ranges!
At some point, of course, as has happened with mobile technology, some of these countries will become pioneers in IPv6 and will have a headstart… So, we'll obviously have to ban imports of networking kit from them!
>When we came up with NAT as a solution in the mid 1990s it was a messy kludge to get a couple or three computers behind a dialup connected simultaneously, not (tens of) thousands of the bloody things..
NAT, rather elegantly, utilised the port address space: 2 octets and thus from the outset had the potential to support up to 32,000(*) end points per protocol, behind a single public address...
Yes, it might not have been envisaged to be used in the way carriers use it and was memory-constrained as to how big the translation table could grow to - but it certainly had the potential.
(*) Less the essential pre-assigned ports. TCP/UDP pre-assigned port allocations is another area of addressing that needs tiding up.
"little pockets of IPv4"
"about a third of the traffic that reaches google is over IPv6"
So, erm gosh, that's tough: 1 - 1/3 = 2/3. Phew! No wonder the poor guy didn't realize what big pockets some people have.
Truly, the price of IPv4 addresses is so astronomical because so is the demand. It will not disappear until a protocol compatible with both v4 and v6 supercedes them both. We could call it The One Ring.*
* Remember the Cambridge Ring, anybody?
"It will not disappear until a protocol compatible with both v4 and v6 supercedes them both. "
Sorry, ain't gonna happen because IPv4 has no provision for forward compatibility. Simple logic tells you that a dual stack solution, or IPv4-IPv6 translation, are the only possible options. We have both.
I see v6 advocates criticizing v4 for not being forwards compatible.
I see v4 advocates criticising v6 for not being backwards compatible.
The only way to resolve this ping-pong idiocy is to have an overarching protocol within which both sit as subsets. Dual-stack then becomes just one option open to the software implementation.
We're not criticizing v4 for not being forwards compatible. It's just a fact of life that it isn't. (Meanwhile, v6 has various methods of backwards compatibility so people complaining that it doesn't are wrong.)
You're not going to fix this by introducing a new protocol to which v4 is also not forwards compatible. The way to fix it is education, but there seems to be an endless supply of people who don't know what they're talking about but are happy to talk as if they did.
"Simple logic tells you that a dual stack solution, or IPv4-IPv6 translation, are the only possible options. We have both."
Not only do we HAVE both, we've DONE THIS BEFORE.
IPX, Netbeui, Vines, Decnet, etc etc
At some point it actually takes _governments_ to legislate that any company selling "network services" that wants to call it "Internet" must provide IPv6 - the day the UK does that, TalkTalk is the country's largest walled garden, because after 12 years of telling customers "we're working on it" they finally admitted in early 2019 that they have no plans whatsoever for consumer IPv6 and will use IPv4 for the forseeable future
I'm clairvoyant, and can see exactly the discussion that took place.
Engineer: hey boss, here's the list of things required to do IPv6
Boss: Hang on a moment, you want to replace EVERY SINGLE BIT of our hardware, and then send practically every single member of our staff who has anything to do with networking off on long and complex training courses?
Engineer: That's what would be required to roll out IPv6.
Boss: Do you have any idea how much that's going to cost for zero actual benefit to us?
Engineer: Quite a lot.
Boss: Quite a lot hardly begins to cover it. Do you think this is a good idea yourself?
Engineer: Personally i'm happier with IPv4 because I understand it. I'm told that i'll become a rabid fanatic after going on the training course though, and we really all ought to go on new security courses as well as everything becomes directly addressable on the internet with IPv6 which has major security concerns.
Boss: **** this, we're sticking with IPv4.
Engineer: Fine with me.
Actually, i'm not clairvoyant. I just know that's exactly the sort of discussion that's happened hundreds of thousands of times across the country because -nobody- wants IPv6 for any reason beyond address exhaustion so it's not getting rolled out.
Did anybody in your imagined conversation consider the cost of not rolling out v6? The cost of NAT, of dealing with RFC1918 clashes, of doing split DNS and VPNs and remapping, of the problems caused by CGNAT, of not being able to do things due to address exhaustion, of spending engineer time fixing problems in workarounds that just don't need to exist?
Probably not, since people ignore it constantly in the real world too, but that doesn't mean the cost isn't there.
>The cost of NAT, of dealing with RFC1918 clashes, of doing split DNS and VPNs and remapping, of the problems caused by CGNAT, of not being able to do things due to address exhaustion
From memory, I'm not aware of having spend time on any of these in the last 30 years that could be wholly attributable to the continued usage of IPv4.
As for CGNAT, from what I've played around with in the UK, the mobile carriers are doing a good job of making IPv6 unusable for business on their normal 4G service: want public static IPv4/IPv6 address then pay extra.
Do you mean a regular home CPE? That would be difficult, as very few of them don't support NAT.
This really should be obvious, but... the fact that NAT support is common in home CPEs does not mean that NAT is free to implement, or that the implementations never have bugs, or that it doesn't introduce additional complexity into networks or software, or that it can't cause problems. To be clear: it costs money to implement, the implementations have bugs, it makes networks more complicated, it adds complexity to software and it causes lots of problems. All of these issues are part of the cost, which you pay for either with money or with time, effort and frustration.
At the ISP side, NAT is done on routers that cost in the £10k-100k range. NAT may be an additional license cost, and it also imposes a performance hit that means you need to buy more of the expensive routers than you do without it. Since internet traffic is increasing over time, the additional costs of NATing that traffic also increase over time. Dual-stack ISPs see over half of their traffic flow over v6, which immediately reduces the cost of the routing hardware needed to NAT the remaining v4 traffic.
Depending on the ISP network, CGNATed traffic may need to be routed out of its way in order to reach one of their CGNAT routers whereas v6 traffic can be handed off early, which increases the latency of v4 traffic. This too is a cost you pay.
So, yes. The cost of NAT.
As for why v4 addresses are in demand, it's a combination of the cost of the workarounds required when you don't have enough address space (including but not limited to the stuff I just wrote three paragraphs about), and the fact that there are a large number of v4-only clients out there that you still want to provide service to. To be clear again: these are reasons to be doing v6, since the address shortage in v4 isn't going away.
>Could you point me to an ISP that gives you a discount for only having an IPv6 address versus only having an IPv4 address?
A ISP provided IPv6 address is no guarantee of not having to deploy NAT. You only need the ISP to give you a /128 address and you will be wanting NAT66...
I think this is one aspect of the IPv4 v IPv6 debate that is being missed: whilst in theory v6 shouldn't need NAT etc. much depends on how the ISPs/mobile operators decide to deploy v6 and use and abuse it to charge for the various services delivered over it.
In practice most of them seem to be doing v6 properly, and even the ones that aren't doing it properly are at least providing one /64 so you can get a single network running. The abuse and charges that you're worried about haven't really materialized.
(Perhaps there might be a "yet" lurking there, since the companies doing v6 first are probably the companies that are more willing to do it right. But so far, remarkably, ISPs seem to have resisted the temptation. Even Comcast are delegating a /60, and they're routinely rated the worst company in America.)
>In practice most of them seem to be doing v6 properly...
If you are using say OpenWRT and want to use mwan3 to implement a WAN failover policy you may find NAT66 is a natural part of the solution ie. it makes things a lot easier to set up and get working because the IPv6 solution is logically similar to the IPv4 solution that you will most probably be running in parallel.
"From memory, I'm not aware of having spend time on any of these in the last 30 years that could be wholly attributable to the continued usage of IPv4."
I've had to deal with it at least a dozen times. Particularly in the early days when people would pull IP numbers out of their arses for networks that "would never connect to the internet", and then a few years later discovered they needed to do exactly that.
Explaining to dickhead "CTOs" that "no, you haven't been hacked by Rutgers university, their names are showing up in your logs because YOU ARE USING IP NUMBERS INTERNALLY WHICH BELONG TO THEM" an then getting a response "How do we keep all these rutgers hackers out of our network" is enough to make you tear your hair out
- especially when the response "Get IP numbers of your own allocated, use those and stop trying to steal other people's allocations" would be met with "OH NOES, WE CAN'T DO THAAAAT, IT'S TOOO HAAARD TO RENUMBERRRRRR OUR INTERNAL NETWORRRRRK. WE WANT YOU TO FIX THIS!"
I can see at least 2 people in this thread I've had exactly this discussion with in the 1990s now claiming that IPv6 is too hard because "renumberring is too hard, Waaaaah!"
"It means that one third of the people hitting Google do so from TCP (...or UDP...) connections that have a v6 source address."
It would probably be more if it wasn't for the number of mobile providers who shoehorn LTE (which is IPv6) through CGNAT gateways to connect to the world using IPv4 instead of letting them run IPv6 natively
https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption - shows that in the 4 months since this article was published, IPv6 access proportion has increased from 31 to 33%
The bigger problem at the moment is ISPs who won't provide IPv6 automatically to users (even "by request" is an impediment), or refuse to provide IPv6 at all.
While I can't see any benefit whatsoever for most users in transitioning to IPv6, I'm told that IPv6 has much better routing algorithms. So if my ISP wants to somehow bridge my IPv4 traffic to IPV6 in the outside world for their own convenience, I guess that's sort of OK. But how do they keep from breaking ICMP(and thus Path MTU Discovery), traceroute, et. al.? I don't know. I don't care. As long as they don't make it my problem.
"It was, at least from RFC1933 (April 1996). I used exactly that method until my ISP supported native IPv6."
Thanks, I read through most of the RFC before thinking to check the status which turns out to be obsoleted by RFC2893 which was in turn replaced by RFC4213. Overall, the RFCs seem quite sensible. Two things I'd comment on.
"The mechanisms in this document are designed to be employed by IPv6 hosts and routers that need to interoperate with IPv4 hosts and utilize IPv4 routing infrastructures. We expect that most nodes in the Internet will need such compatibility for a long time to come, and perhaps even indefinitely" (RFC1933,RFC4213 both p2)"
I read that as saying it's perfectly OK for us Neanderthalen who for any of a variety of reasons don't or can't do IPv6 to stick with IPv4 forever if we so choose.
"Specified minimal rules for IPv4 reassembly and IPv6 MRU to enhance interoperability and to minimize blacholes." (RFC4213 p23)
I'd be a lot happier if that said "eliminate" rather than "minimize". I have long suspected that blackhole routing is at the root of many of the mysterious problems that affect digital communications. It's not easy to diagnose, and very few people even know it exists.
"But how do they keep from breaking ICMP(and thus Path MTU Discovery), traceroute, et. al.? I don't know."
They don't break, because if your IPv4 flows through an IPv6 tunnel, your ICMPv4 flows through the same tunnel. The IPv6 tunnel will show up as a single IPv4 hop in your traceroute and you won't even know.
Fragmentation isn't affected because the IPv6 minimum MTU is higher than for IPv4. (Duh, people *thought* about these problems.)
Pinging theregister.com [188.8.131.52] with 32 bytes of data:
Pinging google.com [2a00:1450:4009:814::200e] with 32 bytes of data:
Pinging forums.thinkbroadband.com.cdn.cloudflare.net [2606:4700:10::6814:349] with 32 bytes of data:
Spot the odd one out.
Pity the poor Register, missing out. On Google and Thinkbroadband, the 1s are so much sharper, the zeroes are richer and fuller, and their webpages just feel more bright and modern.
Or alternatively all of the above is bullshite, and there is no discernible difference at all to the web-browsing end-user. Hence the stagnation of IPv6.
They seem to be tweeking it, earlier this week:
www.theregister.com has address 184.108.40.206
www.theregister.com has address 220.127.116.11
www.theregister.com has IPv6 address 2606:4700::6812:416
www.theregister.com has IPv6 address 2606:4700::6812:516
forums.theregister.com has address 18.104.22.168
forums.theregister.com has address 22.214.171.124
forums.theregister.com has IPv6 address 2606:4700::6812:516
forums.theregister.com has IPv6 address 2606:4700::6812:416
theregister.com has address 126.96.36.199
theregister.com has address 188.8.131.52
theregister.com mail is handled by 1 aspmx.l.google.com.
theregister.com mail is handled by 5 alt1.aspmx.l.google.com.
theregister.com mail is handled by 5 alt2.aspmx.l.google.com.
theregister.com mail is handled by 10 aspmx2.googlemail.com.
theregister.com mail is handled by 10 aspmx3.googlemail.com.
theregister.com mail is handled by 10 aspmx4.googlemail.com.
theregister.com mail is handled by 10 aspmx5.googlemail.com.
forums.theregister.com has address 184.108.40.206
forums.theregister.com has address 220.127.116.11
So they've overwritten their IPv6 records with some MX records :)
wrt porn sites
Offering "premium porn services" on IPv6 only would likely result in people bugging their ISPs heavily even though they won't ADMIT why they want it
(When I was a callow youth working in a video rental store, nobody ever admitted hiring the porno movies and the people hiring most of them are not the ones you'd expect. Quite why apparently normal middle age women seem to get off on hardcore gay male porn is something that puzzles me to this day when the "lesbian porn" everyone made the most noise about was hardly hired by anyone)
It feels like every time there is a tectonic shift in how people use tech, IPv6 misses the boat. I think it's doomed to live in perpetual limbo.
- It missed the explosion in cloud. Even today, AWS and Azure etc have good support for IPv6, but not great. Your first contact is probably something like an EC2 instance, and IPv4 just works, out of the gate. For most people, that's it, game over, never look at IPv6 again. Imagine what might have happened if AWS had said, "any new service is going to have an IPv6 endpoint, and you must pay extra if you want IPv4"
- It missed the explosion in home devices. Netgear, Belkin etc were never going to make the DHCP on their home routers dole out IPv6 by default when all the home TVs and lightbulbs dont support it. At best you end up with dual-stack, and then you have a support nightmare on your hands (given that we are talking about consumers). Ugh.
I do think it will live on for some (large) niches, like mobile internet, where operators have been doing Ipv6 for years, but as a world-changing tech, I dont see it.
- It missed the explosion in home devices. Netgear, Belkin etc were never going to make the DHCP on their home routers dole out IPv6 by default when all the home TVs and lightbulbs dont support it. At best you end up with dual-stack, and then you have a support nightmare on your hands (given that we are talking about consumers). Ugh.
Not wishing to pick a fight but my ISP (IDNet) has been providing dual-stack IPv6 for over a decade and I've been a customer for nearly that long. I run a mail server from my spare bedroom and it communicates happily using both protocols. If a device only supports IPv4 it works on my LAN just fine. If it supports IPv6 it works just fine.
What problems have you experienced, and why?
Oh and why would a router need to dole out IPv6 addresses using DHCP? All my routers had that disabled by default and everything uses SLAAC.
Not wanting to pick a fight either. But I reckon that I -- and probably others -- had always assumed that IPV6 devices come with a built in unique address and that the unique address would be propagated (hopefully fully transparently) to everything in my network which would then just work. I might (probably would) have to conjure up some new firewall rules and maybe replace an old box or two. But aside from configuration being a PITA and needing a bit of budget, nothing much would change.
So when I saw your post, I said to myself SLAAC. Self, that must be how they make it all play together. So I Googled SLAAC and found a lot of stuff like this. https://www.hpc.mil/program-areas/networking-overview/2013-10-03-17-24-38/ipv6-knowledge-base-infrastructure/dhcp-on-ipv6-networks
My initial take. I'm nowhere near smart enough to make that work on anything but a trivial network. And neither are most other folks. No damn wonder folks aren't embracing IPV6, the damn thing looks like a booby trapped porcupine. You'd have to be both arrogant and crazy to try to grab hold of it. Especially in a typical non-gold plated working environment with diverse legacy equipment, limited budget, and folks wandering in with all sorts of stuff that needs to connect temporarily or permanently to the network.
What are the mitigating factors? What am I missing?
You're thinking of MAC addresses, not IP addresses. MAC addresses come burned into each device, and get distributed via ARP/NDP. IP addresses are assigned to each machine from the prefix on the network.
SLAAC is very simple to set up... but the vast majority of people don't need to do so, because their routers will ship with it configured automatically in the same way they ship with DHCPv4 servers configured automatically. If you do need to set it up yourself, it's easier than setting a DHCP server up by yourself.
Lots. It does "just work".
If you are ip6 enabled, you'll see that your android devices (since 5.0) and chromebox "just work".
Anything that runs slaac will just work. If it's not, enable it. It's no different than saying your ip4 box needs configuring if you don't enable dhcp.
Oh, and if you dislike slaac, dhcp6 exists also.
You're spoilt for choice!
SLAAC was most of a great idea but it leaks. That was/is fixed/fixable, but here in the real the bog standard gear most people are stuck with can't be relied on to have implemented it properly, or ever fix the firmware. DHCP v6 is slightly more annoying to set up, bit fixes some other problems can helps provisioning, but some devices don't play nice with it(same also true other way round).
4to6 address translation using a border router and BGP sounds like a simple way any grandmother could get set up in a hour right? And she'll hack together firmware for the WiFi router and the old baby monitor right?
The cheap crap that is IoT in the real world is usually designed to only use out of date 2.4 wifi standards, and IPv6 support is a train wreck. Most of it works fine behind NAT though, because that's what the people who built it were working on, crap wifi, IPv4, and NAT.
But the IPv6 doomsday cult still talks of pushing other people onto something the have been happily ignoring for 20 years, blithely ignoring the fact they will be causing a bigger breakdown in the internet then they will be fixing.
v6 isn't going to cause a bigger breakdown in the internet than it's fixing. There's somewhere around a billion people using v6, about a third of the total on the internet, and it hasn't broken down, and neither have the networks of the people that're using it.
Meanwhile various things are broken on v4 and cannot really be fixed due to address shortages.
"The cheap crap that is IoT in the real world is usually designed to only use out of date 2.4 wifi standards"
Because the IoT processors which do it (most commonly ESP8266 family ) are 5p each in quantity whilst the 5G ones are 10-20p each thanks to licensing on 2.4G being signficantly cheaper than 5G.
Critical 5GHz patents have started expiring over the last 12 months and the latest generation of processors are coming down in price
(Fun stuff: Tasmota, etc)
the IoT SoCs themselves are IP agnostic and will happily do IPv4 or IPv6, but the standardised arduino toolkiits are the limit: https://github.com/esp8266/Arduino/issues/638
"Oh and why would a router need to dole out IPv6 addresses using DHCP? All my routers had that disabled by default and everything uses SLAAC."
Well, that's a choice, but not one I'd make. For those who are not aware, SLAAC is basically the globally-unique address which gets attached to the router's address range automatically, meaning you neither have to attach static IPs nor run a DHCP server. And it means that every device becomes publicly addressable.
I do not want random devices to be publicly addressable, and therefore I use DHCP to local address ranges. Yes, I know what a firewall is. I have one configured. But I find that NAT is a good method of not letting a device receive commands from nobody knows where. If someone connects to my home network and I don't set the firewall rules properly, they either become a potential target for attacks or cannot be found by bots. I prefer the latter. For the same reason, my home network doesn't support UPNP. If I do want to have a device accessed from the open internet, I have to take manual steps to enable that. For my small network, I think this is preferable configuration.
In addition, unique addresses per device make it easier to track traffic coming from them. Using one address to route all my outbound traffic, a potential tracker cannot easily tell my phone from my laptop from a guest's laptop purely from the packet headers. Fingerprinting can still occur, but only by the sites I connect to. The ISP would not be able to track individual devices as easily. If I used individual addresses, not only would they be easier to track, but a tracker would also know extra information. The default SLAAC implementation includes MAC address data in the created unique address. This allows them to know the manufacturer of the device or network chipset and to identify that device if it is moved to another network without changing the SLAAC settings or MAC address. I view those things as negatives, and blocking direct addressing is one of my ways of combatting it.
I think there may be a disconnect here. My comment does not make any points against IPV6. In fact, I don't mention IPV6 itself, either positively or negatively. I meant my comments to be limited to a SLAAC versus NAT discussion only. In fact, while my home network currently uses a private IPV4 address space, I have others using NAT on IPV6, and I'm perfectly fine with that. I'm primarily a proponent of IPV6 adoption.
"And it means that every device becomes publicly addressable."
Funny. All my devices have SLACC and have unique public addresses.
You still only get to touch them - or even see that they exist at all - if I say you can - and unsurprisingly that's the router's DEFAULT setting (it tracks IPv4 firewall holes and uses the usual assistants on both protocols to open/close ports as needed)
Yes. That is the firewall point from above. I acknowledged it and I acknowledge that I still think NAT has a benefit there. What about the tracking aspect? Because those addresses also look different to the external server, which I don't want them to do. I assume you don't mind that, but for people like me who do, do you have a suggestion other than NAT?
This post has been deleted by its author
Thanks for answers, all. I have to admit I'd not want to use IPv6 is a business setting - my experience is simply as a home user.
And I also dislike the 'everything has a public address' side of IPv6. Now that you've mentioned NAT someone will probably be along to have a go at it saying that it has ruined the internet. My response to that is that I've never had problems with NAT and never found that it breaks anything.
IPv6 is more complicated than IPv4 and I'm pretty sure I don't have a full grasp of it so thanks again for providing some insight.
IPv6 is less complicated than ipv4, and nat is one of those things that makes it so. Your devices have multiple addresses, you have the added complexity of correlating them. Then on a network of any size with interconnects you have to worry about address overlaps.
NAT does break things, many protocols have been redesigned to work with nat and often losing features or performance in the process, many nat implementations have specific kludges for certain protocols (eg ftp) that can be abused for malicious purposes. Having a single nat gateway under you control is also nowhere near as bad as one provided by the isp that you have no control over, or multiple layers of nat.
NAT turns the internet into a client-server model instead of a peer to peer model... Communications protocols were designed to connect users directly together (eg original ICQ, the DCC features of IRC etc), nowadays since users can't connect to each other directly all communication takes place through a third party server which decreases performance and reduces security/privacy.
No people didn't "go to those lengths... in order to avoid IPv6". They went to those lengths because - at the time - very few people were on IPv6 and so the problem had to be solved for IPv4. And not too much has changed since.
NAT is horrible. The fact that various things work at the IPv4 level doesn't change that.
"It's telling that people would go to those lengths and put up with those inconvenienced in order to avoid IPv6."
No, they go to those lengths and put up with those inconvenience BECAUSE IPv6 ISN'T AVAILABLE
It's called working around NAT's fuckups, because you don't have any other choice, but it ONLY works through one layer of NAT. As soon as you have CGNAT or multiple layers, you are reduced to client-server models
It's that client-server kludgearound which usually ends up poking glaring holes in IoT implementations and completely backdooring even NATed networks in the quest for remote accessiblility
"Having a single nat gateway under you control is also nowhere near as bad as one provided by the isp that you have no control over, or multiple layers of nat."
If you want to experience how bad the fuckupery of multiple NAT layers is, go to Myanmar.
You'll find yourself behind between 3 and 7 layers of NAT to the outside world. If you're REALLY lucky you might be able to achieve 2kB/second or see ssh latencies low enough to type a couple of lines, look up and see them appearing on your screen - and Myanmar is entirely connected via cables, not satellites (the ISPs I was using were anyway)
Thailand is a little better, as is Vietnam. Laos and Cambodia are much much worse and interactive sessions are effectively impossible. This applies across large parts of Africa and India too - and not sparsely populated areas.
The "developed countries" got 95%+ of the IPv4 space and the longer we cling obstinately to it, the harder we're collectively fucking over the developing countries
"Communications protocols were designed to connect users directly together (eg original ICQ, the DCC features of IRC etc), nowadays since users can't connect to each other directly all communication takes place through a third party server which decreases performance and reduces security/privacy."
As a GLARING, REAL WORLD CASE of this, just about every single DVR and webcam using Huawei(HiSilicon) SoC - and that's 95% of them - is capable of being broken into if it's on the Internet - this is a direct result of that "third party server" policy coupled with hard coded passwords and replacing it with a "port knocking" policy when called out that's trivially defeated (it slows attackers down by about 6 seconds)
>Communications protocols were designed to connect users directly together...
That underlying assumption in the design of the Internet was due in part to the world as it stood in the 1960s and 1970's ie. the time when computers were mainframes and minicomputers and it was these that were being connected together, not the individual terminals being used to access these systems. (Remember in the early 1980's we used TELNET TCP/IP with private addressing to replace point-to-point RS232 terminal connections with networked terminal connections.)
The question is whether such an assumption is still valid in today's world with a more diverse range of end-point devices.
I grant that NAT breaks many protocols. The problem is that many of those protocols from before NAT was taken into account aren't very useful anymore as they were. Take your chat protocols. They would still work, but few people will use them. Why? Well, most of us now use devices which might move around, from laptops to phones. We probably want chat messages to come to us wherever we may be, without having to have dynamic DNS attached to our personal machines. Our address will keep changing, so merely identifying an address is a little painful. For that reason, a lot of old chat systems used a central server that associated names with addresses. Yes, a central server, so it wasn't purely P2P. And that just fixes the discovery problem. What about storing messages if the device is offline? For the chat purpose, using a central server is usually not a problem.
There are other protocols that could benefit from a direct connection, but there are also ways of creating that with NAT in place. Some of them pipe all the data through a central server, but many others use that server only to identify a pathway between devices which is then used without the server's involvement.
NAT isn't good everywhere. I like it on my own network, but I don't like it on my ISP. Since we don't have sufficient IPV4 addresses for all the individual users and machines we want to be addressable, IPV6 is likely our best path to not having that problem. That doesn't diminish the benefits of NAT. To the adoption of both.
"Imagine what might have happened if AWS had said, "any new service is going to have an IPv6 endpoint, and you must pay extra if you want IPv4"
They would have to pay the extra for IPv4, or most people wouldn't be able to access it.
I don't know about Amazon's pricing, but a lot of cloud providers do charge for IPv4 addresses already, and people pay for them, so actually this wouldn't be particularly unexpected.
This post has been deleted by its author
> And in any case, Elastic IP doesn't even support IPv6
EC2 doesn't offer Elastic IPv6 addresses because there is no need to... there's plenty of IPv6 addresses to go around!
You add a /56 to a VPC then a /64 from that into each subnet. Easy. It's been like that for some years now.
Using ipv4 addresses with AWS and similar providers has problems...
With AWS at least all ipv4 traffic is natted, ipv6 traffic is not, some protocols don't like this.
Also ipv4 addresses are recycled whereas ipv6 addresses are not, if you shut down an ipv4 instance you have to make sure anything that was pointing to it (firewall rules, dns records, static configurations etc) has also been cleaned up otherwise you could have a security breach when someone else is allocated the same address. For an example of malicious activity taking advantage of this, read the recent story about houseparty posted here a couple of weeks back.
We are told that commercial fusion reactors, flying cars, living in orbit and IPv6 adoption are only 10 or 20 years away!
(Did anyone else think the "cat in front of laptop" clip art accompanying this article had to do with IPv4's nine lives? However, the principal use of both IP address protocols as conduits for cat videos works too.)
If you have $400,000 or so laying around and a REALLY long driveway, these folks MIGHT be able to sell you a flying car of sorts. https://en.wikipedia.org/wiki/Terrafugia_Transition
... Or not ... They've been a few months away from delivering a product for a decade or so. Their concept seems doable and their prototype actually worked. OTOH, they still aren't shipping product.
Flying cars exist.
The way people drive, would you risk EVER taking one on the road or parking it anywhere, knowing that some asswipe would sideswipe it when parked or change lanes into you and what was a relatively expensive paint and panel job is now a complete engineering teardown and flight recertification?
"After the last decade of dolts connecting fridges, lightbulbs and other junk to the internet, each one of those devices needing access to an IP address, humanity ran out of unallocated IPv4 addresses in November 2019."
I worked at intragovernmental organisation (about 500 people) over a decade ago they had been using an allocation of /19. They assigned a registered IP address to every system at their premses, inculding all the desktop PCs. Their needs could have been entirely satisfied with a /24. They had agreed the /19 with a Belgian company that had the rest of the /16. The Belgian company had since been bought up and the /16 was forgotten - it remains allocated to the defunct company.
Bottom line: There is a /16 allocated of which only /24 is actually needed.
I bet there are plenty more allocations like this.
and they can't be bothered to change them for private ones. Why ? Because there's no business need and also no business value added. This is also the same reason they can't be bothered to move to IPv6.
How can one justify going in front of the CFO asking for a large sum of money and warning him about possible disruptions of the company's core systems just because the outside Internet is running out of IPv4 addresses ?
Before IANA ran out in 2011, we were going through one /8 per month, and demand has only gone up since then. At that rate, a /16 would last for about 2 hours of allocations. Even if you could hunt down a few thousand of them, it's just not a lot of space compared to what we need.
At the end of the day, v4 is simply too small. No amount of unused allocations will change that.
Hypothetically, if you added an additional two octets to the IPv4 addressing then how long would the additional addresses last?
ie, from IPv4's 4,162,314,256 (~4 billion addresses)
to IPv4+2's 268,535,866,540,096 addresses (~two hundred sixty-eight trillion five hundred thirty-five billion addresses)
It's really hard to put a specific duration on it, because it depends on how much you're willing to give up and how much time and effort you're willing to spend working around address space limitations, and on far too many parameters to get a proper handle on. But let's see what I can do.
In v6, you're supposed to get something between a /56 and a /48, with each network being /64. In other words, 256 to 65536 networks of effectively infinite hosts each. If we took the lower end of network count (256 networks, 8 bits) and dramatically reduced the number of hosts per network to 256 (again, 8 bits) and allocated out of a 48-bit space, then each user would get a /32 and there would be 2^32 (4 billion) /32s available.
Well, the standard allocation to end users in v4 is already either /32 or -- for phones or ISPs with CGNAT, which is probably billions of users -- absolutely nothing, and we're running out in v4, so with these allocation assumptions in a 48-bit space it seems like we'd be at least a significant fraction of the way to running out just with the current internet, let alone accommodating any future growth.
Deploying a new layer 3 protocol is an extremely long and expensive process. We only want to do it once, which means that providing far too many addresses is a design goal, so that we don't hit the point of having any reason to need another upgrade. I don't think 48 bits would meet that goal.
... Why not?
There are 254 usable addresses per octet, so my math is running at 254*254*254*254 gives you the ip v4 address space (0 & 255 being unusable, obviously) which gives you 4.2 billion addresses, minus the ~600k reserved addresses.
254*254*254*254*254*254 = two hundred sixty-eight trillion five hundred thirty-five billion addresses.
Think about that for a moment. 268.535 trillion addresses. That .535 trillion? That's five hundred and thirty five billion addresses. IPv4 has 4 billion. The existing IP space would sink into this scheme without leaving a ripple.
A new top level block would be 1,057,227,821,024 addresses under this scheme. That's one trillion, fifty seven billion each. You could literally reserve a top level block to contain IPv4 (which would waste one trillion, 53 billion addresses), allocate the 192 countries in the world a block each and still have 61 blocks that size left spare.
Even China which has a population of a billion and a half would still have seventy addresses per person in it's address block. How is this not enough? How many do you think are needed?
It's not enough because we're talking about layer 3 here, not layer 2. We aren't talking about MAC addresses, but IP addresses. They aren't allocated densely, but rather sparsely. The sparse allocation is critically important because it's how we scale the internet up to the scale of the internet. This is the entire reason we have IP in the first place rather than relying only on MAC addresses, and you can't just ignore it.
You're suggesting to allocate one /8 to each country, i.e. to use 8 bits of the address space to identify a country. With my lower-end allocations to end users, I'm suggesting to allocate 16 bits of address space to each user for their networks. Out of 48 bits, that leaves us with 48-8-16 = 24 bits of address space for the ISPs in each country. There are many countries, perhaps even most of them, that wouldn't fit into 24 bits of address space even in v4 land where the default end-user allocation size is often no addresses. As such, 48 total bits seems like it might very well be too few bits now, let alone in the future. That's why I don't think it'll meet the goal of giving us too many addresses.
To answer your last question: layer 2 is 64 bits for new protocols, and layer 3's routing and aggregation consumes additional address space, so we need something like 80-96 bits at L3 to handle the full L2 address space.
"It's not enough because we're talking about layer 3 here, not layer 2. We aren't talking about MAC addresses, but IP addresses. They aren't allocated densely, but rather sparsely."
you clearly have no clue how IP addressing works or how its allocated or why.
Addresses are hierarchical so traffic can be routed. Groups of addresses are routed to, for example 18.104.22.168, 22.214.171.124, 126.96.36.199 are subnets of 8.200.64/18 the isp responsible for routing to 8.200.64 can also route for 180.200.64/18 or any other subnet its authoritative for but that adds extra entries in global route tables.
Domestic and also business users (that don't own their IP range) will have IP's bound to their ISP's allocation, change ISP get a different range.
Isn't that what I said when I mentioned sparse allocations and aggregation? Allocations are made hierarchically and in large blocks in order to minimize fragmentation and the number of routing table entries needed, and all of this consumes address space.
Essentially, a majority of IP addresses "go unused" in order to make routing on the internet more efficient (but those addresses are actually in use, they're just being used to make routing more efficient rather than being used for assignment to an end host).
...which is why it's not enough for the IP:person ratio to be equal to or only very slightly higher than the number of devices that each person owns. You need to consider the various layers of allocations above the end device.
Won't happen in 10 years, IPv6 has already been around over 20 years and shows little sign of mass adoption.
I'd actually be surprised if it happens in my lifetime.
They would be better off designing IPv8 (or whatever) which is backwards compatible with IPv4, which doesn't require throwing away the protocol that powers the internet and is embedded in trillions of devices, many of which can never be updated.
We already have a protocol that's backwards-compatible with v4 though (namely IPv6). How would designing another one help? You'd just end up in the same situation v6 is, except 20 years behind in software support and development.
The compatibility problem with v4 and v6 is that v4 isn't forwards compatible with bigger address sizes. Designing a new protocol won't change v4's lack of forwards-compatibility.
The problem is not v4's lack of forwards compatibility. Nothing is ever forwards compatible in any meaningful way.
The problem with IPv6 is quite simply that nobody wants it. Nobody wants it because it obsoletes the knowledge of everybody that is currently keeping the internet working and requires expensive training courses, plus wholesale replacement of entire infrastructures by people who don't particularly care for the expense of either equipment or retraining, and the security risks alone are enough to cause anybody with a functional brain from locking up when confronted with the risks of GDPR fines if their setup isn't 100% safe, and that puts people off of ticking the "enable" box.
If you had buy in from people, it'd have been done by now. If IPv8 was IPv4 with an additional two octets and didn't do a single thing differently then in five years time the uptake would be almost universal because buy in would be immediately universal and when the equipment was replaced in a normal replacement cycle nobody is going to hesitate ticking that "enable" box because they already know what it's going to do.
It doesn't obsolete your knowledge, because a significant fraction of your v4 knowledge applies to v6. It doesn't require expensive training courses; I learnt it from random web pages. It doesn't require a wholesale replacement of your entire infrastructure; you can replace each component during your normal refresh cycle. The security risks are not really any different to v4, and people's brains mostly don't lock up when dealing with v4.
If IPv8 was IPv4 with an additional two octets, then IPv8 would be too small. Deploying a new layer 3 protocol is an extremely long and expensive process. We absolutely do not want to do it more than once, so deploying a protocol that's too small would be a bad idea.
I'm also not convinced that making the protocol too small would give you universal buy-in. A lot of complaints don't seem to be based on reality, and most of the real problems involved in upgrading v4 will still exist regardless of how many bits you add.
So based on learning it from "random web pages" you'd be willing to tick the IPv6 box?
If there is a security compromise as a result, your company probably goes out of business due to GDPR fines. You personally lose your job, and almost certainly never work in IT again. Are you that sure? Few people are.
The risks are huge, the rewards are zero. Hence, nobody ticks that box.
Yes? That's how I learnt v4 too, and I'd be willing to tick the v4 box on the same basis. If you're that afraid of running a network, then you already can't work in IT.
The risks aren't as big as you think they are... and the rewards are bigger than you think they are too. But I suppose you're not the only person who's afraid of new things.
"A lot of complaints don't seem to be based on reality"
Virtually all complaints are that renumbering or redeploying is far too hard and they can't be arsed moving on from IPv4
As I've mentioned I ran into this regularly dealing with organisations which allocated themselves addresses for internal use (usualy 128.*) on the basis that they'd never need the Internet, then found they DID need it.
Telling them they had to renumber their internally used nets out of public space and into 10.* or 172.16-32 had exactly the same resistance as seen to moving to IPv6 and many of them TO THIS DAY are using 128.* addresses internally.
The fact that the worst offenders are regional health authorities shouldn't surprise many people (frequently the same organisations would be running their entire financial systems using MS Access - these are organisations employing upwards of 10,000 people and handling hundreds of millions of dollars a year)
Nobody wants it because it obsoletes the knowledge of everybody that is currently keeping the internet working and requires expensive training courses,
I disagree with that. For the people who actually run the Internet, it's their profession. They have no problems using/learning IPv6. It would surprise me if IPv6 knowledge wasn't a part of CCNE and other network engineering certifications for at least the last 15-years.
If you eat and breathe this stuff all day every day, as a professional working network engineer would, I doubt it would impose any issues.
The people who have a problem with it are the non-professional-network engineers like me. People who don't do network engineering as a profession. People who 20 years ago may have been network enginners, but these days have moved on to other things so would rather not have to learn IPv6 because it's no longer their profession, it's stuff they used to know that they find useful in their current jobs (dev, sysadmin, applicatoin architect, whatever) for 'big picture' or tracking down immediate application issues. Or people who learned IPv4 at university 30/20/10 years ago, and use it in their hobbies (home nettworks etc.), but don't want to have to learn IPv6 because inertia.
Learning new stuff can be hard if it's not directly part of professional responsibilities (network engineer) or it's outside active interest areas. I know enough IPv4 to get my network set up, how to diagnose issues, how to talk reasonable intelligently at a high level when troubleshooting sysadmin-type issues at work. But I don't 'do' networking in any detail day-to-day, therefore lerning IPv6 is an imposition since it is outside my area of expertise and IPv4 seems to work well enough for my purposes.
So most people who 'dabble' in networking just to get stuff working at home are not overly familiar with networking, they just know how to get their home IPv4 network working, and maybe a few ancillary services (DHCP, DNS). Having to expend the time and effort to learn IPv6 for them (me included) is a hurdle. I think this'll be like that saying about scientific theories, that theories lose favour as the generation that supported them die off and newer gnerations come along with new theories. I think IPv6 will be like that, as the young'uns learn IPv6 from the get-go at university, or the knowledge becomes more 'standard' such that it's where the IT-nerds start from and the oldsters like me whose TCP/IP nerding started with IPv4 before there was an v6, who know IPv4 but find IPv6 hard retire and die out ...
So depressing that this is a tech website and the forum section on any IPv6 articles are full of comments about how different, wrong, funny-looking, new, scary etc IPv6 is.
Often people say something like "IPv6 is 25 years old and still crap" then no follow-up or technical justification of their opinion. Probably voted for Brexit.
Sometimes people reel off one of these:
- "IPv4 had better features" (then claim NAT is a feature)
- "But my IoT will be publicly addressable" (noone cares what random address your TV got out of the grains-of-sand-on-earth's worth that your ISP delegated to you. Your ISP gave you a box which does the same job with IPv6 as it did with IPv4)
- "But they can track my pr0n" (lol as if your v4 address in a residential ISP pool and browser user-agent isn't all up in pr0n trackers already)
- "But Android doesn't support DHCPv6" (ok, sure, you need to push out vendor-class options or PXE boot your Android device)
However people waffling away in forums and tech websites dissing some technology they don't want to learn are not the point.
IPv6 will keep being deployed to end-user networks regardless of whether `COBOLSL4Y3R` in some forum thinks it's crap for... reasons.
If you're a recent fixed-line subscriber to BT/PussNet or Sky in the UK in the last couple of years, you likely already have IPv6 enabled and it just works.
Mobile networks in the UK are a long way behind US, Europe, Asia, but I've been roaming, tethering, all of it, with IPv6 on mobile and it just works.
I'd be extremely surprised if there's an end-user ISP or mobile provider in the UK that isn't piloting or actively deploying IPv6, if not deployed already. In fact I'd welcome anyone naming any UK ISPs that are categorically saying they will never deploy IPv6.
If you're running servers in an enterprise, small biz, hosting provider, public cloud or your own shite-cloud and happy with v4 NAT to RFC 1918... then fine. Leave it. Noone will care about your dreadful Citrix/Exchange/whatever being v4-only anyway.
Is IPv6 perfect? No. It's different. Read about it. Learn all of it. Deploy it.
IPv6 will keep rolling out to end-user networks over time regardless of whether you like it or not.
Crying in a forum and waiting for IPv4-ng is just pointless my friends.
If that dreadful Citrix/Exchange/whatever is serving users/customers and helps paying my salary then I care. Why would I put internal systems at risk and spend money if there's no business value in it for the enterprise. Just for the love of IPv6 ?
Just for your information, there are still organizations with IPX networks and we're in bloody 2020. For a decade now their technicians have read and learned about IPv6. As for deploying.... stay tuned but don't hold your breadth.
Upvoted because I completely realise there are legacy networks. My point is that there is no need or rush to migrate those dreadful Citrix/Exchange/whatever to dual-stack. Leave it as v4-only if you have the IPs and infrastructure already in-place.
Adding up all those enterprise/business applications and legacy networks across the UK will not contribute to a country's IPv6 deployment percentage to any meaningful degree. IPv6 exists and is completely workable for new deployments if there is the knowledge and expertise in an organisation. The real increase in IPv6 adoption will be driven by end-user/home/mobile networks and deployment by sites in the Alexa top 500/500k etc. Little Bobby SMB SysAdmins likely do not need to worry about IPv6 - it will happen regardless.
"In fact I'd welcome anyone naming any UK ISPs that are categorically saying they will never deploy IPv6."
TalkTalk - they've been saying "real soon now" to their customers on forums for over 12 years - but they unequivocally told their resellers to fuck off when pressed and their resellers dutifully came back with the statement that they have NO INTENTION WHATSOEVER to deploy IPv6
If you're a recent fixed-line subscriber to BT/PussNet or Sky in the UK in the last couple of years, you likely already have IPv6 enabled and it just works.
I'm not sure if Plusnet support it yet. According to this:
"A Plusnet Spokesperson told ISPreview.co.uk:
“We’re committed to the roll out of IPv6, as this an important evolution for our networks and the service we provide our customers. We’re in a good place with our internal testing which means we are hoping to start making this available to customers in Spring next year.”
Meaning Spring 2020.
The planning for IPv6 didn't include a very good transition phase, and it isn't that good. All of those nice home routers/nat boxes might have been good to accommodate IPv6 at that point, and then it might have worked out better.
Alas, my DSL provider wants to do PPPoE with IPv4 addresses, and that is what routers support. I haven't seen any IPv6 home routers, but they may exist.
IPv6 home routers: I'm using one right now. I've had two others over the last half decade. Perhaps you need to sign up with a competent ISP who, amongst other things, can point you at such a router or even supply you with one.
IPv6 has been up and running for years now. If you haven't noticed, it's because it works.
"I haven't seen any IPv6 home routers, but they may exist."
I haven't seen any home routers that AREN'T IPv6 capable for over a decade. On the other hand I've seen ISPs disable it in their custom skins (AHEM*BT HOMEHUB*AHEM*)
What junkbox are you trawling through?
...IPv6 had been designed to be backwards compatible with IPv4!
Didn't that occur to the Internet Engineering Task Force? Why not?
Considering how popular IPv6 has not become, maybe it's time for IPv7 that IS backwards compatible with both IPv6 and IPv4?!
Raw IPv4 has no such provision, but if the laggards are happy to paddle in lagoons behind a NAT (and to judge from this forum, they actually see that as a feature) then we can certainly design an internet that uses IPv6 for the heavy lifting (and routing) but hand-holds the ageing IPv4 boxrs and devices until they actually die of old age.
In fact, we did, and it is running. Measuring adoption by percentage traffic is the wrong metric. It has been fully adopted and your percentage merely tracks the rate at which old crap finally falls over and needs to be replaced.
Raw IPv4 has no such provision, but if the laggards are happy to paddle in lagoons behind a NAT (and to judge from this forum, they actually see that as a feature)
Do we see it being very difficult being able to access internal servers on the internet a feature? Hell yes.
Who wants their internal servers accessible to the internet? Hackers. And possibly GCHQ/NSA.
Otherwise, many of us go to a great deal of trouble and expense ensuring that our internal networks are as close to being impossible to connect to from the internet as is humanly possible. Changing this is not something many of us find particularly desirable.
Probably not hackers or the GCHQ/NSA. It's more likely to be gamers, people using VoIP, people wanting to reach their Nextcloud install or similar. These people aren't hackers.
It's okay to not want people from the internet to be able to connect by default, and it's okay to not want to change that. But you don't need NAT to stop people connecting, and in fact can't use NAT to stop people connecting, so not using NAT doesn't constitute a change to whether or not people can connect.
Not if you're paying attention. Gaming forums are full of people trying to "fix their NAT type", and they don't have much success when behind CGNAT. Games are using UPnP where they can, but people here keep complaining that UPnP is a security risk, and in any case it doesn't work so well behind CGNAT either. When they can't get a direct connection, games are relaying through central servers which adds latency and means you need the server to stay up to play the game. Similar problems abound outside of gaming too.
Yes, there are workarounds for many of the problems caused by NAT, but they're workarounds. The problems are still there, and the workarounds are expensive, and it's not necessary to pay that cost to stop people from accessing a server on your network.
You don't need it to be backwards compatible. Systems have been using multiple network protocols for many years now. I used to work at a place that had both IPX and IPv4. Our NT boxes could use either. Also, there are numerous tunneling, translation, and proxy schemes for systems and applications that are not IPv6 aware.
In developed countries you still get your own ipv4 address when you sign up for home internet...
In developing countries this is not the case, you are stuck behind CGN and have a second class connection. You are an outside viewer, you are not part of the internet. Not to mention the performance overhead and extra cost caused by this setup.
Getting new ipv4 allocations is difficult and expensive, and developing countries are not exactly flush with cash.
Many popular sites and services on the internet started out as a hobby, if getting an externally addressable connection is difficult or expensive this innovation goes away too.
Until ipv6 takes over, ipv4 will continue to stifle developing countries and will continue to stifle the development of new services.
Even in developed countries new ISPs can't find enough IPv4s available on the market and have to put most of their customers behind CG-NAT. Even when you get a public IPv4 often is dynamic and you need some kind of dynamic DNS to access your network when you can't even ask for a static IP - which may not be available for consumer contracts.
One reason IPv6 is late is also some ISPs around the world are not eager to give users an "unlimited" number of routable fixed IPs.
"In developing countries this is not the case, you are stuck behind CGN and have a second class connection. You are an outside viewer, you are not part of the internet."
Most people don't know about this and wouldn't care if they were told. The vast majority of Internet users can function quite happily without a unique registered address - as long as they can use their choice of social media apps, Youtube, Amazon, etc. they are happy. IPv6 is a solution for a problem that they do not have.
They don't have much choice
Goo, FB and friends are deprecating it (forcing browsers to use higher levels) whilst browsers are doing the same thing (refusing to talk to websites only doing older protocols
It does cause problems talking to legacy shit like old printers in your internal networks though....
Every time ElReg gets an article on IPv6 out I read a lot of us fellas on here against IPv6 and I ask myself: do you not play with stuff at home? I mean, I love to have my static /56 on my Mikrotik, I don't have to do port forwarding and weird things to host various stuff in my network... and most importantly: do you know how annyoing it is the alternative? CG-NAT? No thanks, I want my public IP. And we don't have enough IPv4s to do that. End of the story. As a network engineer, I always found IPv6 to be so much relaxed and easy than IPv4.
Sure - but ordinary folk don't know about the whole IPv4 vs IPv6 thing and wouldn't care about it anyway. They just want access to the popular social media sites/app, Youtube, Amazon, etc. The number of people who care about this is probably a lot less than the number of remaining IPv4 addresses.
YT, FB, Scamazon, etc are going to be the LAST outfits to deprecate IPv4, for simple commercial reasons
But they may well be the first to encourage users to push across to IPv6 access for enhanced features, given the expenses of operating IPv4/IPv6 tunnels at the edges of their networks
IPv6 is already clearly lower latency for most of these guys so "faster access" might be the selling point that pushes people to bug ISPs for v6
Working for a large MSP, with large global businesses in the UK, US, Europe and beyond as customers there appears so far to be little impetus to move to ipv6. What little there is appears to be mainly public facing cloud based stuff like websites. In terms of penetration into internal networks it appears to be minimal. Given the likely impact of COVID on IT budgets can anyone see ipv6 really making its way deep into large corporate networks? Five years ago I might not have seen the issue so much as most things were proxied or sent via a VPN or direct connection to third parties, but with cloud take off increasing all the time there seems to be a greater move to local breakouts and direct connect to things such as office 365 and AWS. So its either going to be more like 10 years for big corp orates or we'd better get used to some dirty workarounds like 4in6 tunnelling.
If you have a sufficiently large block of IPv4 addresses, I agree. There really isn't a major technical reason to adopt IPv6 at the moment.
However, my employer is moving to IPv6 for a different reason: IPv4 addresses have value. They've slowly been selling off large blocks of them for some tidy sums. Eventually, the goal is to have both IPv4 and IPv6 addresses on the front of our public facing load-balancers, but to otherwise use IPv6 for most everything else behind it.
"If you have a sufficiently large block of IPv4 addresses, I agree. There really isn't a major technical reason Ito adopt IPv6 at the moment."
I can think of a very sound one. There are increasing numbers of sites and companies with IPv6 ONLY connections. You're sitting in a walled garden.
In the last twenty years, I have worked for two intra-governmental organisations. In both organisations, procurements would typically have requirements of IPv6 compatibility but neither organisation ever embarked on any IPv6 implementations - because they have no business need for IPv6. Both organisations have generous IPv4 allocations, which will likely meet their needs for decades.
"Both organisations have generous IPv4 allocations"
Which are not "theirs" and can be clawed back if ARIN/RIPE etc feel there is a need.
This has been a regular occurence when IP netspace hijacking takes place as it's regarded as proof-positive that the org no longer needs the allocations
And no, ARIN/RIPE/ETC are not obligated to pay for the clawbacks. IP addresses have no intrinsic value. If you're silly enough to pay a million for a /8 from someone then the sayings about fools and money are vindicated
I expect that IPV4 will still be in use for another 40+ years, with usage gradually declining until it's so rarely used that the networks don't feel the need to support it any more. That actually may be never. The important factor is cross-compatility such that some mechanism allows traffic between them ... somehow. That's already pretty much the case. So, just like the duck-billed platypus and the coelecanth, it may hang on indefinitely after its original ecosystem has long gone.
I never got why they did such a complicated re-implementation when doing IPv6. How on earth am I supposed to remember IP addresses in the format of:
I'm sure somebody can tell me but is there any reason they went for such a complicated new format rather then just allowing IPs up to 999.999.999.999?
You can represent ipv4 addresses as hex if you want:
e.g. 188.8.131.52 => d8.3a.d2.c4 (www.google.com)
Indeed, the operating systems I use work just fine with that, for example. My browser (pale moon) correctly connects to http://0xd83ad2c4/ on Linux. Other things like ping work as well:
~$ ping -c 2 0xd83ad2c4
PING 0xd83ad2c4 (184.108.40.206) 56(84) bytes of data.
64 bytes from 220.127.116.11: icmp_seq=1 ttl=54 time=17.6 ms
64 bytes from 18.104.22.168: icmp_seq=2 ttl=54 time=15.4 ms
--- 0xd83ad2c4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 15.459/16.540/17.622/1.089 ms
Same thing is with ipv6 in reverse, you can represent it as decimal. For example. the ipv6 address you gave can be represented in decimal like so:
2001:4860:4860::8888 => 42541956123769880606220662448000886044
As ipv6 has more bits, to keep it short and easy to remember, hex rather than decimal is used.
While I don't find "2001:4860:4860::8888" particularly easy to remember, it is easier than its decimal representation.
You're not supposed to remember them, you're supposed to use DNS and remember the hostnames.
And yes, there is: you can't just "allow bigger numbers" in the textual representation of a v4 address. The addresses are actually a sequence of 32 bits and there's no space in there to represent anything outside of the set of 256^4 addresses that it can currently do.
In that case you just copy/paste the address out of your /etc/resolv.conf file. Or type it out from memory, because it's not that hard to remember v6 addresses like 2001:db8:abcd::1; it's just your prefix plus "1". Or put it into /etc/hosts if your DNS breaks so often that this is such a big problem for you. Or connect over v4 -- one of the benefits of dual stack is that you can connect over one address family when you break the other one.
I zero'd in on it because in some respects this ease of access is a big issue for tech's - its the reason why there is a need for such IPv4 basic services as TELNET and TFTP. However, at some stage we are going to have to bite the bullet and remove IPv4 because ultimately these will become security issues.
I suspect part of the problem is that IPv6 has been in waiting for too long, thus networking courses have focused on IPv4 and related networking matters, treating IPv6 as something "you need to be aware of - but will most probably never use", plus it is much easier to write introductory textbooks drawing on IPv4 (particularly as there is many decades of source material to draw upon).
However, Nanashi, whilst I am critical of IPv6 and where we are at with it's adopton, there really is nothing else that is close to being ready for prime time and that includes another idea that utilises a mandatory IPv4 header field to acheive an IPv4 address space expansion, like NAT did.
All the discusion here is technical stuff that seems to me to be irrelevant. The technology is mature, tested and in use, and at some point we will need to take the corset off, so given no better solutions the question is how to do it?
What it needs therefore is for a major trading block (the EU or the US from a western perspective) to mandate that all devices brought onto the market after a given date only use IPv6. This then pushes usage up with little cost and will drag the rest of the world along. The EU has well establised processes for regulating changes like this and could lead on it. The US ability to regulate is a bit more chaotic it seems.
A I missing something here?
"What it needs therefore is for a major trading block (the EU or the US from a western perspective) to mandate that all devices brought onto the market after a given date only use IPv6."
Why? There is no business imperative to do this - if there were, businesses would already be migrating to IPv6.
The technology is mature, tested and in use
From my experience just implementing IPv6 on my home LAN when my ISP started their beta test for it, when they finally got it up and running on their network, that's not quite the case. I'm connected to Australia's NBN network. My ISP hit their first bug on their Cisco ASR BNG's with the IPv6 DHCP having it's CoS hardcoded & not customisable like it was with IPv4 so the NBN network would just drop the DHCP v6 requests as they required the CoS to be set to a particular value. Cisco supplied a hot fix in a few months. The second bug they hit was the DHCPv6 service crashing due to memory exhaustion and only a reboot of the BNG every 15 odd days would resolve it. They received another hot fix from Cisco but when this hot fix was installed it broke PPPoE, so it had to be rolled back. A third hot fix was required before the beta was able to restart proper. During this testing my ISP was also testing the modem that they'd being supplying their customers who didn't BYO, which they fully support to their best effort. They then found the IPv6 implementation on the modem was buggy again and the vendor supplied them with 2 versions before the bugs were ironed out. Next problem, to install the new version of the software it will reset the modem back to factory defaults. That's quite a problem.
In the ISP's IPv6 end user support forum there's many bugs or incomplete IPv6 implementations on various modem & firewall's that end users have hit before they even deploy to their LAN. eg the ISP is using DHCP v6 PD, Palo Alto's don't support it for their WAN interfaces. My ISP supplies a /56 for me to use which I was grateful for because I run a number of VLAN's behind my firewall. My firewall doesn't seem to do prefix delegation 100% of the time if I use 0 for a prefix on a client interface, start at 1 and it works 100% of the time. I wasn't the only one to find this.
When I deployed IPv6 to my LAN, I was using a older L3 Cisco switch behind the firewall for a number of VLAN's & it doesn't support SLAAC RDNSS so I needed to run DHCPv6 on that but Android for a stupid philosophical reason doesn't support DHCPv6. In the end I run a network segment off a subinterface on my firewall to support Android devices specifically as the firewall supports SLAAC RDNSS. Another thing I found was that my firewall's DHCP v6 client isn't as robust as the IPv4 one. So if my ISP goes offline due to maintenance or an outage IPv6 doesn't always come back & I have to manually intervene. The DHCP server & DNS resolver on my firewall support adding DHCP IPv4 static leases to the DNS resolver so I can just type the name on a client and DNS works but it doesn't support that for IPv6 static address. The clients themselves on my LAN that support IPv6 apart from the Android ones seem to have no issues however. So despite IPv6 being mature the various software implementations are far from it if they are even feature complete.
@The man in the pub - "mandate that all devices brought onto the market after a given date only use IPv6"
First, mandate that all ISPs must support IPv6 as a standard (no extra charge) part of their service. If it doesn't include IPv6, you cannot advertise it as an internet service.
disable IPv4 at your router, fiddle with all your connected devices. How many still work? This is nothing more than the digital television debacle part 2 :(
ps I have found I will need to replace both televisions, 8 computers, 4 laptops, 1 printer, and not even going to attempt the connecting of the trash-80 coupler to the mess... All these wonderful promises, very little delivery after the changeover (I get 1 OTA channel now v. 5-7 before the digital switch); the solution? Buy all new devices! Think of the boost to the world (Chinese) economy! Get off my LAN! mumblegrumble
The televisions possibly, but I don't believe you have 8 computers and 4 laptops that don't support IPv6. It sounds like you disabled v4 without setting up any alternate backwards compatibility mechanism for reaching legacy v4-only hosts.
I'm trying your experiment here and things are still working, because I have NAT64 to handle the backwards compat.
So I'll play devil's advocate here. I just checked my RUT950 screen and BOOM there's an IPv6 IP address showing. This is on EE 4G.
If I did want to get IPv6 enabled on my LAN, where IP(v4) addresses are handed out by my Windows server DHCP, what do I need to do next? Do I need to configure default gateways somewhere, if so what? Using the online IPv6 websites suggests I have no IPv6 connectivity, so what do I need to configure/enable? IPv6 is enabled on my NIC.
And is there a recommended forum or group of users willing to help others get stuff working? Yes I know there's a ton of documentation out there, but it's always easier to get real help from real people.
Well assuming you have IPv6 enabled on the RUT950, I suggest heading over to the EE Community which has several conversation threads around IPv4/IPv6 eg:
Also The EE Mobile Network uses IPv6 with 464XLAT..
I am going to repeat my comments from another Reg article on IPv6.
So, around the mid 90's what should have been done is IETF "We need everyone coding a TCP/IP stack to update their #DEFINE LEN_IP_ADDR from 32 to 64 bits and the same for LEN_IP_MASK. Front PAD any v4 TCP addresses with 4 x 0 when translating between V4 and V6 addresses. If you can't reach the next hop send the DESTINATION NET NOT AVAILABLE code in the usual manner".
This will be IP protocol V6.
New IP stacks could have been rolled out in as much time as it took the BSD crowd to code it, and others to implement the code in their OS/device. Weeks or at most months. IPv4 only devices would be museum pieces by now. A wistful Reg article on the passing of IPv4, commented on by a few greybeards, while a PFY mutters OK Boomer would all that marks its passing. "Imagine that, IP protocol with only 2 to the 32 addresses!"
I will add to the above:
IPv6 might have won the engineering war (debatable). But it has LOST the marketing war. It has failed to win hearts and minds. Admit it, move on. Learn the lessons. Start again (but steal whole chunks of ideas from what has been done before, and window dress them in a prettier shade green).
10 years is more than enough time to have become the dominant force - but it hasn't.
We already rolled out the new IP stacks 20 years ago. Even Windows had the new stack in XP. The hold-up in deployment hasn't been in rolling out new IP stacks, it's been in getting support for bigger addresses into software and in getting people to actually use them. Your suggestion wouldn't have helped the part that's taken most of the time.
The translation you mention already exists in v6 -- it just doesn't help as much as you think it does.
v4 took more than 10 years to become dominant, and it wasn't trying to replace a massively-entrenched existing protocol across literally billions of devices, so I think reaching roughly one third of users in the 7 years or so that we've been seriously deploying v6 is not so much a sign of failure but rather a sign of how difficult it is to upgrade layer 3.
>Your suggestion wouldn't have helped the part that's taken most of the time.
It would of as prior to circa 1994 (the launch of Win95), the - minuscule by today's standards - "Internet" was controlled by a small elite of academic's. The opportunity was there and publicly spoken about, but the IPv6 Working Group decided they knew best... When they finally delivered the "Internet" was looking more like how we now know it with the massively-entrenched usage of IPv4...
"small elite of academic's", really? The internet was long outside the control of any single entity by the 90s.
The work on a new version of IP happened too late to make it into Windows 95. Windows 95 was originally scheduled for release in 1993, although it was eventually delayed by two years, and I think it's unlikely they would've done the OS level work so close to the expected release date (and especially unlikely that they would've done it when already 1-2 years delayed). To be clear, there's a lot more work involved in increasing the address length than a single #define.
Even if they had, there would still be the issue of actually getting ISPs to provide the new version and getting people to use it, and getting developers to support it, "even though there's no point and nobody's using it". These are the parts that have taken the most time.
We only really started seeing v6 deployment take off once the RIRs started running out of space in ~2013. That timeframe would've been the same even if v6 had been in Windows 95.
@Nanashi - I was active in the network standardisation space back then...
Remember the choice was very simple: take the MAP/TOP version of OSI CLNS - proven in 1988 - and strip the warts out, or do a homebrew that looked like IPv4 but would also be totally incompatible with IPv4...
But we are where we are now, CLNS is long dead, many involved in OSI, moved over to the IETF and have contributed much to the advancement of the Internet protocol suite.
>We only really started seeing v6 deployment take off once the RIRs started running out of space in ~2013.
Back in circa 2006, the larger mobile networks were already running into addressing issues with IPv4 as their subscriber numbers climbed, hence why IPv6 was adopted as the carrier service for 4G/5G. I don't really pay attention to the headline numbers, because the deployment of 4G will distort them, however, I am interested in the more established fixed-line market and seeing if that is really migrating over to IPv6.
But CLNS had all of the exact same compatibility problems with v4 that v6 has. You'd still be stuck with all of the same excuses that people are providing today for failing to do v6, just with the ISO as the bogeyman rather than the IETF.
On top of that, it also has a different networking model than v4, which probably wouldn't go down well with the people complaining that v6 (with an identical model to v4) changed too much from v4. Then there's the issue of hardware routing when your address length is variable. None of this would help.
We didn't really see much notable deployment of v6 from 4G itself. Many mobile companies rolled out a v4-only service on top of 4G (and many of those are still not doing v6 today). 4G supported v6 before 2013 because it was obvious it would be needed, but that doesn't mean that mobile networks started using it right away.
>But CLNS had all of the exact same compatibility problems with v4 that v6 has.
Don't disagree, there wasn't an easy solution (even the 'easy' solutions like just extending the IPv4 address length had ramifications), any change was going to "break the (IPV4) Internet".
With CLNS, I preferring the more pragmatic MAP/TOP approach, so supported the reducing the full ISO-OSI functionality to a useful subset...
However, the big problem is addressing, once you fix the length and structure of the address fields you are always going to have problems if you need to change the length or structure - so CLNS would have suffered in the same way IPv6 has, if it had gone with say IPv4 address support and then at a latter date decided to support IPv6 addresses.
However, this is history we are where we are...
Who is your ISP? Because when I switched to IDNet IPv6 'just started working' and as far as I can tell continues to 'just work'. I had to get to grips with it a bit because I run a mail server but that's my 'fault'. I have Thinkbroadband quality meters set up for IPv4 (pings my router) and IPv6 (pings my server) so I can see what kind of uptime I have. And it's 99%. The only time I see a glitch on the IPv6 side there's a similar one on the IPv4 side.
I am willing to criticise the complexity of IPv6 and bemoan the imminent death of NAT but IPv6 as a protocol (in my experience) 'just works'. If that's not your experience then it's either your ISP's implementation or a flaky router.
IPv4, IPv6, IPv999,..... nobody outside of the IT industry gives a f*** so long as it works. Now IPv4 and IPv6 both work and most of the infrastructure works, and you are never going to get some people/sites off of IPv4, so why not just convert the parts of the Internet that you can, work around the bits that you can't and end up with a godawful f***ing mess, JUST LIKE WE ALREADY HAVE WITH IPv4? You are all arguing over should and shouldn't when you should be dealing with has and hasn't. It is beyond the "design" stage and into the evolutionary stage so you are not going to change anything fundamental any more and the Internet will continue to evolve in new and random ways, and will continue to do so even after the day that it becomes self aware. :-)
If consumers were told "don't buy any new kit that doesn't support IPv6" and it was sold as a feature of the internet connection as a means of solving the horrid mess of nat and port forwarding, maybe we could make progress.
back in May, it was proposed to the UK Network Operators Forum that they announce the end of IPv4 for a future date but it was met with a range of responses, from apathy to "too hard" to enthusiasm.
The interesting thing is that the big players like Sky and BT have deployed it to domestic customers, and BT and other business providers have offered it for a long time, but because they have hoarded IPv4 they can use it as a competitive advantage over newcomers to the market who cannot buy large blocks of IPv4 addresses easily or cheaply.
>If consumers were told "don't buy any new kit that doesn't support IPv6" and it was sold as a feature of the internet connection as a means of solving the horrid mess of nat and port forwarding, maybe we could make progress.
You are missing the point, NAT and Port forwarding are under the hood tech that most consumers have zero knowledge of.
IPv6 needs to be sold to consumers in ways similar to 5G: There is very little in 5G that is of benefit to Consumers (there was an ElReg article a while back that did a nice list of the "benefits" of 5G), however, you can bet that consumers will be wanting 5G phones because they perceive them to somehow be better than 3G and 4G phones. So an upgrade to IPv6 needs to incorporate things that, like 5G, are network enhancements (eg. increased frequency bands) that can be sold to consumers.
Remember for some years now Windows, Android and iOS/macOS have supported and had IPv6 enabled out-of-the-box (aside: you can't turn IPv6 off in iOS or Android), so for consumers the issue is getting them to go out and buy the IPv6 enabled ISP service because they perceive it to somehow be better than the IPv4 service and for all their (consumer) devices to just work.
0) This is a very intriguing analysis. Below are URLs to two current activities that may go with yours:
1) This is a discussion about the state of the IPv6 based on publicly available statistics.
2) This is a report on the possible use of the long-reserved but hardly-used 240/4 netblock and its implications.
3) We are keenly aware that our approach is rather unorthodox. However, please consider the proposed architecture as a newly created full spherical layer of cyberspace consisting of RANs (Regional Area Networks), between the current Internet proper and the subscriber premises. Each RAN is defined around one reusable 240/4 netblock. Regarded as a private / independent environment, much of the existing Internet protocols, conventions, restrictions, etc. may be repurposed from a revised perspective in the RAN.
4) Hope you will enjoy exploring this new facility.
Feedback will be much appreciated.
Abe (2020-08-22 11:26 EDT)
Biting the hand that feeds IT © 1998–2021