IPv6 Addressing: How Wrong Can You Get It?
Mike was wondering whether his ISP is giving him what he needs to start an IPv6 pilot within his enterprise network. He wrote:
So I got an IPv6 assignment with a /120 mask (basically our IPv4/24 network mapped to IPv6) and two smaller networks to use for links between our external router and the ISP.
Dear Mike’s ISP: where were you when the rest of the world was preparing to deploy IPv6? Did you read IPv6 Unicast Address Assignment Considerations (RFC 5375) or IPv6 Address Allocation and Assignment Policy from RIPE or your regional registry?
Let’s start with prefix lengths. RFC 5375 is very explicit (section 3):
Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others.
It’s therefore highly recommended to use a /64 prefix on every subnet. The use of longer prefixes on point-to-point inter-router links is debatable (some people recommend /126 or /127, others /112). Properly implemented network devices have no problem with shorter subnets; after all, IPv6 is classless. However, to ensure you won’t get a hiccup from a just-good-enough-too-cheap-to-pass box someone will eventually connect to your network, be conservative and use /64 everywhere.
Summary: assigning someone a public /120 prefix is ... let’s be diplomatic ... out of touch with reality.
So, Mike got a /120 and tried to make sense out of it. He needs to allocate IPv6 addresses to the whole network and somehow can’t do that with a /120. Here is the next bit of wisdom passed to him by a helpful colleague (I’m not making this up either):
I asked someone more familiar (but no hands-on-experience) about this, and got the answer that I should use a link-local or unique-local addresses beginning with fe08 or fd for all computers within the company, the same way we use RFC1918 addresses today, and then just NAT them to the /120 network I got assigned from the ISP.
We were all confused by the plethora of different types of IPv6 addresses (Packet Pushers IPv6 podcast has a lively debate on that topic), but they are really not that hard to grasp. Let’s over-simplify them a bit:
- Link-local addresses are a better solution for unnumbered interfaces and other communication needs before you get a real IPv6 address (for example, DHCPv6 request packets are sent from a link-local address);
- Unique local addresses (ULA) can be used for intra-network connectivity (for example, for those hosts and servers that never communicate with the Internet). Your host could have an ULA and a global IPv6 address (or even more than one global address) and use one or the other as needed.
- In most cases, your hosts should have a globally unique IPv6 address.
Regardless of whether you decide to use ULA or not, remember that there is no NAT in IPv6 (although some people are seriously longing for NAT66). Let me repeat that: there is no NAT in IPv6.
Mike is thus stuck: he needs a /64 on every subnet in his network and got a meager /120 from the ISP. What’s wrong? The ISP’s IPv6 address allocation policy.
A minimum allocation an ISP has to give to a residential end-user is a /64. If a residential end-user needs multiple subnets, he should get a /56. Minimum end-site allocation is /48 (Mike should thus get a /48, not a /120). Minimum provider-independent allocation assigned by RIPE or ARIN is /48.
Mike could get 65000 /64 prefixes from the /48 prefix he should have got from the ISP, probably more than enough to number his entire network. If you have a larger network, it’s not hard to get a larger allocation; you just have to provide the paperwork documenting your needs.
Summary: If you are an enterprise customer and your ISP is giving you anything less than a /48, it’s time to consider changing the ISP.
For more information, check out ipSpace.net IPv6 webinars.
Also - there are implementations of NAT66 in existence already openBSD PF being one.
Also - there are implementations of NAT66 in existence already openBSD PF being one.
Jens Link's point is probably one of the most technically valid reasons for NAT66. Auto-renumbering of IPv6 networks is not a current reality, and it's not clear if will ever materialize. If you look at the IETF and informational drafts its clear that there's a lot of implementation details in relation to IPv6 that are being worked out, but the good news is that people are working hard at it.
More disconcerting to me is the idea that residential users should some how be treated as second-class end-sites and be given /56s or worse, /64s. There is no good reason not to give residential customers /48s like any other end site. There are MANY good reasons to give them /48s, not the least of which is to support likely innovation in the area of automatic prefix delegation and self-determining network hierarchies within the home.
Sometimes it's not just about the number of possible end subnets. Sometimes it's about the number of bits available for topology and hierarchy.
There are approximately 7 billion people on the planet with an average household being 3.2 people per household. As such, there is need for approximately 2 billion /48s to support every existing residence. Even if the population doubles, that's still only 4 billion households. All of that could be contained within a single /16 of IPv6 space, giving every household a /48. Really, if we can support double the current number of households with /48s using only 1/65,536 or 0.001% of the total address space, i don't see the problem with being that generous with addresses.
Even Cisco ( the buys that published (RFC 6296).
NAT 66 is needed:
a) Security. NAT is a deny first policy.
b) Management. Organize you internal networks as you like, not limited by the public networks delivered to you.
c) Multi-home. Try to switch IPv& after a fail of your ISP in just 2 min. Try to renumber your ENTIRE internal IPv6. Yeah, right!
I'm not particularly advocating NAT66 - just saying that to claim 'there is no NAT in IPv6' is a bit of an exaggeration. Of course this argument has been done to death hundreds of times already, unfortunately it's not always the best solution that wins out. I guess we'll only find out if it'll become widespread or not once CPE vendors finally get round to implementing IPv6.
(sorry for the triple post btw - the javascript actually told me it had retried 3 times and failed all of them?)
As for SLAAC and Microsoft - this time they did the right thing for the residential customers (but of course every enterprise network engineer hates them when he has to troubleshoot the network).
As for "MANY good reasons to give them /48", I would kindly ask you to give me a few - I always love to reduce my ignorance.
Last but not least, I'm somewhat tired of hearing how this-or-that is stifling innovation. There are many things that have that effect, but 8 bits in IPv6 address is definitely not on my list of those things. Even the numerous broken NAT implementations were not able to stifle innovation when people really wanted to roll out exciting new products or services.
Frank
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
"'randomizeidentifiers' is not a valid argument for this command."
XP lacks "full" IPv6 support.
As a comparison, look at CLNP. CLNP is a nice protocol, but how do you optimize an implementation for a loosely defined address space? Look what router vendors ended up doing.
One of my many interests is in embedded Linux. Just about all run-from-rom devices that use it these days (whether they admit it or not, and most do) are built around Linux, particularly modified Debian 2.4 kernels with various hacked up versions of busybox, wrapped in a webinterface. And not just router CPEs I'm talking, also NASs and a whole lot of other stuff out there. (tv sets, cable modems, DSL modems, etc.) The SOHO router stuff hitting the market today is more and more 2.6 kernels now but all of them chintz enormously on the amount of flash. 4MB is still almost always used but some of the better gear uses 8MB. And 32MB of ram is usually a max also.
Anyway, with all due respect to the OpenBSD pf NAT66 implementation, you simply aren't going to see NAT66 in these inexpensive SOHO CPE devices until it's integrated into iptables, into the standard distro. And the only alpha-quality NAT66 implementation out there for iptables is http://map66.sourceforge.net/ That one was written more from a "prove it can be done" than anything else, and the developer has already said he's not going to do anything more on it for now.
These manufactures - and you can include Cisco with it's Linksys and "SOHO Business Routers" like the RVS4000 - simply aren't going to put in experimental modules into iptables for their devices. The chance of an undetected memory leak is high and it's not like your running on a PC with 4GB of ram where a few bytes of leakage can go for months if not years before it becomes a problem. And they aren't going to sink development dollars into it either - the entire point of using Linux on these devices in the first place is to leverage other people's work, particularly the Linux developers. Besides that they have enough problems with dealing with the chip vendors like Broadcom, Intel, Atheros, and so on, removing bugs from their hardware drivers and integrating them into the embedded linux code they are using.
So, in summary you might possibly see a NAT66 implementation in a Cisco or Juniper $10,000.00 router or a $5K firewall from Checkpoint or some such, but you won't see it in Ma and Pa Kettle's home cable modem until the major Linux distros adopt it - and the iptables developers won't accept anything like that until the IETF has agreed on a standard and a lot of people in the community have put time into beating on someone's set of patches. And that would be years from now even if a solid set of patches adding NAT66 into iptables existed today.