IPv6 addresses are so long that you can't remember them long enough to read the address from one machine and type it into another. I understand it requires a long number to have a large enough address space. But, it seems unworkable from a human perspective. No I haven't thought of a better solution. I'm just saying that this is a significant usability problem and a barrier to adoption.

I don't think that's a viable solution to the OP's issue ("IPv6 addresses are so long that you can't remember them"). From the RFC:

For example, consider the address shown above
1080:0:0:0:8:800:200C:417A...
Then, when encoded as specified above, this becomes:4)+k&C#VzJ4br>0wv%Yp

It's shorter, yes, but much harder to memorize. Especially when this address can be abbreviated to
1080::8:800:200C:417A

The author's views about his suggestion's efficiency are also... interesting:

Many current processors do not find 128 bit integer arithmetic, as
required for this technique, a trivial operation. This is not
considered a serious drawback in the representation, but a flaw of
the processor designs.

Uh, you might want to look at the date on that RFC. The whole thing is a joke. Written by a guy who was involved with the IETF IPng working group, and was well aware of why the format was chosen to be what it is.

More to the point: use DNS.

More to the meta-point: IPv6 is already entering wide-scale deployment. I saw a Verizon report that something like 30% of their LTE traffic was over IPv6.

This response always pisses me off. What do you do when DNS is broken? What do you do when you are the guy setting up DNS services? With IP 4 it is pretty easy to remember a 4 number string long enough to transpose some addresses. It is easy enough to remember a small handful of well known DNS servers' addresses so that you can get a machine talking on the Internet or on your local network. IP 6 has a short-hand notation, but it's still a pain. Looking at the example given, when transposing that address one has to hold in mind 5 sets of variable-length numbers (in Hexidecimal, no less) and remember the location for the double-colons. The IP 6 designers only answer to this complaint is to suck it up - and use DNS. It is a flippant and arrogant answer.

This response always pisses me off. What do you do when DNS is broken? What do you do when you are the guy setting up DNS services? With IP 4 it is pretty easy to remember a 4 number string long enough to transpose some addresses. It is easy enough to remember a small handful of well known DNS servers' addresses so that you can get a machine talking on the Internet or on your local network. IP 6 has a short-hand notation, but it's still a pain. Looking at the example given, when transposing that address one has to hold in mind 5 sets of variable-length numbers (in Hexidecimal, no less) and remember the location for the double-colons.

Short answer: write it on a piece of scrap paper, or put it into a note on your tablet|phone|pda.

My god, are we so enamored of our technology that we have abandoned the pen and paper?

Why not Simplified Chinese? Just as many characters as Traditional and much faster to read and write. (The "simplification" refers to a reduction in the number of strokes per character, not in the number of characters.)

DNS still works just fine and IPv6 has a built-in feature to use globally unique self-applied addresses. It is the EUI-64 standard. [ieee.org] Essentially all that happens is a system uses the network portion of whatever it is connected to and the rest is autogenerated by using the MAC address split in half with an FFFE inserted.

That is how it is in all IPv6 deployments I have seen. There is no reason to do static addressing anymore, save for servers and the like.

run dnsmasq on one of your linux boxes
point all your machines to that box as their dns server
add your local devices to the dnsmasq box's/etc/hosts like a so (pick your own domain name ofc):
192.168.1.200 server.l
192.168.1.70 panapi.l
192.168.1.80 sonypi.l
192.168.1.31 mini.l
dnsmasq will just get anything that's not in/etc/hosts from whatever that box's dns server is

IPv6 addresses are so long that you can't remember them long enough to read the address from one machine and type it into another.

Which is not a problem because normal people don't have to read the IP address from one machine and type it into another. They use DNS and DHCP, which were specifically intended to eliminate the overwhelming majority of instances of dealing with IP addresses directly.

I've been a networking software engineer for most of my career, so I do have to deal directly with IP address (v4 and v6) routinely, and I don't complain about it. My mother is not a networking software engineer or IT person, so she's had to do that exactly ZERO times in the 15+ years that she's used the Internet.

But, it seems unworkable from a human perspective. No I haven't thought of a better solution. I'm just saying that this is a significant usability problem and a barrier to adoption.

It's not a usability problem, because people shouldn't be directly dealing with IP addresses. If people are directly dealing with IP addresses, that is the usability problem which needs fixing, and not the length of the address.

