Individual Submission S. Blake Internet-Draft Extreme Networks Updates: 6296 (if approved) October 24, 2011 Intended status: Experimental Expires: April 26, 2012 ICMP Handling in IPv6-to-IPv6 Network Prefix Translation draft-blake-nptv6-icmp-00 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 April 26, 2012. Copyright Notice Copyright (c) 2011 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 Expires April 26, 2012 [Page 1] Internet-Draft ICMP Handling in NPTv6 October 2011 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. Detecting ICMPv6 Error Messages . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Informative References . . . . . . . . . . . . . . . . . . 6 8.2. Normative References . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Blake Expires April 26, 2012 [Page 2] Internet-Draft ICMP Handling in NPTv6 October 2011 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 Expires April 26, 2012 [Page 3] Internet-Draft ICMP Handling in NPTv6 October 2011 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. 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 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 transmitted the invoking packet, and 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 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 received the invoking packet, and 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 Blake Expires April 26, 2012 [Page 4] Internet-Draft ICMP Handling in NPTv6 October 2011 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. 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 examing the next header value in the packet's IPv6 header [RFC2460]. However, if 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. 5. IANA Considerations This memo includes no request to IANA. 6. 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. 7. Acknowledgements To the author's knowledge, the issue described in this draft was first raised in [Linux-NPTv6]. The author would like to thank Terry Moes and Fred Baker for helpful discussions [elaborate more later]. This document was produced using the xml2rfc tool [RFC2629]. 8. References Blake Expires April 26, 2012 [Page 5] Internet-Draft ICMP Handling in NPTv6 October 2011 8.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-NPTv6] Moes, T., "IPv6 Address Translation in a Linux Kernel", 2011. 8.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. Author's Address 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 Blake Expires April 26, 2012 [Page 6]