Hacker News Reader

Comment by phicoh | Hacker News Reader

There are 3 problems with IPv6

- There is a lot in IPv6 that is different from IPv4. Ignoring if those changes are good or bad, it does make the transition harder.

- IPv6 was promoted way before there was demand. To some extent it is good to prepare people (and vendors). But it does create the impression that IPv6 is a failure

- Demand for IPv6 is highly asymmetrical. The party that is out of IPv4 addresses needs IPv6. But everyone who has enough IPv4 space has no reason to care.

When IPv6 was first promoted, there basically was no IPv4 market. You would just go and get more IPv4 space when needed. For the last couple of years we now have a mature market for IPv4 addresses.

It is possible to buy IPv4 addresses, but prices go up. At some point it becomes interesting to try to move traffic to IPv6.

View on HN

More issues with IPv6 that are relevant for me as a techie:

- Memorising an IPv4 address is about as easy as memorising a phone number, which is to say, fairly easy. I remember the iPv4 addresses of both my rental servers, every device on my home LAN, a bunch of public DNS servers if things go wrong, ...; there's no way I'm going to be able to do that for IPv6.

- At least last time I tested it (more than 10 years ago now), the greater length of IPv6 headers had a quite measurable adverse impact on transmission latency of small packets (online gaming, remote shell...)

