27

Will it still be useful to make use of private IP addresses with IPv6?

Mit94
  • 373
  • 3
  • 5
  • 1
    The IPv6 ULA addresses can be used for traffic that will never go out on the public Internet, but you can easily assign multiple IPv6 addresses on an interface (much more difficult for IPv4), so you can easily have one or more ULA and one or more Global addresses configured on one interface. – Ron Maupin Apr 28 '20 at 19:39
  • 8
    It will (hopefully) make them *not mandatory*! – user253751 Apr 29 '20 at 12:37
  • 1
    @user253751 Well said. Yes, your average Comcast account these days comes with enough IPv6 addresses for every nanide on the *Revolut10n* TV show... about a million times over. Nah, you'll still want unroutable private IPs for protection, for certain traffic you want to preclude leaking onto the open internet... or coming in. A side-effect of a NAT router is nobody can portscan your PC, since it doesn't have a public address. – Harper - Reinstate Monica Apr 29 '20 at 18:04
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. – Ron Maupin Dec 17 '20 at 16:57

3 Answers3

31

No, private addressing will not become obsolete. But actually, there are two kinds of private addresses: the Unique Local Addresses (ULAs) and the link-local addresses (LLAs).

There will always be a need for big (i.e. routed) private networks that are not directly connected to the internet. Now, you could argue you don't require a private address space for this, just use whatever you want. There are still good arguments why there is still a dedicated IANA-assigned prefix FC00::/7 with a 40 bit randomizer for local unicast addresses as per RFC 4139:

  • Some devices on that network may be connected to the global internet also, either simultaneously or by moving networks. In any case, re-using prefixes will mess up routing tables. Worst case you even leak a 'privately used prefix' into the global routing table and black-hole that regularly routable address. Leaking a non-routable address is less bad.
  • Actual global addresses are owned by people and organisations. These people are free to do with those addresses what they want, including hard-coding them in certain applications. If you re-use those addresses internally you may see some weird traffic and/or application behavior.
  • At some point you may want to interconnect two private networks (e.g. combine two offices), at which point overlap would be a headache. The randomization makes sure this should be extremly unlikely.

Now, most homes and offices don't have such a complex network and only have one router that guarantees connection to the internet. Even here it is useful to have a kind of private addressing. For example you want to run a service that is only reachable from inside the home, or run a service that is not dependent on your internet connection. For this you can easily rely on the LLAs in prefix fe80::/64 as defined in RFC 4291. Most devices will automatically assign a link-local address to any IPv6-enabled interface. This address is only meaningful within a given broadcast domain and cannot be reached from outside that broadcast domain.

As a final: what IPv6 obsoletes is the need for private addresses that are NAT'ed into public ones. IPv6 allows for multiple addresses per interface, so the private addresses above can perfectly be combined with public addresses. Aside from that the IP resource saving from NAT is no longer necessary and the neglible perceived security that NAT gives can perfectly be built for IPv6 without actually doing NAT itself and is better of using a dedicated firewall anyway.

Community
  • 1
