Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Stateless Source Network Prefix Translation for IPv6

Stateless Source Network Prefix Translation for IPv6 Overview

Starting with Junos OS Release 15.1, you can configure stateless translation of source address prefixes in IPv6 networks (IPv6 to IPv6). This capability is supported on MX Series routers with MPCs where inline NAT is supported. To configure stateless network prefix translation for IPv6 packets (NPTv6), include the translation-type nptv6 statement at the [edit services nat rule rule-name term term-name then translated] hierarchy level. The NPTv6 translator translates the source address prefix in such a way that the transport layer checksum of the packet does not need to be recomputed. NPTv6 defines a stateless method of IPv6 network prefix translation between internal and external networks. NPTv6 does not maintain the state for each node or each flow in the translator. You can use the show services nat mappings nptv6 (internal | external) command to view the NAT mappings for NPTv6 for internal and external addresses respectively. You can also use the show services inline nat statistics and show services inline nat pool commands to display information about inline NAT with NPTv6 configured.

Benefits of Stateless Source Network Prefix Translation

  • For edge networks, you do not need to renumber the IPv6 addresses used inside the local network for interfaces, access lists, and system logging messages if:

    • The global prefixes used by the edge network are changed.

    • The IPv6 addresses are used inside the edge network or within other upstream networks (such as multihomed devices) when a site adds, drops, or changes upstream networks.

  • IPv6 addresses used by the edge network do not need ingress filtering in upstream networks and do not need their customer-specific prefixes advertised to upstream networks.

  • Connections that traverse the translation function are not disrupted by a reset or brief outage of an NPTv6 translator.

NPTv6

Network prefix translation for IPv6 (NPTv6) defines a stateless way of IPv6 address prefix translation between internal and external networks. NPTv6 does not maintain the state for each node or each flow in the translator. Maintenance of mapping state is not required for the address mapping of inbound or outbound packets. A stateless, transport-agnostic IPv6-to-IPv6 NPTv6 function offers the advantage of address-independence associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the inside and outside prefixes, thereby preserving end-to-end reachability at the network layer. In upstream networks, IPv6 addresses used by the edge network always contain a provider-allocated prefix.

NPTv6 is designed to provide address independence to the edge networks to achieve internal address stability, regardless of its upstream service provider networks. However, using provider-independent addresses without translation might be very expensive because the routing table enumerates the edge networks, instead of enumerating the transit domain that provides the service to the edge networks. This phenomenon can cause a massive and unmanageable route table. NPTv6 is a mechanism that effectively and cohesively provides address independence without advertising an internal network prefix to external networks. In contrast, the main objective of network address port translation (NAPT) for IPv4 (NAPT44) is to solve IPv4 address depletion, although it brings the same benefit of address independence. NAPT for IPv6, specifically NAPT66, is already supported in microkernel. However, similar to NAPT44, NAPT66 requires flow-state information to be preserved. NPTv6 provides a simple and streamlined technique to avoid as many of the limitations associated with NAPT66 as possible. It is defined to include a two-way, checksum-neutral, and an algorithmic translation function.

NPTv6 does not maintain state information for a node, flow, or a connection in the translator. Internal to external and external to internal packets are translated algorithmically using information present in the IPv6 header. As a result of its stateless nature, if multiple NPTv6 translators exist between the same two networks, the load can shift or be dynamically shared among them. Also, unlike NAPT44, because the mapping can be done in either direction, the translator does not interfere with the inbound connection establishment. Instead, a firewall can be used in conjunction with an NPTv6 translator. This behavior offers the network administrator more flexibility to specify security policy than that can be achieved with a traditional NAT.

Another advantage of NPTv6 is checksum-neutral translations. The translator does not need to rewrite the transport header for updating the checksum and does not perform port mapping. As a result, to deploy new transport layer protocols, you do not need to modify the translator. Because the transport layer is not modified, the algorithm does not interfere with encryption of the IP payload. Although NPTv6 compares favorably to NAPT44 or NAPT66 in several ways, it does not eliminate all of the architectural problems. Because NPTv6 modifies the IP headers of packets, it is not compatible with security mechanisms such as the IPsec authentication header. The use of separate internal and external prefixes creates complexity for Domain Name System (DNS) deployment. Also, those applications that require application layer gateways (ALGs) to work correctly through NAPT44 or NAPT66 devices might require similar ALGs to work through NPTv6 translators. Because NPTv6 does not maintain connection states, the failure of the translator does not impact the non-transmit power control (TPC) traffic through the server. TCP connections can be interrupted because of the change in the source IP address of a connection. Connections might be timed out and then reestablished in this case.

