Individual Submission S. Blake Internet-Draft Extreme Networks Updates: 6296 (if approved) T. Moes Intended status: Experimental Deltatec Expires: July 31, 2012 January 28, 2012 ICMP Handling in IPv6-to-IPv6 Network Prefix Translation draft-blake-nptv6-icmp-01 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 July 31, 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 Blake & Moes Expires July 31, 2012 [Page 1] Internet-Draft ICMP Handling in NPTv6 January 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. ICMPv6 Error Message Network Prefix Translation . . . . . . . . 4 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Detecting ICMPv6 Error Messages . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Informative References . . . . . . . . . . . . . . . . . . 8 9.2. Normative References . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Blake & Moes Expires July 31, 2012 [Page 2] Internet-Draft ICMP Handling in NPTv6 January 2012 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) contain 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. 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]. Blake & Moes Expires July 31, 2012 [Page 3] Internet-Draft ICMP Handling in NPTv6 January 2012 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 Blake & Moes Expires July 31, 2012 [Page 4] Internet-Draft ICMP Handling in NPTv6 January 2012 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. 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 Figure 1: A simple translator 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 | +----------------------------+ Blake & Moes Expires July 31, 2012 [Page 5] Internet-Draft ICMP Handling in NPTv6 January 2012 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 Blake & Moes Expires July 31, 2012 [Page 6] Internet-Draft ICMP Handling in NPTv6 January 2012 source IP address of the ICMPv6 error message payload does not match hers. 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. 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. 6. IANA Considerations This memo includes no request to IANA. 7. 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 Blake & Moes Expires July 31, 2012 [Page 7] Internet-Draft ICMP Handling in NPTv6 January 2012 vulnerabilities. Incorrectly translated IPv6 addresses in ICMPv6 error message bodies will result in the recipient host discarding the error message silenty. 8. 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]. 9. References 9.1. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [Linux-NAT66] Moes, T., "IPv6 Address Translation in a Linux Kernel", University of Liege, 2011. 9.2. Normative References [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011. Blake & Moes Expires July 31, 2012 [Page 8] Internet-Draft ICMP Handling in NPTv6 January 2012 Authors' Addresses Steven Blake Extreme Networks Pamlico Building One, Suite 100 3306/08 E. NC Hwy 54 RTP, NC 27709 USA Phone: +1 919-884-3211 Email: sblake@extremenetworks.com Terry Moes Deltatec Email: moes.terry@gmail.com Blake & Moes Expires July 31, 2012 [Page 9]