Network Working Group X. Li Internet-Draft C. Bao Intended status: Informational CERNET Center/Tsinghua University Expires: February 24, 2011 D. Wing R. Vaithianathan Cisco August 23, 2010 Stateless Source Address Mapping Algorithm for ICMPv6 Packets draft-xli-behave-icmp-address-01 Abstract For stateless IPv4/IPv6 translator, it may receive ICMPv6 packets containing non IPv4-translatable addresses as the source. This document defines a stateless address mapping mechanism for source address translation in ICMPv6 headers for such cases. Status of this Memo This Internet-Draft is submitted to IETF 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 February 24, 2011. Copyright Notice Copyright (c) 2010 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 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 Li, et al. Expires February 24, 2011 [Page 1] Internet-Draft Source Address Mapping for ICMPv6 August 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Analysis of the Possible Approaches . . . . . . . . . . . . . 4 4.1. Configure IPv6 Routers Using IPv4-translatable Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1. Use Public IPv4 Addresses . . . . . . . . . . . . . . 4 4.1.2. Use RFC1918 Addresses . . . . . . . . . . . . . . . . 4 4.2. Perform Stateful Source Address Mapping for ICMPv6 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2.1. Use Public IPv4 Addresses . . . . . . . . . . . . . . 4 4.2.2. Use RFC1918 Addresses . . . . . . . . . . . . . . . . 4 4.3. Use Translator's Interface Address to Represent Source Address for ICMPv6 Packets . . . . . . . . . . . . . . . . 5 4.4. Comparisons . . . . . . . . . . . . . . . . . . . . . . . 5 5. Stateless Source Address Mapping Algorithms for ICMPv6 Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Choosing an IPv4 /24 Address Block . . . . . . . . . . . . 6 5.1.1. Use Public IPv4 Addresses . . . . . . . . . . . . . . 6 5.1.2. Use RFC1918 Addresses . . . . . . . . . . . . . . . . 6 5.1.3. Ask IANA for allocating an IPv4 Well-Known Prefix . . 6 5.2. Design an Algorithm to Generate the Last Octet of IPv4 /24 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2.1. Randomly Generate the Last Octet . . . . . . . . . . . 7 5.2.2. Copy Hop Count into Last Octet . . . . . . . . . . . . 7 5.2.3. Hashing of the IPv6 address to generate Last Octet . . 8 5.3. Recommendations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Li, et al. Expires February 24, 2011 [Page 2] Internet-Draft Source Address Mapping for ICMPv6 August 2010 1. Introduction The IP/ICMP translation document of IPv4/IPv6 translation [I-D.ietf-behave-v6v4-xlate] states that "the IPv6 addresses in the ICMPv6 header may not be IPv4-translatable addresses and there will be no corresponding IPv4 addresses represented of this IPv6 address. In this case, the translator can do stateful translation. A mechanism by which the translator can instead do stateless translation is left for future work. " This document defines such a mechanism. 2. Notational Conventions The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Problem Statement As shown in the following figure, IPv6 host (H6) and IPv4 host (H4) can communicate via a stateless translator (XLATE). H6 is configured with an IPv4-translatable IPv6 address while IPv6 routers (R2, R3 and R4) are configured with non IPv4-translatable addresses. ------ ------ | IPv4 | -- ----- -- -- -- | IPv6 | | host |--|R1|----|XLATE|----|R2|--|R3|--|R4|--| host | | H4 | -- ----- -- -- -- | H6 | ------ | ------ | IPv4 --->|<---IPv6 Figure 1: Example topology of stateless translation If a packet sent by H4 exceeds the link MTU between R3 and R4, then R3 will generate a "Packet Too Big" ICMPv6 error message. In this case, the destination address is IPv4-converted address of H4 and the source address is non IPv4-translatable address of R3. Due to path MTU discovery requirement, the ICMPv6 MUST be translated to ICMP by XLATE. It is clear that the IPv4 source addresses of the ICMP packets translated by the translator SHOULD be valid IPv4 addresses in order not to be dropped alone the path, but who sends the ICMP error message is not as important as the content itself. Li, et al. Expires February 24, 2011 [Page 3] Internet-Draft Source Address Mapping for ICMPv6 August 2010 4. Analysis of the Possible Approaches 4.1. Configure IPv6 Routers Using IPv4-translatable Addresses Stateless translation can be used for scenarios 1, 2, 5 and 6 [I-D.ietf-behave-v6v4-framework] and all of these scenarios are concerning "an IPv6 network". Except for the case when "an IPv6 network" has multiple translators using different IPv6 prefixes, the network administrator can configure IPv6 routers using IPv4- translatable addresses and therefore the translator can translate the source addresses of ICMPv6 packets generated by IPv6 routers to valid IPv4 addresses. There are two variations of this method to form IPv4-translatable IPv6 addresses based on the algorithm defined in [I-D.ietf-behave-address-format]. 4.1.1. Use Public IPv4 Addresses The IPv6 routers in "an IPv6 network" can be configured using IPv4- translatable addresses, which are based on public IPv4 addresses. In this case, public IPv4 addresses will be wasted, since all interfaces of all IPv6 routers require IPv4-translatable addresses. 4.1.2. Use RFC1918 Addresses The IPv6 routers in "an IPv6 network" can be configured using IPv4- translatable addresses, which are based on [RFC1918] addresses. In this case, there is no waste of public IPv4 addresses. This method is similar to an IPv4 network when the infrastructure is using [RFC1918] addresses. 4.2. Perform Stateful Source Address Mapping for ICMPv6 Packets When translator receives ICMPv6 containing non IPv4-translatable address as the source, the translator can do stateful translation. There are two variations of the stateful translation. 4.2.1. Use Public IPv4 Addresses The translator can treat ICMPv6 packets the same as the ordinary IPv6 packets and performs stateful translation. However, this will consume public IPv4 addresses in the address pool if a lot of ICMPv6 packets are received. 4.2.2. Use RFC1918 Addresses The translator can do stateful translation, but map the source addresses of the ICMPv6 packets to [RFC1918] addresses. This method Li, et al. Expires February 24, 2011 [Page 4] Internet-Draft Source Address Mapping for ICMPv6 August 2010 does not consume public IPv4 addresses for the ICMPv6. 4.3. Use Translator's Interface Address to Represent Source Address for ICMPv6 Packets The translator can map non IPv4-translatable source addresses of the ICMPv6 packets to the interface address of the translator. This method does not waste public IPv4 addresses and is used in [I-D.xli-behave-ivi]. 4.4. Comparisons The current approaches have their own drawbacks: 1. Configuring IPv6 routers using IPv4-translatable addresses may involve the renumbering of all the IPv6 interface addresses in all routers. In addition, if public IPv4 addresses are used, it is a waste of the address resource. The major problem is that if multiple translators with multiple prefixes are used, there is no way to do so, since IPv4-translatable IPv6 addresses are prefix dependent. 2. Performing stateful source address mapping for ICMPv6 Packets can be used in an environment when the translator operates in combined stateless/stateful modes, or in stateful-only mode. However, for stateless-only translator, performing stateful source address mapping for ICMPv6 Packets is not worth the cost. 3. Using translator's interface address to represent source address for ICMPv6 Packets is the simplest method. However, different non IPv4-translatable addresses will be mapped to same IPv4 address. In the case of traceroute, it may be confused as a routing loop. Therefore, it is desirable to define a new mapping mechanism. 5. Stateless Source Address Mapping Algorithms for ICMPv6 Packets Based on above analysis, the requirements of stateless source address mapping for ICMPv6 Packets are: 1. The ICMP that is translated from ICMPv6 by translator SHOULD not be dropped by the IPv4 routers. This implies the source address of the ICMP SHOULD use valid IPv4 address. In addition, the source address SHOULD follow the uRPF policy if it is configured. Li, et al. Expires February 24, 2011 [Page 5] Internet-Draft Source Address Mapping for ICMPv6 August 2010 2. Since it is impossible to uniquely map arbitrary IPv6 addresses to different IPv4 addresses and content in the ICMP message is more important than who generating the content, a unique reverse mapping from these IPv4 addresses to the original IPv6 addresses is not critical. 3. Public IPv4 addresses SHOULD not be wasted. 4. If possible, the source address of the ICMP MAY indicate that it is translated from non IPv4-translatable IPv6 address by the translator. 5. If possible, different non IPv4-translatable IPv6 addresses MAY have different IPv4 address representations for a specific application. Therefore, we can use a small IPv4 address block as a to represent a group of non IPv4-translatable IPv6 addresses. The next question is how big of this small IPv4 address block. Consider a traceroute application, in order to identify different routers alone a path an IPv4 /24 is a reasonable size, since the maximum value of hop count is 256 in IPv6. 5.1. Choosing an IPv4 /24 Address Block 5.1.1. Use Public IPv4 Addresses The network administrator can allocate a public IPv4 /24 for the source address mapping of ICMPv6 packets. The advantage is that it is totally under network administrator's control. However, it wastes public IPv4 addresses and except the network operator of this network, no body knows that they are the holder of non IPv4- translatable IPv6 addresses. 5.1.2. Use RFC1918 Addresses An IPv4 /24 can be allocated from [RFC1918] address block. There is no waste of public IPv4 addresses. However, if the organization's network also uses RFC1918's block, it may cause confusion. In addition, except the network operator of this network, no body knows that they are the holder of non IPv4-translatable IPv6 addresses. 5.1.3. Ask IANA for allocating an IPv4 Well-Known Prefix Allocating an IPv4 /24 as Well-Known Prefix by IANA for mapping source address in ICMPv6 packet has several advantages. Li, et al. Expires February 24, 2011 [Page 6] Internet-Draft Source Address Mapping for ICMPv6 August 2010 o There is no waste of public IPv4 addresses, since same IPv4 /24 can be used for different networks. o The Well-Known Prefix can be used to identify the IPv4 addresses are actually mapped from non IPv4-translatable addresses via IPv4/ IPv6 translator. 5.2. Design an Algorithm to Generate the Last Octet of IPv4 /24 5.2.1. Randomly Generate the Last Octet The translator can randomly generates the Last Octet of the /24 prefix for different non IPv4-translatable addresses as shown in the following figure 0 8 16 24 32 ----------------------------+---------- | Prefix | Random | ----------------------------+---------- Figure 2: Randomly generated Last Octet However, in this case the translator may need to maintain some states to ensure same non IPv4-translatable IPv6 address maps to same IPv4 address. 5.2.2. Copy Hop Count into 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. Hence, the translator can copy the "Hop Count" in the IPv6 header of the ICMPv6 to the Last Octet as shown in the following figure. 0 8 16 24 32 ----------------------------+---------- | Prefix |Hop Count | ----------------------------+---------- Figure 3: Copy Hop Count into Last Octet If the routers emit ICMPv6 packets with different hop counts, it may Li, et al. Expires February 24, 2011 [Page 7] Internet-Draft Source Address Mapping for ICMPv6 August 2010 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. 5.2.3. Hashing of the IPv6 address to generate Last Octet Hashing of the IPv6 address to generate a 8 bit value which will be used to generate the last octet. 0 8 16 24 32 ----------------------------+---------- | Prefix |Hashing | ----------------------------+---------- Figure 4: Hashing of the IPv6 address to generate Last Octet The advantages of this approach are: 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. 5.3. Recommendations According to above discussion, we suggest asking IANA for an IPv4 /24 as a "Well-Known Prefix" and give the routing administrators option to configure one of the approaches: 1. Random Approach. 2. "Hop Count" approach. 3. Hashing approach. 6. Security Considerations None. 7. IANA Considerations This memo asks IANA for an IPv4 /24 as a "Well-Known Prefix". Li, et al. Expires February 24, 2011 [Page 8] Internet-Draft Source Address Mapping for ICMPv6 August 2010 Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the author's perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion. 8. Acknowledgments The authors would like to acknowledge the following contributors of this document: Kevin Yin, Chris Metz and Neeraj Gupta. 9. References 9.1. Normative References [I-D.ietf-behave-address-format] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-10 (work in progress), August 2010. [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-10 (work in progress), July 2010. [I-D.ietf-behave-v6v4-framework] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", draft-ietf-behave-v6v4-framework-10 (work in progress), August 2010. [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", draft-ietf-behave-v6v4-xlate-21 (work in progress), August 2010. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Li, et al. Expires February 24, 2011 [Page 9] Internet-Draft Source Address Mapping for ICMPv6 August 2010 [RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998. 9.2. Informative References [I-D.xli-behave-ivi] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation Design and Deployment for the IPv4/ IPv6 Coexistence and Transition", draft-xli-behave-ivi-07 (work in progress), January 2010. Authors' Addresses Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 CN Phone: +86 10-62785983 Email: xing@cernet.edu.cn Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 CN Phone: +86 10-62785983 Email: congxiao@cernet.edu.cn Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: dwing@cisco.com Li, et al. Expires February 24, 2011 [Page 10] Internet-Draft Source Address Mapping for ICMPv6 August 2010 Ramji Vaithianathan Cisco Systems, Inc. A 5-2, BGL 12-4, SEZ Unit, Cessna Business Park, Varthur Hobli Sarjapur Outer Ring Road BANGALORE KARNATAKA 560 103 INDIA Phone: +91 80 4426 0895 Email: rvaithia@cisco.com Li, et al. Expires February 24, 2011 [Page 11]