CDRouter Support

MAP-T testing with CDRouter

knowledge-base version 11.0


Support for RFC7599, Mapping of Address and Port using Translation (MAP-T), has been added to CDRouter 10.2. MAP-T is a stateless NAT64 technique that is designed to deliver IPv4 services over native IPv6 connections without having to deploy a full dual-stack network infrastructure. It also incorporates some carrier grade NAT (CGN) concepts by allowing multiple end user devices to share a single public IPv4 address.

A more complete description 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.

Introduction to MAP-T

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-T takes. It is a mechanism to statelessly provide IPv4 connectivity via shared IPv4 addresses in an IPv6-only ISP network.

In MAP-T, IPv4 packets coming from the CE are translated to 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 are translated to 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.

         User N
       Private IPv4
      |  Network
   |  | MAP-T CE      |
   | +-----+--------+ |
   | NAPT44|  MAP-T | |
   | +-----+        | +-._   ,-------.                     .------.
   |       +--------+ |   ,-'         `-.                ,-'       `-.
   O------------------O  /              \   O---------O /   Public   \
                         /   IPv6-only   \  |  MAP-T  |/     IPv4     \
                        (    Network      --+  Border +-   Network     )
                         \               /  |  Relay  |\              /
   O------------------O  \              /   O---------O \             /
   |    MAP-T CE      |   ;".         ,-'                `-.       ,-'
   | +-----+--------+ | ,"   `----+--'                      ------'
   | NAPT44|  MAP-T | |,          |
   | +-----+        | +        IPv6 node(s)
   |   |   +--------+ |  (with IPv4-embedded IPv6 address)
         User M
       Private IPv4

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. Likewise, 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 destined for a host on the IPv4 internet becomes 2001::[] (NAT’ed source IP) to 4001::[] (destination IP) when translated and sent out the CE’s WAN interface.

This is not the whole story, however. The public IPv4 address 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 packet from port 1024 sent to port 1050 becomes 2001::[ ports 1000-2000] port 1048 to 4001:: 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 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 4001::/48 and 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 the 4001::/48 prefix.

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  |

Default and Basic Mapping Rules

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 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. Unlike the DMR, the BMR also contains an IPv4 prefix and prefix length which the CE uses to learn a portion of its public IPv4 address. The DMR and BMR 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-T 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 domain is using a DMR of 4001::/48 and a BMR of 2001::/40 and This implies that all CE’s will be assigned a public IPv4 address within the 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 4001::/48 prefix.

Now suppose a CE is assigned an End-user IPv6 prefix of 2001:0:34:2700:/56 via 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 composed of a DMR, a BMR and a PSID offset. A DMR is composed of an IPv6 prefix and prefix length. A BMR is composed of an IPv6 prefix and prefix length, an IPv4 prefix and prefix length and an EA-bits length. All CE’s and BR’s in the same MAP domain must be configured with the identical DMR, BMR and PSID offset, all of which can be provisioned via DHCPv6 options. The DMR IPv6 prefix is used 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.

Testing MAP-T with CDRouter


MAP-T support requires the CDRouter IPv6 add- on and a working native IPv6 configuration. The most common configuration for MAP-T involves native IPv6 connectivity that has been established via DHCPv6 with an end-user prefix assigned using DHCPv6 PD.

Native IPv6 connecitivity can also be enabled using static addresses, however, this will require manual configuration of MAP-T parameters within the CE.

Enabling MAP-T

Within CDRouter, MAP-T is treated as a new IPv4 WAN mode that can be enabled by setting the testvar wanMode to a value of MAP-T.

MAP-T Configuration Options

The testvars mapDmrIpv6Prefix and mapDmrIpv6PrefixLen define the DMR IPv6 prefix and prefix length.

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.

The testvars mapSharingRatio and mapStartPort are used to derive the PSID offset and the length in bits of the CE’s PSID. The PSID offset is derived from the following equation:

16 - int(log($startPort) / log(2)).

For example if mapStartPort is 1024 then the PID offset is 6 since 16 - 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-T Test Module

The mapt test module can be used to verify 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-T is enabled.

CDRouter MAP-T Configuration Example

Native IPv6 Configuration

The following MAP-T 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 is 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 2001:db8:9597:8500::/56:

testvar dhcpv6WanAssignPrefix            2001:db8:9597:8500::
testvar dhcpv6WanAssignPrefixLen         56

Enable MAP-T using the testvar wanMode:

testvar wanMode MAP-T

Now configure the MAP-T DMR rule:

testvar mapDmrIpv6Prefix                 4001::
testvar mapDmrIpv6PrefixLen              48

The MAP-T BMR rule is based on the end-user prefix assigned by CDRouter:

testvar mapBmrRuleIpv6Prefix             2001:db8:9500::
testvar mapBmrRuleIpv6PrefixLen          40
testvar mapBmrRuleIpv4Prefix   
testvar mapBmrRuleIpv4PrefixLen          24
testvar mapBmrRuleEABitLen               16

The port set must be configured using the following testvars:

testvar mapSharingRatio                  256
testvar mapStartPort                     4096
testvar mapPsid                          133

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 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               
testvar wanIspAssignIp         
testvar wanNatIp               

Additional Resources



About CDRouter

CDRouter is made by QA Cafe, a technology company based in Portsmouth, NH.

Get in touch via our Contact page or by following us on your favorite service: