draft-ietf-v6ops-ivi-icmp-address-03.txt   draft-ietf-v6ops-ivi-icmp-address-04.txt 
Network Working Group X. Li Network Working Group X. Li
Internet-Draft C. Bao Internet-Draft C. Bao
Intended status: BCP CERNET Center/Tsinghua Intended status: BCP CERNET Center/Tsinghua
Expires: January 12, 2013 University Expires: March 9, 2013 University
D. Wing D. Wing
R. Vaithianathan R. Vaithianathan
Cisco Cisco
G. Huston G. Huston
APNIC APNIC
July 11, 2012 September 5, 2012
Stateless Source Address Mapping for ICMPv6 Packets Stateless Source Address Mapping for ICMPv6 Packets
draft-ietf-v6ops-ivi-icmp-address-03 draft-ietf-v6ops-ivi-icmp-address-04
Abstract Abstract
A stateless IPv4/IPv6 translator may receive ICMPv6 packets A stateless IPv4/IPv6 translator may receive ICMPv6 packets
containing non IPv4-translatable addresses as the source that should containing non IPv4-translatable addresses as the source. These
be passed across the translator as an ICMP packet directed to the packets should be passed across the translator as ICMP packets
IPv4-translatable destination. This document presents directed to the IPv4 destination. This document presents
recommendations for source address translation in ICMPv6 headers for recommendations for source address translation in ICMPv6 headers to
such cases. handle such cases.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2013. This Internet-Draft will expire on March 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement and Considerations . . . . . . . . . . . . . 3 3. Problem Statement and Considerations . . . . . . . . . . . . . 3
3.1. Considerations . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Recommendations . . . . . . . . . . . . . . . . . . . . . . 4
4. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 4 4. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4 5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The IP/ICMP translation document of IPv4/IPv6 translation [RFC6145] [RFC6145] section 5.2 of the "IP/ICMP Translation Algorithm"
states that "the IPv6 addresses in the ICMPv6 header may not be IPv4- document. states that "the IPv6 addresses in the ICMPv6 header may
translatable addresses and there will be no corresponding IPv4 not be IPv4-translatable addresses and there will be no corresponding
addresses represented of this IPv6 address. In this case, the IPv4 addresses representing this IPv6 address. In this case, the
translator can do stateful translation. A mechanism by which the translator can do stateful translation. A mechanism by which the
translator can instead do stateless translation is left for future translator can instead do stateless translation is left for future
work." This document presents recommendations for this case. work." This document, Stateless Source Address Mapping for ICMPv6
Packets, provides recommendations for this case.
2. Notational Conventions 2. Notational Conventions
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119]. document, are to be interpreted as described in [RFC2119].
3. Problem Statement and Considerations 3. Problem Statement and Considerations
When a stateless IPv4/IPv6 translator receives an ICMPv6 message When a stateless IPv4/IPv6 translator receives an ICMPv6 message
[RFC4443] (for example "Packet Too Big") sourced from an non-IPv4- [RFC4443] (for example "Packet Too Big") sourced from an non-IPv4-
translatable IPv6 address, directed to an IPv4-translatable IPv6 translatable IPv6 address, bound for to an IPv4-translatable IPv6
address, it needs to generate an ICMP message. For the reasons address, the translator needs to pick a source address with which to
discussed below, choosing the source IPv4 address of this ICMP generate an ICMP message. For the reasons discussed below, this
message is problematic. choice is problematic.
The address used should not cause the ICMP packet to be a candidate 3.1. Considerations
for discarding, particularly in the contest of uRPF filters
[RFC3704]. This consideration precludes the use of private IPv4
address space [RFC1918] in this context.
It is also a consideration that the IPv4/IPv6 translation is intended The source address used, should not cause the ICMP packet to be a
for use in contexts where IPv4 addresses may not be readily candidate for discarding. The possibility of uRPF filters in the
available, so it is not considered to be appropriate to use IPv4- path are a critical consideration [RFC3704] which precludes the use
translatable IPv6 addresses for all internal points in the IPv6 of private IPv4 address space [RFC1918] in this context.
network that may originate ICMPv6 messages.
It is also an objective that it is possible for the IPv4 recipient of IPv4/IPv6 translation is intended for use in contexts where IPv4
the ICMP message be able to distinguish between different IPv6 ICMPv6 addresses may not be readily available, so it is not considered
originations (for example, to support a traceroute diagnostic utility appropriate to assign IPv4-translatable IPv6 addresses for all
that provides some limited network level visibility across the IPv4/ internal points in the IPv6 network that may originate ICMPv6
IPv6 translator). This implies that an IPv4/IPv6 translator needs to messages.
have a pool of IPv4 addresses for mapping the source address of
ICMPv6 packets generated from different originations, or to include
the IPv6 source address information for mapping the source address by
others means.
These considerations leads to the recommendation of using the a Another consideration for source selection is that it be possible for
single (or small pool) of public IPv4 address as the source address the IPv4 recipients of the ICMP message to be able to distinguish
of translated ICMP and using ICMP extension [RFC5837] to include IPv6 between different IPv6 network origination of ICMPv6 messages, (for
address as Interface IP Address Sub-Object. example, to support a traceroute diagnostic utility that provides
some limited network level visibility across the IPv4/IPv6
translator). This consideration implies that an IPv4/IPv6 translator
needs to have a pool of IPv4 addresses for mapping the source address
of ICMPv6 packets generated from different origins, or to include the
IPv6 source address information for mapping the source address by
others means. Currently, the TRACEROUTE and MTR [MTR] are the only
consumers of translated ICMPv6 messages that care about the ICMPv6
source address.
3.2. Recommendations
The recommended approach to source selection is to use the a single
(or small pool) of public IPv4 address as the source address of the
translated ICMP message and leverage ICMP extension [RFC5837] to
include IPv6 address as an Interface IP Address Sub-Object.
4. ICMP Extension 4. ICMP Extension
No matter a single public IPv4 address (in the IPv4 interface or a In the case of either a single public IPv4 address (the IPv4
loopback address of the translator) or a pool of public IPv4 interface address or loopback address of the translator) or a pool of
addresses are used, the translator SHOULD implement ICMP extension public IPv4 addresses, the translator SHOULD implement ICMP extension
defined by [RFC5837]. The resulting ICMP extension SHOULD include defined by [RFC5837]. The ICMP message SHOULD include the Interface
the Interface IP Address Sub-Object that specify the source IPv6 IP Address Sub-Object, and specify the source IPv6 addresses of the
addresses in the original ICMPv6. When an enhanced traceroute original ICMPv6. When an enhanced traceroute application is used, it
application is used, it can get the real IPv6 source addresses which can derive the real IPv6 source addresses which generated the ICMPv6
generate the ICMPv6 messages. Therefore, it is able to traceback to messages. Therefore, it would be able improve on visibility towards
their origins and take filtering/rate-limiting actions if necessary. the origin rather than simply blackholing at or beyond the
translator. In the future, a new ICMP extension whose presence
indicates that the packet has been translated and that the source
address belongs to the translator, not the originating node can also
be considered.
5. Stateless Address Mapping Algorithm 5. Stateless Address Mapping Algorithm
If a pool of public IPv4 addresses is configured in the translator, If a pool of public IPv4 addresses is configured on the translator,
it is RECOMMENDED to randomly pick up the IPv4 public address in the it is RECOMMENDED to randomly select the IPv4 source address from the
pool. This can somehow avoid the appearance of a routing loop to pool. This can superficially avoid the appearance of a routing loop
tools such as traceroute. An enhanced traceroute application is in tools unaware of the ICMP extension such as traceroute. An
still RECOMMENDED in order to obtain the real IPv6 source addresses enhanced traceroute application is RECOMMENDED in order to obtain the
which generate the ICMPv6 messages. IPv6 source addresses which generated the ICMPv6 messages.
6. Security Considerations 6. Security Considerations
This document does not introduce any new security considerations. This document recommends the generation of IPv4 ICMP messages from
IPv6 ICMP messages. These messages would otherwise have been
discarded. It is not expected that new considerations result from
this change. As with a number of ICMP messages, a spoofed source
address may result in replies arriving at hosts that did not expect
them using the facility of the translator.
7. IANA Considerations 7. IANA Considerations
None. There is no consideration requested of IANA.
8. Acknowledgments 8. Acknowledgments
The authors would like to acknowledge the following contributors of The authors would like to acknowledge the following contributors of
this document: Kevin Yin, Chris Metz and Neeraj Gupta. The authors this document: Kevin Yin, Chris Metz, Neeraj Gupta and Joel Jaeggli.
would also like to thank Ronald Bonica, Ray Hunter, George Wes, Yu The authors would also like to thank Ronald Bonica, Ray Hunter,
Guanghui, Sowmini Varadhan, David Farmer, Fred Baker, Leo Vegoda, George Wes, Yu Guanghui, Sowmini Varadhan, David Farmer, Fred Baker,
Joel Jaeggli, Henrik Levkowetz, Henrik Levkowetz, Randy Bush and Leo Vegoda, Joel Jaeggli, Henrik Levkowetz, Henrik Levkowetz, Randy
Warren Kumari for their comments and suggestions. Bush and Warren Kumari for their comments and suggestions.
9. Normative References 9. References
9.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
skipping to change at page 5, line 28 skipping to change at page 5, line 44
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.
Rivers, "Extending ICMP for Interface and Next-Hop Rivers, "Extending ICMP for Interface and Next-Hop
Identification", RFC 5837, April 2010. Identification", RFC 5837, April 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
9.2. Informative References
[MTR] "http://www.bitwizard.nl/mtr/".
Authors' Addresses Authors' Addresses
Xing Li Xing Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University Room 225, Main Building, Tsinghua University
Beijing 100084 Beijing 100084
CN CN
Phone: +86 10-62785983 Phone: +86 10-62785983
Email: xing@cernet.edu.cn Email: xing@cernet.edu.cn
 End of changes. 21 change blocks. 
67 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/