- Why do people keep treating "you get your own unique IP address when browsing" as if it were an advantage? The way I see it, NAT and IP address reuse (especially together with some European countries' laws stipulating the address->identity mapping must be deleted within some time period) are the currently most widely rolled out privacy technology. Somewhere downthread, they talk about how Belgian police is trying to prevent ISPs from putting more than 16 customers behind the same internet address. Since I can hardly say everything I do on the internet is perfectly legal, what's bad for Belgian police is probably good for me.

I have no real first hand knowledge of this, but I have wondered if part of the reluctance of ipv6 is the fact that many of the "powers that be" use ip addresses to identify and group traffic and other activity from multiple devices. They also use ip addresses to block scrapers (both Google and Amazon do this heavily).

With ipv6, an IP address can be completely disposable. You could scrape Google search results all day long and use a different address for each call.

Heck, you could completely proxy search results in real time and create your own search engine, secretly using Google as your backend while injecting your own ads.

Wouldn't you be bound to a specific subnet dedicated to you? Or how does it work? Can you really just propagate to the world at any time "I am now baba:fefe:..."? Don't backbone routing tables get crazy mad verbose that way?

I know next to nothing about ipv6, I'm afraid.

It would be a random address from a given subnet, yes. Basically the privacy, tracking and banning implications of this are more or less the same as they are with v4+NAT, with the v4 public IP mapping to the v6 subnet.

Note that there's still no way to map a subnet to a person, just like there's no way to map a public v4 address to a person.

Huh, are you implying that with IPv6, the ISP can place multiple unrelated people in the same subnet but not coordinate with them regarding what address from the subnet they use? How does this work from a routing perspective? What if two people pick the same address?

On the other hand, if the ISP ultimately does hand out the address in the subnet (and the end user can merely ask it for a new one), the ISP can retain a record of this, which together with the server-side data can be used to unambiguously deduce who accessed what, whereas the equivalent information in v4+NAT is insufficient without also logging everyone's connection metadata. It would therefore be more appropriate to say the privacy, tracking and banning implications are the same as dynamic IPv4 without NAT, where you can likewise request a new address from your provider at any time.

Normally what happens is: you request a prefix from the ISP (call it a /56, which is 256 subnets of /64 size each), then you pick one /64 from the prefix and use it for your network. Your computers then assign themselves randomly-selected addresses from the /64.

The prefix might be 2001:db8:1:2300::/56, the first network 2001:db8:1:2301::/64, and the machines on that network 2001:db8:1:2301:random:numbers:go:here.

The ISP knows who has which prefix, because they handed them out, but the allocation of IPs inside that prefix is handled entirely by the end-user network. The ISP isn't involved in it, so they have no idea which IP is which computer.

With NAT the LAN-side IPs are hidden from the ISP. In v6 the ISP can see the LAN part of the address, but without any way to identify which machine is using which IP that doesn't give them any extra information. All they get is the prefix and a random number. Computers typically change the random number on a regular basis too so you can't even do any long-term analysis on it.

Oh, I see where the misunderstanding is. In cases like the one addressed in Belgium, the ISP actually assigns the same outward-facing IP address to multiple unrelated customers, and NAT is performed on the ISP side. Somebody who has merely recorded the IP address that made a request therefore has no legal way of determining that it came from you or someone close to you, rather than a number of complete strangers who were assigned the same address, unless the ISP maintains a record of what connections were mapped. As far as I know, in the US this is mostly common for mobile providers. If we are just talking about a NAT in your home LAN, this won't help you for privacy/security: law enforcement and whoever else still know that the IP address is yours.

That would normally be called CGNAT. Yes, that does change things somewhat... except what's actually going to happen is that people will record the port number and the time as well as the IP, and the ISP is going to record every single connection you make in a big database, and then bill you for the privilege of doing it. Law enforcement will still be able to identify you, now your ISP has a record of everything you've done, and you're still dealing with the headaches of NAT all the time. Doesn't really seem worth it to me.

As far as I know, several court cases in Germany have confirmed[1] that the mapping of dynamically assigned IP to customer identity may only be stored for 7 days. I imagine the same upper bound, or an even tighter one, applies to the records you are talking about.

[1] https://www.e-recht24.de/news/datenschutz/10387-datenschutz-... (in German)

ISPs use port logs for the same reasons as address logs so I imagine a court would treat them the same.

Around here I'd expect something more like a 7 year minimum to be more likely...

Limiting the timeframe does improve the costs and the privacy impact, but the ISP will still need to build and run all of the logging infrastructure, and the end result is that you'll still be identifiable.

If you try to do this at scale you'll find you won't get transit anywhere. Any AS will drop routes from you when Google looks their way. If you think you can ignore them, they'll just threaten upstream. You'll be cut off in hours.

It works the same way on v4 and v6.

I'm a techie too but I think:

- If you go around memorising addresses then you are doing IT wrong in general. So many things depend on DNS (not just A records) that punching in IPs by default is a bad habit. Browsers will keep on enforcing SSL/TLS more and more until the point where typing in an IP address into the URL bar will be as painful as using the web GUI for say an elderly HP switch is right now.

- In general latency is not affected by header lengths these days. In some cases, networks are prioritising IPv6 for the opposite affect. In other cases ISPs have dropped their entire IPv6 support without noticing for quite some time. sigh

- The addressing scheme in use should have nothing to do with your privacy. Yes NAT does accidentally hide you a little bit. However I can fingerprint your browser instead, for example. I'll trade easy SIP n RTP over NAT any day.

Now, for my gripes:

- Try doing multi WAN effectively over IPv6 without PI and a routing algorithm, or NAT - Try changing ISP (new addressing everywhere)

The second gripe I currently work around with RFC 4193 - Unique Local IPv6 Unicast Addresses, the first one I whine about and will probably use NPT (wholesale NAT for IPv6)

> - If you go around memorising addresses then you are doing IT wrong in general. So many things depend on DNS (not just A records) that punching in IPs by default is a bad habit. Browsers will keep on enforcing SSL/TLS more and more until the point where typing in an IP address into the URL bar will be as painful as using the web GUI for say an elderly HP switch is right now.

Most of the things I do with memorised addresses have nothing to do with the browser or HTTP. (Mind you, though, the moment a browser won't let me access a bare IP, I'm switching away from that browser.)

> - In general latency is not affected by header lengths these days. In some cases, networks are prioritising IPv6 for the opposite affect. In other cases ISPs have dropped their entire IPv6 support without noticing for quite some time. sigh

I wondered if this may be the case; I may need to rerun some tests.

> - The addressing scheme in use should have nothing to do with your privacy. Yes NAT does accidentally hide you a little bit. However I can fingerprint your browser instead, for example. I'll trade easy SIP n RTP over NAT any day.

A website I navigate to may, but how will the carrier fingerprint my browser?

All in all, it seems like we are talking about very different threat models to privacy/security. You are worried about the likes of Google and Facebook profiling you, whereas I am worried about the likes of $intellectualpropertymonopolist sending me a $20k bill for identifying me in a torrent, or experiencing a nasty surprise at $nationalborder (or at home, [1]!) for something I said on an internet forum.

(This does not seem like an abstract or overblown threat to me; I've seen 2 out of the 3 things above happen to friends and even one schoolmate more than 2 times.)

[1] https://www.theguardian.com/uk/2012/nov/12/teenager-arrested...

Me too. Wireshark, nmap and co are in regular use in my job. All browsers are playing nanny, more and more apart from the likes of Links (which I also use quite often). A lack of https is already flagged and I suspect that things will get worse in this regard. Links2 has saved my bacon many times in the past so you may enjoy it 8)

You are worried about the likes of Google and Facebook profiling you

No mate. I'm CREST accredited: I'm not worried about G and F profiling me - I know they do. However I also know that my choice of addressing scheme does not affect my privacy whatsoever. A carrier can use metadata to derive loads of facts about your usage even if you are connecting to the oher end over say https. NAT will save you from some silly firewall screw ups but not much else. A VPN can help but is no silver bullet either. If I really put my mind to it I could probably make myself near enough anonymous with enough use of proxies, VPNs and TOR but I'm not too sure about that!

I too am from the UK and have seen silly overreactions such as your [1] link. However, this is the world we have nowadays and in our case we have a horrific level of CCTV pointed at us as well as some pretty impressive levels of IP traffic mining. We also have the rather unpleasant RIP Act and a few others to belie our supposed liberal way of life in the UK. You do have to be careful what you say nowadays, within reason.

Well, my assumption was always that in a scenario such as: ISP makes me share my public-facing IP with 15 randos -> I get on a torrent for Sony Corporate Secrets [full pack] [2018].zip -> Sony's legal department connects a honeypot and harvests all IPs it sees on it and sends out subpoenae to identify everyone who is in a friendly jurisdiction, the circumstance that I'm NATted by my provider will actually do nontrivial work in reducing the probability that I am ultimately identified in a legally actionable way (especially if it were to take Sony a while to process its data). Is this not accurate?

Your ISP would usually have port mapping logs.

GDPR in theory means that we should be able to tell exactly what data ISPs have about us.

But surely you can visit a McDonald's car park, run tor-browser and download whatever that Sony thing was without being traced.

>- If you go around memorising addresses then you are doing IT wrong in general.

Because I'll surely have an TLD for my local nginx and for my home router...

You can buy a DNS domain for a few quid per year or you can use a dynamic DNS service such as freeDNS for err free.

If you go around exposing services on the internet then you should know how to do it properly. If you can get a name on it then you can put a SSL certificate on it (cheers Lets Encrypt).

If you have a SSL cert on it then you can be fairly sure you are talking to your gear and not a MitM if you take other precautions.

I absolutely do have a LE SSL cert for my home router and all my home web sites. pfSense has a ACME and dynamic DNS client for many services and HA Proxy built in. What more could you want!

With IPv4 you don't HAVE to buy a domain for your local network. You can do just fine with IP addresses. With IPv6, you probably will need to just to make it sane. That adds a whole new step, and a complex one that most people (general public) won't know how to do.

To be fair, most of the general public doesn't know what an ip address is.

I'm in the group that you're speaking of—I have a personal server set up that I can log into remotely, but the prospect of setting up a domain and TLS is very daunting. But, I don't think people like me are all that common.

Just use home.arpa from https://tools.ietf.org/html/rfc8375 with a custom DNS server or host file. Or one of the many dynamic DNS systems.

Sure, because a custom DNS server is easy to set up.

It's actually pretty easy. I was able to set one up when I was a teenager, almost 25 years ago, in the early days of the commercial Internet. It is even simpler now.

Yes, it is.

Depends on your skill set. If you're ok with *nix, then PowerDNS is pretty simple to work with:

https://github.com/PowerDNS/pdns

It's also fairly complete, used in production by some pretty big ISPs.

For a light weight approach instead, Dnsmasq is good:

http://www.thekelleys.org.uk/dnsmasq/doc.html

It's what most home routers (and lots of other stuff) embed. :)

Ok, fair enough. It’s fairly simple to set up.

It’s just a bit of a pain to maintain if the only thing you care about is connecting to server nr 192.168.0.x

I could certainly do it, but there’s 5 services in my house I’d care to connect to, and remembering 1-5 is just as easy as giving them all names. The marginal gains are very low.

Oh, I very much agree. For very small local networks in a flat address space, manually remembering stuff works ok.

Personally I tend to throw the more stable IP addresses in /etc/hosts, as that's simple too. :)

Ever heard of dnsmasq? Comes with many home routers. Puts a dns entry for each host that gets it's ip address via dhcp, plus your static mappings.

.local?

Using .local in DNS is a violation of RFC6762. You really ought not to do this.

It's also too long for something you type a lot. I use .hm.

This is easily solved with mDNS/Avahi. I had the same gripe years ago, now my hosts advertise their own records or even on behalf of others without running a NS.

> If you go around memorising addresses then you are doing IT wrong in general. So many things depend on DNS (not just A records) that punching in IPs by default is a bad habit.

If you are debugging network connectivity, then I have a tough time believing it’s possible without typing in a few network addresses.

This heavily reminded me of the good old Night Watch essay[1]. You can punch DNS names into the address bar on a browser, because someone out there traded normal sleep schedules for the tremendous opportunity to think about BGP trees, netmasks, and other exciting arcana.

[1] https://www.usenix.org/system/files/1311_05-08_mickens.pdf

Your point (and reply) about memorization was good. Yes, I'm not constantly remembering "210.40.138.43" but enough tech people need to remember some of these things - for debugging, support, etc - that IPv6 is painful. Asking someone to verify an IPv4 in a dialog setting is doable - an IPv6 is not.

I've maintained for 2 decades that simply adding another 2 slots for 0-255 would have opened up a greatly usable amount. Every current v4 - 210.40.134.34 - would also be 0.0.210.40.134.34, but we'd have another 65000 groupings of 4 billion addresses to allocate as needed, and a transition would have been far easier (smaller space, less processing, easier to think about, etc).

I use copy and paste for both IPv4 and IPv6 addresses.

I understand where you are coming from by adding a few more bytes to the address scheme but one of the things IPv6 was designed for was massive address aggregation which means really short routing tables. Your 192.192.168.168.0.0 (say) scheme does not go far enough. Also, your scheme needs to be efficient in the world of bits and bytes and I don't think it is. Your scheme would probably need to be 64 bit to start with and not 48 bit because silicon, etc doesn't work like that.

However that simple routing scheme was blown out of the water by private addressing - ie get your own ISP independent address range. When you change ISP you end up with another prefix and hence all your addresses change. All addresses. So you buy your own range (about £3000 set up and £3000 per year from memory. You also need an ISP(s) to route it and if more than one then a BGP peering arrangement.

Another wrong in the name of IPv6: 64 bit IPv6 prefixes from an ISP means you can only have one subnet. No way to put your dodgy IoT stuff on its own VLAN.

Sorry I'm not sure i understand:

> Another wrong in the name of IPv6: 64 bit IPv6 prefixes from an ISP means you can only have one subnet. No way to put your dodgy IoT stuff on its own VLAN.

Can't your router handle carving up a subnet just fine?

A lot of self-assigned IPv6 networks just tack on the device's 64-bit MAC address on to the end of some 64-bit network prefix. So if you're going with self-assignment of IPv6 addresses then you will have difficulty if your assigned prefix is already 64-bits, since you can't really use any of the 64-bit suffix bits for your own network.

The mechanism is called StateLess Address Auto-Configuration (SLAAC) [0]. It removes the need for DHCP, and the determinism is very convenient. There are of course privacy downsides for deterministic addresses that are globally routable, and that's where SLAAC privacy extensions come in [1].

[0] https://en.wikipedia.org/wiki/IPv6#Stateless_address_autocon...

[1] https://en.wikipedia.org/wiki/IPv6#SLAAC_privacy_extensions

More precisely, disabling the autonomous addressing flag in the router advertisement packet allows you to completely control the addresses which will then only be handled by DHCPv6, which allows you to slice a /64. But that means no v6 temporary addresses for anonymisation, which might be exactly what you want in a managed network/corporate scenario which requires liability tracing.

What are you using at layer 2 that has 64-bit MAC addresses?

The recommendation is to assign a /56 to end users from an ISP. That would give you plenty of subnets to work with.

/56 == 256 /64s Each /64 == 18,446,744,073,709,551,616 addresses

Sadly, plenty of ISPs use DS-Lite with a single /64 issued.

(I'm looking at you UPC/Virgin Media/Liberty Global)

Vodafone cable in germany does the same..

I have a pretty good ISP - I get a /56 but the original idea was /48 for everyone. I only have 256 subnets available. With /48 I would have say 256 x 256 subnets which would be ideal for my family. With /56 I have very little elbow room.

Each subnet (/64) is 18,446,744,073,709,551,616 addresses - which is nice.

That only helps in making the addresses seem more familiar but does not solve any of the other problems IPv6 solved. You would still need two separate protocols anyway because there is no backwards compatible way to route that.

NATs break end to end. This might be acceptable in a HTTP(s) only world though.

Of course, some people aren't only using the Internet for browsing.

The Internet of things will end up needing unique endpoints, and NAT does not play will with those either.

India has a lot of people, and quite a few of them will be IPv6 only (or behind a very degraded carrier grade NAT). If you are talking to customers/clients/vendors there, assume you need IPv6.

Memorising IP addresses isn't done in any larger scale network, you use DNS.

NATs work well at about the scale of a single household, beyond that, they keep making things worse.

> NATs break end to end. This might be acceptable in a HTTP(s) only world though.

I was always curious about this argument -- do you mean that NAT elimination will allow any two arbitrary devices to communicate with each other?

I would think that even in IPv6 world, the firewalls would still be a necessity. Most ISP would continue shipping routers with stateful firewall enabled by default (to prevent internet exploits), so any peer-to-peer software would still have to deal with UPnP/STUN/TURN. Sure, the STUN protocol will be simplified a bit because it would not need to worry about IP changing, but it would still be way more complex than just a simple connect() call.

Note that the situation maybe better in some cases -- like for India or for cell phone networks -- but there would still be enough people behind the firewall to make arbitrary incoming connections unreliable.

Related: the privacy extensions seem to be a pretty bad idea. I have no idea how would I set up a firewall to say "allow incoming traffic to my main laptop, port 22222" if it's IP address always changes. Ideas like "disable privacy extensions" and "filter by MAC" have their own significant downsides.

NAT elimination will indeed allow arbitrary devices to communicate with each other. Whether they do so will depend on the end users.

Stateful packet filters will still be necessary, but those would be end user configurable.

Keep in mind that you are thinking about a NAT you control. If your ISP is NATing you as well, you would have a very different impression.

> Why do people keep treating "you get your own unique IP address when browsing" as if it were an advantage?

The original tenet of the internet pretty much hinged on the idea that every person with a computer can host/self-publish information as well as consume other people's information in a distributed way. They will not have to depend on a centralized publishing authority.

I think v6 could have enabled this

> Why do people keep treating "you get your own unique IP address when browsing" as if it were an advantage? The way I see it, NAT and IP address reuse (especially together with some European countries' laws stipulating the address->identity mapping must be deleted within some time period) are the currently most widely rolled out privacy technology. ...

Although IPv6 doesn't have NAT, per se, it does have Network Prefix Translation (NPTv6). And some VPN services (FrootVPN and Perfect Privacy, for example) have already implemented that.

- No transition or migration design. It seems like IPv6 was designed as if it was being built instead of building IPv4, and didn't consider how the move would happen beyond something like "everyone run dual-stack IPv4/IPv6, and once that's at 100% we'll turn off IPv4."

This results in a stale-mate of sorts:

As a server operator, as long as you have IPv4-only clients, you need an IPv4 address. There are no [1] IPv6-only clients, so implementing IPv6 at all is a lot of work with no tangible benefits for the next x years [2].

As a client, you can't go IPv6-only without losing access to the IPv4-only services. There are no[1] IPv6-only servers, so implementing IPv6 at all is a bunch of work with no real benefits for the next x years[2]

[1] no meaning a tiny fraction that rounds to 0%

[2] x being the number of years before there's a significant number of IPv6-only servers or users.

This is literally my problem with upgrading to IPv6 currently. And at the cost of potentially embarrassing myself, I haven't really looked into what the potential problems are going to be (and I'm embarrassed to ask :-) ). My ISP will happily switch me from IPv4 to IPv6 but I've got absolutely no idea what the potential problems are. This has put the task into a near perpetual, "I'll look at that when I'm not so busy". I'm sure I'm not alone in this...

demand dual stack. nothing else really works.

sure, we can simply stay on v4 and encapsulate everything into UDP and use vhost or other names and simply treat v4 address + ports as the solution. economically both are costs of growing the internet. (any solution requires a lot of application changes anyhow, v6 is simpler, but requires ISP buy in, so what app devs can do?)

To some extent this is unavoidable. Anything that is 'IPv4-like with larger addresses' is very much incompatible with any IPv4 equipment or setup at the edge.

You could design something where the IPv4 could be left unchanged in the core of the Internet. But the core of the Internet has supported IPv6 for a long time, it is the edges where the problems are.

Just something as simple as writing an address to a log file would fail if addresses suddenly became bigger.

> Anything that is 'IPv4-like with larger addresses' is very much incompatible with any IPv4 equipment or setup at the edge.

I disagree somewhat. You could imagine a hierarchical routing structure where IPv4 NAT servers double as IPv4ext routers and gateways. All current servers maintain an IPv4 address which, if the server is unaware of IPv4ext, will not be able to decode things like full client IP address for loging, giving an incentive for server operators to upgrade.

Meanwhile, unaware client end-points connect to IPv4ext servers just as before, via NAT, but of course don't have end to end connectivity to other IPv4ext clients, giving them a (weak) incentive to upgrade.

This would go on for a decade or two just like it did with IPv6, until the moment where virtually all firmware and software is upgraded. At this point carrier grade NATs would stop mangling, the IPv4 only packets are dropped from the core and full non-hierarchical routing can commence on the full IPv4ext address field, finally solving the IPv4 exhaustion problem, in addition to the already solved e2e problem.

I agree this backwards compatible deployment scenario is much more convoluted than a clean slate redesign, and it's hard to imagine it could have seen preferable in the 90s, before wide-spread carrier NAT was a thing.

There problem here is two fold:

1) As far as I know, nobody ever wrote down a protocol description, and preferably made an implementation. The devil is in the details. It is very hard to estimate if such a design would actually work.

2) At the moment, the core of the internet and just about all host operating system support IPv6. The hard part is getting the edge networks to upgrade. My guess is that your proposal would run into similar issues.

