What we should take away from the IPv6 debacle is a fine lesson in hubris.
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.
ARP was unsuitable for anything except ethernet and ipv4, and would have needed to change in an incompatable way no matter what. I dont see why replacing it is a big deal.
> ARP was replaced by neighbor discovery protocol.
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?
Well, but I didn't ask for "changes between v6 and v4", I was asking for changes other than the change in address size that hinder adoption--with the point being that most of the stuff that people complain about is actually an unavoidable consequence of the change in address size, such as the replacement of ARP with a new protocol that can actually transport longer addresses than 32 bits (and that otherwise isn't all that different from ARP).
Its not like "ipv4 with longer addresses" would have been any more compatable, we would be stuck in exactly the same situation wrt actually deploying it.
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've had this question for some time, and you mentioned that you were present during the debate phase.
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 remember any variable-length encodings being proposed, but it was a long time ago.
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
> 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.
To the downvoters: I'd be curious to read your counter-arguments. To start the discussion - "NATO cybersecurity bods warn about transition to new protocol":
> 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.
The fact that network security software dosent support ipv6, so ipv6 is an inherent risk is sort of a vaccuous statement, it also wouldnt support whatever replaced ipv4 either.
I think the author is approaching this the wrong way, it's trivial to show the advantages listed are mostly not true. The marginal benefits are more than negated by the risks and costs of IPv6. IPv6 is not the product that needs to be sold, and deploying it usually has negative cost benefit on short term, for most businesses.
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.
The IT director for a global corporation will care, once the bottom line is being effected and he will have to implement it. Profits will not be allowed to suffer.
I wouldn't say it's "the right thing", but it definitely makes sense in most scenarios. Who in their right mind would voluntarily welcome a new layer of complexity into their network when it's not really necessary?
Decades from now, the story of IPv6 will be a cautionary tale about the danger of ignoring incentives when enhancing open standards.
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.
IPv6 was designed in the early 90'ies where the internet looked very different - this was even before the web. Large scale changes were much easier to coordinate and roll out. I dont think the players at that time needed incentives beyond knowing that the upgrade solved the address space problem.
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.
Isn't the same true of HTTPS (first developed in 1994, but has only seen wide usage recently, outside of specific use-cases), or even programming languages like Python 3? At the end of the day, it seems to me that incumbent internet technologies that are widely used will always see slow incremental change to a new incompatible version, regardless of how small the changes or how many improvements there are, without significant and clear external incentives. Such incentives are very hard to manufacture - so foresight of upcoming issues (such as IPv4 address space depletion) will always seem premature until they actually occur. But it certainly doesn't make forward planning a bad idea.
I deployed a dual ipv4 + ipv6 stack on my home lan a few years ago. I got myself a /48 from hurricane electric, and did everything like it's in the book: SLAAC for subnets, fixed addresses on servers, every device had a public ipv6 and the firewall allowed or denied stuff. Everything worked as it should work. One day something stopped working on the he tunnel, and as I was about to debug what went wrong, I just asked myself "Why am I doing this? My ISP has no ipv6, every site I visit has an ipv4 address, why am I keeping all this ipv6 stuff on? I don't need it. It's just useless work". And so I reverted everything to ipv4 and I am happy since. Less work for me.
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?
> I deployed a dual ipv4 + ipv6 stack on my home lan a few years ago. I got myself a /48 from hurricane electric, and did everything like it's in the book: SLAAC for subnets, fixed addresses on servers, every device had a public ipv6 and the firewall allowed or denied stuff. Everything worked as it should work. One day something stopped working on the he tunnel
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 ...).
"You can have a gazillion IP addresses with IPv6" isn't necessarily that interesting, but "You can have one IP address with IPv6", or "You can have on IP address per device with IPv6", or "You can get rid of NAT with IPv6", are very interesting.
Comcast is my biggest blocker to IPv6 adoption. I maintain a static v4 block with them, they tell me I have to give that up if I want a v6 block. Until I give up v4, v6 works on my network right up to the Comcast modem, and is promptly dropped on the floor. Regrettably, that is 'no bueno' for a multitude of reasons. :-(
Very weird, the Comcast consumer lines support IPv6 quite well. Their default is to give a /60, which seems appropriately overkill. Generally it "just works", and my roku, android phones, and similar average over 50% of the packets on IPv6.
Comcast seems like one of the largest deployments of IPv6 for normal consumers outside of the cell companies.
> Their default is to give a /60, which seems appropriately overkill.
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.
How does a household with 3 people need 14 subnets?
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.
> Even as a tech enthusiast filling that would be some work
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.
> Have you ever used VMs on a laptop? How many virtual networks do you need?
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.
Seems pretty huge to me. I could give just about every person on the planet (call it 8 billion or 2^33) each their own personal IPv4 (2^32) worth of IPs.
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.
That's not how IPv6 works. In IPv6 the lower 64 bits are essentially random, and the most significant 64 bits are used for routing. Each additional level of routing must use up one bit, except because of over-provisioning concerns, and to keep everything nice, you are supposed to use a nibble (4 bits).
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.
> A /64 can't be subnetted any more (one host, NO VMs!).
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.
Sometimes it's fine to do that, other times it isn't. If you plan to test network topology, firewalls, you can't do that. If you plan to run untrusted VMs, you also can't do that.
At this point I'd argue your case is a bit special and you may need special arrangements. If it is that critical for you to have a gazillion of IoT devices and untrusted VMs accessible from the internet via IPv6, get a /48 tunnel from he.net
On a business account you get a /56 and on MetroE you get a /48 or more. Given the huge majority of consumers only ever use a /64, giving a /60 seems reasonable.
Here in Vienna, the "local Comcast" started deploying IPv6. However, they stopped providing real IPv4 for IPv6 customers, and instead do CGN. Well thanks, but no thanks.
That's the problem with most consumer-grade ISPs that "embrace" IPv6. They will give it to you, but you have to give up your public IPv4 adress and be stuck within private address range.
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.
I still think that while the hardware may be ready by now, the software certainly isn't. Not only does an IPv6 break a lot of old software,that's not designed for the stack. Even today, not all network librarys do support IPv6. It's nothing that can't be worked out, but we are just not there yet and will never be there until a forced adaption comes into play.
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.
I wonder if anyone has tried making their home network IPv6 only? How did that work out for you?
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).
Either way I'd have to renumber everything. If I'm going to do that why wouldn't I just go straight to IPv6? I already have IPv6 on my home network (but everything has an IPv4 primary address and name resolution always resolves to IPv4); and an IPv6-supporting ISP. The question is if it's a good idea to go IPv6 only for some or all machines, and how to deal with the IPv4<->IPv6 issues.
If it's your home network, you could use 172.16.0.0/20, as well as the CGNAT /16.
> 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.
Of course it is the NAT. It always was the NAT. NAT is the easy thing, nearly effortless, that dramatically improves network security — there is a "bastion host" (router) and private network computers, almost impossible to be accessed from the outside without breaking the bastion host first. This is good security, and with NAT, everybody was getting it for free. With IPv6, it doesn't work this way, everybody needs to know how to set up proper packet filtering, ACLs, and whatsnot. It is really easy to misconfigure the network, especially in the unfamiliar environment which is IPv6. Huge loss for security. Of course IPv6 adoption suffers.
NAT is not a firewall. You are confusing the firewall function of your home router with NAT. NAT does nothing to prevent packets from flowing into your network, as NAT hole punching is fairly doable to accomplish.
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).
This, whilst technically correct, isn't necessarily end-users experience of things.
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.
You can achive precisely 100% exactly the same functionality with a firewall without NAT, indeed you need that sorta functionality to implement NAT to begin with.
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.
> 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.
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.
> 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.
> 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
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.
Hole punching refers to cooperative nat traversal, that is, with help from the inside - in every discussion I have ever seen.
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)
> Hole punching refers to cooperative nat traversal, that is, with help from the inside - in every discussion I have ever seen.
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.
That paper does not support your assertion that "most NATs do not check the source address and only check the port", in fact, they only consider "endpoints" which are (ip,port) pairs.
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.
I really don't know a lot about the hole-punching thing, can you please point me to some docs / demos / code / etc. available that would demonstrate this ?
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.
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.
> 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.
It's actually just as easy with IPv6. All you need is a stateful firewall which allows all outgoing connections and only allows incoming packets for already established connections. This was the default setting on my home router and behaves exactly like a NAT.
It is easy enough, but it is fragile. If NAT is misconfigured, your network stops working. If firewall is misconfigured (or e.g. your network topology has changed and you forgot to update the firewall configuration), the network works, but it is exposed to the elements and security goes away. We have enough security problems with IoT even in mostly IPv4 world; with massive IPv6 deployment, it wilk be a total nightmare.
It is easy enough with home routers (packet filtering is hidden from the user, and no need to configure it). It is much harder for corporate networks where you need to configure everything yourself and maintain ACLs. No more easy default option.
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).
You a talking about large corporations. I am talking about small and medium business where networks are abused and misconfigured in every way, and the only thing holding them relatively undamaged is the NAT. There are millions of them.
Don't forget people running some kind of container environment on their VPS and wanting internet for their containers. With IPv4 you at least need masquerading with IPv6 you're exposing all your microservers at once unless you think about fiewalling.
Google offering no ipv6 networking options in their cloud is one giant dick of a blocker. Screw this. Immoral awful cataclysmic prevention of us getting better at #ipv6. Wtf Google. https://issuetracker.google.com/issues/35904387
I'm surprised security and privacy weren't mentioned. In the current state of affairs (no, I'm not talking about some ideal utopia with IPv6 perfection where fifty quintillion additional RFCs have been finally deployed and battle-tested world-wide; I'm talking about IPv6 as available to the ordinary user /today/) I simply do not trust using IPv6 to provide as much security or privacy as IPv4. More than happy to change my mind when (...if?) the technology moves forward 10 years from now, but I just can't see it working right now. Sorry.
It is really sad to see that essentially all security issues of IPv4 were inherited, at least on the LAN level. However, besides of the "firewall protection" provided by NAT, which is largely mirrored as "outgoing connections only" in ipv6 deployments, I fail to see how it actually makes security worse. Do you have examples for what you had in mind?
The one you excluded (why?) is a pretty darn big one. It means for example that a random hacker would have a hell of a hard time spontaneously reaching my phone via the cellular data connection... or the WiFi connection for that matter, since that's NAT'ed too. Which reduces the attack surface immensely. I don't see why even this by itself would be insufficient reason...
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.
And you're also claiming every single router I'm going to encounter today has already set up IPv6 correctly as needed to mirror the security and privacy characteristics of IPv4 like this?
You know, I really have to apologize, because it seems I missed a critical detail that changed the entire story. Thanks to both of you for making me go double-check.
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.
Thanks for checking. I actually also expected this to be an issue when IPv6 started to become a thing, but I've seen very little in the way of reports of it and am positively surprised that manufacturers appear to be copying templates that do it properly, so I'm more worried about crap like the "forgotten" backdoors, exposed management interfaces like UPnP, ... right now.
Interesting. Note that this router manufacturer is probably one of the better ones, so I wouldn't weight this data point too much for generalizing, but that's good to know.
As others have said, most major operating systems implemented RFC4941 (IPv6 Privacy Extensions) years ago. Unless you're using unmaintained OSes (in which case you shouldn't be complaining about security), what privacy implications are you calling out?
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?
That's orthogonal to IPv4 and IPv6. There's ISPs that give you always the same IPv4 adress, there's ISPs that give you a different IPv6 prefix each time.
In fact, it is eye-opening to disable IPv4 when you have native IPv6. So little works. It is not painful, it is totally unusable. Today, in 2018, a few months away from the 20th birthday of IPv6.
Performance? How exactly is ipv6 more performing? It even has bigger headers.
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?
> Performance? How exactly is ipv6 more performing? It even has bigger headers.
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.
I'm by no means am expert in this space, but I was working on some routing issues lately and doing some speed testing with my router.
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, it has a simpler checksum to calculate and a far simpler header. The header is larger but has far less fields. This should make packet processing faster aswell.
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.
But I like NAT. I don’t want to spark a ‘NAT is not a firewall’ debate, but it solves many security and privacy issues with little overhead, and does so in an incredibly simple and elegant way. Having the private LAN as a trusted network zone makes perfect sense, and for home users is works perfectly well with 0 configuration. Remove it and you’re giving every single device a globally unique L3 identifier (no fucking thank you), and to get the same benefits that NAT provides you’ll have to replace it with an unavoidably more complex solution.
> How exactly is ipv6 more performing? It even has bigger headers.
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 used default mirrors and I didn't file a report because I'm not sure where and which part of the system is to blame. All IPv6 traffic was slow. This question is from 2 years ago so I assumed it's a known issue.
It honestly doesn't matter what bug it is. It should be promptly investigated further and solved. Random blame assignment doesn't help anyone. In this case though, seeing how most mirrors still can't do HTTPS I would not be surprised if the IPv6 issue is caused by the mirrors - another thing not yet properly configured.
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.
It's a feature of the client device, not the router, and is implemented in all major operating systems. They are not perfect though, since at least the original design was purely timer-based, which left some tracking potential.
couldn't you get around this by wrapping all tcp/udp connections in an encrypted manner say a tunnel and using dns+tls to encrypt dns queries? Sure it's not as easy as just using NAT but not having to translate via NAT to get to the internet sounds good to me. Access points wouldn't need to route anymore would they?
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.