Blockers to IPv6 Adoption
labs.ripe.net
labs.ripe.net
I was hanging out in the IPv6 mailing lists at the time the various solutions were being debated.
The prevailing attitude was "the Internet is about to die from routing overload without IPv6, so we can stick whatever complexity we want inside it, and they will have no choice but to accept it."
Except that new router hardware and new incremental software improvements came out, and the enormous complexity of the "boil the ocean" redesign inherent in IPv6 was rightly regarded as completely unnecessary.
If the IETF had simply made IPV6 "ipv4 with longer addresses", (and there was a proposal to do just that), implementations and deployment would have been dramatically simpler and would have stood a real chance of succeeding.
Instead we have this baroque construction, which I _still_ have to explicitly disable in my work environment because various bits of supposedly IPV6 software don't play nice together.
I was in the camp hoping for two octects at the beginning of the address (so they could be zeroes). Actually, a single i text would have taken us to a trillion IPs and given us enough time to think about the topic a bit more.
Large changes rarely succeed. Perl 6, Mozilla (back in the 1990’s) and others come to mind.
This is hard stuff, and we were made to swallow the kitchen sink.
Would you be happy if we renamed NDP to ARPv6? Or is your suggestion that we continue to use ARP and put a more-than-four-byte-address into a fixed-size four byte field?
> Broadcast was replaced by multicast.
So, in IPv6 you can only send packets to a small subset of recipients, whereas in IPv4 you could address a packet to "every IPv4 device on the planet"?
Or are you suggesting we should misname multicast in IPv6 as "broadcast" just as we did in IPv4 in order to solve which technical problem exactly?
For me as a home user, IPv6 seems like what you'd get when you ask a group of 6-year olds to design a concept car.
The things that ipv6 brings along that are not present in ipv4 are pretty inconsequential.
Virtually every related protocol (e.g. ARP, BOOTP, OSPF, BGP) was modified in non-trivial ways, the rules around different kinds of addresses (link-local, etc) are very different, IP-level encryption stuff started out mandatory (may not be anymore), various flow-control stuff was tweaked (and tweaked again since then to match the improvements in IPv4), rules for parsing optional header fields was tweaked, etc, etc.
I wonder if I could ask if there was any mention of a solution to expand IP address space in a manner similar to how UTF-8 expands as needed?
I'm not a SME on low-level protocols, but it seems the jump from 32 to 128 bits was an ambitious leap to future-proof and maybe a small part of the reason adoption is slowed.
I don't think the 128-bit length was ever an issue, that is just a field length, one parameter amongst many. It's all the other details that make a protocol (and it's surrounding infrastructure) more or less difficult to implement.
One of the contending proposals literally modified an existing TCP/IP stack with a constant in all the relevant places, and was then compiled twice. It had
#ifdef IPV6 #define ADDR_LENGTH 4 #else #define ADDR_LENGTH 16 #endif
and then you could compile the same source twice, once for each protocol, just passing a -DIP6 on the command line for the IPV6 version.
Most security-conscious people do the same.
> What's the solution? According to the authors, nothing short of a wholesale review of how network traffic is interpreted. Sysadmins need to look at how their security systems are configured to make sure they pick up any unusual traffic flows made using this technique.
https://www.theregister.co.uk/2017/04/10/ipv6_security_conce...
This is just one example of many IPv6 security threats.
Also, if IPv6 was a simpler protocol it would be easier for the authors of security tools to implement support for it.
IPv6 needs to be deployed today because the internet literally cannot move forward without it. There are tens of millions of new internet users in Africa and Asia who get an inferior and more costly service for the simple reason their countries weren't around for the great IPv4 feast in the 90s. The data-centers of the world waste enormous energy and hardware for routing the more and more fragmented IPv4 space. The costs of all this, as well as renting IPv4 addresses, which have steadily rised, are passed down to the consumers.
IPv6 should be sold as a status simbol: we deploy it because we care, we are altruist industry leaders not stingy bean-counters.
As a network engineer and enthusiast, I would do the same.
So much of the spec seems to have been designed in an idealist vacuum that the promoters are blind to its own failures. The addresses are ugly and impossible to memorize but that shouldn't matter because... There are no performance advantages but that was out of scope because... There are few security advantages because that wasn't a core goal because...
I'm not saying that we should give up on IPv6. But we should acknowledge that its slow adoption is entirely due to a standard that was poorly designed for the real needs of critical stakeholders and poorly marketed to everyone else.
The problems of adoption can be compared to the Python 3 debacle. When Python 3 was first planned, Python were mostly used by enthusiasts which would be quick to adopt a new version - even if it had a few minor incompatible changes. But when the release finally rolled out, Python had become much more popular and entrenched and widely used by business and scientists which were more reluctant to adopt breaking changes.
I see NO reason to deploy ipv6 at the moment. I don't see it for home lans, I don't see it for my workplace, I don't see it for bigger enterprises.
But you can have a gazillion IPs with ipv6!! Yeah, so what?
If your IPv4 address changes, you need to re-start the tunnel.
I ran a setup like this, but since the closest HE tunnelbroker end-point was 180+ms away I configured radvd to only advertise to the RIPE Atlas probe I was running at the time, so only my gateway/firewall and the Atlas probe were IPv6 enabled.
My ISP can't enable IPv6 because the last-mile ISP, who does layer-3 hand-over uses half-duplex MPLS VPNs for traffic hand-over (separate VPNs for each ISP), and the equipment (Cisco and Alcatel-Lucent BNGs) in use doesn't support Half-Duplex VRF for IPv6 (only IPv4). I am not aware of another last-mile fixed-line provider (there are quite a few here) that supports IPv6 at all. When I enquired with one of them, they indicated that it was on their roadmap (or backlog, they didn't have any idea of timeline ...).
the major one is a vastly smaller BGP routing table, which is becoming more and more of an issue.[1]
We need IPv6 to remove the horrible IPV4 space fragmentation.
But that's not a problem for me. It's a problem for my isp. And if he does not care, why should I?
Comcast seems like one of the largest deployments of IPv6 for normal consumers outside of the cell companies.
A /60 is pathetically small, with SLAAC you have 16 (!!) subnets for your whole network. With people having multiple computers and multiple phones, this is not enough even for a normal household of 3 people. If you are a IT person, with multiple computers and VMs, forget it.
The recommended size of block that every ISP should give is /48 (RFC 6177). Good ISPs will give you a /48, some lesser ISPs will give you a /56. Comcast and crappy ISPs will give you a /60.
I agree a /60 is stingy, but "not enough even for a normal household of 3 people" sounds like massive hyperbole. Even as a tech enthusiast filling that would be some work, unless you insist I use a /64 for point-to-point links.
Have you ever used VMs on a laptop? How many virtual networks do you need? Only one? With only one you only need one extra bit bit for routing, so you could give a /63 instead of a /64 to your laptop, except that IPv6 allocation is supposed to be done in nibbles (and you need to overprovison anyway, what if tomorrow you need two networks?), so the next logical step is a /60, which means your ISP should give you at least a /56. Personally, I use much more than one virtual network on my laptops, so I would need a /60 anyway (if I want to keep all the nice properties of IPv6, that is).
As long as you want to keep everything nice with IPv6, the block you need is /64-(4*n), where n is the level of routing you plan to do.
> unless you insist I use a /64 for point-to-point links.
Each p2p link on IPv6 uses a /64 (even though it's only assigned an /127).
> How does a household with 3 people need 14 subnets?
In the IoT era (where S stands for security), if you don't put each IoT device in its own VLAN, you are in for a surprise.
Very few, to the point of "if it's more than one, the other ones aren't intended be reachable and thus don't need public space".
> Each p2p link on IPv6 uses a /64 (even though it's only assigned an /127).
No, it doesn't, since my routers don't need to do SLAAC between each other, but can happily live with static IPs.
> In the IoT era (where S stands for security), if you don't put each IoT device in its own VLAN, you are in for a surprise.
Never felt the need to put each device in it's own subnet, sensible firewalling seems enough. I tend to avoid devices that really want to talk to the internet though, so most of the time it's "you don't get to talk to the internet"-subnet. But ok, if you love connected stuff and want to split it in very fine ways, that'd be a bunch of subnets.
So yes, as I said /56 would be nice and should be the default but /60 is likely to be enough for the vast majority of users.
I've got a larger then normal home router with 6 ports. I can have a /64 for each, and still have a bunch left over if I want to split up wireless into more secure, medium secure, less secure, and least secure networks.
I'm all for more address space, but I'm at a loss as to why a normal even a sophisticated home user needs more than a /60.
I wouldn't turn down a /48, but realistically I've got 30 or so IPs in use. Sure recently I added an IP for a wristwatch, TV, and a stereo. Clearly cheaper devices are getting Wifi. It's becoming more common in appliances, thermostats, door locks, electrical outlets, light bulbs etc. But 2^64 pennies is quite a bit, and I doubt anything will be consuming more than one IP per $0.01 of cost anytime soon.
A /64 can't be subnetted any more (one host, NO VMs!).
A /60 can support one level of extra routing.
A /56 can support two levels of extra routing.
If you plan to run VMs on your laptop, you need a /60 on your laptop, which means you need a /56 from your ISP. If you want to keep everything nice and future proof, that is, if you want to fuck up with special configurations, you can use your /60 from your ISP, and give a /62 to your laptop, then each laptop can have 4 networks for VMs. But that is limiting and a PITA to set-up.
Why not directly bind all VMs to laptop's NIC? This way, they can get IP from the same /64 subnet. On firewall, only enable public access to those VMs that are needed.
I do have a home lab, but every VM is directly bridged to NIC and gets its IP from home router. So a single /64 is sufficient for me.
Of course, given the state of IPv6 in the world, that's not usable for anyone who uses IPv4 today, so instead of using both simultaneously and using IPv6 when possible, you are stuck with IPv4 only, and be counted in the IPv4 stats.
It's not as fast as past me would have hoped for and I think the criticism is perfectly valid but I'm quite happy to look at this graph no and again
https://ripe76.ripe.net/wp-content/uploads/presentations/9-2...
It is actually growing slower and slower and looking as a logistic curve, which is perhaps unsurprising. Also note the increasing gap between weekdays and weekends, which is a sign that enterprises don't care about v6.
The reason I ask is (as described in the article) I've nearly run out of RFC1918 space because of dozens of machines, gadgets and many more virtual machines. (For complicated reasons to do with the VPN routing, I cannot use 10.x).
> If I'm going to do that why wouldn't I just go straight to IPv6?
Because it is a lot more than just renumbering.
Whether or not it's a good idea depends on what you expect to get from it (anything?), how good your ISP's IPV6 support is, and how good the support of hosts you connect to is.
If whatever hosts you contact are all on IPV4 only, then you'll have to occasionally debug the 6to4/4to6/Teredo/whatever kludges that add latency and provide nothing of value compared to using an IPv4 directly.
I also use some VPN tunnels, which also still rely on IPv4.
Also, all consumer routers simply block any incoming IPV6 packets, this has been the default for more then 10 years now. (the only thing not blocked is ICMP for MTU path-discovery, which is actually a good thing).
Yes NAT doesn't block packets, however without explicit configuration traffic from the Internet will be very unlikely to flow into an RFC1918 addressed network from the Internet.
So effectively it does prevent traffic inbound in the same way a firewall does.
Yes you can punch holes in NAT, but that's an explicit action (well side-stepping the insanity that is UPnP) for for non-technical users sitting behind a NAT router will effectively mean that they're unlikely to receive direct inbound network attacks from the Internet.
All you need is a default deny inbound traffic rule, this isnt some kind of arcane thing that is so much harder than NAT for end users.
Hole punching the NAT does not mean that the user will configure port forwarding. It means that the outside is able to send packets inside, without any explicit user action. It works, because most NAT implementations do not check the source IP address, so when user sends packets from port A to ip X, and the router receives packets to port A from ip Y, it will dutifully forward them, even if they are not related.
That is completely untrue. The vast majority of home routers (I would venture 99% of them) run Linux, and use the built in NAT, which does check source IP, for both TCP and UDP connections.
NAT is not a firewall, and many NAT implementations will let packets in through _if_ you know the internal IP, _and_ all routers along the way including the last one support source-routing -- which is definitely not most setups.
Furthermore, quite a bit of the home users using IPV4 these days are behind a CGNAT, which makes this even harder, as you need to source route through multiple NATs.
Hole punching without cooperation from the inside is not impossible, but it is extremely hard these days, to the point that unless its an ultra-targeted attack, no one is likely to try.
Of course it is true. The true thing you wrote is, that Linux is one of the few implementations that do check the source IPs. However, even if many home routers do run Linux, it does not mean that they use Linux's NAT. Many do not have enough CPU power to route/NAT at the speeds needed, so they have hw acceleration for that, and that is a separate implementation.
But hey, why do you think hole punching is a thing? Because it works, relatively large scale.
Care to point to 3 examples of common home routers that do not check source IP? I’ve verified many TP-Links, Linksys (when they were owned by Cisco) and Netgears, and all used the kernel to NAT (and yes, they couldn’t do the 1Gb while NATting - usually 300-700 or so. And much lower if you use IPSEC)
If by cooperative you mean that there is outcoming connection on the port, then yes, that's cooperative. If by cooperative you mean some sort of port mapping, whether manual or UPnP, then no, you don't need that.
For details, see the paper linked in sibling response.
Thinking about it, any NAT that ignores the ip part is horribly broken. I still await your examples of routers in actual use that have this behaviour.
Is there any exploit / known technique / program that allows you to explore a network behind a NAT without cooperation from inside ?
A web page can, in some circumstances, be made to probe - e.g. if you have an <img src="http://192.168.1.0"/> it will likely do an http connection to that address; whether you can actually use it for exploration depends on a lot of things.
There's a class of attacks called "DNS rebinding" that use DNS and named hosts to bypass some browser protections and cross-origin policies (see e.g. [0])
But you still need some form of cooperation - a browser request - which, as [0] points out, can be bought as an ad -- just one more reason for ad blockers.
[0] https://medium.com/@brannondorsey/attacking-private-networks...
Ford, Bryan; Srisuresh, Pyda; Kegel, Dan (2005), Peer-to-Peer Communication Across Network Address Translators (http://www.brynosaurus.com/pub/net/p2pnat/)
Abstract:
Network Address Translation (NAT) causes well-known difficulties for peer-to-peer (P2P) communication, since the peers involved may not be reachable at any globally valid IP address. Several NAT traversal techniques are known, but their documentation is slim, and data about their robustness or relative merits is slimmer. This paper documents and analyzes one of the simplest but most robust and practical NAT traversal techniques, commonly known as “hole punching.” Hole punching is moderately well-understood for UDP communication, but we show how it can be reliably used to set up peer-to-peer TCP streams as well. After gathering data on the reliability of this technique on a wide variety of deployed NATs, we find that about 82% of the NATs tested support hole punching for UDP, and about 64% support hole punching for TCP streams. As NAT vendors become increasingly conscious of the needs of important P2P applications such as Voice over IP and online gaming protocols, support for hole punching is likely to increase in the future.
> Is there any exploit / known technique / program that allows you to explore a network behind a NAT without cooperation from inside
If you wanted to exploit this, you would have to guess the port, and it would be forwarded to a machine behind the NAT, which "owns" the open port.
Only iff you have static nat forwarding that port, which is almost never. With dynamic NAT (99.99% of setups) no machine "owns" the port before it sends a packet out, and once it does, it only "owns" it with respect to the IP it sent the packets to.
For a corporate network, their requirements usually result in them having to manage their own ACL's anyways. It does not matter if that is IPV4 or IPV6. There is no "easy default" for corporate networks because they don't have easy requirements.
On a enterprise grade firewall/router, the end rule of an ACL is a DEFAULT DENY ANY ANY, on both ipv4 and ipv6. (this assumes you actually enable ACL's. But that depends on your platform).
No, it doesn't. The "attack surface" is a IP stack that looks in some hash tables whether there is anyone listening on the port, and then rejects the connection. Vs. a huge browser with a javascript interpreter and JIT and what have you that is accessible regardless of NAT or firewalls or whatever else you do on the network level. The fear of inbound connections is completely irrational.
What do you see?
What happened was I vividly recalled seeing "stateless" as the default option for the router I had in mind over a year ago. Which was indeed correct. However, in response to the other comment I went back and checked again, and just noticed that "stateless" was in fact under the NAT page, not the firewall. The IPv6 firewall page is rather hidden so it's something I forget about completely, as I don't use IPv6. Looking there, the firewall page indeed does say it blocks unrelated input traffic by default.
This wasn't the entire story though, because I could also remember that ip6tables -L was empty when I checked it. I now see, though, that this must have been because when I had done this check, IPv6 was turned off, and that made the router purge all the rules. I had always assumed it was never setting them up in the first place.
Frankly as of right now I can't really verify what actually happens because I don't immediately get an IPv6 address when I enable it. I trust it does what you say. That said, I'm still not sure how I could rely on this fact being true everywhere. With IPv4 it's pretty much a given that you will hit a NAT due to the lack of enough IPv4 addresses, but with IPv6 they could easily assign you an IP address, so what guarantee is there that the router has things set up this way? It still seems like a risk vs. no-risk, with the same resulting decision.
What privacy erosion/easier tracking are you talking about that wasn't remedied by the very wide deployment of RFC4941 (IPv6 Privacy Extensions) in operating systems?
Why would ipv6 be more reliable than ipv4? I’d say it’s the opposite: many times I’ve found websites with AAAA registers that pointed to a dead server. I mean, if you’re going to blame cgn for your problems, let’s steep to your level.
Analytics? Forensics? So you’re telling me ipv6 destroys my privacy. How is that a pro argument?
IPv6 has smaller routing tables, doesn't required routers to recalculate header checksums and doesn't support packet fragmentation (the endpoints are required to handle that). This allows more efficient router designs despite the larger headers.
The specs on the router claimed that the highest speeds could be reached with ipv6 support because you could then avoid the overhead of nat for your ipv4 addresses. So that may be what they are referring to. Nat does create overhead.
Also, MTU path-discovery is a pretty big deal in terms of performance, as IPV6 does not allow packet fragmentation. Which should improve performance aswell.
This is something I don't really see anybody mention, but IPv6 doesn't allow packet fragmentation as far as I know -- which means you don't get the sudden performance degredation (and extra data loss probability, etc.) that comes with using the wrong packet size. I expect that boosts performance but I haven't had a chance to measure.
I just updated from 2001:878:346::116 / mirrors.dotsrc.org; no problems.
Which mirror were you using, and did you file a report?
If the former I'd image this is a kernel bug and has nothing to do with any Ubuntu servers.
It will enable clients to be individually identified without needing to rely on cookies and fingerprinting anymore.
NAT is great in that it obscures individual machines without too much lose of functionality.
One of the few benefits of an extended roll-out of IPv6 is that there's been time for people to identify issues like this and get fixes rolled out widely before systems started relying on the old behaviour.