There are a number of proposals that build on these ideas, for example EnhancedIP. Typically, they would encode the extended addressing info in an options field. They were to late the party and missed the circa 2000-2005 window where it became clear Ipv6 will be an uphill struggle. Back in the day, only naive proposals like ipv7 existed, "ipv4 with larger address" but that solves little.

The fundamental difference compared to dual stack is that there is no technical cost to deploy it outside software updates and very little risk - aside from the dubious security benefits of NAT. Not only the core, but virtually all hardware and software on the Internet today support ipv6, but there is an enormous cost to configure it to work.

This flexibility and drop in upgradability of things like EnhancedIP comes with the significant cost of breaking the internet into 2^32 independent routing domains that prevent you for getting the full benefits of the larger address format. This is an acceptable trade off only in retrospect, after the v6 "failure".

There is a large cost to configure IPv6 because most operators have ignored IPv6, waiting for the IETF to magically get it right.

There is very little consensus within the operator community on how to deploy IPv6. The net effect is that there is an endless series of configuration options.

Which leads to having to select equipment very carefully to make sure you get an overlapping feature set.

The problem with something like encoding extra address bits in IPv4 options is that you would have to get a large group of operators on board for it to get any traction.

For example, the ISP that I use for my home internet connection give customers a static (officially 'stable') IPv4 address. It may not be beneficial for them if a next generation internet protocol would force the deployment of NAT boxes.