KillianDS
  • 989
  • 8
  • 19
  • 3
    "_the security that NAT gives_" is a non-existent myth. Firewalls provide security, and a NAT device without a firewall is vulnerable to being compromised, and since it has full access to the internal private network, then the private network is fully exposed to the attacker. NAT provides no real security. – Ron Maupin Apr 28 '20 at 21:03
  • 1
    You are forgetting the part where if there is no NAPT table entry, then the packet is destined to the NAPT device itself. As I explained, the NAPT device is vulnerable to attack without a firewall, and it has full access to the private network. It is firewalls that provide network security, not NAT or NAPT. – Ron Maupin Apr 28 '20 at 21:12
  • 9
    The real problem is that NAPT has stifled protocol innovation because it only allows TCP, UDP, and ICMP. SCTP probably would have taken over TCP and UDP years ago, except for NAPT, and other protocols cannot be developed due to NAPT. Restoring the original IP premise of end-to-end connectivity will open up innovation again, and we can retire things like TCP and UDP that have known weaknesses that have been solved by other protocols that we cannot use. The programmers on [so] cuss about the current protocols available, but we cannot use the ones that solve their problems. – Ron Maupin Apr 28 '20 at 21:40
  • @RonMaupin: I would think that what's missing is a connection-based store-and-forward protocol, where an application would establish a connection with a router in some standard way, and then ask the router to establish a connection with a device that has a global address. The concept of individual packets being delivered end to end via connection-agnostic means doesn't strike me as a good design for today's internet. If I send a packet to a machine that's sufficiently bogged down that it can't process it, does it make sense to have a retransmission cross the entire Internet? – supercat Apr 29 '20 at 22:38
  • 1
    @supercat, the entire premise of IP is that only the end-devices need to maintain state. The point was that any failure in the middle would automatically reroute around the failure, but that cannot happen if the device maintaining state fails because the connection would need to be reestablished, which was the point of packet-switching over the old telco circuit-switching. The government funded the research for packet-switching that resulted in IP to overcome the limitations of circuit switching in the event of disaster or war, and putting state back in defeats that. – Ron Maupin Apr 29 '20 at 22:42
  • @RonMaupin: I'm aware that's the design premise, but the mix traffic on the Internet today is nothing like the mix for which it was designed. If video is being streamed along a connection that understands the bandwidth and timeliness requirements, the points along the connection could optimize packet delivery order so as to deliver the best possible service. Sending end-to-end packets over a stateless network wouldn't allow such optimizations. – supercat Apr 29 '20 at 22:51
  • @supercat, there is no QoS on the public Internet. All the ISPs along the path will ignore your QoS policies. With large transfers or real-time traffic like VoIP/Video that are more common, it becomes a problem to reestablish connections when a device maintaining the communications state fails, or is bypassed by a failure or purposeful change ins ISP connections. It is more important today than 20 years ago to eliminate state in the path. – Ron Maupin Apr 29 '20 at 22:55
  • @RonMaupin: Having the Internet-backbone portion of a connection handled in stateless fashion makes sense, but that doesn't mean that the same protocol used for a densely-connected network is suitable for connections between end-user equipment and the backbone. – supercat Apr 29 '20 at 23:07
  • 1
    @supercat, there is no Internet backbone. The Internet is simply the ISPs connecting to each other in whatever fashion they choose and contract. Think about a company with multiple egress points using VoIP with a bunch of calls. Using IPv4 and NAT, the failure of one NAPT box fails all the call calls going through that box because they would get different IPv4 addresses on a different NAPT box. With IPv6, the calls automatically reroute around the failed box through another box and continue because the addressing does not change. – Ron Maupin Apr 29 '20 at 23:13
  • Congratulation, @supercat, you just re-invented [BITNET](https://en.wikipedia.org/wiki/BITNET). – Mark Wood May 01 '20 at 13:47
11

IPv6 has Unique Local Addresses (ULA) (see RFC 4193) which function roughly like RFC1918 addresses.

These addresses are called Unique Local IPv6 Unicast Addresses and are abbreviated in this document as Local IPv6 addresses. They are not expected to be routable on the global Internet. They are routable inside of a more limited area such as a site. They may also be routed between a limited set of sites.

Community
  • 1
Ron Trunk
  • 66,852
  • 5
  • 65
  • 126
  • 1
    The key about ULA vs. RFC 1918 or even the deprecated IPv6 Site-Local addresses is that it is not expected that the same addressing will be used in multiple places because of the required, randomly-chosen 40-bit Global ID. – Ron Maupin Apr 28 '20 at 19:41
  • 1
    Nitpick it is expected that (assuming people follow the RFC which of course not everyone will) that the probability of two sites that want to communicate with each other using the same address block is low. However it is very likely that even if everyone does pick their blocks randomly that there will be multiple sites in the world using the same block. – Peter Green Apr 28 '20 at 22:19
  • "randomly chosen" People are very bad at random, and so are computers. Overlaps are going to happen, but IPv6 is, in theory, easier to renumber. The hope is these overlaps will be rare -- far more so than RFC1918 networks. – Ricky Apr 29 '20 at 04:49
  • 1
    @RickyBeam there also is only a problem if those prefixes somewow come into contact, e.g. due to accidental route leaks or due to office merges. Both those should be rare enough, adding that to the randomization in the RFC I doubt it will ever be a real issue. The real issue is that many people will ignore the randomization and just pick zero. – KillianDS Apr 29 '20 at 06:49
4

Yes, IPv6 NAT is possible. Juniper Junos, for example, supports generally similar features for IPv6 as it has for IPv4.

You may wish to read about IPv6 Unique Local Addresses.

Many will argue that 6-to-6 NAT is unnecessary, that you shouldn't rely on it as a security tool, etc. I don't believe they're wrong, but I'm glad NAT is still a tool we can use when it's the most practical option.

Community
  • 1
Jeff Wheeler
  • 5,439
  • 9
  • 18
  • IPv6 does not have a NAT standard RFC the way IPv4 does. The _experimental_ IPv6 NAT RFC explicitly forbids NAPT, which is the most common NAT version used on IPv4. The fact that IPv6 interfaces will happily accept multiple addresses from the different address types means that you can have one or more ULA and one or more Global addresses at the same time on the same interface, thus obviating the need for NAT in IPv6. – Ron Maupin Apr 28 '20 at 19:36
  • 1
    The standards documents for IPv6 explicitly specify a lot of really stupid things. Forbidding NAPT is one of them. Remember, IPv6 also specifies you musn't configure subnets longer than /64, yet breaking this "rule" is almost universally standard among transit networks. Requiring end-systems to participate in multiple networks, instead of permitting NAT to abstract hosts from network inter-connections, is fine for purists but just isn't the most practical option in many cases. – Jeff Wheeler Apr 28 '20 at 20:10
  • 4
    "_IPv6 also specifies you musn't configure subnets longer than /64_" That is a common misconception. There are some feature that do not work with networks that are not `/64`, but ask @RickyBeam, and he will tell you that it works just fine. The only RFCs about the length will give you pros and cons about using different lengths, but there is not one that says you can only use `/64`. On the contrary, there is one that recommends `/127` for point-to-point networks. In any case, there is no real need for NAT, much less NAPT, which breaks the IP end-to-end paradigm that IPv6 restores. – Ron Maupin Apr 28 '20 at 20:57
  • 3
    "_permitting NAT to abstract hosts from network inter-connections, is fine for purists but just isn't the most practical option in many cases._" Why is that not practical? That is the very foundation of IP. IP is based on end-to-end connectivity, and NAPT breaks that, rendering many protocols unusable. NAPT only works with TCP, UDP, and ICMP. SCTP is a better, more modern protocol that breaks, and new protocols cannot be defined because of NAPT, which also breaks some application-layer protocols. – Ron Maupin Apr 28 '20 at 21:08
  • 2
    OK, I'll jump in this rant too: This terribly broken paradigm has somehow allowed more people on the planet to communicate and share information than anything else in history, not to mention creating all our careers. Yes, end to end may have some advantages for more efficient protocols, but it eliminates all the practical things that make the Internet work, like security proxies and load balancers. End to end sounds good until you need to inspect traffic in order to protect your company’s or government’s assets. – Ron Trunk Apr 29 '20 at 03:50
  • 1
    Actually the "/64 rule" does exist, but it's in the context of LANs. In the myriad of RFCs constantly redefining IPv6, they make it out like a /96 LAN will bring about the apocalypse. Try it yourself, it only "breaks" SLAAC because "prefix length === 64" is hard coded in the standard. (if you edit your linux source, that rule is trivial to remove.) If you take it too far, you can run into issues with anycast and other special, reserved addresses, which is why /127 takes special handling. Also, the smaller the network, the harder it is to find a unique address. – Ricky Apr 29 '20 at 05:00
  • 1
    @RonTrunk I don't understand what you are saying. End to end doesn't increase the burden of the firewall. If anything it decreases the load by making a lot of stateful decisions stateless. Presently firewalls are typically the same appliance as the NAT because the NAT is the only place where there is enough information to apply the firewall rules. End-to-end would allow you to spread to load to the various internal routers. – Aron Apr 29 '20 at 09:59
  • @RonTrunk security proxies are the reason that every protocol nowadays is tunnelled over HTTPS, because thanks to NAPT, and overzealous network admins interfering with even the traffic that can traverse NAPT, HTTPS is the only protocol you can realistically expect to make it to the other side in one piece. Load balancers have no trouble with IPv6. This mess makes the things that currently work work, but it's also a big piece of the reason that stuff that doesn't work doesn't work, and why the stuff that does work is centralised rather than peer-to-peer. – James_pic Apr 29 '20 at 14:38
  • @James_pic Do you want to manage firewalls and inspection devices distributed over thousands of users with multiple OSes? – Ron Trunk Apr 29 '20 at 15:07
  • @RonTrunk even in a fully IPv6 world, with everything end-to-end, nobody should have to do this. In IPv6, the router that currently acts as a NAPT gateway and firewall loses the NAPT, but remains a firewall and a router. Network admins who want to block everything but outbound port 443 will remain able to do so, in exactly the same way they do now. The only real change is that it's now possible to have inbound connection policies other than deny all (deny all is still an option). And developers will continue to stuff everything through port 443, largely negating the value of the firewalls. – James_pic Apr 29 '20 at 15:17
  • @James_pic I know we network admins are a bunch of megalomaniac, power hungry SOBs, but still traffic inspection is necessary. So proxies will still exist, as will load balancers that have to read payloads. – Ron Trunk Apr 29 '20 at 18:38