We have DNS because IPv4 addresses are too long to remember:)Before that we had host files:)Your "significant usablility problem" was thought of and dealt with before most of the readers here were born.

IPv6 sort of demands that you forget everything you know about IPv4. Once you get IPv6, you'll ask yourself why anybody still uses IPv4. For example.

There are more/48 networks in IPv6 space than there are IPv4 addresses. Everybody ought to get a/48 network which include 18 quintillion addresses. The first part of the a global unicast address is often referred to as a prefix and all your IP's will have that. The second part may be derived from you NIC's MAC. So there is some good sense to it.

You'll really want to use DNS.

I'm using IPv6 at home and work now and think its time is way overdue.

How do we manage this with phone numbers? We have someone call or text us, store the received number in our cell phone's phonebook, give it a descriptive name and we forget about the number. If only we had something like this for IP-addresses... Oh, we do! It's called DNS and works fine for both IPv4 and IPv6.

Someone explained to me in 1993 (yes, back then!) why that was a stupid idea but I can't actually remember why (it wasn't as simple as the bleeding obvious of throwing away a lot of addressable bits) - however your idea was one of the many thrown around before the winning idea came up as the IPv6 addressing system. Maybe that's why you got some angry comments?

Whether they realized it or not, adding four more 255-size fields (the same amount as signified by two hex digits, 0xFF = 255) would far more than double the number of addresses, it would square it. For example, if we're using 0.255.255.255.255 (~4.2 million) now, 1.255.255.255.255 would allow another 4.2 million, and 2.255.255.255.255 yet another 4.2 million. All together, 8 fields of values up to 255 would allow for a total of ~17,878,000,000,000,000,000 or nearly 18 quintillion addresses. IPv6 allows for the square of this value, up to ~319,000,000,000,000,000,000,000,000,000,000,000,000 or 319 undecillion addresses, clearly an overshot but with the bonus that all the:0000: ranges we are unlikely to fill for many years can be abbreviated as::, such that FE80:0000:0000:0000:0000:0000:3f57:FEFD can be abbreviated FE80::3f57:FEFD

What do you expect from the sort of people who expect everyone to use a different long nonsensical password for every login and change them all every couple months?

Knowing the restrictions on a password (like "must have at least two digits, one upper case letter and a symbol"), attackers can reduce the number of attacks quite a bit.

Worse, when you change your password, and are told that the new password is unacceptable because it's too similar to your old password. That means that they're actually storing your password, and not a hash. And they think that's secure?

Worse, when you change your password, and are told that the new password is unacceptable because it's too similar to your old password. That means that they're actually storing your password, and not a hash. And they think that's secure?

You might not have noticed, but password change utilities always require you to enter the old password as part of the change process. That means there is no need to store the old password for comparison, you have just entered it, and it can be discarded as soon as the comparison is done.

Ever noticed how all systems ask you to type in your old password during the process of changing your password? The system can store a hash, but compare to what you typed to prove you're still the real user. There is no need to have the old password on fixed media to check in this scenario.

True, but it's still stored temporarily during the password change. Which can take quite a bit of time before you manage to come up with one "secure" enough.

And that still doesn't excuse all the systems that doesn't let you use a password similar to any of your last N passwords. Then you know they keep passwords and not a hash.

We will switch to IPv6 not one single day before we force the telecoms to give out real, publicly-routable addresses rather than throwing up layer after layer after layer of IPv4 NAT'ing. And we can't even agree about network neutrality?

Most of the new Internet users are now mobile, people get smartphones before they get computers, the cheapest Android phone I could find around here now is $40 with a 240x320 crap screen and they'd still need a cell phone. I don't know and I've never bothered to find out what my IP address is when I'm on the phone. So I figure the Internet will continue to grow, you'll probably pay another $1/month if you want an IPv4 address and a lot of people won't bother. A lot of people don't run servers or host games or use P2P, for example I don't think my parents would notice if they no longer had a public IPv4. As long as they can browse the web and pay their bills and check their email they're happy. And don't forget how many are now using "the cloud", all their own devices are just clients that run client-to-server not peer-to-peer.

Actually, mobile networks seem to be adopting IPv6, as there are sufficiently large numbers of clients that NAT breaks down. Specifically, that even the 10/8 block is too small to accommodate all the users without breaking it up into multiple separate NATed networks, with the annoyance that implies.