The downside of dual stack is that you have to manage 2 networks. The benefit it that you manage two completely separate networks. IPv4 routing has very little effect on IPv6 routing.

Merging the two, as is done for example with NAT64/DNS64, leads to network issues that many people don't understand. I think you would get the same if you mix legacy IPv4 stacks with stacks that encode extra bits in an IPv4 header option.

This is of course completely ignoring the fact that many firewalls just drop anything that has IPv4 options. So deployment may be just as an uphill battle as IPv6.

> The problem with something like encoding extra address bits in IPv4 options is that you would have to get a large group of operators on board for it to get any traction.

Sure that's why you have things like IETF, to coordinate such changes. If that were to happen, the EnhancedIP option would quickly become transparent, as the core of the internet upgrades firmware in a few years. I'm not in any way proposing this to be a good idea today, let alone that it could be deployed in ad-hoc uncoordinated fashion.

> my home internet connection give customers a static (officially 'stable') IPv4 address. It may not be beneficial for them if a next generation internet protocol would force the deployment of NAT boxes.

In that case you become the owner of your own routing domain and you have the option to provide your "customers" with an extended IP address that is e2e reachable from the outside world, while NATing the rest of the legacy devices. Your ISP does not have to do anything aside from not filtering options, that's the beauty of a backwards compatible solution.

