Understanding Mapping of Address and Port with Encapsulation (MAP-E)

Benefits of Mapping of Address and Port with Encapsulation (MAP-E)

Reduces administrative overhead and creates a scalable network infrastructure that easily supports connectivity to a large number of IPv4 subscribers over the ISP's IPv6 access network.

Mapping of Address and Port with Encapsulation (MAP-E) Terminology

1. Border Relay (BR)—MAP-E-enabled provider edge device in a MAP domain. A BR device has at least an IPv6-enabled interface and an IPv4 interface connected to the native IPv4 network.

2. MAP-E Customer Edge (CE)—MAP-E-enabled customer edge device in a MAP deployment.

3. MAP domain—One or more MAP-E CE devices and BR devices connected to the same virtual link.

4. Port Set ID (PSID)—Separate part of the transport layer port space that is denoted as port set ID.

5. Embedded Address (EA) Bits—EA-bits in the IPv6 address identify an IPv4 prefix or address or a shared IPv4 address and a port-set identifier.

6. Softwire—Tunnel between two IPv6 end-points to carry IPv4 packets or two IPv4 end-points to carry IPv6 packets.

7. Softwire Initiator (SI)—Softwire at the customer end that encapsulates native packets and tunnels them to a softwire concentrator at the service provider.

8. Softwire Concentrator (SC)—Softwire that decapsulates the packets received from a softwire initiator and sends them to their destination.

Mapping of Address and Port with Encapsulation (MAP-E) Functionality

The following figure illustrates a simple MAP-E deployment scenario.

In the MAP-E network topology, there are two MAP-E customer edge (CE) devices, each connected to a private IPv4 host. The MAP-E CE devices are dual stack and are capable of Network Address Port Translation (NAPT). The MAP-E CE devices connect to a MAP-E Border Relay (BR) device through an IPv6-only MAP-E network domain. The MAP-E BR device is dual stack and is connected to both a public IPv4 network and an IPv6 MAP-E network.

The MAP-E functionality is as follows:

1. The MAP-E CE devices are capable of NAPT. On receiving an IPv4 packet from the host, the MAP-E CE device performs NAT translation on the incoming IPv4 packets.

2. The NAT translated IPv4 packets are then encapsulated into IPv6 packets by the MAP-E CE device, and sent to the MAP-E BR device.

3. The IPv6 packet gets transported through the IPv6-only service provider network and reaches the MAP-E BR device.

4. On receiving the IPv6 packets, the incoming IPv6 packets are decapsulated by the MAP-E CE device and routed to the IPv4 public network.

In the reverse path, the incoming IPv4 packet is encapsulated into an IPv6 packet by the MAP-E BR device, and routed to the MAP-E CE devices.

In full reassembly of packets, the IPv4 fragments from the public IPv4 network are reassembled into a single IPv4 packet which is later encapsulated into IPv6 and routed towards MAP-E CE device. The IPv6 fragments from MAP-E CE device are reassembled into a single IPv6 packet, inner IPv4 packets are decapsulated, and forwarded to the IPv4 cloud.

Starting in Junos OS Release 22.3R1, in order to enhance the reassembly capabilities of the line cards, the line cards on MX series routers support partial reassembly of IPv4 packets for MAP-E. The MAP-E border relay device encapsulates the IPv4 packets from public IPv4 networks into IPv6 and then routes the packets to the MAP-E customer edge (CE) devices.

You must first enable IPv4 reassembly in order to configure IPv4 partial reassembly of fragments.

The following table summarises IPv4 partial reassembly capabilities.

Table 1: IPv4 Partial Reassembly Capabilities

Maximum supported fragments per flow for partial reassembly	Maximum IP packet size (in bytes) that can be partially reassembled	Maximum IP fragment size (in bytes)
64	65535	15900

When the maximum supported fragments per flow exceeds or when the maximum IP fragment size exceeds, the fragments are discarded.

Starting in Junos OS Release 22.4R1, the line cards on MX304, MX960, and MX10008 routers support full reassembly of IPv4 and IPv6 packets for Mapping of Address and Port with Encapsulation (MAP-E).

The following table summarises the enhanced IPv4 and IPv6 full reassembly capabilities.

Table 2: IPv4 and IPv6 Full Reassembly Capabilities

Maximum supported fragments per flow for full reassembly	Maximum IP packet size (in bytes) that can be fully reassembled	Maximum IP fragment size (in bytes)
16	15900	15900

When the maximum supported fragments per flow exceeds or when the maximum IP fragment size exceeds, the fragments are discarded.

Mapping of Address and Port with Encapsulation (MAP-E) Supported and Unsupported Features

Junos OS supports the following MAP-E features and functionality:

• MAP-E implementation supports line card throughput of 100 Gigabits.

• support for Inline MAP-E Border Relay (BR) solution that adheres to draft version 03 of RFC 7597

  Fully compliant with draft version 03 of RFC 7597, Mapping of Address and Port with Encapsulation (MAP), when the version-3 option is disabled at the services softwires softwire-types map-e map-e-concentrator-name

• Support chassis-wide scale of 250 shared MAP-E rules.

• Support the feature on all MPCs using service interfaces with 100 Gigabits.

• Ability to ping MAP-E BR IPv6 address.

• Support only next-hop style of configuration for MAP-E.

• Support reassembly of fragmented IPv4 traffic arriving from IPv4 network before encapsulating it into an IPv6 packet.

• Support fragmentation of inner IPv4 packet if the packet size after encapsulation exceeds the MAP-E maximum transmission unit (MTU).

• Packets having Internet Control Message Protocol (ICMP) payload with the following message types are accepted for MAP-E encapsulation and decapsulation:

  • Echo or Echo Reply Message of type 0 and 8

  • Timestamp or Timestamp Reply Message of type 13 and 14

  • Information Request or Information Reply Message of type 15 and 16

  • Source quench, destination_unreachable, time_exceeded, Icmp_redirect, Icmp_address_mask_reply and parameter_problem errors

• Border Relay (BR) anycast is supported.

The following features and functionality are not supported with the MAP-E feature:

• Anti-spoof check is not supported for fragmented IPv4 packets coming from a customer edge (CE) device.

• Section 8.2 of the Internet draft draft-ietf-softwire-map-03 (expires on July 28, 2013), Mapping of Address and Port with Encapsulation (MAP) is not supported. Instead of responding with an ICMPv6 Destination Unreachable, Source address failed ingress/egress policy (Type 1, Code 5) message, spoof packets are silently dropped and the counter is incremented.

• IPv6 reassembly is not supported.

• ICMP v6-to-v4 translation at the BR is not supported.

• Inline MAP-E with virtual routing and forwarding (VRF) is not supported.

• Inline MAP-E with inline Network Address Translation (NAT) or dual stack (DS)-Lite is not supported.

• Interface-style MAP-E configuration is not supported.