A lot of times they're adopting IPv6 internally, but translating to IPv4 for the devices (older ones don't support V6 anyway) and doing a lot of magic to keep everything straight. This works because phones spend most of their time idle and you can reuse IP addresses aggressively for the active phones.

Aren't you the AC bitching about Apple and their walled gardens ?
I own my machines. I pay my ISP fees. Let me run my services as I see fit.
NAT sucks. It's a walled garden that breaks the internet. Seems lots of people here really do want a walled garden.

What do you mean by Large Scale Deployment? Every Apple computer, and most iPhones; Every Windows 7,8,8.1, Server 2008, Server 2012 machine; Every Linux box; all non end-of-life Cisco equipment, Juniper equipment; Every BSD, OpenVMS, HP-UX, and Solaris box; IBM big iron machines; lots of 4g cell phones, They all are IPv6 ready and capable.

We need to implement that around here. I was in my local computer store looking for a DSL modem that supported IPv6. Nothing so marked on any of the packaging. I find your notion that NAT and IPv4 scarcity will force people to be content sinks very insightful. However, since most ISPs don't allow you to run servers, we're kind of already there.

China has a much lower pool of available IPv4 numbers and the layered NAT as used in India creates too many hassles to last long in a place that can organise at scale - so if they are not already doing it in bulk it's not far off. As others have noted in the US there are already large deployments using IPv6 simply because that's the only way to get a million spare static addresses these days.

In the early days companies were able to claim entire class B or class C address ranges without much penalty. Usually only a few of these addresses are reachable from the outside world. Some companies don't even exist anymore but the range just lingers on.

A real world example is my former employer Exabyte. They used to produce tape streamers and libraries, the remnants are now part of Tandberg. They claimed the entire 161.81/16 address range in the early nineties. All but a few were reachable from the outside. Today there's still a few addresses active, but most of the range is lost.

Go through the list of address range owners. If they expose less than half of their range to the outside world, recycle. DNS will cope with the changes.

Looking at the Google IPv6 stats [google.com], we can see that IPv6 is already used by nearly 4% of users globally. This number has more than doubled compared to one year ago. These statistics show actual enabled usage, showing that everything from end device, router, ISP and the route to Google supports IPv6.

More significantly, there are some countries that have a much higher IPv6 user share. The USA and Germany have around 8%, and Belgium already even has 20% IPv6 users, and Switzerland 10%.

In my view, the number of IPv6 users in most developed countries will easily be above 50% by 2020. However, I would consider even a 4% share of all internet users a large-scale deployment, so I would consider anybody choosing any option other than "before 2020" as misinformed.

As the cheap, consumer-grade routers that don't support IPv6 people have in their homes die off, people will replace them with cheap, consumer-grade routers that DO support IPv6. It will be a slow process, but it will happen eventually.

At that point it will be up the ISPs to provide IPv6 support. Some (like Comcast, oddly) already do. But the cynic in me thinks we'll probably see more ISPs putting up CGNAT and charging people $14.95/month for a public IP, after they've upgraded to a business account of course. (Like they do with static IPs now.)

Seriously, with NAT, you have a possibility of 64512 unique devices behind the router, you can port-forward any of them, and even use UPNP should you use to (not that I would).

TBH, I like the fact that my router is the only device facing the public network (security wise).

I like the fact that you think it provides any security.
Just ask yourself this question: when I contact a server outside the NAT, how does it get back to me? Is there any special reason that prevents someone else to do the same?

Just ask yourself this question: when I contact a server outside the NAT, how does it get back to me?

The packet with SRC=192.168.100.101 reaches your router on the 192.168.100.1 interface. Your router notes the destination, the destination port, the source port, and the source IP. It then replaces the source IP with SRC=[PublicAddress], and possibly the source port with an available one if multiple connections are made to that service (connections are unique SRC,SPORT,DST,DPORT).

When a packet returns from SRC:SPORT, for example slashdot.org's IP on port 80, the SRC, SPORT, and DPORT are looked up in the table. This tells the router that the connection was PNAT, that it originated from the internal interface, that it came from 192.168.100.101, and what source port 192.168.100.101 used. It then replaces the public address and DPORT with the internal machine's address and the source port it used, and forwards the packet out the internal interface.

