Internet DRAFT - draft-blake-nptv6-icmp
draft-blake-nptv6-icmp
Individual Submission S. Blake
Internet-Draft Extreme Networks
Updates: 6296 (if approved) T. Moes
Intended status: Experimental Deltatec
Expires: September 13, 2012 March 12, 2012
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 13, 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 September 13, 2012 [Page 1]
Internet-Draft ICMP Handling in NPTv6 March 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ICMPv6 Error Message Network Prefix Translation . . . . . . . 4
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Hairpinning . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Detecting ICMPv6 Error Messages . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Informative References . . . . . . . . . . . . . . . . . 9
10.2. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Blake & Moes Expires September 13, 2012 [Page 2]
Internet-Draft ICMP Handling in NPTv6 March 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) 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
Blake & Moes Expires September 13, 2012 [Page 3]
Internet-Draft ICMP Handling in NPTv6 March 2012
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
Blake & Moes Expires September 13, 2012 [Page 4]
Internet-Draft ICMP Handling in NPTv6 March 2012
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.
Blake & Moes Expires September 13, 2012 [Page 5]
Internet-Draft ICMP Handling in NPTv6 March 2012
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 |
+----------------------------+
The NPTv6 translator modifies the packet to resemble:
Blake & Moes Expires September 13, 2012 [Page 6]
Internet-Draft ICMP Handling in NPTv6 March 2012
+----------------------------+
| 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
Blake & Moes Expires September 13, 2012 [Page 7]
Internet-Draft ICMP Handling in NPTv6 March 2012
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.
Blake & Moes Expires September 13, 2012 [Page 8]
Internet-Draft ICMP Handling in NPTv6 March 2012
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
[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.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009.
Blake & Moes Expires September 13, 2012 [Page 9]
Internet-Draft ICMP Handling in NPTv6 March 2012
[Linux-NAT66]
Moes, T., "IPv6 Address Translation in a Linux Kernel",
University of Liege, 2011.
10.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.
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 September 13, 2012 [Page 10]