NPTv6 uses inline NAT. Inline NAT uses the capabilites of the Modular Port Concentrator (MPC) line card, eliminating the need for a MultiServices DPC (MS-DPC) for NAT. To configure inline NAT, you define your service interface as type si- (service-inline) interface. You must also reserve adequate bandwidth for the inline interface. This enables you to configure both interface service sets and next-hop service sets used for NAT. The si- interface serves as a virtual service PIC.

Interoperation of Functionalities with Network Prefix Translation for IPv6

This topic contains the following sections that describe the working behavior of different functionalities with stateless source IPv6 prefix translation and the various system conditions:

Address Mapping Algorithm

The NPTv6 translator filters the packets going out of the network and, if the source address of the packet matches with the source address defined in the rule (the from or source address in configuration), the source address is replaced with an address prefix from the pool defined for the rule. The next 16 bits after the prefix of the source address are replaced with the checksum-adjusted value to ensure that the checksum remains the same in the outgoing packet even though the source address is changed. During the definition of the configuration rule and pool for the packets going outside the network, a denat rule and pool are created for the translation of the destination address for the packets coming into the network.

Internal to External Translation

When a packet is going from the internal network to the external network, the IPv6 prefix in the source address of the packet (coming from inside node) is mapped to the external prefix. After checksum adjustment, the packet is routed toward the external network.

External to Internal Translation

When a packet is coming from external network to internal network, the IPv6 prefix in the destination address of the packet (coming from outside host) is mapped to the internal prefix. After checksum adjustment, the packet is routed to internal network.

Checksum-Neutral Translation

The NPTv6 translator translates the source address prefix in such a way that the transport layer checksum of the packet does not need to be recomputed. A checksum change caused by modifying part of the area covered by the checksum can be corrected by making an additional change to a different 16-bit field covered by the same checksum. This checksum neutral method first computes 1's complement checksum of the internal-prefix and the external-prefix.

For packets coming from the internal network, the adjustment is calculated as 1’s complement and it is computed as follows:

Adjustment = Internal prefix checksum – External prefix checksum.

The adjustment value is added to the 16-bit word of the source address after the prefix.

For packets coming from external network, the adjustment is 1’s complement and it is calculated as follows:

Adjustment = External prefix checksum – Internal prefix checksum.

The adjustment is added to the 16-bit word of the destination address after the translated prefix.

Multihoming

If there are two NPTv6 translators with different external IPv6 prefix configurations for the same internal IPv6 prefix, then these two NPTV6 translators will translate the same internal IPv6 network prefix to two different external IPv6 network prefixes, depending on the translator the packet traverses.

Hairpinning

When an internal node has knowledge of only the external (that is, the global address) of another internal node, it uses that address to send packet to that internal node. If such a packet is received by an NPTv6 translator, that packet is routed toward the internal network again after it undergoes source address and destination address translation.

Load Balancing

Load sharing is achieved when two translators have the same internal to external mapping configuration and packet load is shared between them. How the load balancing is achieved is beyond the scope of NPTv6.

The balancing could be implemented based on subnet ID portion of the IPv6 address. There can be two si- logical interfaces with the same mapping of the internal prefix to the external prefix. Packets are routed to one of the si- logical interfaces based on the subnet ID.

ICMPv6 for NPTv6

Any host in the internal network should be able to ping a host in the external network through an NPTv6 translator. All ICMP error messages should be forwarded to the host in the internal network. During internal to external translation if there is no mapping possible for a prefix, then packet is dropped and the ICMP Destination Unreachable message is sent back. An ICMPv6 Destination Unreachable error is returned by the translator if the ICMP error is enabled in the following cases:

  • If source address prefix lengths are less than or equal to /48 and the 48-63 bits are equal to 0xFFFF

  • If prefix lengths are greater than /48 and all the 16-bit blocks in the interface ID (IID) (bits 64-127) are equal to 0xFFFF

Otherwise the packet is discarded.

For prefix lengths less than or equal to /48, the bits 48-63 are used as the 16-bit word adjusted for checksum. For prefix lengths greater than /48, the first 16-bit block in the IID that does not have the value 0xFFFF is the 16-bit word adjusted for checksum.

If the interface ID (IID) part of the address to be translated contains all zeros, ICMPv6 Parameter Problem error is returned by the translator if the ICMP error option is enabled. Otherwise the packet is discarded. ICMPv6 errors are generated by the control plane. The source address of the ICMPv6 pakcket is the IP address of the ingress interface.

Guidelines for Configuring Stateless Source Network Prefix Translation

Keep the following points in mind when you configure stateless translation of source IPv6 prefixes:

This topic contains the following sections that describe the working behavior of different functionalities with stateless source IPv6 prefix translation and the various system conditions:

  • Graceful Routing Engine switchover (GRES) support is the same as for NAT44.

  • Unified ISSU and nonstop software upgrade (NSSU) are not supported.

  • NPTv6 deployment enables direct inbound connections to internal nodes from external networks. This mechanism causes slight vulnerability because it opens the internal nodes to attacks from outside. The stateless translation of NPTv6 makes it difficult to trace external connection requests, based on connection states. This behavior enables NAT44 networks to be well-protected against external attacks. The best option to secure an NPTv6 translator is to add a firewall above the NPTv6 translator.

  • A 6rd softwire concentrator interoperates with NPTv6. All other mechanisms that do not require the application layer gateway (ALG) to change the source IP address in the payload are supported. TCP, UDP, ICMP, SSH, and Telnet are supported by the NPTv6 translator. FTP and Session Initiation Protocol (SIP) that require the ALG to change the source IP address in the payload are not supported.

  • The NPTv6 pools are allocated in the external data memory. The pool data structure consists of the address prefix, prefix length, and the checksum. The size of each record is of 192 bits. For every pool, a denat pool is allocated automatically. The size of the denat pool is 192 bits. There is a total allocation of 8000 64-bit entries for NAT-processed and untranslated NPTv6 pools. This allocation comes from the 64,000 entries allocated for the inline services (JNH_APP_INLINE_SVCS).

  • Chaining of inline services for interoperation of 6rd with NPTv6 is not supported.

  • You need to configure a source pool and specify the from (source) address, while configuring NPTv6.

  • The external and internal prefix lengths must be greater than or equal to /16 subnet mask and less than or equal to /112 subnet mask.

  • Two different internal prefixes cannot be translated to the same external prefix.

  • NPTv6 cannot be applied to IPSec and Internet Key Exchange (IKE) packets. The NPTv6 translator is bypassed in this case.

  • Because the translation is of one IPv6 address prefix, there is only one address in the pool. If more than one address is configured by the user, the system does not raise any error, instead only the first address prefix of the pool is chosen for translation.

  • For packets going from internal network to external network, if the internal subnet is not mapped or is set to 0xFFFF, then the datagram is discarded and an ICMP destination unreachable error is generated.

  • For packets going from internal network to external network, if the 16-bit word has the adjustment added to it using the 1’s complement method and is equal to 0xFFFF, then the value is written as zero.

  • For packets coming from the external network to internal network, if the 16-bit word has the adjustment subtracted from it using 1’s complement method and is equal to 0xFFFF, the 16-bit word is overwritten as zero.

  • For translation of prefixes /48 or shorter, the adjustment must be added or subtracted from the first 16 bits after the /48 subnet mask, the values of which are not 0xFFFF. If the prefix is /49 or longer, then the adjustment must be added or subtracted from the first 16 bits (from 64 to 123), the values of which are not 0xFFFF.

Working of NPTv6 with Interface-Style and Next Hop-Style Service Sets

The objective is to add network prefix translation for IPv6 (NPTv6) inline service that performs stateless translation of the source IPv6 address. Consider a sample topology in which NPTv6 is implemented between an internal network with the prefix of FD01:0203:0405:/48 and an external network with the prefix of 2001:0DB8:0001:/48.

The source addresses FD01:0203:0405:/48 in the packets from a single administrative domain (internal network) destined to hosts in global network (external network) will be translated to 2001:0DB8:0001:/48. Packets destined to internal network coming from external network will have their destination address as 2001:0DB8:0001:/48. This destination address will be mapped to internal network address FD01:0203:0405:/48 and will be forwarded to the internal network host. The lengths of both the subnets are assumed to be the same for this case. If they differ the shorter one would be extended to the prefix length of the longer one by suffixing zeros.

Address mapping algorithm used for NPTv6 is checksum-neutral. The translated IP headers will generate the same IPv6 pseudo-header checksum. Checksum is calculated using the standard Internet checksum algorithm. Changes that are made during translation of the IPv6 prefix are offset by the calculated changes made to the other parts of the IPv6 address. This results in transport layers that use the Internet checksum (such as TCP and UDP) calculating the same IPv6 pseudo-header checksum for both the internal and external forms of the same datagram and avoids the need to modify transport layer headers to correct the checksum value. The algorithm can map the addresses for inbound packets and outbound packets.

The NPTv6 translator works for both fragmented packets and packets with IP options enabled. The configuration changes required for NPTv6 are covered in the next sections.

The configuration of a router to handle services is through the definition of logical service interface, service sets and service set rules. These define how the service is applied to the packets.

The inline services logical interface, si-ifl, implementation available for static v4-v4 source-address inline-NAT can be reused for inline NPTv6. The configuration for the NPTv6 implemented for MS-DPC can be modified for inline NPTv6 implementation. There are two types of service set configurations—interface style and next hop style.

For the next hop-style service, a route entry is configured to steer packets to an inline service interface. There the packet would go through the service rules. If the packet matches the service rules, it is processed as per the service rules. For the interface-style service, the service set is configured directly on the media interface affecting traffic as it leaves and enters the interface. The packets are steered to the inline service interface by the service filter applied to the media interface.

Example: Achieving Address Independence By Configuring Stateless Network Prefix Translation in IPv6 Networks by Using Interface-Style Service Sets

You can configure stateless translation of source address prefixes in IPv6 networks (IPv6 to IPv6) on MX Series routers with MPCs that support inline NAT. The NPTv6 translator translates the source address prefix in such a way that the transport layer checksum of the packet does not need to be recomputed. NPTv6 defines a stateless method of IPv6 network prefix translation between internal and external networks. NPTv6 does not maintain the state for each node or each flow in the translator. You can use the show services nat mappings nptv6 (internal | external) command to view the NAT mappings for NPTv6 for internal and external addresses respectively. You can also use the show services inline nat statistics and show services inline nat pool commands to display information about inline NAT with NPTv6 configured.

Note:

This functionality is supported on MX Series routers with Trio-based FPCs (MPCs).

This example describes how to configure stateless source prefix translation for IPv6 packets using interface-style service sets on MX Series routers with MPCs, and contains the following sections:

Requirements

This example uses the following hardware and software components:

  • One MX Series router with an MPC.

  • Junos OS Release 15.1R1 or later for MX Series routers

Overview and Topology for Stateless Network Prefix Translation in IPv6 Networks Using Interface-Style Service Sets

For the interface style service, the service set is configured directly on the media interface affecting traffic as it leaves and enters the interface. The packets are steered to the inline service interface by the service filter applied to the media interface.

When you have defined and grouped the service rules by configuring the service-set definition, you can apply services to one or more interfaces installed on the router. When you apply the service set to an interface, it automatically ensures that packets are directed to the PIC.

Consider a sample configuration scenario in which NPTv6 is configured using interface-style service sets. An inline services interface, si-0/1/0, is configured with a bandwidth reserved for 10 gigabits per second. The si-0/1/0 interface is defined with inet6 family. A NAT address pool, nptv6_pool, is configured with the address of abcd:ef12:3456::/48. A NAT rule is applied in the input direction to perform NPTv6 translation on packets that arrive from the source address of 1234:5678:9abc::/48. For packets from the source address of 1234:5678:9abc::/48 that match the NAT rule criterion, the address from the NAT address pool is allocated. A service set, ss_nptv6, is specified with the NAT rule. A gigabit Ethernet interface, ge-5/0/0, is configured and the service set is applied to this interface.

Configuration

To configure stateless network prefix translation for IPv6 using interface-style service sets, perform these tasks:

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them in a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level:

Configuring Interfaces

Configuring Interfaces for Traffic to Be Handled By the Service Set

Configuring Bandwidth for the Service Inline (si-) Interface

Configuring NAT Pool and Rules

Configuring the Service Set

Procedure

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure stateless network prefix translation for IPv6 using interface-style service sets:

  1. Configure an inline services (si-) interface.

  2. Configure the interfaces for traffic to be handled by the service set.

  3. Configure the bandwidth for the service inline (si-) interface.

  4. Configure a NAT pool and rule.

  5. Configure the service set

Results

From the configuration mode, confirm your configuration by entering the show chassis, show interfaces, and show services commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

To confirm that the configuration is working properly, perform the following:

Verifying the NAT Pool Mappings

Purpose

Verify the existing NAT address pools and mappings for IPv6 network prefix translation.

Action

From operational mode, use the show services nat mappings nptv6 command:

Meaning

The output shows the mapping between NAT addresses and ports for IPv6 stateless network prefix translation of external and internal addresses. The address and port details that are originally sent and converted using NAT are displayed.

Verifying the Inline NAT Pools and Statistics

Purpose

Verify the inline NAT pools and statistics for IPv6 network prefix translation.

Action

From operational mode, use the show services inline nat command:

Meaning

The output shows the information about inline NAT address translations, such as the number of packets that are subject to NAT processing, the packets that are not translated, and the packets with translation errors for a specified service set and an si- interface.

Example: Achieving Address Independence By Configuring Stateless Network Prefix Translation in IPv6 Networks by Using Next-Hop -Style Service Sets

You can configure stateless translation of source address prefixes in IPv6 networks (IPv6 to IPv6) on MX Series routers with MPCs where inline NAT is supported. The NPTv6 translator translates the source address prefix in such a way that the transport layer checksum of the packet does not need to be recomputed. NPTv6 defines a stateless method of IPv6 network prefix translation between internal and external networks. NPTv6 does not maintain per node or per flow state in the translator. You can use the show services nat mappings nptv6 (internal | external) command to view the NAT mappings for NPTv6 for internal and external addresses respectively. You can also use the show services inline nat statistics and show services inline nat pool commands to display information about inline NAT with NPTv6 configured.

Note:

This functionality is supported on MX Series routers with Trio-based FPCs (MPCs).

This example describes how to configure stateless source prefix translation for IPv6 packets using next-hop style service sets on MX Series routers with MPCs, and contains the following sections:

Requirements

This example uses the following hardware and software components:

  • One MX Series router with an MPC.

  • Junos OS Release 15.1R1 or later for MX Series routers

Overview and Topology of Stateless Network Prefix Translation in IPv6 Networks Using Next-Hop Style Service Sets

A next-hop service set is a route-based method of applying a particular service. Only packets destined for a specific next hop are serviced by the creation of explicit static routes. This configuration is useful when services need to be applied to an entire virtual private network (VPN) routing and forwarding (VRF) table, or when routing decisions determine that services need to be performed.

For the next hop style service, a route entry is configured to steer packets to an inline service interface. The packet is validated through the service rules. If the packet matches the service rules, it would be processed according to the service rules.

Consider a sample configuration scenario in which NPTv6 is configured using next-hop style service sets. An inline services interface, si-0/1/0, is configured with a bandwidth reserved for 10 gigabits per second. The si-0/1/0 interface is defined with inet6 family. A NAT address pool, nptv6_pool, is configured with the address of abcd:ef12:3456::/48. A NAT rule is applied in the input direction to perform NPTv6 translation on packets that arrive from the source address of 1234:5678:9abc::/48. For packets from the source address of 1234:5678:9abc::/48 that match the NAT rule criterion, the address from the NAT address pool is allocated. The service set is configured for forwarding next-hops with the service interface of si-0/1/0.1 associated with the service set applied inside the network. with parameters for next hop service interfaces for the inside network and si-/1/0.2 associated with the service set applied outside the network. A service set, ss_nptv6, is specified with the NAT rule. The service interface domain is specified for the si- interface with the inside service-domain configured for si-0/1/0.1 and outside service domain configured for si-0/1/0.2. A routing instance, inst1, is configured with the instance type as a VRF instance. interface si-0/1/0.1 and interface ge-5/0/0 are associated with inst1. The inside and outside interface domain matches that specified with the inside-service-interface and outside-service-interface statements. A policy is configured for NAT events with the action to reject all packets.

Configuration

To configure stateless network prefix translation for IPv6 using next-hop style service sets, perform these tasks:

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them in a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level:

Configuring Inline Interfaces

Configuring Bandwidth for Inline Services

Configuring NAT Pool and Rule

Configuring a Service Set

Configuring Routing Instances

Configuring the Policy and Action Modifier

Procedure

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure stateless network prefix translation for IPv6 using next-hop style service sets:

  1. Configure the inline interface for NAT services.

  2. Set the bandwidth for inline services.

  3. Configure the NAT pool and rule.

  4. Configure a service set using the NAT rule associated with the NAT pool.

  5. Configure routing instances that use the si- interfaces configured.

  6. Configure the policy and the action modifier for NAT packets.

Results

From the configuration mode, confirm your configuration by entering the show chassis, show interfaces, show policy-options, show routing-instances, and show services commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

To confirm that the configuration is working properly, perform the following:

Verifying the NAT Pool Mappings

Purpose

Verify the existing NAT address pools and mappings for IPv6 network prefix translation.

Action

From operational mode, use the show services nat mappings nptv6 command:

Meaning

The output shows the information about inline NAT address translations, such as the number of packets that are subject to NAT processing, the packets that are not translated, and the packets with translation errors for a specified service set and an si- interface.

Verifying the Inline NAT Pools and Statistics

Purpose

Verify the inline NAT pools and statistics for IPv6 network prefix translation.

Action

From operational mode, use the show services inline nat command:

Meaning

The output shows the mapping between NAT addresses and ports for IPv6 stateless network prefix translation of external and internal addresses. The address and port details that are originally sent and converted using NAT are displayed.