ICMP Handling in IPv6-to-IPv6 Network Prefix Translation
draft-blake-nptv6-icmp-02

Abstract

NPTv6 is a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT without some of that mechanism's drawbacks. NPTv6 is intended to be deployed in environments where a host might not know its "external" network prefix(es). In such an environment, a NPTv6 device must also translate network prefixes present in in-bound and out-bound ICMPv6 error message payloads. This document describes the required processing of ICMPv6 error messages.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 11, 2012.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. ICMPv6 Error Message Network Prefix Translation
• 4. Example
• 5. Hairpinning
• 6. Detecting ICMPv6 Error Messages
• 7. IANA Considerations
• 8. Security Considerations
• 9. Acknowledgements
• 10. References
• 10.1. Informative References
• 10.2. Normative References
• Authors' Addresses

1. Introduction

NPTv6 [RFC6296] is a stateless, transport-agnostic network prefix translation function for IPv6-to-IPv6 communication, which is intended to be deployed at the edge of networks which have been delegated provider-aggregatable (PA) network prefixes from one or more providers. By allowing hosts within a network to be numbered using stable address prefixes (e.g., Unique Local Addresses [RFC4193]), these hosts do not needed to be renumbered whenever there is a change in the available PA network prefixes for the network, due to loss of connectivity or a change in providers.

NPTv6 achieves its stateless property by performing a 1:1 network prefix translation operation which is checksum-neutral with respect to the 16-bit one's complement checksum function implemented in TCP, UDP, DCCP, and ICMPv6. Therefore, NPTv6 is (mostly) transparent to applications which do not perform address referrals or otherwise exchange IPv6 addresses.

ICMPv6 [RFC4443] error messages (Destination Unreachable, Packet Too Big, Time Exceeded, and Parameter Problem) embed the IPv6 header of the packet triggering the error message, along with as much of the original packet's payload as will fit without exceeding the IPv6 minimum MTU [RFC2460]. If an ICMPv6 error message is originated in an external network destined for a host behind a NPTv6 device, then that device must translate the IPv6 source address embedded in the error message payload; otherwise the destination host will not recognize the error message as pertaining to itself, since the source address in the error message payload contains an external network prefix, rather than the internal address prefix configured on the host. Similarly, if a host behind a NPTv6 device generates an ICMPv6 error message in response to a packet received from a host in an external network, then the NPTv6 device must translate the IPv6 destination address embedded in the error message payload; otherwise the external host will not recognize the error message, since it will seem to pertain to a packet sent to a host with an unknown network prefix.

Additional translation operations do not need to be performed on ICMPv6 informational messages, because such messages do not embed IPv6 addresses [RFC4443]. In the particular case of ICMPv6 "Echo Request" and "Echo Reply" messages, the identifier and sequence number fields do not need to be modified. Since NPTv6 devices do not perform address multiplexing, the identifier and sequence number spaces of multiple hosts behind the NPTv6 device do not need to be mapped into a smaller set of collision-free number spaces.

This document details the processing steps required by a NPTv6 device to correctly process ICMPv6 packets traversing the device between the internal and external networks.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. ICMPv6 Error Message Network Prefix Translation

As described in [RFC4443], ICMPv6 error messages are encoded with a Type value from 0 to 127. Each of the defined error messages (Destination Unreachable, Packet Too Big, Time Exceeded, and Parameter Problem) contains a message body which includes the IPv6 header of the invoking packet along with as much of the invoking packet's payload as will fit without exceeding the minimum IPv6 MTU. In each case the embedded IPv6 header is located at an offset of 8 bytes from the first byte of the ICMPv6 message. The embedded payload of the invoking IPv6 packet must include the upper-layer protocol type; otherwise the intended recipient of the error message will not be able to reliably deliver the error message to the appropriate upper-layer protocol for processing.

ICMPv6 messages include a 16-bit checksum field. The checksum is the 16-bit one's complement of the one's complement sum of the entire ICMPv6 message, starting with the ICMPv6 message type field, and prepended with a "pseudo-header" of IPv6 header fields, with a next header value in the pseudo-header of 58 [RFC2460], [RFC4443]. Because the embedded IPv6 addresses in an ICMPv6 error message body are 16-bit aligned, then the network prefix translation function defined in [RFC6296] is also ICMPv6 checksum-neutral when applied to the embedded IPv6 addresses.

