Since most IPv4 addresses are taken (and many people have not yet started their transition process to IPv6), we need to make sure that we have all the tools available to make the most of the remaining addresses without breaking the Internet even more than we did with NAT.
Carrier Grade NAT (CGN) or Large Scale NAT (LSN) proposes to run NAT at the Service Provider rather than, or in addition to, the Customer Premises Equipment (CPE).
There are many solutions based on LSN such as NAT444, NAT464 or DS-Lite. These solutions have many issues including severe scalability issues and sometimes also some network design issues (NAT444). LSN is a single point of failure as it must keep a big amount of states and should any LSN device reboot, many users will see their sessions restarted and will experience some problems with their applications. It is a severe concern when more and more people use the Internet for real time applications like VoIP, WebEx or video.
With LSN, it becomes also impossible to track a user with its IP address; a user cannot configure some static NAT translations to run some inside servers, and if an Application Layer Gateway (ALG) must be installed to support a new application, the Service Provider must install it.
2. An alternative to LSN/CGN: A+P
A+P (Experimental rfc6346) gives another solution for sharing IPv4 addresses among users without LSN and all its known issues.
This solution uses some of the source port to share an IPv4 address among multiple users.
A+P has many benefits:
- It does not have the scalability issue of LSN.
- It does not break the end-to-end model of the Internet in most cases.
- It does not require keeping much states in the SP network.
- Users can be tracked with their IP address and source port.
- It does not bias the users from migrating to IPv6 as NAT444 does.
For successful implementation, A+P requires the following features:
A+P can run on all hosts and routers in the network. If this is not the case, some routers called Port Range Routers will be responsible to establish tunnels through existing devices. These tunnels can be IPv6, IPv4 or Layer 2.
If hosts are not upgraded to support A+P, they will still think that they have all the source ports available for a given address and the CPE will have to do some kind of translation to make sure that only the ports allocated to a site will be used.
A+P requires some signaling to discover which ports are available for an address.
The initial proposal actually relies on dIVI-pd, more exactly dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation and 4rd. It does not require any signaling to operate.
3. A+P Limitations
A+P also comes with some limitations but it does not share the scalability issue and should require keeping fewer states not to be such a hot single point of failure like LSN.
The A+P limitations are:
- ICMP will need particular processing, as it does not have any port available.
- Fragmentation will need reassembly as A+P needs the port information in each packet.
- An application that may require a particular port may not have it available, as only a port range will be allocated to each CPE.
4. Standardization and Current Work in Progress.
Ole Troan has been a great CISCO IPv6 Engineer Team Leader for many years. He was responsible for most IPv6 IOS projects and participate to most IPv6 protocols developments. He also worked on writing many RFCs. He is now an independant consultant very active on many projects and very much involved in A+P.
Ole Trøan: IETF Softwires is in the progress of standardizing a stateless IPv4 over IPv6 A+P variant. That does not require any signaling for the port space. Initial proposals are 4rd and dIVI-pd.
Ole Trøan • Well, the idea probably originated from SAM (Stateless Address Mapping) by Remi Despres. Or was invented independently. In any case the port set id for the purpose of routing isn’t going in the suffix, it is going to be in the prefix delegated to the mapped node. The simplest way to think about this is that embedded in the IPv6 address is an IPv4 suffix used to calculate an IPv4 address, and a port prefix used to calculate the port space. E.g. an end user is allocated /8 worth of port space (256 ports). We are merging a number of the ideas and documents in this space, so wait until after the Taipei meeting.
Also the Wiki page about dIVI and dIVI-pd is very interesting:
“Stateless NAT464 (dIVI, dIVI-PD) is intended to benefit the network operators (ISPs) to effectively share the public IPv4 addresses among a set of customers (since IANA has run out of public IPv4 addresses). In parallel, it leverages IPv6 in the network in a manner that makes IPv4-customer originated traffic looks like native IPv6 traffic in the network, resulting in simplified operations. More importantly, (unlike CGN44, DS-Lite, CGN64 etc.) dIVI/dIVI-PD does not require any Stateful NAT, DNS64 and ALG in the network, thereby benefiting the network operator to not deal with any NAT logging etc. dIVI maintains end-to-end address transparency and bidirectional-initiated communications.
Suffice to say that Stateless NAT464 (dIVI, dIVI-PD) keeps any stateful NAT44 where it belongs – Customer Premises (e.g. Homes).”
This is an interesting draft about dIVI testing in a large SP network environment: “Considerations for Stateless Translation”
"4.2. Experiment configuration In our experiment, we selected ratio to be 128. That is to say, one IPv4 address is shared by 128 users, and there are 512 available ports per user."
Next IETF meeting will take place in Taipei, November 13-18 and we may see many updates coming in this area!
A+P is an alternate choice to LSN transition tools but not an alternate choice to IPv6, which is still the only solution for the Internet.
A+P is an architecture which relies on many protocols to provide IPv4 Addresses Sharing among multiple users by using the source port. First A+P proposal relies on dIVI, dIVI-pd and 4RD and does not require any signaling.
It does not have most of the LSN/CGN issues.
On the other hand, it will not be of any help for enterprises that require IP addresses without any port restrictions.
Most of the signaling protocols are still “Work In Progress” but the developers can confidently deliver it in time. So it is still mostly in development but could be ready in about 5 months from now.
For some early testing, there is an Open Source implementation available from Orange FT Labs: