Any general-use IP protocol stack that supports IPv6 also supports IPv4. That is, it is dual stack capable. “General-use” is an important qualifier here: Certainly there will be specialized devices that support only IPv6. But these devices – until we get to some unspecified time in the future where IPv4 no longer exists – function in “walled garden” applications such as sensor or control networks that have distinct boundaries and never interact with IPv4. The important significance of dual stacking is that if one of the devices in a two-way conversation can speak both IPv4 and IPv6, it does not matter if the device on the other end is restricted to one or the other version. As long as one of the two speakers is “bilingual,” a conversation can take place.
Dual stacking is therefore the simplest way to begin deploying IPv6. If all the devices in an IPv6-enabled network are dual stacked, they can speak to any destination whether it is IPv4 or IPv6. This is extremely important in the early stages of deployment, when the vast majority of destination content on the public Internet is still IPv4-only.
The glaring problem with dual stacking, as I discussed in the previous post, is that the chief reason why we need to begin deploying IPv6 at all is that we are quickly running out of IPv4 addresses. How do you put both an IPv6 address and an IPv4 address on every interface if you have run out of IPv4 addresses?
The fact of the matter is that we actually ran out of globally unique IPv4 addresses a long time ago. You may ask (sounding a little like Tevye), “How can this be? The IANA still has 28 /8 IPv4 address blocks that have not yet been allocated. That’s about 469 million addresses. We have not run out of IPv4 addresses!”
My answer is that we have given ourselves the illusion of having enough IPv4 addresses by nicely sharing the addresses we have.
One means of sharing is dynamic address allocation using DHCP. We assume not all devices on a given network need to be online at the same time, so we lend an address out of a limited pool as a device needs it, and reclaim the address when the device is done with it. The address can then be given to some other needy device. We are statistically multiplexing the address pool.
That worked fine in the 1990s, but more and more these days network-connected devices want to be “always on.” That means devices hold on to the addresses they’re given, reducing the number of addresses that can be shared on an as-needed basis.
The other means of sharing globally unique IPv4 addresses, and by far the more successful, is the venerable Network Address Translation (NAT). Specifically NAT44, which translates an IPv4 address to another IPv4 address. Private (RFC1918) IPv4 addresses are used within a given network; the assumption here being that within a network most IP devices only want to talk to other IP devices in the same network.
But because RFC1918 addresses can be reused in different networks, they are not globally unique. When a device on one network wants to talk to a device in a different administrative domain, reachable across the public Internet, there is no guarantee that the two devices are not using the same address. There is also no way for routers in the public domain to differentiate between networks using the same address blocks.
So we put NAT44 (normally residing either in a router or a firewall) at the edge of the network where it interfaces to the public Internet. The NAT has one or more globally unique IPv4 addresses. and as a packet passes from its inside or private interface to its outside or public interface, NAT replaces the packet’s private IPv4 address with one of its public IPv4 addresses. The NAT “remembers” which inside device the packet came from by mapping the inside address to the outside address.
If NAT44 did no more than I have described so far, it would have the same problem as dynamic address allocation: The pool of available addresses would not scale to the demands of modern networks of “always-on” devices. The assumption that most network-internal devices talk to other network-internal devices most of the time is no longer valid, as more and more data exchanges are across the public Internet.
NAT44 overcomes this scaling problem by using not only its pool of public IPv4 addresses but also the port numbers available with each of the addresses. TCP and UDP headers support up to 65,536 port numbers, most of which are unused. So by mapping an internal [private address, port] tuple to an outside [public address, port] tuple, NAT44 is really mapping sessions rather than devices and can support a very large number of sessions with each public address.
This approach has variously been called Network Address and Port Translation (NAPT), Port Address Translation (PAT), address overloading, or IP masquerading in the past. These days it’s just considered a standard function of NAT44.
NAT has been around since the early to mid 1990s, when it was one of several short-term solutions (along with DHCP, RFC1918 addresses, and CIDR) created to slow the depletion of IPv4 while a next-generation Internet Protocol – which eventually became IPv6 – was developed. Back then it was just called NAT, not NAT44, because translating an IPv4 address to another IPv4 address was the only option there was. There was no need to distinguish it from, say, NAT64, because IPv6 did not yet exist and so something that could translate between IPv4 and IPv6 did not yet exist either.
Getting back to the dual stack dilemma that service providers face: Why not NAT the IPv4 half of dual stack connections to customers? That gets customers started on IPv6 while still providing IPv4 connectivity.
This is the basis for Carrier Grade NAT (CGN). Traditional NAT – CPE NAT – appears at the edge of the customer network where it connects to a service provider, and translates between private IPv4 addresses within the customer network and one or a few public addresses assigned by the provider. CGN appears within the service provider network. It, too, translates between private and public IPv4 addresses; the private side of the CGN faces the provider’s customers.
I other words, CGN enables service providers to assign private RFC 1918 IPv4 addresses to their customers rather than public, globally unique IPv4 addresses. Once again NAT comes to the rescue of a dwindling address supply.
It also raises the question: Why not just use CGN and forget about IPv6? I’ll address that question (forgive the pun) in a later post, after we’ve looked further into the various CGN issues and architectural options.
The first issue around CGN is the name. There is no real distinction between a CGN and any other NAT, other than the assumption that if it appears in a service provider network it is probably going to be on a carrier class router. But there are no specified qualities that make CGN “carrier grade” in and of itself.
Because nothing really defines the “Carrier Grade” part of CGN, a movement is afoot to change the name to “Large Scale NAT” (LSN). I kicked off this article using the term CGN, because that’s still the term most people are familiar with. But I’m going to pull a switcheroo and use “Large Scale NAT” in subsequent articles, now that I’ve had a chance to explain why the name is changing: LSN better reflects the intent of a NAT that serves a large number of service provider customers, say in a single PoP, and must scale to a massive amount of customer traffic.
Also by taking the “carrier” reference out of the name it better reflects the fact that LSN is a NAT solution that can be used in more than just service provider scenarios. It can be useful in any large-scale network.
Apart from the need to scale, the other big issue with LSN is the fact that it is used to assign RFC 1918 addresses to customers, which then use the addresses on the “public” side of their own NATs. Those CPE NATs are then translating from customer-side RFC 1918 addresses to provider-side RFC 1918 addresses. So end-user traffic is now passing through a two-tiered or hierarchical NAT architecture rather than a single device.
That architecture, and the issues that arise from having private IPv4 addresses between the LSN and the CPE NATs, are the subjects of my next post.
Jeff Doyle is president of Jeff Doyle and Associates, an IP network consultancy. Jeff is the author of Routing TCP/IP, Volumes I (read an excerpt) and II and of OSPF and IS-IS: Choosing an IGP for Large-Scale Networks. He is a frequent speaker on IPv6, MPLS, and large-scale routing.
The Leader in Network Knowledge
Good One!
Like to read this continuously, but just curious, instead of having the customers getting involved in the equation at the start, why not have the backbone use only ipv6 ?
So any router connecting ONLY to another router can talk over ipv6, or is it too small even in the perspective of slower change?
Cheers,
Rajesh
IPv6 in the Core
Hi Rajesh,
If I understand your question correctly (and please do re-state it if I have misunderstood it), the reason customers must be involved in an IPv6 deployment is that that's where new IP addresses are needed. At least, from a service provider viewpoint. This is especially true of broadband service providers, who have very large, commoditized customer bases served at very thin margins and who depend on a continual supply of new customers -- and hence a continual supply of new IP addresses -- to stay in business.
Thus any broadband service provider who is not ready for IPv6 is going to be hit hard when IPv4 addresses become unavailable.
But in the core, there's really not much of an IPv6 issue. That part of the network grows slowly, and could be sustained on IPv4 for quite a while yet.
So the real issue for a service provider's core is not adding IPv6 because the addresses are needed, but adding it because it must transport IPv6 customer packets. Usually there are two choices: Either dual stack the core routers or leave the core interfaces IPv4 only and use MPLS to tunnel IPv6 across the core. For service providers who already have an MPLS core (and most do these days), I strongly recommend the second option. I also usually recommend starting an IPv6 deployment in the core rather at the customer edge, for a number of reasons that I won't go into here.
So getting around to your question of making the core IPv6 only, that's not practical for the time being because most customer traffic is still going to be IPv4 for a while yet. A core that cannot carry IPv4 just isn't practical for a service provider.
--Jeff
I wait patiently for Juniper
I wait patiently for Juniper to make this happen on the M-series.. all those annoying NAT restrictions... gone! We are not a carrier, but we are in a sense a service provider. Thousands of private customer networks converge on our data center to use hosted applications.
So we have large carrier boxes at the edge of our network doing L3VPN for all of our customers. We NAT them coming into our environment out of their VRFs...
Our requirement is not based on capacity, but on configuration scalability. We need, literally, thousands and thousands of NAT translations across thousands of virtual-routers.
CGN will save us! I hope!
Interesting Read
Jeff - extremely clear article - thanks for the interesting read. I've posted a short perspective on my blog http://blogs.cisco.com/sp/comments/the_compelling_business_case_for_ip_addressing_technologies/
And if you're interested, we have Fred Baker, former Chair of the IETF, taking questions this week. You can read about details here https://www.myciscocommunity.com/community/sp/mobility/blog/2009/09/04/fred-baker-former-ietf-chair-answers-your-ipv6-questions
Thanks again, MikeC - Cisco
Use Of LISP Architecture
I am interested in the IPv6 deployment but think there would be lot of operation involved in that. The main point is to remember the address.
There is one more architecture proposed of LISP where in we will use the IPv4 addresses endlessly.
LISP
Hi Shilu,
Personally I'm skeptical whether LISP (Locator/ID Separation Protocol) will ever be used, for a number of reasons. But it would certainly be a god topic to cover. Thanks for the suggestion!
-- Jeff
back to the old days - IPv4 address pool multiplexing
Jeff,
I like the idea of going back to multiplexing IPv4 addresses. Users will be always on with their globally unique IPv6 addresses while the IPv4 addresses is given to te residential gateway only on demand - let's say when the DNS response for www.sample.com only returns an IPv4 and no IPv6 address. Over time we use less IPv6 addresses and people are still always on with their VoIP and TV services (running IPv6).
What do you think?
I my opinion, CGN or LSN doesn't work well with the many users each having many sessions (just think about bittorrent) and all the problems with ALGs.
Kai
Re: Old Days
Hi Kai,
I have the same doubts about LSN. Bittorrnet is a good example; so is Google Maps or Amazon, where a single page view can open dozens of individual TCP sessions. An LSN that might be ultimately serving thousands of end users might struggle to maintain mappings, and ports on the outside addresses could be depleted.
The problem with multiplexing IPv4 addresses, however, is the "always on" model. Where some years ago applications didn't try to hog so much network resources, they're more likely to now be less tolerant of having to wait for an address assignment every time they want to "go public."
That's something that everyone needs to understand about LSN in its several different architectures: It's still a band-aid on the IPv4 problem.
--Jeff
Post new comment