Mapping of Address and Port

Mapping of Address and Port (MAP) is a Cisco IPv6 transition proposal which combines A+P port address translation with the tunneling of legacy IPv4 protocol packets over an ISP provider's internal IPv6 network.^[1]

MAP combines uses the extra bits available in the IPv6 address to contain the extra port range identifier bits of the A+P addressing pair that cannot be encoded directly into the IPv4 address, thus completely eliminating the need for "port routing" within the carrier network by leveraging the provider's own IPv6 rollout.

In effect, MAP is an (almost) stateless alternative to Carrier Grade NAT and DS-Lite that pushes the IPv4 IP address/port translation function (and therefore the maintenance of NAT state) entirely into the existing customer premises equipment IPv4 NAT implementation, thus avoiding the NAT444 and statefulness problems of Carrier Grade NAT in operator network, and also provides a transition mechanism for the deployment of native IPv6 at the same time with very little added complexity.

There are two operational modes in the overall MAP framework: one, MAP-T, uses protocol translation to carry its IPv4 traffic, and the other, MAP-E, uses encapsulation. MAP-T results in stateless NAT64 operation on both CPE router (within the home network) and on the Border router (within the operator network), whereas MAP-E results in stateless encapsulation/decapsulation of IPv4-over-IPv6 packets on both CPE router (within the home network) and on the Border router (within the operator network). Of course, both modes leave the stateful NAT44 on the CPE router.

MAP is fast progressing through the standardization at the IETF within Softwire Working Group. Interesting enough, Translation and Encapsulation modes were part of the single IETF MAP specification until version-1,^[2] however, during the IETF 84 softwire WG meeting in Vancouver, the decision was made to separate them out in two separate specifications: MAP-E and MAP-T. The decision was made by flipping the coin during the meeting, as reflected in the meeting-minutes.^[3]

                Coin toss: between MAP being one or two solutions.
                Ralph is calling.
                One solution is what Ralph calls in the air. Brian throws.
                Results is tails: MAP is two solutions.

^[3]

Since IETF 84 softwire WG meeting, both MAP-T and MAP-E specifications have become active items internet draft in the softwires working group. The IETF 84 softwire WG meeting also resulted in putting MAP-E on the standards track and MAP-T on the experimental track with an intent to speed up the progress of standardization of at least one specification and allow converting the experimental to standards track as/when appropriate (this is commonly allowed by the IETF process, of course. A good example is IPv6 RA option for RDNS was standardized in experimental track RFC5006 ^[4] first, and in standards track RFC6106^[5] later). Both specifications should soon become the RFCs.

MAP-T ^[6]

MAP-E ^[7]

See also

• DS-Lite
• IPv4 Residual Deployment (4rd)

References