One document matched: draft-blake-nptv6-icmp-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC4884 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4884.xml">
<!ENTITY RFC5508 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5508.xml">
<!ENTITY RFC6296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6296.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most
I-Ds might want to use. (Here they are set differently than their
defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="no" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-blake-nptv6-icmp-02" ipr="trust200902" updates="6296">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3978, noModification3978, noDerivatives3978
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only
necessary if the full title is longer than 39 characters -->
<title abbrev="ICMP Handling in NPTv6"> ICMP Handling in IPv6-to-IPv6 Network Prefix Translation</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Steven Blake" initials="S" surname="Blake">
<organization>Extreme Networks</organization>
<address>
<postal>
<street>Pamlico Building One, Suite 100</street>
<street>3306/08 E. NC Hwy 54</street>
<city>RTP</city>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>
<phone>+1 919-884-3211</phone>
<email>sblake@extremenetworks.com</email>
</address>
</author>
<author fullname="Terry Moes" initials="T" surname="Moes">
<organization>Deltatec</organization>
<address>
<email>moes.terry@gmail.com</email>
</address>
</author>
<date year="2012" month="March" day="12"/>
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>Individual Submission</workgroup>
<!-- WG name at the upperleft corner of the doc, IETF is fine for
individual submissions. If this element is not present, the default
is "Network Working Group", which is used by the RFC Editor as a nod
to the history of the IETF. -->
<keyword>ICMP, NPTv6</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
NPTv6 <xref target="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 <xref target="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.
</t>
<t>
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.
</t>
<t>
ICMPv6 <xref target="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 <xref target="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.
</t>
<t>
Additional translation operations do not need to be performed on ICMPv6
informational messages, because such messages do not embed IPv6
addresses <xref target="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.
</t>
<t>
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.
</t>
</section>
<section title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
<section title="ICMPv6 Error Message Network Prefix Translation">
<t>
As described in <xref target="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.
</t>
<t>
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 <xref target="RFC2460"/>,
<xref target="RFC4443"/>. Because the embedded IPv6 addresses
in an ICMPv6 error message body are 16-bit aligned, then the
network prefix translation function defined in <xref target="RFC6296"/>
is also ICMPv6 checksum-neutral when applied to the embedded IPv6
addresses.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
<xref target="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.
</t>
<t>
<xref target="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.
</t>
</section>
<section title="Example">
<figure anchor="NetworkConfiguration" title="A simple translator">
<preamble>Let us consider the configuration described in paragraph
2.1 of <xref target="RFC6296"/>.</preamble>
<artwork>
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
|
|
+-------------+
| NPTv6 |
| Translator |
+-------------+
|
|
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
</artwork>
</figure>
<t>
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.
</t>
<t>
Let us assume that Alice's IP Address is FD01:0203:0405:0001::1234/48.
Applying the algorithm described in <xref target="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.
</t>
<t>
The first packet sent by Alice to the server is similar to this:
</t>
<figure><artwork>
+----------------------------+
| IPv6 Header Fields |
| FD01:0203:0405:0001::1234 |
| 2001:0DB8:cafe::5678 |
| ---------------- |
| Layer 4 datagram |
+----------------------------+
</artwork></figure>
<t>
The NPTv6 translator modifies the packet to resemble:
</t>
<figure><artwork>
+----------------------------+
| IPv6 Header Fields |
| 2001:0DB8:0001:D550::1234 |
| 2001:0DB8:cafe::5678 |
| ---------------- |
| Layer 4 datagram |
+----------------------------+
</artwork></figure>
<t>
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:
</t>
<figure><artwork>
+----------------------------+
| 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 |
| ... |
+----------------------------+
</artwork></figure>
<t>
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.
</t>
<t>The NPTv6 translator will receive this packet, and according to
<xref target="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:
</t>
<figure><artwork>
+----------------------------+
| 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 |
| ... |
+----------------------------+
</artwork></figure>
<t>
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:
</t>
<figure><artwork>
+----------------------------+
| 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 |
| ... |
+----------------------------+
</artwork></figure>
</section>
<section title="Hairpinning">
<t>
<xref target="RFC6296"/> specifies that NPTv6 devices MUST support
hairpinning behavior, as defined in <xref target="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.
</t>
</section>
<section title="Detecting ICMPv6 Error Messages">
<t>
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 <xref target="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 <xref target="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.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This memo includes no request to IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
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.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
To the authors' knowledge, the issue described in this draft was first
raised in <xref target="Linux-NAT66"/>. The authors would like to thank
Fred Baker for helpful discussions.
</t>
<t>
This document was produced using the xml2rfc tool
<xref target="RFC2629" />.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation
libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629;
here (as shown)
2. simply use a PI "less than character"?rfc
include="reference.RFC.2119.xml"?> here (for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find
included files in the same directory as the including file. You can
also define the XML_LIBRARY environment variable with a value
containing a set of directories to search. These can be either in
the local filing system or remote ones accessed by
http (http://domain/dir/... ). -->
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2119;
&RFC2460;
&RFC2629;
&RFC4193;
&RFC4787;
&RFC4884;
&RFC5508;
<reference anchor="Linux-NAT66">
<front>
<title>IPv6 Address Translation in a Linux Kernel</title>
<author initials="T" surname="Moes" fullname="Terry Moes">
<organization>
"University of Liege"
</organization>
</author>
<date year="2011" />
</front>
</reference>
</references>
<references title="Normative References">
&RFC4443;
&RFC6296;
</references>
</back>
</rfc>
<!-- Change Log
00 2011-10-24 First draft (generated without review).
01 2012-01-23 Second draft. Make a few minor grammar/spelling edits. Add
example from Terry.
-->
| PAFTECH AB 2003-2026 | 2026-04-21 20:22:54 |