MAP and LW4o6 testing with CDRouter

Background

CDRouter has support for RFC7599, Mapping of Address and Port using Translation (MAP-T), and for RFC7597, Mapping of Address and Port with Encapsulation (MAP-E),

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 202.254.1.2 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 192.168.1.100 port 1024 sent to 3.3.3.3 port 1050 becomes 2001::[202.254.1.2 ports 1000-2000] port 1048 to 4001::3.3.3.3 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 192.168.1.100 destined for a host on the IPv4 internet 3.3.3.3 becomes 2001::[202.254.1.2] (NAT’ed source IP) to 4001::[3.3.3.3] (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 4001::/48 and the CE is trying to send a packet to the public IPv4 internet address 3.3.3.3, 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.

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 2001::/40 and 202.254.1.0/24. This implies that all CE’s will be assigned a public IPv4 address within the 202.254.1.0/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 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 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

Requirements

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.

Enabling MAP

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.

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.

The testvar mapIpv6InterfaceIdFormat determines the IPv6 interface identifier format used in the MAP domain. If set to rfc-7597, CDRouter will expect IPv6 interface identifiers formatted as specified in RFC 7597 Section 6. Otherwise, if set to draft-03, CDRouter will expect IPv6 interface identifiers formatted as specified in Internet-Draft draft-ietf-softwire-map-03.

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 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

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

Configure the IPv6 interface identifier format expected by CDRouter:

# -- choose one
testvar mapIpv6InterfaceIdFormat         rfc-7597
testvar mapIpv6InterfaceIdFormat         draft-03

The port set must be configured using the following testvars:

testvar mapSharingRatio                  256
testvar mapStartPort                     1024
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 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

LW4o6 Configuration

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

Since a full 32-bit IPv4 address is assigned in LW4o6 configurations, the testvars mapBmrRuleIpv4PrefixLen and mapBmrRuleEABitLen are hard coded to values of 32 and 0, respectively.