dig -6 www.theregister.co.uk still hangs
If you want ripe RIPE IPv4 addresses, there will be a literal waiting list to join. In a new policy approved and posted on Tuesday, the regional internet registry (RIR) that serves Europe, the Middle East and Central Asia, dubbed RIPE, has decided that the only way it can deal with the ever-diminishing number of unassigned …
They're behind Cloudflare, who definitely support v6. Actually you can reach El Reg over v6 with the appropriate hosts file manipulation, but the last time I tried to make a forum post when doing that the post apparently got wedged and had to be manually removed.
(Cloudflare do support an option that hashes v6 addresses into 240/4 and uses the hashed address as the apparent source address of the inbound connection, which should work around databases with incorrectly-sized columns or whatever the problem is...)
> dig -6 www.theregister.co.uk still hangs
Works for me...
$ dig -6 www.theregister.co.uk +short | wc -l
Maybe you should use a resolver that is reachable over IPv6 transport? :)
I guess the point you wanted to make was this though...
$ dig www.theregister.co.uk AAAA +short | wc -l
They have specifically gone in and disabled the automatic IPv6 that cloduflare provides with absolutely no public explanation, and make a point of mocking the lack of universal deployment in every article that has an excuse to mention IPv6.
...just wanted to see if a moderator would censor me for ruining the joke.
IPv6 is "on" for _all_ places we could enable it at the flick of a button. ALL of them, bar none.
... like our image hosting domain, regmedia.co.uk
All images you load, or all assets you request from that domain, are likely to be served over IPv6 if that's your preferred method of connecting to the interwebz.
Not all hope is lost - it's "only" the main content site that lacks IPv6.
with absolutely no public explanation
Seriously? No public explanation? Look at my comment history, and look for "IPv6".
https://forums.theregister.co.uk/forum/containing/3687246 - 4th Jan 2019
https://forums.theregister.co.uk/forum/containing/3579103 - 1st August 2018
https://forums.theregister.co.uk/forum/containing/3536352 - 7th June 2018
https://forums.theregister.co.uk/forum/containing/3521098 - 22nd May 2018
It comes up in every IPv6-related thread, and usually in the same condescending manner (not your case!): "my phone has IPv6 only!" "my car has IPv6, why can't you" and whatever else.
My/our reasons are still the same. We're a small team; we have other priorities; the business has other priorities; my own business ISP still doesn't give me proper IPv6 connectivity; I have to use he.net's IPv6 tunnel; bits and bobs in our system (database fields, some validator, other bits and bobs) still can't deal with IPv6.
All those reasons are still the case, and will continue to be the case until the situation or the priorities change.
The very moment I'll be sure that the systems can deal with it, it'll likely be the most happy I've ever been at flicking a deploy button, and I look a LOT forward to being able to do that ;)
This post has been deleted by its author
As long as many ISPs don't even bother to assign IPv6 addresses - even on newer FTTH lines, and when they do they ignore advices and assign a /64 (some let you pay more for a /56) they are not exactly promoting IPv6 adoption - up to the point the prefer carrier grade NAT to exploit their IPv4 pool and make more money from those requesting a public address. There's also the issue you can't easily change the prefix and force a renumbering of all devices inside a network without causing some disruption, so most people would end to have a fixed IP network.
So probably the real answer to your rhetorical question is "less money to be made".
As long as many ISPs don't even bother to assign IPv6 addresses - even on newer FTTH lines, and when they do they ignore advices and assign a /64 (some let you pay more for a /56) they are not exactly promoting IPv6 adoption
That's the advantage of using a serious ISP like Zen - you get a /48 as standard. However, they don't exactly promote IPv6, you've got to rummage around their knowledge base for IPv6 info.
VIrgin Media, PlusNet and TalkTalk are lagging behind, but elsewhere it is standard and deployed by default.
Who is only assigning a /64 to customers? I have never seen that...
Also, not heard of any significant fixed line provider using a CGN without also having full IPv6. Mobile networks yes, but not fixed line providers...
What's wrong with a home network getting a /64?
Hell what's wrong with a data centre getting a /64?
A /64 IPv6 network can contain an entire IPv4 internet's worth of subnets the size of the entire IPv4 internet. What on earth are you planning to do that needs more IP addresses than that on a single connection?
IPv6 addresses are 128 bits long. A /64 assigns only half that to the network, the remaining 64 bits are free for the host addresses. Compare that to IPv4 addresses which are only 32 bits long.
there are enough v6 addresses to assign 7 to every atom of every person on earth.
lusers can handle giving you a max 12 digit dotted decimal address for troubleshooting
try getting them to give you just the 16 Hex of the host part and there'll be all kinds of bother.
plus the amount of overhead the blooming addresses take up in the headers
MACs are globallly unique (well they're sposed to be) and only 48bit and we have only just started to run out of v4s even though it does stupid things like assign a whole /8 for loopback.
so with NAT in place an say the whole v4 space as Private addresses, do we need v6?
Well, I suspect the answer to your question has to do with how NAT was shunned from the IPv6 community from the start. IPv6 was originally branded as not compatable with NAT and I think that turned off a lot of people. I have been using NAT6 since January of 2011, so I know it is possible. My ISP declared that they will never deploy IPv6 because they have a class B IPv4 range. There are still a lot of home routers that do not support IPv6 (which is probably the biggest divider). The home routers that do support it use NAT6.
...no they don't. Even the routers that support NAT66 (which is a minority of the set that support v6) don't set it up by default. Major deployments in the UK (BT, Sky) and the US (Comcast) don't use NAT66. In fact I don't think I've heard of any ISP v6 deployments that rely on NAT66.
I'm under the impression that most new routers support v6, although there's certainly a long tail of crap out there. On the other hand, something like 97% of people use the ISP-provided router, so there's an argument that third-party routers are mostly irrelevant.
"I'm under the impression that most new routers support v6, although there's certainly a long tail of crap out there"
I haven't seen _anything_ less than a decade old that doesn't support IPv6 unless it's been deliberately crippled in the ISP's local masking of the OEM kit (ie: It's there, just not visible to the users)
"My ISP declared that they will never deploy IPv6 because they have a class B IPv4 range"
Your ISP misses the point - sooner or later there will be resources which are IPv6 ONLY and at that point their customers horizons start rapidly shrinking.
If Google announced that they were throttling IPv4 speeds, there'd be a stampede to IPv6.
Why do I say that? Barcodes.
For _decades_ there was much pissing and moaning from grocery manufacturers about how hard they were to implement despite governments in various countries trying to encourage their adoption. Then in the 1980s most supermarkets simply said "If it doesn't have a barcode on the package, we're not buying it" - at which point the objections disappeared overnight.
" Remind us again why the IETF didn't make IPv6 backwards compatible…"
Last time I've checked (I'm not in networks), there was a compatibility mode in IPV6. Sure, it's arrived WAY too late, but it is here.
Basically, you encapsulate IPV4 addresses in the IPV6 packets, and prefix the whole with the V6 network address.
The fundamental incompatibility is that IPv4 can only address 32 bits worth of different hosts. As soon as you have 2^32+1 hosts (and we have far more than that hiding behind NAT) an IPv4 host can't address it and your network becomes fragmented.
The original logic was that there was enough time available to roll out IPv6 before the IPv4 address space was exhausted so the requirement for compatibility was simply that IPv6 hosts could talk to IPv4 hosts for as long as it took for them to be upgraded.
Of course, what actually happened is that most people did nothing at all, and those that did engage with IPv6 spent most of their time arguing about it rather than making progress. It's a bit like Brexit in that respect - all these years later and not much has happened.
You could make IPv6 more compatible with IPv4 for the longer run by, for example, virtualising the IPv4 address space: with the cooperation of DNS and IPv6 relay services, an IPv4 host does a gethostbyname and if the target has only an IPv6 address, the DNS service allocates a temporary IPv4 address which it returns to the requester and signals the relay service to gateway any IPv4 traffic to that address to the IPv6 host. This would allow IPv4 systems to talk to IPv6 systems in perpetuity. In the reverse direction, the IPv4 host has an IPv6 address in DNS with a prefix that causes the incoming traffic to be routed via the relay service. You could also do it in other ways, but they all require the active participation of ISPs who haven't exactly been that keen even to roll out IPv6-capable routers to their customers until recently. But if you want people to simply move to IPv6, why give them more excuses to delay?
I first got involved in IPv6 more than 25 years ago (it has really been that long) and I gave up in despair shortly afterwards when I saw the (lack of) direction it was taking. There have been a number of opportunities to change course over that time, but we are now where we are and there's not much choice but to plough on. The implementations are done, they work, there isn't going to be a Plan B.
IPv6 was released 21 years ago and is now older than IPv4 was when IPv6 was released. It is clearly Not Going To Happen. We need to try something new. Something that is more backwards compatible. In particular something that is more NAT friendly because that means we don’t need to completely redesign our network security.
Absolutely agree. I think a big issue with IPv6 is that it may be better on paper, but the human element hasn't been given enough weight. We have all grown up with IPv4 and on the surface it's pretty simple, people are lazy and don't like something that different and looks complicated.
While NAT does ensure some form of basic security which kept many unaware users somehow safer without any need to configure a real firewall - and without being able to disable the implicit rule for a whole network, you'd be a fool today if you're basing your security upon NAT only - especially when protocols line UPnP, NAT-PMP and PCP happily pierce holes through it if not disabled on the router.
Anyway, it's not that IPv6 is less "NAT friendly" - NAT can work with IPv6 just like it works with IPv4. The problem is if a given router does not implement IPv6 NAT, as there is far less need of it, and has been discouraged.
The real issue today could be privacy - when NAT is not used it would be far easier to map an internal network by observing the packets addresses, and if addresses are not generated with a good random algorithm, and changed after some time, each device has an observable unique ID.
Not in the normal and/or recommended use of them. IPv6 is deisgned to be an individual public address per device, IPv4 is now normally used behind NAT. Therefore you can't identify an individual machine from just the public IPv4 address and due to the shortage these are often being double-Natted by ISPs. ISPs also often reuse the IP if you didn't purchase a static IP so it can't be relied upon to be the same person.
Yes, I know this is simplistic and there are variations and options..but as a simple use case.
No, you don't. Just because an IP is "public" doesn't mean that it has to be completely open to the outside!
Most devices out there already have an implicit deny any for inbound packets that aren't associated with an outbound connection. So while your IP might be "public", it doesn't mean that it's wide open either!
NAT is NOT meant to be a security feature. Basic filtering still applies!
You are correct, and I never meant to imply otherwise. Here's why I need NAT regardless of IPv6 -- there is more than one box that I want to be able to contact from the internet, but I don't want the IP address of those boxen to be exposed to the internet (by "exposed, I mean both that it shouldn't be possible to contact it directly and that it shouldn't be possible for anyone outside my LAN to see that IP address is even in use). What I want is to have a single IP address that is used for incoming internet traffic, then my router directs it to wherever it needs to go.
NAT accomplishes this. I can also accomplish it with other router rules -- but in doing so, I've really just implemented a NAT via a different mechanism.
NAT is not firewalling and firewalling is not NAT.
Just because NAT happens to achieve some parts of firewalling doesn't really make it an acceptable substitute and relying on it as a security wall is asking to be reamed - anything that gets behind your NAT wall can tunnel out and render your entire security model useless.
Still they can't easily map how many devices are behind the fixed IPv4, and which makes a given request (without deep packet inspection) - it becomes more feasible with IPv6.
With IPv6 some older devices and OS may also burp out their MAC address - making them observable even across networks.
In v6 you'll most likely be using privacy addresses, which randomize the host part of the address regularly. This obfuscates the number of active devices and the identity of each device, if in a slightly different way to NAT.
And there are far easier ways to track you, such as browser cookies. Those work across completely different networks.
Not all traffic is HTTP, and even if it's HTTP, it may not happen within a browser.
Auto-generated addresses work better when people don't have to find and talk to their own devices - setting up IPv6 for creating proper DNS entries and work flawlessly while devices change addresses may require the proper setup - and not always people can own a device that automates it.
The risk is people follow some Internet advice to set identifiable addresses so they can find and use their own devices on a LAN.
If you are a network administrator or sysadmin can you think of any issues with hosts who constantly change their IP address?
Troubleshooting becomes a laborious job and incident forensics (even simple forensics) becomes a lot more difficult.
This has been discussed numerous times such as here: https://www.internetsociety.org/blog/2015/02/ipv6-security-myth-5-privacy-addresses-fix-everything/
That's why I'd prefer DHCP-generated addresses, coupled with DNS registrations - that way it could be easier to match logs and identify who had a given address in a given moment. Letting the client generate its address may have looked cool in 1996, but it's less compelling today. Router could still update related logs, but when you can have rogue clients you'd like more control.
My own computers need to know where my printer is and how to contact it [192.168.0.131 if you are wondering]. The rest of the world doesn't need to know it even exists and definitely shouldn't be able to contact it. The fact that I've just put its IP address on a public internet forum isn't going to help you at all.
Very easy to arrange in IPv4, but how do I do this in IPv6?
Ahh, the "my device has a single address" mentality combined with referencing devices by IP addresses.
I reference my printer by its name, which resolves to its link-local address. Although, I could use the link-local address directly as it is static and won't change even if I renumber my network.
You can't run IPv6 safely without a firewall. While scanning an IPv6 is not feasible, there are other ways to try to guess or get the addresses. Evidently if your printer does not need to be available outside it won't have a firewall rule saying otherwise.
Just hope you didn't enable some 'web service' on your printer, because ot could make it vulnerable even from a private address, like the thousand of IoT devices p0wnable have shown.
"The real issue today could be privacy - when NAT is not used it would be far easier to map an internal network by observing the packets addresses, and if addresses are not generated with a good random algorithm, and changed after some time, each device has an observable unique ID."
In that situation use DHCPv6 with a suitably short lease time on IPV6 addresses to internal hosts, and a suitably random address allocation algorithm, in preference to SLAAC. But this won't protect your host privacy against higher level attacks which are IP version independent, such as HTML Canvas browser recognition etc, and if you're that concerned about privacy you should probably be using TOR in any case.
Without any need of going TOR - there are many shades of privacy. We've seen data hoarder employ any technique they can to build profiles. There's a risk to make their life easier (and our worse).
Remember that not all traffic is HTTP/HTML - but if they can get your address from HTTP/HTML traffic - as you note - then they can match it to all the non-HTTP/HTML traffic until the IP changes as well. It's another source of information which could be easily exploited. If they can identify you from non-encrypted traffic, they can track your encrypted traffic endpoints, for example.
Before Google and Facebook (and the whole business they spawned) nobody would have really worried about it. Today, it's a bit different.
"when NAT is not used it would be far easier to map an internal network by observing the packets addresses, and if addresses are not generated with a good random algorithm, and changed after some time, each device has an observable unique ID."
This is really my only problem with IPv6. When I shift my LAN to IPv6, I see a fair bit of work necessary (including making sure I have a working IPv6 NAT) to ensure that I can both have static IPv6 addresses on my machines and that those IPv6 addresses are not visible to the internet (not just that they aren't reachable from the internet). That's enough work that I will put off making that transition until I have no other choice.
This post has been deleted by its author
"What happened to IPV5?"
IPv4 was a hacky kludge designed to last as long as it took for the "real" internet protocol that was being developed by Novell to roll out.
We know it as IPX (Internet Protocol Exchange) - and it's extremely difficult to route, which is why everyone stuck with IPv4
IPv4 was originally intended to use the first octet to show the SITE, second for local destination and 3,4 for local networking - whilst there are 4 billion possibilities the intention was a few thousand hosts at most and 10-20 routes.
IPv6 does something similar: the first section is country/major network, second= suballocation, etc all the way down to the /48 point. This means instead of _millions_ of routes that we see in IPv4 backbones, it will reduce to a few thousand.
Sparseness is good. It's an addressing table, not a stuffing competition.
I don't know why you *FEEL* (not think) that "it's not going to happen" based on slow adoption by ISPs...
seems to work fine for me. I have had an IPv6 tunnel for YEARS.
Aside from that, a big problem _might_ be the way IPv4 is allocated. Setting up a /30 for everyone is kinda *stupid*. If you have less than a /28 you should be forced to use PPPoE or some similar method to get your IP address assigned. That would effectively free up a good percentage of the "taken" addresses...
/me points out that if the pipe is good enough, you don't NEED a /30 netblock to get that extra 5% or 10% bandwidth. It's just wasting 3 IP addresses for every one being TRULY used. But it's easier for an ISP to *CLAIM* you get a benefit when you do it that way. And in the process, 3 IPv4 addresses are wasted to get YOU "the one".
let's focus on THAT, too. Raise the price for a /30, or give a price break to use PPPoE or some similar tunnel method that only uses 1 IPv 4 instead of 4 of them.
(yeahTHERE's your problem!!!)
Nat started as a solution to a difficult problem of IP address availability. However it has become so seamless, easily understood (without even needing to understand the underlying mechanism) and provides workable quick setups especially with dhcp that the idea of switching to dedicated addressing, needing changes to every networking device and support from all suppliers and vendors makes switching to pure IPv6 a 'task for another day'.
Sure there are workarounds and dual stacks and encapsulation etc but seeing as IPv4 for everyone (who has enough public IPv4 addresses already) just works, is well understood by the whole IT team (and even most users) there is an obvious reluctance to press go on that project until it becomes necessary.
> at home I've got plenty of choice over suppliers and equipment
So you're concerned enough to switch ISPs over it. But if you take shelter under a tree during a thunderstorm, you can't simply move over to the next tree once the first one is drenched.
And if you've never had an RFC1918 clash on a VPN (or M&A) at work, consider yourself lucky.
Sheltering under a tree during a thunderstorm won't dry you out if there's a lightning strike.
The lightning boils the sap under the bark, making steam and usually causing the outer layer of trunk trunk to go off like a giant firecracker. If you don't get pulverised by the supersonic large sheet of bark you'll get some pretty nasty steam burns.
A similar fate awaits those who keep sticking with IPv4 and refusing to make plans for IPv6.
CGNAT is crap and if you don't have (and understand) IPv6 on the day you need it, your business is going to suffer.
0) It looks that the IPv6 vs IPv4 arena is still very much active. Allow me to update you about our efforts in not only prolonging the life of the IPv4, but also transcending it to be the backbone / infrastructure for multiple new collaborating worldwide digital communication systems.
1) Please have a look at the following presentation file. The graphics pages should be sufficient for providing you a pretty good idea about the scheme.
2) Appendix C. of the following IETF Draft describes what we have done and where we are.
3) We look forward to your thoughts, comments, etc.
Abe (2019-08-27 17:45)
In case anybody cares, I looked at this draft the last time it was posted and came to the conclusion that it's more or less a rehashing of methods that already exist in v6 (that is, 6to4 and NAT64/NAT46).
Like I said earlier in this thread, people's ideas seem to be either impossible or already implemented in v6. This one happens to fall more into the latter.
1) It would do everyone a big favor if you could browse through the presentation. It has been streamlined from the earlier version which attempted to be diplomatic but resulted in too many logistic turns that clouded the perspectives. The current version in response to audience reactions has nothing to do with any concepts related to V6. In fact, it is a simple RFC791 implementation (then, degenerated to the basics) whose timeline was around 1981!
2) In addition, please check the credentials of the authors of the only other Normative Reference cited by the IETF Draft. Ten years ago, they were just one small step shy of what we now propose.
Abe (2019-08-31 16:49)
Yes, I did recall you read the Draft previously (last year?), That was why my initial comment this time was phrased to acknowledge so. The fact of the matter is that the Draft is a formal document that tried to cover the technical aspects of the EzIP proposal from all bases. Although several senior networking colleagues and marketing people got the message, it turned out to be hard for at least two general categories of audience, those who do not know communication at all, and those who are too involved with IPv6. We learned this through various feedback situations, not just from this forum. So, the new presentation was distilled through the technical twists and then just focuses on conveying high level concepts. I believe that if we can to reason through this high level of perspective, then the technical details / specifics will be easier to discuss. Thanks.
Abe (2019-09-01 10:56)
1) " already have wide deployment.": Please have a look at the following constantly updated worldwide "deployment" statistics. It seems that we are not close to critical-mass yet:
2) In addition, the following actual traffic distribution is even move enlightening (It is hard to see the IPv6 contribution with the scale used in the graphics. You need to read the numbers in the tables below them.):
Abe (2019-09-06 09:07)
My "wide deployment" comment was referring to the things necessary to support a network of the type described in your draft/presentation but using existing v6 transition tech -- mainly that's support for v4, v6, NAT64 and NAT46 in ISP gear, CPEs and client devices. Those are either supported by almost everything or (in the case of ISP gear and CPEs for NAT64/NAT46) supported by enough things that you shouldn't have any trouble getting equipment for them if you want to.
I've looked at APNIC's stats many times, but what they track is the percentage of clients that hit their measurement servers over v6. As it happens, that's not a useful stat when it comes to tracking support for any of the above.
As for the AMS-IX stats, I already explained to you why they're not an accurate measurement of the overall amount of v6 traffic on the internet, but they're also not a useful stat for tracking the above things either.
1) "the percentage of clients that hit their measurement servers over v6 .": Where and how did you get this impression of a limited scope? It is true that this kind of restriction applies to the commonly known "Google's IPv6 traffic statistics", but not the ones that I cited. As far as I know, both of these are really based on "as much overall worldwide as possible" Internet traffic, not any subset of something.
2) I can not tell you my source at this juncture, because the sensitivity. But, I was referred to these by a well-known and very knowledgeable person whom I requested for worldwide statistics to get some insight of the IPv6 status. He stated that these are the only publicly available data that are constantly collected from the largest possible base (i.e., not necessarily everything, but close). If you look at the organizations that are sponsoring these, you will get some idea why they can do these.
Abe (2019-09-07 16:09)
APNIC's methodology is explained here: https://labs.apnic.net/measureipv6/. AMS-IX's graphs are obviously flow statistics from their network only.
Your source was right in that these (plus Google's) are the best publicly available statistics, but they won't be of any use to you if you don't understand what they're measuring.
1) "https://labs.apnic.net/measureipv6/.": How did you find this? Could you please explain how does it work? It appears to be a somewhat manual operation. If so, it would be very difficult to get the volume of test data implied by in the statistics that I shared.
2) "AMS-IX's graphs are obviously flow statistics from their network only.": Yes, As I stated, I was told that this is the largest publicly available statistics. AMS-IX is the third largest IXS:
and their total traffic volume about 4 Tbps is shown at:
So, statistics from AMS-IX is the best possible source for getting some idea about the behavior of the overall Internet traffic.
3) What is the traffic volume that your statistics is based upon?
Abe (2019-09-09 00:08)
I found it by Googling for "apnic ipv6 measurement". There's a more detailed explanation here: https://labs.apnic.net/?p=348.
AMS-IX are the best available public statistics. They're nowhere close to the best possible -- in fact the measurement they make is fairly useless in working out where v6 deployment is at. It misses out on on-net caches (which will be mostly v6 where available) and private peering (again mostly v6 by volume), which apparently account for something like 75% of ISP bandwidth between them. It counts large parts of the traffic from v6-only ISPs that use NAT64 as being v4. It's measuring at the wrong place to figure out what percentage of servers or clients have v6, and it's completely incapable of showing how readily available v6 support is to the people who aren't yet actively using it.
These are not very useful stats, unless your goal is to cherry-pick something that makes v6 deployment look bad.
> 3) What is the traffic volume that your statistics is based upon?
I don't know. But the volume doesn't matter if it's not a representative sample or if you're not measuring the right thing.
IPv6 was a mistake and most users know it. Friends don't let friends use IPv6.
Most young whippersnappers these days, who weren't around back then, don't know how IPv6 happened. It was not one of the IETF's prouder moments, if there even is such a thing. During the 1980s, the OSI project forked two different network layers, one based on X.25 and favored by PTTs and IBM, the other connectionless (CLNP) and favored by most other computer companies. CLNP was very much an internetworking protocol, which had learned from the mistakes of 1978's TCP/IP v4. It was being rolled out in most routers of the day (late 1980s-early 1990s). And ca. 1991 IAB adopted a profile of it, called TUBA, as the next IP. But the k1ddi3z of the IETF viewed OSI as The Enemy, and CLNP's OSI taint, even though it came from the friendly side (mainly DEC), made it unacceptable. So Vint Cerf changed his mind and withdrew support for TUBA and the IPv6 effort began. The "A team" working on "IPng" quit, and an effort coalesced around a B team. Their charge was not to fix any flaws in IP (security? fragmentation? aggregation? multihoming?), just raise the address size. And they came out with IPv6. I call it Children's Crusade Protocol because it is foolishness accepted only because it comes from an undeserving "authority".
A better path would be RINA (Recursive InterNetworking Architecture). See the Pouzin Society, IRATI.EU, or other sources to learn about it. It uses one layer mechanism recursively, as required, not a fixed size stack. It can encapsulate IP or be encapsulated in IP, so it is much more compatible with IPv4 networks and easier to adopt than IPv6. It just doesn't have commercial-grade implementations yet. But as a true clean slate approach, it shows that the IETF has gone off in the wrong direction for years.
This "technology" dates from before these young whippersnappers were born, and from when I was a young whippersnapper myself; ie a very long time ago. Its contemporaries were things like Novel Netware, SCO Unix, Compuserve, fax machines, floppy disks, VHS video recorders, Walkmans, analogue modems, four star leaded petrol, "all your base are belong to us" gif animations, "punch the monkey" Java adverts - things that you now find in museums and history books.
The idea that IPv6 is some new technology that people should adopt is a frankly ludicrous suggestion.
There is absolutely no need for NAT, it breaks things and is not a security feature. If you want to block inbound connections then any firewall or router can do that with ipv6 (and home user oriented devices do this by default).
Unless your network is tiny, managing ipv4 is a nightmare - there was a post by microsoft a few years ago about migrating to pure ipv6 to avoid this hassle - address conflicts, duplicate addresses, multiple layers of address translation making it difficult to set firewall rules or correlate logs.
It's even worse in third world countries, where the prevalence of CGN causes all kinds of headaches - you'll quite often find yourself being blacklisted by google etc, or having to fill out captchas because some other user behind the same shared address did something.
The problem is that most users aren't aware of ipv6 or what it is, so there is no demand for it. Prominent companies like google and facebook need to promote ipv6, for instance offering beta features to ipv6 users first or displaying a warning banner when users connect to their services from legacy ip. If users start asking their ISPs for ipv6 en masse and moving towards isps which already support it you will quickly see support expand.
"If users start asking their ISPs for ipv6 en masse"
But why would they? The only thing the vast majority of users would care about is if they can get to the internet. They wouldn't notice whether or not they're using IPv6 to do so. There is no reason why most users would demand IPv6 specifically, they'll only demand that their internet connection works.
IPv6 is really only an issue of great importance to ISPs and users of numerous IP addresses.
"If users start asking their ISPs for ipv6 en masse and moving towards isps which already support it you will quickly see support expand."
The fallacy that has plagued IPv6 from the beginning is the belief that increased support for users or increased support on services somehow reduces the need for IPv4.
It doesn't. As long as there are any commonly used services that are only IPv4, or any users that have IPv4 only, ALL users and ALL services will have to remain to be IPv4 enabled.
It does, though? It reduces the amount of CGNAT hardware the ISP needs to provision. I think for EE the figure was something like 70% of their traffic flows over native v6, which cuts the costs of their CGNAT infrastructure by two thirds.
Having v6 also means that the v4 doesn't need to work as well -- being behind CGNAT is a lot more okay if you can side-step it. Also, in many cases you don't need v4 on the client side. For their v6-capable users, EE provide no v4 service on the network. T-Mobile in the US is the same.
(The server side is a little trickier. I do run most of my own personal services over v6 only, so it's certainly doable.)
IF IPv6 had been designed by engineers - not theorists then it would have been a simple extension of IPv4 with a longer address field and all IPv4 addresses would be directly mapped to a (small) subset of the IPv6 address range. If this had been done then IPv6 would have been widely accepted many years ago.
Do NOT let theorists be in charge of DESIGN - leave that to engineers.
Yup. I remember the early RIPE meeting presentations and the non-academic attendees (I was there on behalf of Demon at the time) watched with open mouths as they - the tenured masses - simply didn't get it, couldn't understand why it would never work. My favourite still: Multi-homing with BGP? Not needed, surely!
I'm afraid it was designed by engineers, that's part of the problem. In fact, there were several competing designs.
The Internet Architecture Board, whose job would normally have been to herd the cats, had proposed using the OSI Connectionless Network Service as IPv6 (it had all the functionality required at the time). This caused uproar at the IETF as:
1) ISO/OSI standards were considered the work of the devil
2) DEC had largely driven development work while SUN and cisco engineers were dominant in the IETF
3) Not Invented Here
The IAB were largely sidelined and the engineers were left unsupervised which is why we are where we are today. And I say that as someone who has spent a large part of my life engineering network software.
Incidentally, all IPv4 address can be directly mapped into a subset of the IPv6 address range, depending on how you choose to do your addressing. It doesn't actually help in any way, especially now that total IPv4 addresses don't even fit into the IPv4 address range.
It doesn't actually help in any way, especially now that total IPv4 addresses don't even fit into the IPv4 address range.
They have 128 bits in IPv6, they would be easy to fix. xx:xx:xx:xx = real IP address yy:yy:yy:yy IP behind the NAT zz:zz:zz:zz:zz IP behind the second NAT.
Figure out a prefix to indicate IPv4 NAT pass through, and an extension to IPv4 NAT to handle such "IPv6 passthru requests" (so you have to configure them, thus preserving security for unconfigured NAT)
Since zz:zz:zz:zz for the second level NAT would would rarely be used, as an option it could provide some minimal security via a challenge response where that 32 bit value is a pseudorandom seed value to allow the remote NAT to send a challenge packet and the IPv6 end send the appropriate response.
But yeah, overall I agree with those who say IPv6 is a lost cause. I always disable it on anything I can. I think my ISP can do it, I haven't checked for years, I just don't care. A 64 bit extension would have made so much sense, it never made sense to me why they went overboard with 128.
You mean like 64:ff9b::xx.xx.xx.xx? We did this. It's a thing you can use, and it works -- it lets a v6 host connect to a v4 host, and it lets the other direction work too if you configure a port forward for the connection (so basically the same as NAT, just with v6 instead of an RFC1918 v4 address).
Why do people keep saying it doesn't exist?
"A 64 bit extension would have made so much sense, it never made sense to me why they went overboard with 128."
Do you know how hard it is to deploy a new IP protocol? That's why they went overboard: so we don't end up needing to go through this a second time.
A new IP protocol most refuse to use is not better. Had they simply added two octets and made 0.0.x.x.x.x map to IPv4 probably everyone would be using it today. Sure maybe in some far future day when IoT really does mean tens of thousands of devices per person (that somehow all need to be directly addressable around the world) it would need to be extended again, but so what. The guys who were doing the extension in the 90s would all be long dead by then. That's better than the hubris required to think you could create a protocol that would serve "forever", as if the only reason to change protocols 50 or 100 years down the road is the number of bits.
What I'm talking about is a way to tunnel through an IPv4 NAT, which 64:ff9b doesn't do. And why the HELL would they choose such randomly useless numbers like that? What's wrong with 1:: or 64::? That's a perfect example of why no one wants to use IPv6, talk about making it user hostile!
64:ff9b:: is checksum neutral, so packets can be translated without needing to adjust the checksum on them (0xffff - 0x64 = 0xff9b, and the rest is all zeros). Since you don't generally deal with IPs directly it's not critical for the prefix to be shorter, while performance is important.
> Had they simply added two octets and made 0.0.x.x.x.x map to IPv4 probably everyone would be using it today.
You clearly didn't think any part of this through. Two extra octets isn't enough, and how would the mapping benefit anybody? How would v4 hosts send packets to the IPs outside of 0.0/16? There are multiple mappings of v4 addresses into v6, but none of them enable v4 to talk to more than 32 bits of hosts, because v4 isn't capable of it -- and v4 will still not be capable of it regardless of the design of the other protocol involved.
Who cares about being "checksum neutral", what a stupid reason to design something that's user unfriendly! Computers work for us, not the other way around!
Two extra octets gives you 65535x bigger address space. The v4 hosts don't need to contact all the "extended address" hosts, they would be in their own world, and a dual homed interface (like how IPv6 works now) would let them communicate with the outside world using the new 6 octet scheme.
People who care about performance. And yes, computers work for us and not the other way around, which is why you let DNS do the heavy lifting rather than manually dealing with IP addresses. Otherwise you're just doing the computer's work for it, which is backwards.
That prefix is actually just a default, though. If you're setting up your own NAT64 router and you want to use another prefix, you can.
> The v4 hosts don't need to contact all the "extended address" hosts, they would be in their own world, and a dual homed interface (like how IPv6 works now) would let them communicate with the outside world using the new 6 octet scheme.
Okay, so the mapping wouldn't actually do anything that we don't already have in v6. As such, it seems unlikely it would be much different to v6 in deployment time either.
"Had they simply added two octets and made 0.0.x.x.x.x map to IPv4 probably everyone would be using it today."
Spoken like someone who doesn't realise that the original intent of the octets was to show LOCATION in the first 2 bytes, not stuff as many IP addresses as possible into as few bits as possible.
Having longer prefixes makes things EASIER, not harder, as it cuts down the size of the routing tables dramatically. There are millions of IPv4 routes on the core networks today whilst the equivalent IPv6 implementation would only need a few hundred to a couple of thousand.
Having had to USE x.25 and X.400 addressing for many years before I came to the internet side of things, I can understand why the networking committee ran screaming into the night when confronted by it.
IPv6 isn't perfect, but it's a lot better solution than IPv4 and CGNAT - and perfect is the enemy of "good enough" - if you keep striving for perfect you'll never move off IPv4 despite it being manifestly unusable in many parts of the world - WE might not notice how bad it is, but I can assure readers that when you're in the wilds of Myanmar behind _3_ layers of CGNAT (I've done this many times, my wife is Burmese) things don't _turn_ to shit, they're simply shit all the time - that "1 IP for every 2600 citizens" in practice is more like 1 IP for 12-15,000 people (and the ISPs have never heard of IPv6)
Not so easily. From a pure mathematical point of view, sure. From a network one, it's far more difficult.
How do you map the network part and the host part of any IPv4 address into a IPv6 address - and still being able to route it properly to destination? One of the design goals of IPv6 was to improve routing and its performance.
To the extent that a new protocol has to interoperate with IPv4, that problem would exist with any replacement. The key is how long that replacement needs to be supported. With IPv6, the answer is effectively "forever". With a better designed replacement people actually wanted to use, we might have been able to phase out IPv4 in our lifetime.
"Do NOT let theorists be in charge of DESIGN - leave that to engineers."
sometimes true, NOT in this case. although 'any to any' routing is a bit much in SOME cases, in theory you could simply adopt a *modified* version of IPv6 that simplifies the routing of /64 or /48, then apply "any to any" for the remaining bits.
That's simple enough, right? But with netblocks being what they are these days, aren't we already at an "any to any" route (in practicality) for IPv4's ?
I just look at how IPv6 works on my LAN and over a tunnel, and I'm not seeing "all these problems" with it. Aside from ":some stupid wifi router" implementing IPv6 routing aggressively [forcing me to plug an ethernet cable between the WAN and one of the LAN ports to compensate] I see it purely as a problem with implementation rather than the actual protocol itself.
Do it right and everything works. DO it wrong and you have problems. Old routers "doing it wrong" sounds like "the problem" to me, and NOT the protocol design.
/me has had no trouble setting up FreeBSD to route IPv6. Ancient 2.6 kernel routers, on the other hand...
Problem is, there just isn't any other proposal that would allow seamless interoperability and migration in a way that would allow users or services to drop IPv4 support during a transition phase.
It's easy to say that the problem is that IPv6 was designed by theorists, but there's no alternative that doesn't have the same fundamental flaws, full stop.
Last time I checked the /24 I picked up in the early 90s would go for $4000+ on the open market. Now that they're on allocation, I guess it is an appreciating asset. If IPv6 ever looks like it might take off I guess that will be the peak for IPv4 addresses and time to sell.
I could have picked up a class B back then, that would really be worth something, though I suppose they would probably have taken it away years ago unless I could demonstrate it was in active use.
Just get the older companies to hand back the large swathes of addressing they are sitting on. I know several companies which have /16s and use only about 500 addresses or so. You used to be able to get whatever you wanted with the RIPE justification form being a formality.
Or start charging for address space. £500k/month for a /8 on a sliding scale down to £5k/month for a /24. That would soon release space that's being sat on and those that need a /8 like ISPs, Microsoft, Google etc can easily afford a high cost because a /8 can enable generation of so huge revenue.
Before IANA runout (almost a decade ago now) we were going through more than one /8 per month, and demand has only gone upwards since then. Reclaiming unused parts of old allocations would buy us a couple of years at best.
And then what? We'd still have to do v6, and anybody who isn't doing it yet isn't suffering from a lack of time; they've had plenty of that. So what's the point? It'd be a massively disruptive and costly exercise to gain us a small amount of extra time which we would then squander. Put that effort into v6.
The UK needed more phone numbers, so they added a digit.
Why didn't they do the same with IPs? So instead of 10.10.10.10 you have 10.10.10.10.10? Takes you from 4 billion up to over a trillion addresses available. Surely it would've been easier to update everything to handle an extra octet? Need more still? Add a 6th octet.
No, not joking. Legacy systems are all well and good, but EVERY other industry in the world modernises when new needs arise.
People complain about IPv6 because it requires a complete redesign of their networks. So, a suggestion is to not have to "completely redesign" them, but extend existing concepts - just like every other industry does.
Those downvoting me - what is your suggestion, because as far as I can see there are very few options:
1. Run out of IPv4 addresses - this has pretty much happened
2. Roll out IPv6, and redesign everything to handle it - including those "legacy systems" that people so keenly cry about constantly.
3. Come up with an easier solution that doesn't require a complete redesign of how networks work.
From what I can tell, people here seem to want things all ways - they want IPv4, they want it to be replaced with something that doesn't require work, they don't want to replace legacy systems. Remember, those legacy systems that only support 32 bit addresses won't support IPv6 anyway!
Its basically Brexit, but with IP addresses - you want unicorns.
To my naive eyes, extending the address space without heavily modifying the protocol should be possible: use the reserve bit to indicate it's an expanded packet and then include the address in the options data area. Older systems would still have to be patched, of course, but not to the degree that completely replacing the protocol requires.
Doing that would have broken the existing ipv4 network and caused significant headaches until the new (ipv4.1?) patches were rolled out everywhere... You would have a mix of systems with some being compatible and some not, some things would never have got updated.
It would also have made the implementations much more complicated, and thus slower and more difficult to do in hardware (high end routers generally implement the routing logic in asics).
The idea of ipv6 is that it's pretty painless to go dual stack, which should have been an obvious thing to do. Any modern OS will prefer ipv6 if available, and revert to legacy ipv4 if not. Pretty much all legacy kit that was around when ipv6 was first introduced has been end of lifed by now. Windows has had ipv6 support since XP for instance.
IPv6 is simply better, i build all networks as dual stack or ipv6-only, and i only use ipv6 internally. It makes many things much easier, you have end to end connectivity controlled by simple firewall rules rather than multiple messy combinations of rules and nat, your logs show the individual endpoints without having to correlate address translation, i can establish vpn connections between multiple independent sites and third parties without suffering address conflicts. Every system on my network is directly addressable, assuming there are firewall rules in place to allow the traffic, and the rules are simple because of that - no need to worry about multiple hosts hiding behind a single address etc.
It's like the transition from the messy days of segmented memory on dos and earlier systems, to the simple flat 32 or 64bit address space on newer systems.
That still requires you to do almost everything that v6 requires you to do. It may save you some code in the IP stack, but that's the part we're not having any trouble with. You still have to update protocols, patch all your software, configure new addresses, firewalls etc, and those are the parts we're having trouble getting done.
And v6 has a mode that works like that! You can put a magic number (41) in the protocol field to indicate that the packet contains v6 addresses, and then the v6 addresses go after the v4 header. People doing v6 deployments seem to strongly prefer running it natively though.
"Remind us again why the IETF didn't make IPv6 backwards compatible… ®"
They did; you can talk from v6 to v4 in the same way that you can talk from RFC1918 v4 to public v4. But they didn't make IPv4 forwards compatible, and that's something we're stuck with -- the only way to fix it would be to deploy an update to v4, which is what we're doing with v6.
Did you really need yet another reminder about this? *reads comments* apparently El Reg's readers do, at least.
Then you're simply ignorant. Which is fine, because we can't all be experts at everything, but you need to realize that it limits how much useful insight you can have on this issue.
You cannot just "add an octet" to v4. v4 is hardcoded to a fixed address width of 4 octets. The header format is hardcoded with 4 octets for the src and dst addresses, and every single device out there (billions and billions of them) have v4 stacks which are hardcoded for 4 octets.
The telephone network is completely different. Telephone numbers have been variable length since the very beginning, which makes it easy to add extra digits. IPv4 isn't like that, at all.
So what can you do? You can deploy a new IP protocol version which has bigger addresses... and that's exactly what we're already doing.
> People complain about IPv6 because it requires a complete redesign of their networks.
These people are wrong. It doesn't require a complete redesign of their networks. v6 is almost completely identical to v4 in most aspects, including network design. Subnetting and routing in v6 is identical to v4, and the way you design your networks with it is also the same. To get v6 onto your existing v4 network, you just put it there alongside the v4. Your router gets a:b:c:d::1 as well as a.b.c.1, and your hosts get a:b:c:d::x as well as a.b.c.x. Firewalling works the same. You use TCP and UDP like you do in v4, and those work the same too. No redesign is needed.
It didn't have to be this way. There were various proposed alternatives for next generation IP which had variable length addressing, a different routing model or more weird and wonderful features, but we went with a protocol that worked the same way as v4 did.
> 3. Come up with an easier solution that doesn't require a complete redesign of how networks work.
As mentioned, this is what we did. But you're right, people want a unicorn. Even when you do the exact things they suggest, they still complain.
You are again defining a potential extension of IPv4 in terms of what IPv4 is now. That's like saying "we can't put a door here because there's no door here!".
Whatever solution was pushed forward necessitates updates to kit. Arguments about how IPv4 works *now* being broken are, to be frank, irrelevant. There is no technical reason why it could not have been extended. That's the reality of it. Old kit needs updating regardless - all billions of bits of kit.
Your argument that people are wrong is also one of theory - you theorise that they are wrong, but you do not have knowledge of everyone's networks. You don't have knowledge of every ISP and how they're handing out IP ranges. You theorise that "these people are wrong".
IPv6 does the job, but it is certainly not the best solution to the problem. If it were, we wouldn't have an uptake problem.
So what sort of network would require a complete redesign for v6? I'm sure there's something out there somewhere, but it's not common. People that incorrectly think that v6 would require a complete redesign of their network are a lot more common.
> IPv6 does the job, but it is certainly not the best solution to the problem. If it were, we wouldn't have an uptake problem.
Your second sentence doesn't logically follow from the first. It's entirely possible that the best solution has an uptake problem.
As far as I can tell, it's impossible to make a solution without an uptake problem, and it's my humble opinion that being impossible disqualifies a solution from being the best solution, on virtue of the fact that we couldn't actually do something that's impossible.
To be clear, my basis for believing that it's impossible is that (a) current v4 doesn't support bigger addresses, (b) any method of upgrading it requires lots of people to do something, and (c) it's the "require lots of people to do something" part that causes the problems in uptake.
Lots of people think they have a way around one or the other of those, but their ideas always seem to be either impossible or already implemented in v6.
(As always, you could easily change my mind by giving me something that doesn't fall into one of those categories. But if your idea is "just add another octet" or if it involves pointing me to dozens of pages of draft text, expecting me to read it all and decipher your idea for you and then spend weeks dancing around explaining it to me when I conclude that you've just reinvented something that already exists and ask you to explain how it's different... then you're probably not going to have much luck.)
IPv6 is here. Any business ISP can get you IPv6 connectivity. Many residential ISPs do it by default (but granted not all).
There is much gear that supports IPv6 natively.
What doesn't do IPv6? People. Especially Enterprise/Business Techs.
That is the number one factor. They see no need. They don't bother learning. They don't bother doing. "I don't need it, I don't want it, I don't use it." Stick their head in the sand, no problems here, no need to do anything.
Just about everyone on their smart phone has fully IPv6 connectivity right now.
My home ISP does IPv6. My mom's home ISP does IPv6, and her computer is fully IPv6 connected without her knowledge.
But in 99% of the enterprise businesses I deal with, even though they could enable IPv6 on their firewall and do it, they do not. They see no need, so they don't enable it.
So ISPs have to go to extraordinary measures, like enabling CGNAT. I do not know how much time I've spent dealing with CGNAT issues. Constant breakage. Constantly dealing with slow downs, and all the rate limiting they have to do on their gateways. I tell the customer to get away from the ISP that has to do CGNAT. They don't. I tell them lets try IPv6, and see if all the content you want can be gotten natively. They don't.
I think the only event that will force enterprise adoption of IPv6 is if Facebook or Slack went IPv6 only. That might make the people learn quickly.
Why would anybody believe that a different protocol than IPv6 that will take another 20 years to adopt would do any better? Anything that makes people change what they are doing is not going to be adopted unless it is done for them.
"That is the number one factor. They see no need. They don't bother learning. They don't bother doing."
Or, to use the adage, "If it ain't broke, don't fix it." Their infrastructure is based on IPv4, is probably pretty comples, and likely contains enough essential legacy hardware that moving forward is an issue. And without an IPv6 internal network, accessing the IPv6 Internet is going to likely involve additional hardware and definitely some additional jiggery-pokery that invites Murphy's Law to strike.
So if you want them to migrate, allow them a way to do so without having to do any of that with an essentially turnkey solution.
At this point the only mainstream ISPs in the UK _not_ offering IPv6 are TalkTalk and resellers of their wholesale service.
It's about time Ofcom and/or the ASA clamped down and said that to call themselves an ISP, they have to offer IPv6 or it's misleading advertising.
As an internet consumer, year's ago I moved to add IPv6 capability, just as quickly as my ISP Comcast supported it. Since then IPv4 / IPv6 addressing and routing have been completely transparent to me. There is a clear path forward for all companies impacted by an IPv4 address shortage: support IPv6.
What's the problem here?
Because, for the Nth time, IPv4 was designed with no provision for forwards compatibility. The address length was set at 32 bits, and that's all. So from the very beginning, longer addresses required a new version. (Actually, of course, there was a version number in the first place. So you could say that the version number is the forwards compatibility feature in IPv4. But it doesn't solve the problem that 32 bits is 32 bits.)
IPv6 wasn't designed by theoreticians. It was designed by people working with IPv4, DECnet Phase IV, Novell Netware, and Appletalk, to name but four. Plus people working with OSI and DECnet Phase V. Plus people working with IBM SNA. It couldn't be backwards compatible because of the design flaw in IPv4, so the model from the beginning was co-existence. That's still the model, and it works well, except that now the plan is to provide IPv4 as a service over IPv6, when needed. (Except that isn't a plan, it's deployed already by various ISPs.) Anyway, 25% of the Internet is now IPv6, and most users don't even know it. Apparently most of the commenters here don't know it either.
I don't really understand why people bleat about the issues with IPv6 (yes, of course there are issues, but there are plenty of issues with IPv4+NAT) instead of just running it and making it work.
Because it takes people out of their comfort zone; that's against human nature, so the only way you're going to do it is to force it...and that'll just open up a market for those who say you don't have to.
PS. If IPv4 wasn't designed to be forwards compatible, what's the Extension Bit for?
Perhaps it would be more accurate to say that v4 as currently specified and implemented everywhere is not forwards compatible with bigger address spaces.
It has multiple places where that forwards compatibility could be added: the version field, option headers, the reserved flag or even a reserved src/dest IP address. (Of those, v6 went with the version field for native operation and the protocol field for operation over the top of v4, which makes sense because that's the intended use of those fields.) But all of these options require upgrading hosts, routers, networks, software etc to handle them, so no existing devices will be compatible with the longer addresses, and none of them allow an unupgraded host to initiate connections to an arbitrary upgraded host.
At the point where you have to change v4 to support bigger addresses, can you really say that v4 is compatible with bigger addresses? Looking at the rest of the thread, it seems to me that "existing, unmodified v4 host can talk to arbitrary v6 host" is what people want, so it looks like their answer to this question is "no".
It might be more accurate to say that, but it's also an awful lot more words to type out every time.