Is there any special reason that prevents someone else to do the same?

The router wouldn't know where to route it, would take it as a connection to the router itself, and would reject it if the router didn't have a service listening on that port and address.

64512 unique connections. For some reason iTunes uses several hundred at once and a web browser with a few tabs open is probably worse - all those images and icons in a Facebook page represent a connection and they get refreshed as frequently as every minute.Stick a small office full of people behind a single address and those connection numbers really add up.

TBH, I like the fact that my router is the only device facing the public network (security wise).

IPv6 does not change that. Don't mistake a firewall on the router with NAT on the router.NAT is not security at all, there are ways to get past NAT (known as NAT traversal) if the firewall rules are inadequate. NAT is a kludge with it's only redeeming feature being that you can fool everything downstream into not knowing that is is there and manipulate the traffic in any way you wish (eg. transparent web proxy to improve speed, reduce traffic etc).

Since we're all using port 80 for just about everything these days it comes out to 65536 connections for everything behind one router that is using port 80 - a real limit with single applications using hundreds for each user. Web browsing, Skype, iTunes - it's all adding up and due to the way web pages are made from many different elements these days more connections are being consumed all the time.Put a hundred people behind a router and that number isn't looking so high anymore.Do what is already happening in some places and have an ISP putting a few thousand people behind one NAT address and I'll bet they already have trouble.

A filtering firewall in theory can be made just as secure as a NAT gateway. It isn't even particularly hard to do so, but it takes marginally more work than being wide open. Doing a NAT is more complex than a secure firewall ruleset, but the circumstances are widely different

The issue comes down to failure mode. If a NAT fails to work correctly because it wasn't configured quite right, then you get no forwarding, but you are secure. If a forwarding device fails to work correctly, then you can get wide open forwarding, and be less secure.

A common consumer will notice the former, but will not notice the latter. Considering the typical use case of customer buying equipment from the cheapest vendor on the shelf and just letting it go, crappy vendor has to still make sure they get the NAT right or else fail completely in the market, but they don't really have to get the forwarding rule restrictions right to be big in the marketplace. One well versed in the area would be baffled that a vendor can produce a NAT capable device easily enough but might flub the much easier filtering rule case, but unfortunately laziest effort must always be assumed.

So unfortunately, those who would be nothing but empowered by freedom of addressibility will be burdened by being in the same ecosystem with people who don't care and vendors that don't really care either.

You seem to be suffering from the delusion that there are enough IPv4 addresses to do even that for everyone. There aren't.

You seem to be under the delusion that every device must be directly routable. That's all this IPv6 hubbub is about, routability. It has nothing to do with having machines/services/ports available on the internet. And there is no reason for anything except routers and major servers to be routable.

Figure an average 3-4 people per household. Then figure that half the households in the world don't and won't have internet access for the next 5-10 years. Then figure that sooner or later China's gonna actually get smart about their internet censorship and put their entire population behind a NAT anyway(Out of curiosity, why haven't we just done that with an additional 1 number prefix for continent routing rather than this IPv6 shit anyway?)

The 4 octets wrap up nicely into a 32-bit integer. In essence, your 0.0.0.0 address is just some number between 0 and 2^32-1. Perhaps your real address is 120936438. But you don't know or remember that, do you? IPv6 is only different in that the number you get is somewhere between 0 and 2^128-1. The problem with arguing readability of IPv6 is that it isn't intended to be readable by humans. You're not supposed to remember the number, nor are you really supposed to change it(there's no need to, your IP address will almost be more unique than any atom on Earth itself).

If you absolutely *must* keep track of a number, you'll just have to write it down. It's a pain, but transcribing a 32-character hexadecimal number isn't the end of the world.

It's not a 4 set, that's just the human-readable formatting. The actual IPv4 address is an unsigned 32-bit integer. The human-readable format splits those into octets and displays them in decimal.

Your "add an octet" would result in using 40-bit integers, which isn't a normally used size nowadays. A variant of your idea would be to use 64-bit integers and simply double the size of the existing addressing, but this would break things the same way (as everything is predicated on dealing with 32-bit addresses), and going to 128 bits allows more future proofing and allows for some convenient auto-configuration methods, as you can stick a almost-always-unique MAC address (64 bits) into half of the address, then you can just stick the 64 bit network prefix in front of that and you've got a full IPv6 address ready.

You could conceivably write an IPv6 address in the same octets format as an IPv4, but it would be absurdly long i.e. 255.255.255.255.255.255.255.255.255.255.255.255.255.255.255.255, hence why they standardized on the "4 sets of 4 hex digits" format.

That's it. I have now officially heard that suggestion too many times.

I have seen it come in two variations. Extending the IP address from four octets to five octets has been suggested frequently. It was funny, when it was mentioned in the IPv4.1 spec published as an April's fool joke a few years back. It was funny then because it was written as a suggestion by somebody with enough of a clue to include the diagrams making it blindingly obvious why it is a non-solution (which would only be slightly more work to deploy than IPv6.)

Another variation is the suggestion to increase the maximum for each octet from 255 to 999 to fully utilize all three digits. Increasing the range to 0-999 would give almost 40 bits of address space, slightly less than the extra octet, which would give exactly 40 bits of address space. But how much address space do we really need? Calculations based on population growth and HD-ratios has shown 45 bits to be on the safe side, and based on that the recommendation to assign a/48 to each site out of the/3 assigned to IANA was approved.

But each of the two suggestions above gave us only about 40 bits, which is less than 45. But if we combine the two, we get almost 50 bits. That should be enough, right? Well, what we have discussed is only notation. The suggestion tends to be made by people who haven't bothered looking at what wire formats actually look like. The only exception was the IPv4.1 spec, which did specify a wire format (and that was one of the primary hints telling the reader, that it was a joke. Another hint was the name 4.1 for something published April 1st. That the IP was extended from 4 bytes to 4+1 bytes just made it extra fun.)

So if we were to accept the notation with five groups of numbers ranging from 0 to 999, what wire format could we use? IPv4 wire-format is a no-go, because there are not enough address bits. We could invent a new format. If we managed to come up with a new format, which is obviously better than both IPv4 and IPv6, then we still have a 20-year deployment task to complete and a deadline three years ago, which makes a new wire-format a no-go as well. This leaves us with only one possible wire-format to apply that notation to, which is IPv6.

Is such a contraption possible? Sure, have a patch [kasperd.net]. And as you can see, it works:

$ ssh 256.93.800.0.1 unameLinux

And it can use familiar looking addresses such as 127.0.0.0.1 for localhost, 192.168.273.35.102 to address a host on your LAN, or 203.0.113.42.789 to address a host using 6to4 behind a router with IPv4 address 203.0.113.42.

This may not be exactly what you had in mind, but it is as close as you can get when you missed the 1998 deadline for improving the official IPv6 spec.

Right, and the company I work for has 200+ servers that need to be accessible from the world. Sure, we could do some horrible port forwarding bullshit and run services on non-standard ports and all that crap but why should we?

One of many examples - China doesn't have a lot of IPv4 addresses due to the way things were divided up years ago so there are nowhere near enough IPv4 addresses to work without multiple layers of NAT.Another - the USA still has some left but still did not have enough when a cable TV company decided to use the net for transport and needed more than a million static addresses immediately - they had no choice but to go IPv6.

Maybe I can, anyone who's tried to manage p2p connections knows that the general public has a lot of trouble with this or can't do it - sometimes due to multiple layers of NAT. UPnP doesn't help either because it's not enabled.

Personally, I like the added protection of my own router.

You might be interested in the added protection of a firewall then where you could block unsolicited connections.

I said this 15 years ago, and I'll say it again, IPv6 will never fly. Ever. We will all just nat and forget about it.

It's starting to fly already! Lots of ISPs have the equipment when they upgrade and it's a good alternative to multi-level NAT. Sure makes p2p connections easy.

What about a smart fridge that keeps track of what food you have? That'd be useful to access while at the grocery store. (I know, I know...:you damn kids with all your technology..."). There are lots of devices that would be nice to access remotely but can't because of NAT.

Basically if you can port forward, you can configure a firewall in the same way for the technology adverse folk.

I worked for an isp where I live. At one point he had 80 homes running through one ip. (yes he was an idiot). He did though, have decent protection on his network, eventually. When he finally went broke from not paying his bills, he had to sell the company at fire sale prices.

The company that bought it, removed any such protection and integrated his network into their own. Within days people started having virus problems.

