Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

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

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

This topic provides an overview of Mapping of Address and Port with Encapsulation (MAP-E) feature and its benefit to service providers when used as an inline service on MX Series routers with MPC and MIC interfaces. Starting in Junos OS release 20.2R1, MAP-E softwires are supported under Next Gen Services on either an MPC or MIC by specifying the inline services si-1/1/0 naming convention. Starting in Junos OS release 20.3R1, MPC10E and MX2K-MPC11E support 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.

Figure 1: Sample MAP-E DeploymentSample MAP-E Deployment

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.

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

This example shows you how to configure the MAP-E Border Relay (BR) solution using a next hop-based style of configuration.

To configure MAP-E:

  1. Create service interface on the device with 100g bandwidth support.
  2. Configure the dual stack service interface unit 0.
  3. Configure service interface inside the dual stack domain.
  4. Configure service interface outside the dual stack domain.
  5. Configure the IPv4-facing interface on BR.
  6. Configure the CPE-facing interface on BR.
  7. Configure the MAP-E softwire concentrator and associated parameters.
    Note:

    When configuring the MAP-E softwire concentrator, take the following into consideration:

    • Possible values for ea-bits-len is 0 through 48.

    • Possible values for v4-prefix-len is 0 through 32.

    • If v4-prefix-len is 0 then ea-bits-len must be non-zero, and vice versa.

    • It is possible that ea-bits-len is equal to 0, but psid-len is non-zero.

    • If the sum of v4-prefix-len and ea-bits-len is less than 32, then the psid-len must be equal to the difference between 32 and the sum total of v4-prefix-len and ea-bits-len.

    • The MAP-E IPv4 and IPv6 prefix must be unique per softwire concentrator.

    • The MAP-E IPv4 prefix must not be 0.0.0.0

    • MAP-E PSID offset has a default value of 4, and MAP-E tunnel maximum transmission unit (MTU) has a default value of 9192.

  8. Configure a softwire rule to specify the direction of traffic to be tunneled and the MAP-E softwire concentrator to be used.
  9. Configure the service set for MAP-E.

For example:

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
22.3R1
Starting in Junos OS Release 22.3R1, the line cards on MX series routers support partial reassembly of IPv4 fragments for MAP-E.
20.3R1
Starting in Junos OS release 20.3R1, MPC10E and MX2K-MPC11E support MAP-E.
20.2R1
Starting in Junos OS release 20.2R1, MAP-E softwires are supported under Next Gen Services on either an MPC or MIC by specifying the inline services si-1/1/0 naming convention.