draft-ietf-v6ops-ivi-icmp-address-00.txt   draft-ietf-v6ops-ivi-icmp-address-01.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: May 17, 2012 University Expires: August 28, 2012 University
D. Wing D. Wing
R. Vaithianathan R. Vaithianathan
Cisco Cisco
G. Huston G. Huston
APNIC APNIC
November 14, 2011 February 25, 2012
Stateless Source Address Mapping for ICMPv6 Packets Stateless Source Address Mapping for ICMPv6 Packets
draft-ietf-v6ops-ivi-icmp-address-00 draft-ietf-v6ops-ivi-icmp-address-01
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 that should
be passed across the translator as an ICMP packet directed to the the be passed across the translator as an ICMP packet directed to the the
IPv4-translatable destination. This document discusses the IPv4-translatable destination. This document discusses the
considerations and the stateless address mapping algorithms for considerations and presents a stateless address mapping algorithm for
source address translation in ICMPv6 headers for such cases. source address translation in ICMPv6 headers for 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 May 17, 2012. This Internet-Draft will expire on August 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
4. Routing Considerations . . . . . . . . . . . . . . . . . . . . 4 4. Routing Considerations . . . . . . . . . . . . . . . . . . . . 4
5. Possible Stateless Address Mapping Algorithms . . . . . . . . . 4 5. Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. ICMP Extension . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Filtering Recommendations . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.2. Rate-limiting Recommendations . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.3. RFC5837 Recommendations . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The IP/ICMP translation document of IPv4/IPv6 translation [RFC6145] The IP/ICMP translation document of IPv4/IPv6 translation [RFC6145]
states that "the IPv6 addresses in the ICMPv6 header may not be IPv4- states that "the IPv6 addresses in the ICMPv6 header may not be IPv4-
translatable addresses and there will be no corresponding IPv4 translatable addresses and there will be no corresponding IPv4
addresses represented of this IPv6 address. In this case, the addresses represented of 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 defines such a stateless translation mechanism. work." This document defines such a stateless translation mechanism.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
application, it is feasible to use a common address pool for mapping application, it is feasible to use a common address pool for mapping
the source addresses of non-translatable ICMPv6 packets as a part of the source addresses of non-translatable ICMPv6 packets as a part of
the protocol specification. the protocol specification.
These considerations leads to the recommendation of drawing an IPv4 These considerations leads to the recommendation of drawing an IPv4
/24 prefix from the IANA Special Purpose Address Registry as a "Well- /24 prefix from the IANA Special Purpose Address Registry as a "Well-
Known Prefix" for use by IPv4/IPv6 translators for the purpose of Known Prefix" for use by IPv4/IPv6 translators for the purpose of
mapping otherwise untranslatable IPv6 source addresses of ICMPv6 mapping otherwise untranslatable IPv6 source addresses of ICMPv6
messages to IPv4 ICMP messages. messages to IPv4 ICMP messages.
The ICMP extension defined by [RFC5837] provides a mechanism to
process the ICMPv4 messages that contain IP Address Sub-Objects that
specify IPv6 addresses. However, an enhanced traceroute application
must be used, which has not yet been widely available. In this
document, a combined approach is proposed, i.e. non IPv4-translatable
address is mapped to IANA-assigned /24, and the resulting ICMP is
extended according to [RFC5837]. Therefore, ordinary ICMP processing
tools (traceroute) can be utilized in normal cases and when DDoS
happens, enhanced ICMP process tools can be utilized to identify the
real source.
4. Routing Considerations 4. Routing Considerations
Addresses from the assigned address prefix are intended to be used as Addresses from the assigned address prefix are intended to be used as
source addresses and not as destination addresses in the context of source addresses and not as destination addresses in the context of
the public network. As packets passing through the public network the public network. As packets passing through the public network
need to pass through conventional packet filters, including uRPF need to pass through conventional packet filters, including uRPF
filters [RFC3704], this implies that the assigned address may be used filters [RFC3704], this implies that the assigned address may be used
in routing advertisements. Such routing advertisements are non- in routing advertisements. Such routing advertisements are non-
exclusive and should be accepted from any originating AS in an exclusive and should be accepted from any originating AS in an
anycast fashion. anycast fashion.
5. Possible Stateless Address Mapping Algorithms 5. Stateless Address Mapping Algorithm
When an IPv4 /24 prefix is allocated to represent the source address When an IPv4 /24 prefix is allocated to represent the source address
of ICMP, the Last Octet can be generated using one of the following of ICMP, the translator MUST copy the "Hop Count" in the IPv6 header
algorithms. of the ICMPv6 to the Last Octet. When routers emit ICMPv6 packets
with the same hop count, as the ICMPv6 packet is routed through the
o The translator can randomly generates the Last Octet of the /24 network its hop count is decreased. However, if the routers emit
prefix for different non IPv4-translatable addresses. However, in ICMPv6 packets with different hop counts, it may give the appearance
this case the translator may need to maintain states to ensure of a routing loop to tools such as traceroute. That minor side-
same non IPv4-translatable IPv6 address maps to same IPv4 address. effect in that particular case cannot be avoided while still being
stateless.
o The translator can copy the "Hop Count" in the IPv6 header of the
ICMPv6 to the Last Octet. Routers typically emit ICMPv6 packets
with the same hop count, thus as the ICMPv6 packet is routed
through the network its hop count is decreased. However, if the
routers emit ICMPv6 packets with different hop counts, it may give
the appearance of a routing loop to tools such as traceroute.
That minor side-effect in that particular case cannot be avoided
while still being stateless.
o Hashing of the IPv6 address to generate a 8 bit value which will 6. ICMP Extension
be used to generate the last octet. In this case, there is no
need to maintain expensive states, except hashing table which
should be simple with minimal memory usage and consume minimal CPU
cycles. If the hashing function is good and there are limited
number of IPv6 routers (< 256) on the IPv6 side of the network, we
will get unique IPv4 addresses to map the addresses of the IPv6
routers with O(1) lookup.
The selection of the algorithm SHOULD be a configuration function in When translator is configured to use the IANA-assigned /24 to map non
the IPv4/IPv6 translator. IPv4-translatable address, the translator MUST implement ICMP
extension defined by [RFC5837]. The resulting ICMP extension MUST
include the IP address Sub-Objects that specify the source IPv6
addresses in the original ICMPv6. Therefore, an enhanced traceroute
application can get the real IPv6 source addresses which generate the
ICMPv6 messages, be able to traceback to their origins and take
filtering/rate-limiting actions if necessary.
6. Security Considerations 7. Security Considerations
The use of an address for source addresses in ICMP packets is The use of an address for source addresses in ICMP packets is
considered "safe" in so far as ICMP packets are not intended to considered "safe" in so far as ICMP packets are not intended to
generate responses directed to the source address. generate responses directed to the source address.
However it is possible to use this address as a means of gaining However it is possible to use this address as a means of gaining
anonymity when launching a denial of service attacks by using this anonymity when launching a denial of service attacks by using this
address as the source address for other forms of malicious traffic. address as the source address for other forms of malicious traffic.
Packet firewall filters should be configured to treat addresses in Packet firewall filters should be configured to treat addresses in
the IANA-assigned /24 network as martian addresses by discarding all the IANA-assigned /24 network as martian addresses by discarding all
non-ICMP packets that use the IANA-assigned /24 network as a source non-ICMP packets that use the IANA-assigned /24 network as a source
address, and all packets that use the IANA-assigned /24 network as a address, and all packets that use the IANA-assigned /24 network as a
destination address. destination address.
7. IANA Considerations 7.1. Filtering Recommendations
o SHOULD allow ICMP type 3 - Destination Unreachable (inc PTB).
o SHOULD allow ICMP type 11 - Time Exceeded.
o MAY allow ICMP type 12 - Parameter Problem.
o SHOULD NOT allow any of the various ICMP request messages.
7.2. Rate-limiting Recommendations
The rate limiting of traffic from the prefix SHOULD also be enabled
as additional countermeasure against abuse of this prefix. The
methods presented in [RFC4443] [RFC5597] [RFC6192] [RFC6398]
[RFC6450] can be used.
7.3. RFC5837 Recommendations
Advanced filtering and rate-limiting techniques which can process the
ICMP extension defined in [RFC5837] MAY also be used to control the
source of the ICMP.
8. IANA Considerations
IANA is requested to make a permanent assignment of a /24 from the IANA is requested to make a permanent assignment of a /24 from the
IPv4 Special Purpose Address Registry [RFC5736]. The assigned IPv4 Special Purpose Address Registry [RFC5736]. The assigned
address is to be used in the context of generating an IPv4 source address is to be used in the context of generating an IPv4 source
address for mapped ICMPv6 packets being passed through a stateless address for mapped ICMPv6 packets being passed through a stateless
IPv4/IPv6 translator. The assignment is under the category of a IPv4/IPv6 translator. The assignment is under the category of a
specialized use of a designated address block in an anycast context specialized use of a designated address block in an anycast context
associated with an Internet Standards Track protocol. associated with an Internet Standards Track protocol.
The IANA IPv4 Special Purpose Address Registry records are: The IANA IPv4 Special Purpose Address Registry records are:
skipping to change at page 6, line 14 skipping to change at page 6, line 38
o Purpose: Stateless ICMPv6/ICMP translation o Purpose: Stateless ICMPv6/ICMP translation
o Contact: See RFC o Contact: See RFC
o Scope: Addresses from the assigned address prefix are intended to o Scope: Addresses from the assigned address prefix are intended to
be used as source addresses and not as destination addresses in be used as source addresses and not as destination addresses in
the context of the public network. the context of the public network.
o RFC: This draft. o RFC: This draft.
8. Acknowledgments 9. 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. this document: Kevin Yin, Chris Metz and Neeraj Gupta.
9. References 10. References
9.1. Normative References 10.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.
[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.
[RFC5597] Denis-Courmont, R., "Network Address Translation (NAT)
Behavioral Requirements for the Datagram Congestion
Control Protocol", BCP 150, RFC 5597, September 2009.
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.
Rivers, "Extending ICMP for Interface and Next-Hop
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 [RFC6398] Le Faucheur, F., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, October 2011.
[RFC6450] Venaas, S., "Multicast Ping Protocol", RFC 6450,
December 2011.
10.2. Informative References
[RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special
Purpose Address Registry", RFC 5736, January 2010. Purpose Address Registry", RFC 5736, January 2010.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, March 2011.
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. 20 change blocks. 
47 lines changed or deleted 97 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/