Whenever a packet traverses a NPTv6 device from an external host to an internal host behind the device, the device performs a checksum- neutral network prefix translation on the packet's destination address: from an external prefix to the internal one. If the packet is an ICMPv6 error message, then the NPTv6 device must also translate the IPv6 source address embedded in the error message body, since this is the internal source address of the host that a) transmitted the invoking packet, and b) which is the intended destination of the ICMPv6 error message. Since the translated address of the internal host is the same in both cases, it is sufficient to compute the translated network prefix once, and copy it into both the destination address of the packet's IPv6 header, as well as the source address of the IPv6 header embedded in the ICMPv6 error message body.

Whenever a packet traverses a NPTv6 device from an internal host behind the device to an external host, the device performs a checksum-neutral network prefix translation on the packet's source address: from the internal prefix to an external one. If the packet is an ICMPv6 error message, then the NPTv6 device must also translate the IPv6 destination address embedded in the error message body, since this is the internal destination address of the host that a) received the invoking packet, and b) which is the source of the ICMPv6 error message. Since the translated address of the internal host is the same in both cases, it is sufficient to compute the translated network prefix once, and copy it into both the source address of the packet's IPv6 header, as well as the destination address of the IPv6 header embedded in the ICMPv6 error message body.

[RFC5508] defines requirements for ICMPv4 processing in IPv4-to-IPv4 NAT devices. That document specifies that the NAT device should validate the checksum of ICMPv4 error messages, and should silently drop the message if the checksum is invalid. This is recommended because IPv4-to-IPv4 NAT is stateful, and the embedded IPv4 addresses in the ICMPv4 message payload are used to lookup the NAT translation session. NPTv6 is stateless, and the IPv6 addresses embedded within an ICMPv6 error message are not used to lookup state. Therefore, there is no needed for the NPTv6 device to validate the ICMPv6 checksum.

[RFC4884] defines changes to the ICMPv6 "Destination Unreachable" and "Time Exceeded" error messages to support multi-part operation, using a common ICMP extension header that is appended to the original datagram embedded in the ICMP message. The format changes (i.e., the addition of an 8-bit "Length" field within the existing "Unused" field) does not affect the offset of the embedded IPv6 header, nor do the defined ICMP extensions embed IPv6 addresses which require translation. Therefore, the rules for ICMPv6 error message processing above also apply to multi-part ICMPv6 "Destination Unreachable" and "Time Exceeded" messages.

4. Example

Let us consider the configuration described in paragraph 2.1 of [RFC6296].

            External Network:  Prefix = 2001:0DB8:0001:/48
                --------------------------------------
                                  |
                                  |
                           +-------------+
                           |    NPTv6    |
                           |  Translator |
                           +-------------+
                                  |
                                  |
                --------------------------------------
            Internal Network:  Prefix = FD01:0203:0405:/48
        

A computer - let us call it Alice - is connected to the internal network, and is trying to access a server on the Internet. Let us assume that Alice wishes to determine the path MTU to the server; the PMTU discovery technique uses the ICMPv6 "Packet Too Big" error message. It is thus expected that at least at the first message of a flow will result in an ICMPv6 error message.

Let us assume that Alice's IP Address is FD01:0203:0405:0001::1234/48. Applying the algorithm described in [RFC6296], Alice's external IP address is 2001:0DB8:0001:D550::1234/48 - remember that Alice does not know her external address. Let us also consider 2001:0DB8:cafe::5678 to be the server's IP address.

The first packet sent by Alice to the server is similar to this:

               +----------------------------+
               | IPv6 Header Fields         |
               | FD01:0203:0405:0001::1234  |
               | 2001:0DB8:cafe::5678       |
               | ----------------           |
               | Layer 4 datagram           |
               +----------------------------+
      

The NPTv6 translator modifies the packet to resemble:

               +----------------------------+
               | IPv6 Header Fields         |
               | 2001:0DB8:0001:D550::1234  |
               | 2001:0DB8:cafe::5678       |
               | ----------------           |
               | Layer 4 datagram           |
               +----------------------------+
      

A router on the path to the server cannot support such a big packet and sends an ICMP Error message "Packet Too Big" (Type: 2, Code: 0) back to Alice. This packet is similar to this:

               +----------------------------+
               | IPv6 Header Fields         |
               | 2001:0DB8:babe::1          |
               | 2001:0DB8:0001:D550::1234  |
               | ----------------           |
               | 2 - 0 - checksum           |
               | IPv6 Header Fields         |
               | 2001:0DB8:0001:D550::1234  |
               | 2001:0DB8:cafe::5678       |
               | ...                        |
               +----------------------------+
      

We see that the payload of the ICMPv6 error message begins with Alice's original packet, which contains as source address her external IP address.

The NPTv6 translator will receive this packet, and according to [RFC6296] it will change the destination address field of this IPv6 packet to Alice's internal IP address - FD01:0203:0405:0001::1234. The packet would thus become:

               +----------------------------+
               | IPv6 Header Fields         |
               | 2001:0DB8:babe::1          |
               | FD01:0203:0405:0001::1234  |
               | ----------------           |
               | 2 - 0 - checksum           |
               | IPv6 Header Fields         |
               | 2001:0DB8:0001:D550::1234  |
               | 2001:0DB8:cafe::5678       |
               | ...                        |
               +----------------------------+
      

Alice would receive this packet but will not understand it: the source IP address of the ICMPv6 error message payload does not match her configured (internal) address. Hence the packet would be discarded. An additional manipulation must be performed, allowing Alice to process this message as it should: the NPTv6 translator must change the source IP address of the ICMPv6 error message payload to Alice's internal address. The packet then becomes:

               +----------------------------+
               | IPv6 Header Fields         |
               | 2001:0DB8:babe::1          |
               | FD01:0203:0405:0001::1234  |
               | ----------------           |
               | 2 - 0 - checksum           |
               | IPv6 Header Fields         |
               | FD01:0203:0405:0001::1234  |
               | 2001:0DB8:cafe::5678       |
               | ...                        |
               +----------------------------+
      

5. Hairpinning

[RFC6296] specifies that NPTv6 devices MUST support hairpinning behavior, as defined in [RFC4787]. This requirement must also apply to ICMPv6 messages. Hairpinned ICMPv6 informational messages do not require any ICMPv6 message translation, as mentioned in Sec. 1. Hairpinned ICMPv6 error messages MUST be processed using the mechanisms defined in Sec. 3.

6. Detecting ICMPv6 Error Messages

It is necessary to identify ICMPv6 error messages so that the required network prefix translation of the embedded IPv6 addresses can be performed. ICMPv6 messages are identified by a next header value of 58, and error message are distinquished by ICMPv6 type values from 0 to 127 [RFC4443]. In the absence of IPv6 extension headers in a packet, a NPTv6 device can detect an ICMPv6 message directly by examining the next header value within the packet's IPv6 header [RFC2460]. However, if one or more IPv6 extension headers are present, then it is necessary for the NPTv6 device to skip past each extension header in sequence to determine whether an ICMPv6 message is present in the packet. This processing MUST be performed for every packet traversing the NPTv6 device.

7. IANA Considerations

This memo includes no request to IANA.

8. Security Considerations

Because a NPTv6 device is a middle box in the path of communications crossing a network boundary, it is in the position to eavesdrop and perform a wide variety of network attacks if not secured. Improper implementation of the network prefix translation procedure described in this document does not introduce additional security vulnerabilities. Incorrectly translated IPv6 addresses in ICMPv6 error message bodies will result in the recipient host discarding the error message silenty.

9. Acknowledgements

To the authors' knowledge, the issue described in this draft was first raised in [Linux-NAT66]. The authors would like to thank Fred Baker for helpful discussions.

This document was produced using the xml2rfc tool [RFC2629].

10. References

10.1. Informative References

10.2. Normative References

Authors' Addresses