> Merging the two, as is done for example with NAT64/DNS64, leads to network issues that many people don't understand.

The complexity and fragility of something like NAT64 comes exactly from the fact that it tries to bridge two separate internets. An EnhancedIP NAT is simply a transparent router for EnhancedIP aware endpoints within the domain it controls. You can freely mix legacy and upgraded devices in your network with guaranteed interoperability and you get e2e connectivity if both end points and any NATs in the route are upgraded. The rest of the network only "sees" IPv4 traffic as far as they are concerned.

Why is IPv6 more attractive for address exhaustion than IPv4 NAT?

As the article argues, you can't run IPv6-only. You need some strategy to reach IPv4 services on the internet because the internet is IPv4. That answer is going to be either publicly routable IPv4, IPv4-to-IPv4 NAT, or IPv4-to-IPv6 NAT. If you do the latter (or if you do dual stack) you can route directly to other IPv6 hosts without NAT - but what's the benefit? Are there systems of communication between parties on the public internet that can guarantee native IPv6 on both ends, don't want to use IPv4 NAT, and don't want to set up a point-to-point VPN?

(I am actually okay with IPv6 ULAs for private addressing on private VPNs to avoid RFC 1918 collisions/exhaustion, but that also saves you a lot of the complexity of IPv6 deployment because you don't need any network device support, you generally get address assignments from your VPN layer and don't need to think about SLAAC or DHCPv6 or anything, etc. And it's unrelated to public IPv4 exhaustion.)

Native IPv6 is cheaper than NAT at ISP scale. If a consumer ISP adopts IPv6, half of their traffic will be native IPv6 without NAT. If the ISP tries to do NAT444 then all of their traffic will be NATed, requiring more equipment.

There are a couple of reasons:

- There are limits to how many devices you can put behind a single IPv4 address. There is the case of Belgium where law enforcement asked ISPs to limit CGNAT to 16 customers per IPv4 address. Obviously for law enforcement, if an address is shared between multiple customers it makes investigations harder.

- A second problem it that you may lose geographical resolution if customers for a wide area share a pool of addresses. For some ad placement you really want to know where addresses are.

- But the bigger problem is that network speeds keep growing. Compared to an IPv6 router, boxes that can do NAT at a large scale and high speed are quite expensive. So an ISP has an incentive to move traffic volume to IPv6. Relatively low volume oddball sites can go over the NAT box.

Do these arguments not apply to IPv6 customers speaking to legacy IPv4 sites? They also have to go through IPv4 NAT, it's just that the NAT is converting it to a public IPv6 address instead of a CGNAT IPv4 one. Wouldn't law enforcement and ad targeting be equally unhappy by piles of IPv6 users being converted to the same IPv4 address?

If enough of the Internet is running IPv6 that you save significantly on performance by bypassing NAT for IPv6 sites only, that seems worthwhile, sure. But also I'd intuitively find that surprising, at least at present - maybe my intuitions are just wrong about how much IPv6 there is.

For ad networks, the sensible thing to do is to support IPv6. Then any ISP with CGNAT only has to enable IPv6 to make it work.

I have no clue what law enforcement plans to do.

Video services use most of the bandwidth. So with youtube and netflix on IPv6, you can easily have most the traffic go over IPv6.

The most recent figures I've heard were that something like 40-60% of traffic (by bytes) on a dual-stacked client ISP will go over v6. I heard that stat about 4-5 years ago, so it seems reasonable to expect it to be even higher nowadays.

Another advantage is that v6 is easy to hand off early, but if you're CGNATing v4 then your v4 traffic has to go via your CGNAT routers. For cost reasons you probably want as few of those as possible, which means v4 traffic may need to go further to reach them. T-Mobile in the US is like this; v6 traffic is passed off as soon as possible and gets a relatively direct network path, but v4 traffic has to go all the way to one of their datacenters to get NATed. That can add a lot of latency.

But you would have far fewer connections behind the IPv6 - IPv4 NAT.

Then the performance problems are limited to sites without IPv6.

>> There are limits to how many devices you can put behind a single IPv4 address.

Do you mean ~65k devices behind a single public IPv4 address? [0]

>> There is the case of Belgium where law enforcement asked ISPs to limit CGNAT to 16 customers per IPv4 address.

Well if law enforcement in Belgium asked, of course we all need to immediately work to redesign the global IPv4 internet to comply. </sarc>

[0] https://learningnetwork.cisco.com/thread/81720

> Do you mean ~65k devices behind a single public IPv4 address? [0]

That's an absolute limit of 2^16 (65k) - the practical limit is much lower.

If you only allow one connection per client, then yes, you can get to 65k with TCP/UDP.

If you want more than one connection per client (e.g. because the user wants to download content from Facebook while also downloading a YouTube advert), you need to allocate multiple ports on the NAT device.

I'd imagine that most clients need at least 2^4, and possibly up to 2^8 simultaneous connections to ensure that you don't introduce problems. At the level, you have a limit of 2^8 - 2^12 clients (i.e 256 - 4096).

You can actually get more than 65k connections per address depending on NAT technology. Traffic coming from 1.1.1.1:80 to 9.9.9.9:12121 can be mapped to 192.168.1.1:3333 while traffic coming from 2.2.2.2:80 to 9.9.9.9:12121 can be mapped to 192.168.1.100:9999. GCNAT devices usually support that.

The 65k limit only applies to concurrent connections to the same remote ip and port. Meaning that you can only make 65k connections from a single IP to the same port of another IP. Which is unlimited for all practical purposes. However, popular services that could potentially see a lot of connections - ban IP addresses, do rate limiting, don't allow that many connections from a single IP. This in turn drives policies of small number of clients per IP, sometimes even rotating IPs, all to minimize effect of bans on users sharing the same IP.

It's not as unlimited as you might hope.

For a typical provider, a large proportion of their traffic is going to go to a limited number of properties (e.g. facebook, google, youtube).

Each of those properties is only going to return a limited number of IP addresses, and all of the traffic is going to be to a very small number of ports (i.e. 443/80). I can well believe that clients connects via a single ISP to a single remote port a large multiple of times.

> Are there systems of communication between parties on the public internet that can guarantee native IPv6 on both ends, don't want to use IPv4 NAT, and don't want to set up a point-to-point VPN?

WebRTC is one example of something that can greatly benefit from having publicly routable addresses on clients (in practice this tends to mean IPv6). If both clients are behind IPv4 NAT that doesn't allow hole punching, they will need TURN (or media) server in order to communicate. While clients might be close to each other (e.g. same apartment building), that TURN server can have horrible routing for this set of clients. For example, it could be in Europe while both of the clients are in west coast of USA (and that's not even nearly the worst case).

