Support for RFC7599, Mapping of Address and Port using Translation (MAP-T), has been added to CDRouter 10.2. Support for RFC7597, Mapping of Address and Port with Encapsulation (MAP-E), was added to CDRouter 11.1. Both MAP-E and MAP-T are stateless NAT64 techniques that are designed to deliver IPv4 services over native IPv6 connections without having to deploy a full dual-stack network infrastructure. They also incorporate some carrier grade NAT (CGN) concepts by allowing multiple end user devices to share a single public IPv4 address. In this document, we will use the term MAP to refer to the technology shared between both MAP-E and MAP-T. While MAP-E and MAP-T are very similar, they do have some important differences which we will discuss below.
A more complete description of MAP can be found in the introduction of RFC7599:
Experiences from initial service provider IPv6 network deployments, such as RFC6219, indicate that successful transition to IPv6 can happen while supporting legacy IPv4 users without a full end-to-end dual-IP-stack deployment. However, due to public IPv4 address exhaustion, this requires an IPv6 technology that supports IPv4 users utilizing shared IPv4 addressing, while also allowing the network operator to optimize their operations around IPv6 network practices. The use of double NAT64 translation-based solutions is an optimal way to address these requirements, especially in combination with stateless translation techniques that minimize operational challenges outlined in Solutions- 4v6.
The Mapping of Address and Port using Translation (MAP-T) architecture specified in this document is such a double stateless NAT64-based solution. It builds on existing stateless NAT64 techniques specified in RFC6145, along with the stateless algorithmic address and transport-layer port-mapping scheme defined in the Mapping of Address and Port with Encapsulation (MAP-E) specification RFC7597. The MAP-T solution differs from MAP-E in that MAP-T uses IPv4-IPv6 translation, rather than encapsulation, as the form of IPv6 domain transport. The translation mode is considered advantageous in scenarios where the encapsulation overhead, or IPv6 operational practices (e.g., the use of IPv6-only servers, or reliance on IPv6 + protocol headers for traffic classification) rule out encapsulation. These scenarios are presented in MAP-T-Use- Cases.
Additionally, support for RFC7596, Lightweight 4over6 (LW4o6), was added to CDRouter 11.6. From the perspective of a CE, LW4o6 can be thought of as a variant of MAP-E with a few additional constraints imposed on the its configuration parameters. CDRouter’s LW4o6 lwAFTR implementation is built on top of its MAP-E implementation and thus reuses the MAP testvars to configure LW4o6. This is possible because CDRouter only provides LW4o6 functionality for a single CE, however this approach means that certain LW4o6-specific parameters (for example the lwB4’s IPv6 binding prefix) are not as configurable as they would be in a real deployment.
Introduction to MAP
ISP’s are running out of public IPv4 addresses and want to move away from using IPv4 in their internal network. One way to get more mileage out of a finite set of public IPv4 addresses is to share a single IPv4 address amongst multiple customer edge, or CE, devices. This is sometimes referred to as Carrier-Grade NAT or CGN. Sharing requires that each CE with the same IPv4 address use different TCP/UDP ports. This is the route that MAP takes. It is a mechanism to statelessly provide IPv4 connectivity via shared IPv4 addresses in an IPv6-only ISP network.
In MAP, IPv4 packets coming from the CE become IPv6 packets while going through the IPv6-only ISP network on their way to the public IPv4 internet. Similarly, IPv4 packets coming from nodes on the public IPv4 internet become IPv6 packets while going through the IPv6-only ISP network on their way to the CE. The CE performs NAPT44 on IPv4 packets from LAN clients. This means the CE rewrites the source IPv4 address and TCP/UDP port and stores a NAPT44 binding before sending the packet through the IPv6-only ISP network.
The first way that MAP-E and MAP-T differ is in how IPv4 packets become IPv6 packets when passing through the IPv6-only ISP network. MAP-E encapsulates the original IPv4 packet in an IPv6 packet, whereas MAP-T translates the original IPv4 packet into a new IPv6 packet. Put another way, an IPv6 header is added to the original IPv4 packet in MAP-E, while an IPv6 header replaces the original IPv4 header in MAP-T.
User N Private IPv4 | Network | O--+---------------O | | MAP CE | | +-----+--------+ | | NAPT44| MAP | | | +-----+ | +-._ ,-------. .------. | +--------+ | ,-' `-. ,-' `-. O------------------O / \ O---------O / Public \ / IPv6-only \ | MAP |/ IPv4 \ ( Network --+ Border +- Network ) \ (MAP Domain) / | Relay |\ / O------------------O \ / O---------O \ / | MAP CE | ;". ,-' `-. ,-' | +-----+--------+ | ," `----+--' ------' | NAPT44| MAP | |, | +-----+ | + | | +--------+ | O---+--------------O | User M Private IPv4 Network
Each CE is assigned a special IPv6 address used as its IPv6 source address for
sending IPv4 traffic through the ISP’s IPv6-only network. The CE’s public
IPv4 address is encoded in the interface ID of this IPv6 address. This is not
the whole story, however. The public IPv4 address
18.104.22.168 is shared
across multiple CE’s and each CE is only allowed to use a subset of the
TCP/UDP ports for that public IPv4 address. Therefore the allowed ports must
also be encoded into the IPv6 source address’s interface ID as well. So a
192.168.1.100 port 1024 sent to
22.214.171.124 port 1050 becomes
2001::[126.96.36.199 ports 1000-2000] port 1048 to
port 1050. This allows the ISP network to statelessly validate that the
TCP/UDP port chosen by the CE is valid port for that CE.
The special IPv6 address assigned to a CE is also composed from a special IPv6 prefix and an interface ID. The IPv6 prefix encodes a portion of the public IPv4 address used by the CE. When sending MAP traffic, the interface ID of this source address embeds the CE’s full public IPv4 address as well as its allowed port ranges as defined by RFC 7599 Section 6:
| 128-n-o-s bits | | 16 bits| 32 bits | 16 bits| +--------+----------------+--------+ | 0 | IPv4 address | PSID | +--------+----------------+--------+
The second way in which MAP-E and MAP-T differ is the IPv6 destination address
used for sending IPv4 traffic through the ISP’s IPv6-only network. In MAP-E,
the IPv6 destination address is set to the IPv6 address of a special node in
the ISP network which receives MAP traffic and has connectivity to the native
IPv4 internet. In MAP-T, this cannot be done since the original IPv4 header
is removed and the IPv4 destination address must be preserved somehow.
Therefore, in MAP-T the IPv4 destination address is encoded in the interface
ID of another special IPv6 prefix used to address nodes on the public IPv4
internet. So essentially a packet from a LAN client
for a host on the IPv4 internet
(NAT’ed source IP) to
4001::[188.8.131.52] (destination IP) when translated and
sent out the CE’s WAN interface.
The special IPv6 address used to encode IPv4 addresses destined for the public IPv4 internet is composed from a special IPv6 prefix and an interface ID. The interface ID encodes the destination IPv4 address using the method laid out in RFC 6052 Section 2.2:
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |32| prefix |v4(32) | u | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |40| prefix |v4(24) | u |(8)| suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |48| prefix |v4(16) | u | (16) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |56| prefix |(8)| u | v4(24) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |64| prefix | u | v4(32) | suffix | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |96| prefix | v4(32) | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
For example, if the IPv6 prefix for the public IPv4 internet is
the CE is trying to send a packet to the public IPv4 internet address
it would use the destination IPv6 address
4001::303:3:300:0:0. The ISP
network can differentiate native IPv6 traffic from MAP-T traffic destined for
the public IPv4 internet by checking if the IPv6 destination address is within
Default and Basic Mapping Rules
The node in the ISP network which receives MAP traffic and has connectivity to the native IPv4 internet is called the Border Relay or BR. The IPv6 prefix and prefix length used by the CE to generate its source IPv6 address is called the Basic Mapping Rule or BMR. The BMR also contains an IPv4 prefix and prefix length which the CE uses to learn a portion of its public IPv4 address.
The third and final way that MAP-E and MAP-T differ is the additional mapping rule required for MAP-T. The IPv6 prefix and prefix length used to translate IPv4 addresses on the public internet into an IPv6 address is called the Default Mapping Rule or DMR.
The BMR (and DMR if using MAP-T) must be the same for all CE’s and BR’s in the same MAP domain and can either be statically provisioned or learned via a mechanism such as DHCPv6, TR-069 or NETCONF. The DHCPv6 options for MAP are defined in RFC 7598.
While the BMR IPv4 prefix does contain part of the CE’s public IPv4 address, it generally does not contain all 32 bits. Furthermore, the BMR contains no information about the CE’s allowed port ranges. This makes sense, since all CE’s in the same MAP domain must be configured with the same BMR. If a CE learned its public IPv4 address and port ranges solely from the BMR, all CE’s in the same MAP domain would end up with the same IPv4 address and port ranges. So how does the CE learn its full public IPv4 address and how does it learn which ports it is allowed to use? The CE derives this information by combining the BMR with a longer, CE-specific prefix known as the End-user IPv6 prefix. The End-user IPv6 prefix must be contained within the BMR’s IPv6 prefix and can be statically provisioned but is usually learned via DHCPv6 PD.
Assume a MAP-T domain is using a DMR of
4001::/48 and a BMR of
184.108.40.206/24. This implies that all CE’s will be assigned a public
IPv4 address within the
220.127.116.11/24 prefix, that a CE’s source IPv6
address will be within the
2001::/40 prefix and that nodes on the public
IPv4 internet can be addressed using the
Now suppose a CE is assigned an End-user IPv6 prefix of
DHCPv6 PD. Note that the BMR IPv6 prefix length is 40 and the End-user IPv6
prefix length is 56. This means there are an 16 extra bits that are not in the
BMR IPv6 prefix. There is actually a third component of the BMR called the
Embedded Address bit length or EA-bit length. The End-user IPv6 prefix
assigned to a CE must have a prefix length at least EA-bits length longer than
the BMR IPv6 prefix length.
| n bits | o bits | s bits | 128-n-o-s bits | +--------------------+-----------+---------+-----------------------+ | Rule IPv6 prefix | EA bits |subnet ID| interface ID | +--------------------+-----------+---------+-----------------------+ |<--- End-user IPv6 prefix --->|
The 16 EA-bits from the End-user IPv6 prefix are combined with the BMR IPv4 prefix to compute the CE’s full public IPv4 address and allowed port ranges. The CE uses as many EA-bits from the End-user IPv6 prefix to fill in the BMR’s IPv4 prefix so that a full 32-bit IPv4 address is formed. In the example above, since the BMR IPv4 prefix is a /24, the first 8 bits of the EA- bits must be used to complete a full 32-bit IPv4 address. This is the CE’s public IPv4 address on the WAN. The remaining EA-bits not used to complete the IPv4 address is known as the CE’s port set ID or PSID. The number of EA-bits that remain for use in the PSID controls how many or how few ports a CE is allowed to use. In the example above, the CE would have an 8 bit PSID.
How does a CE use its PSID to determine which port ranges it’s allowed to use with its public IPv4 address? By default, the CE’s PSID must be hardcoded into all TCP/UDP ports used by the CE starting at bit 6. A BR will drop a packet from the CE if the TCP/UDP port does not contain the appropriate PSID bits. However, the PSID doesn’t have to start at bit 6. The MAP domain can be configured with a PSID offset which controls how many bits from the left the PSID is stored in. The PSID offset controls where the first allowed port begins. The default PSID offset of 6 results in a starting port of 1024, thus preventing the CE from using well-known ports 0-1023. All of this is laid out in more detail in RFC 7597 Section 5.1.
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-----------+-----------+-------+ Ports in | A | PSID | j | the CE port set | > 0 | | | +-----------+-----------+-------+ | a bits | k bits |m bits |
To summarize, a MAP domain is always composed of a BMR and a PSID offset. If using MAP-T, there is also a DMR. A BMR is composed of an IPv6 prefix and prefix length, an IPv4 prefix and prefix length and an EA-bits length. A DMR is composed of an IPv6 prefix and prefix length. All CE’s and BR’s in the same MAP domain must be configured with the identical BMR, DMR (if using MAP-T) and PSID offset, all of which can be provisioned via DHCPv6 options. The DMR IPv6 prefix is used by MAP-T to address nodes on the public IPv4 internet. A CE learns its full public IPv4 address and allowed port ranges by combining the EA-bits contained in its End-user IPv6 prefix, most likely received via DHCPv6 PD, with the BMR’s IPv4 prefix. EA-bits leftover from completing the BMR IPv4 prefix are used as the CE’s PSID. A CE’s PSID combined with the MAP domain’s PSID offset determines which port number bits are hardcoded and restricts which port ranges a CE is allowed to use with its public IPv4 address.
Forward Mapping Rule
Forward Mapping Rules or FMR’s enable direct CE-to- CE connectivity without needing to go through a BR. The presence of FMR’s in a MAP domain’s configuration implies that the MAP domain is configured for “mesh mode” rather than the default “hub-and-spoke mode”. Support for testing FMRs will be added to a future release of CDRouter.
Differences between MAP-E and MAP-T
MAP-E and MAP-T differ in three ways. First, MAP-E encapsulates IPv4 packets in an IPv6 packet whereas MAP-T translates IPv4 packets into an IPv6 packet. Secondly, MAP-E sets the IPv6 destination address to the address of the MAP Border Relay whereas MAP-T sets the IPv6 destination address by encoding the IPv4 destination address into a special IPv6 address contained within the DMR prefix. Finally, a MAP-E domain requires a BMR and PSID offset whereas a MAP-T domain requires a DMR, BMR and PSID offset.
Testing MAP with CDRouter
MAP support requires the CDRouter IPv6 add- on and a working native IPv6 configuration. The most common configuration for MAP involves native IPv6 connectivity that has been established via DHCPv6 with an end-user prefix assigned using DHCPv6 PD.
Native IPv6 connectivity can also be enabled using static addresses, however, this will require manual configuration of MAP parameters within the CE.
Within CDRouter, MAP is treated as two new IPv4 WAN modes that can be enabled by setting the testvar wanMode to a value of MAP-E or MAP-T.
MAP Configuration Options
The testvars mapBmrRuleIpv6Prefix, mapBmrRuleIpv6PrefixLen, mapBmrRuleIpv4Prefix, mapBmrRuleIpv4PrefixLen and mapBmrRuleEABitLen define the BMR IPv6 prefix and prefix length, BMR IPv4 prefix and prefix length and BMR EA- bits length.
If wanMode is set to MAP-T, the testvars mapDmrIpv6Prefix and mapDmrIpv6PrefixLen define the DMR IPv6 prefix and prefix length. The testvar mapTosTranslate can be set to ‘no’ if the MAP-T CE does not copy the IPv4 Type of Service (TOS) field from the original IPv4 packet into the IPv6 Traffic Class (TC) field when translating the original IPv4 packet.
If wanMode is set to MAP-E, the testvars mapTunnelFlowLabel, mapTunnelHopLimit and mapTunnelTrafficClass define the expected flow label, hop limit and traffic class fields in the IPv6 header of MAP traffic from the CE.
16 - int(log($startPort) / log(2)).
For example if mapStartPort is 1024 then the PID offset is 6 since
int(log(1024) / log(2)) = 16 - 10 = 6. The length in bits of the CE’s PSID is
derived from the following equation:
int(log($sharingRatio) / log(2))
For example, if mapSharingRatio is 256 then the length in bits of the CE’s PSID
is 8 since
int(log(256) / log(2)) = 8.
The testvar mapPsid determines the CE’s expected PSID. CDRouter will use this value in conjunction with the PSID offset to validate the ports used by the CE.
By default, CDRouter will automatically provision the CE with the DMR, BMR and PSID parameters taken from the config file using DHCPv6 options. The testvar mapEnableDhcpv6Options can be used to disable this if static configuration is desired.
CDRouter expects the End-user IPv6 prefix to be provisioned via DHCPv6 PD. Currently, the user must set dhcpv6WanEnablePD to ‘yes’ and set dhcpv6WanAssignPrefix to the appropriate End-user IPv6 prefix. The testvars wanIspAssignIp and wanNatIp must also be set to the public IPv4 address which the CE will derive from its BMR IPv4 prefix and EA-bits from dhcpv6WanAssignPrefix.
MAP Test Modules
The mape test module can be used when wanMode is set to MAP-E and verifies the MAP-E functionality of the device under test. The mapt test module can be used when wanMode is set to MAP-T and verifies the MAP-T functionality of the device under test.
In addition, many of CDRouter’s existing IPv4 test modules can also be run when MAP-E or MAP-T is enabled.
CDRouter MAP Configuration Example
Native IPv6 Configuration
The following MAP configuration examples assume that the DUT is using DHCPv6 with prefix delegation. To enable IPv6 the testvar supportsIPv6 must be set to yes:
testvar supportsIPv6 yes
Within CDRouter, DHCPv6 is the default IPv6 WAN mode, so there is no need to
explicitly enable DHCPv6. The default IPv6 address provided by CDRouter to DUT
3001::2/64. Prefix delegation is disabled by default, and can be enabled
using the testvar dhcpv6WanEnablePD:
testvar dhcpv6WanEnablePD yes
For this example, the end-user prefix assigned by CDRouter is
testvar dhcpv6WanAssignPrefix 2001:db8:9597:8500:: testvar dhcpv6WanAssignPrefixLen 56
MAP-E / MAP-T Configuration
Enable MAP-E or MAP-T using the testvar wanMode:
# -- choose one testvar wanMode MAP-E testvar wanMode MAP-T
If using MAP-T, configure the MAP-T DMR rule:
testvar mapDmrIpv6Prefix 4001:: testvar mapDmrIpv6PrefixLen 48
The MAP BMR rule is based on the end-user prefix assigned by CDRouter:
testvar mapBmrRuleIpv6Prefix 2001:db8:9500:: testvar mapBmrRuleIpv6PrefixLen 40 testvar mapBmrRuleIpv4Prefix 198.51.100.0 testvar mapBmrRuleIpv4PrefixLen 24 testvar mapBmrRuleEABitLen 16
The port set must be configured using the following testvars:
testvar mapSharingRatio 256 testvar mapStartPort 1024 testvar mapPsid 197
Based on the above values, the final 8 bits of the CE’s public IPv4 address are the first 8 bits of the EA bits. In the above example these bits are 0x97 which is 151 decimal. The CE’s public IPv4 address is therefore 198.51.100.151. The final step is to ensure that the wanIspAssignIp and wanNatIp are configured to match the expected public IPv4 address of the CE:
testvar wanIspIp 198.51.100.1 testvar wanIspAssignIp 198.51.100.151 testvar wanNatIp 198.51.100.151
Enable LW4o6 using the testvar wanMode:
# -- choose one testvar wanMode LW4o6
Configure CDRouter’s IPv4 WAN address and the IPv4 address that the CE’s lwB4 should be configured to use:
testvar wanIspIp 198.51.100.1 testvar wanIspAssignIp 198.51.100.151 testvar wanNatIp 198.51.100.151
The MAP BMR testvars must be consistent with the end-user prefix assigned by CDRouter and public IPv4 address the CE’s lwB4 is configured to use:
testvar mapBmrRuleIpv6Prefix 2001:db8:9500:: testvar mapBmrRuleIpv6PrefixLen 40 testvar mapBmrRuleIpv4Prefix 198.51.100.151
Address sharing is an optional feature of LW4o6. When address sharing is disabled, there are no restrictions on the ports that the CE can use. To disable address sharing:
testvar mapSharingRatio 1 testvar mapStartPort 0 testvar mapPsid 0
With the above port set configuration, the
OPTION_S46_PORTPARAMS option will
be omitted from CDRouter’s DHCPv6 messages.
To simulate address sharing with a single contiguous range of ports per CE, as recommended in Section 5.1 of RFC 7596:
testvar mapSharingRatio 256 testvar mapStartPort 0 testvar mapPsid 197