One document matched: draft-blake-nptv6-icmp-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-21 09:39:24 |