NAT has many severe limitations.

When I was on an ISP with CGNAT I regularly saturated the connection tracking tables which resulted in all new connections failing until some some slots were freed up.

NAT also makes it difficult to run any kind of server at home (PCP support varies) or use any kind of p2p protocol. NAT traversal techniques don't work all the time and even when they work they may only help for coordinated connections but not for unsolicited contacts.

> NAT also makes it difficult to run any kind of server at home (PCP support varies) or use any kind of p2p protocol.

I care about this greatly, but I'm not clear that ISP's do. On the contrary, my ISP's TOS states that I'm technically not allowed to run my own server on my home internet plan.

P2P isn't just file sharing and home servers, for example the popular PS4/Xbox/PC game "Destiny" is all serverless P2P instances. I can't imagine an ISP banning you from playing PS4 games.

I recall reading that you could make P2P connections work behind a NAT by having an external server route the connections initially. Is this not true, or does it only work in some circumstances?

It often works, a common method is called “UDP hole punching”.

This is the "nat traversal techniques don't work all the time" caveat, especially with TCP.

I've had the same experience when my ISP put me behind a CGNAT: the port table got reset every other day, and some other customer could have taken the port you wanted at that point, applications with ports hardcoded over number 2000 did not work because they could not be requested, people with PPTP VPNs could not use them anymore as GRE didn't work. Plus, enjoy getting banned from things because you share your IPv4 with plenty of strangers. The solution from the ISP was to give those who complained a "fixed IPv4 plan" for free, since that pulled you out of their IPv6+CGNAT deployment plan, at least for the moment.

I never truly delved into low level networking, but I generally got a grasp for IPv4, I can setup simple networks and I think that I understand what's going on on every level. Now despite the fact that I tried to understand IPv6 multiple times, I failed miserably all the time. I tried to setup IPv6-over-IPv4 OpenVPN, it did not work despite all efforts. IPv6 is just too complex. At this point I wish that IPv6 would be just IPv4 with 16-byte address (or better 8-byte, because that's really enough for everyone and another 8 bytes I have no idea who really need that, and our computers work natively with 8 bytes), keeping all concepts the same. Now I'm aggressively against any IPv6 and I'll do only the minimal amount of work to support IPv6 clients for my services while using IPv4 for my own infrastructure everywhere.

By and large IPv6 is very similar to IPv4, but of course without NAT.

For example, at my home I get a /48 prefix from my ISP over DHCPv6 (over PPPoE). Then I assign /64 prefixes to my subnets. After that, hosts pick up addresses using SLAAC.

Obviously, VPNs are more complex, but that's not the fault of IPv6.

Well, that's pretty childish of you. "I didn't understand it, so I will be bitching how bad it is."

If you think, you understand IPv4 well enough, this book will explain the differences and why certain decisions were made when IPv6 was designed: https://sites.google.com/site/yartikhiy/home/ipv6book

IPv6 is in no way more complicated than IPv4, especially if you include all the things you need to make IPv4 work in practice (NAT, techniques for dealing with NAT, etc.). IPv6 is different which is probably why you are having trouble: you wanted something just like IPv4 but with larger addresses, but that is not IPv6. For me the key to understanding IPv6 was to view it as something totally different, and not try to map my understanding of IPv4 onto IPv6.