I had switched a year before and the company I switched to actually gave me a 192.168.x.x address for my router. I thought that was weird but I did check and I do have an internet facing ip. I had them open up port 3389 on their router/modem and I could remote in.

What gets really strange though is that I have my network running on another router hooked up to theirs. Everything works fine, I can game, watch videos, port forward etc. There is a second port on their router for an xbox. After having latency issues because my wife was watching videos, I hooked up that port to my gaming machine. Guess what? Virus issues within hours.

Cleaned out the virus, went back to my router, no more issues.

The bottom line: The general public will never switch to IPv6 if is going to cost them money with no reward. If what we have works now, there is zero incentive. The isp's won't change until they have to either. No-one is going to volunteer.

The mobile networks using LTE have already volunteered for IPv6 (mostly - Australia's Telstra being a shambolic mess have an IPv4 translation kludge added to their LTE). Also China is starting to use a lot of IPv6 (they have a much lower number of IPv4 numbers than the USA) and that is where most networking gear is made and an increasing amount is designed. When the stuff that everyone has can already do IPv6 it becomes a lot easier to "volunteer".

The virus thing baffles me - was this Win9x? I've never seen a virus spread through open ports on a patched system, unless you include the first days of the Slammer work for MS SQL (and that was almost 15 years ago).

I see that becoming a problem for the first time since Win9x with internet-connected unpatchable appliances, but that's a future problem.

The Internet rarely sees radical, clean change and IPv4 is going to limp on for a long, long time.

This. Oh for some mod points, I'd have sent one this way. FWIW, I think we'll see concerted efforts to reclaim unused addresses or blocks. It'll take some serious hurt to governmental and corporate wallets before any meaningful change happens.

This is why we still have HTTP with cookies, HTML, JavaScript and Flash rather than a new protocol.

Flash can be safely ignored, because it's going away.

That leaves HTTP, HTML, and Javascript.A new protocol that did all the stuff as a transport protocol, markup language, and scripting language would be a bloated mess. There's a reason that the functionality is separated this way. People often use each of these technologies separately.

Agreed, and what I voted as well. While a lot of newer hardware and OS's support it, and have the IPv6 stack ready, I think a major hurdle is going to be all the existing applications, whether older commercial apps and custom business apps, everywhere very rarely support IPv6. If DNS is used, then maybe no change there is needed, but any app that needs to point to a server or another PC on the network usually has an option for hardcoded IP's, and none of these apps have I ever seen use IPv6, and all have the normal IPv4 address space.

The other major hurdle is going to be some of the lesser hardware gear that no-one really thinks about, this includes existing building monitoring/automation system, safety/fire systems, entry/security systems, and anything else that runs on embedded hardware and PLC systems. Many of these types of systems sit on the network, and most are IPv4 only. These types of systems are rarely (if ever) upgraded and are deployed and last in field for very long periods of time...sometimes the life of a building, or at least decades.

Because of these drawbacks, I think at the very closest we will see a hybrid net (which would be close to a new internet), where most or all LAN's remain IPv4 internally, and get NAT'd like they currently public IPv6 addresses. So similar to our topology now, where say everything in my house stays IPv4 within my house LAN, but my Router's public WAN address is IPv6 to my ISP. This would give ISP's and businesses more IP's to mess with, but not require hardware and software within a LAN environment to worry about IPv6. Somehow I doubt that we'd even see this scenario any time real soon.

Thank you for this informative post. I was under the impression that at least the Linux network stack and, most probably, the Win 7-8 network stack are fully IPv6 compatible. I know my router is IPv6 compatible and I had used IPv6 briefly in the past (via tunneling) out of curiosity. So, why is everyone so pessimistic? How hard can it be to just enable IPv6 if everything is ready at the user side?

I think the problem comes in that not every web server in the world supports ipv6. Heck, when I was setting up a personal web server, I was sort of tempted to disable ipv6 because fail2ban doesn't support it and so it represents a bit of a security hole in that a cracker can bypass the security by simply using ipv6. (But I decided to do The Right Thing for the Internet and left it on, even though no-one relies on it right now)

I'd be curious to see the results from someone who has ipv6 but NOT ipv4 in day to day browsing, as that's the scenario we're ultimately looking at when v4 addresses dry up - not people who are running both, like now, but people who are exclusively running v6. Would they then only half half an internet with loads of blackspots due to sites that haven't adopted v6 yet.