Now I am aggressively against IPv4, because over and over I see problems resulting from NAT, or collisions in private address ranges on two LANs, or broken path MTU discovery, etc. The only arguments for IPv4 are economic or political; at this point the technical debate is over and IPv6 is a clear winner (the majority of technical problems in IPv6 deployment are related to compatibility with IPv4).

Configuring OpenVPN ipv6-over-ipv4 are exactly two lines in your server config:

server-ipv6 your-ipv6-subnet-for-clients push "route-ipv6 subnet-you want-to-route" (either your real subnet, or 2000::/3 for all traffic).

You need the same for the IPv4 side of things too.

Clients need no change.

Unfortunately it does not work for me.

> For the last couple of years we now have a mature market for IPv4 addresses.

Which highlights the utter failure of v6 - people are willing to pay for access to technology that v6 was supposed to make obsolete over a decade ago.

I disagree. You have to consider network effects. Even if IPv6 was completely perfect, switching on your own doesn't do any good. You need to get most of the network to switch to get the benefits.

Given that there is always a cost to switching, people will consider switching when continuing on the old path will become more costly than switching.

>> ... the utter failure of v6.

> Even if IPv6 was completely perfect...

More specifically: "completely technologically perfect". Which is the point being made in this thread: the technical aspect is of only partial relevance. If IPv6 fails because of political problems, or "contextual ones" (like “we could make it technologically inferior but more readily backwards compatible; it would make it less awesome but easier for people to migrate”), then that is still "failure of IPv6".

If IPv6 had been perfect, it would be fully backwards compatible, and there would be no market for IPv4 right now.

Just because that isn't possible doesn't mean there isn't a middle ground.

It is easy enough to criticize the IETF and the wider IPv6 community for the mistakes they made.

But as far as I know, nobody came up with a credible protocol that is fully backward compatible with IPv4.

So, you can ask the IETF to come up with a magically protocol that has longer addresses and is still backward compatible with IPv4. But they are only human. So that kind of magic is not going to happen.

Wouldn’t a predefined mask for IPv6 addresses do exactly that? The last 32 bytes of the address could easily be an IPv4 address I should think.

A mask like 0000:0000:0000:0000:0000:ffff:xxxx:xxxx/96?

Nope, because:

- you would need to restrict yourself to an extremely tiny fraction of the v6 space that's the same size as the v4 space

- you couldn't use any IPs that correspond to in-use v4 IPs because they would overlap

- you couldn't use any IPs that correspond to unusable v4 IPs, for the same reasons you can't use them in v4

- you'd have to talk a protocol that looks the same as v4 on the wire, because otherwise v4 hosts won't be able to handle it

You know what we call that? We call it IPv4.

If IPv6 fails because of political problems

Every major OS, network device maker, service and program supports it. I can't imagine it "will fail" in any way where everyone goes "ok, forget IPv6, let's move on to IPv7 it's the new thing" and the world says "phew, at last!".

> According to market researcher Gartner, over 1.5 billion smartphones were sold last year

That's an IPv4 internet of address-needing devices every couple of years, just in smartphones. World IPv6 day was 8 years ago in 2011, and then Vint Cerf said there were no plans for an IPv7, and 8 years later there still isn't an IPv7 coming from the IETF. https://www.networkworld.com/article/2200118/router/cerf--fu...

IPv6 can't "fail" for the same kind of reasons huge financial companies can't fail - there isn't an alternative.

Sure there is, it's called IPv4. For profit companies will continue to beat that dead horse with things like CGNAT for as long as IPv6 continues to fail. The failure is a process not an end state, IPv6 is falling for two decades now and the eventual complete deployment in the year 2040-2050 will be it's complete and giant failure, unless something else comes along to make it irrelevant.

> - Demand for IPv6 is highly asymmetrical. The party that is out of IPv4 addresses needs IPv6. But everyone who has enough IPv4 space has no reason to care.

We might need some way to force them... Google has done a lot of good by changing functionality for SEO + chrome by giving warning or giving PR boost if your site has a certain feature.

They should consider prioritizing sites that have both IPv4 and IPv6 and also warn users in the browser if the site does not have IPv6.

It's a legit warning too:

"Warning! This site may not work on some networks!"

> IPv6 was promoted way before there was demand.

No? My recollection is the original primary objective of IP Next was to prevent the net's flat address space from collapsing into NATed fragments. The need was immediate and pressing. We failed. Now we all live in what was feared - a post-collapse wasteland of centralized systems.

You missed:

- No real competition in ISPs

If you had a national ISP in the US who ran IPv6 with end-to-end connectivity without NATs, a killer app would move to it and then drag all the other ISPs onto IPv6.

Comcast runs native IPv6, along with Verizon Wireless and T-Mobile. A full 40 percent of US traffic to Google is over v6.

> The party that is out of IPv4 addresses needs IPv6.

That party is not an ISP though. An ISP is interested to provide IPv4 internet no matter whether there is IPv6 or there isn't.

Reply on news.ycombinator.com