RFC 6791

Stateless Source Address Mapping for ICMPv6 Packets

📅 published November 2012, from ietf

Stateless Source Address Mapping for ICMPv6 Packets 💖

okay bestie, so this is RFC 6791 🦋 It's a Standards Track doc from the IETF, dated November 2012, and it's got ISSN 2070-1721. It updates RFC 6145 (IP/ICMP Translation Algorithm), so it's basically a follow-up patch to that one 🧚 The authors are Xing Li and Congxiao Bao from CERNET Center/Tsinghua University, Dan Wing and Ramji Vaithianathan from Cisco, and Geoff Huston from APNIC. Their full addresses and contact info are down at the bottom in Authors' Addresses 💅

Abstract ✨

okay so a stateless IPv4/IPv6 translator can get ICMPv6 packets where the source is an address that can't be turned into an IPv4 address 🙈 those packets should still get passed through the translator as ICMP packets going to the IPv4 destination. This doc gives recommendations for translating the source address inside ICMPv6 headers so that works 🌸

Status of This Memo

This is an Internet Standards Track document. 🎀

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. ⭐

Info about the current status of this doc, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6791. 💜

Copyright (c) 2012 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) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this doc 🫶 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
3.  Problem Statement and Considerations  . . . . . . . . . . . . . 3
  3.1.  Considerations  . . . . . . . . . . . . . . . . . . . . . . 3
  3.2.  Recommendations . . . . . . . . . . . . . . . . . . . . . . 3
4.  ICMP Extension  . . . . . . . . . . . . . . . . . . . . . . . . 4
5.  Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4
6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
  8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5

1. Introduction ✨

Section 5.3 of "IP/ICMP Translation Algorithm" [RFC6145] says that "the IPv6 addresses in the IPv6 header may not be IPv4-translatable addresses and there will be no corresponding IPv4 addresses representing this IPv6 address. In this case, the translator can do stateful translation. A mechanism by which the translator can instead do stateless translation of this address is left for future work." 🙈 This doc, "Stateless Source Address Mapping for ICMPv6 Packets", gives recommendations for exactly that case 💅

For this document, the term "IPv4-translatable IPv6 address" means what Section 2.2 of [RFC6052] defines it as 🧚

2. Notational Conventions 🎀

Whenever the words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL show up in this doc, they're meant as described in [RFC2119] 🔥

3. Problem Statement and Considerations 🦋

So when a stateless IPv4/IPv6 translator gets an ICMPv6 message [RFC4443] (like "Packet Too Big") whose source is a non-IPv4-translatable IPv6 address and it's heading to an IPv4-translatable IPv6 address, the translator has to pick a source address to build its own ICMP message with. 😭 And for the reasons below, that choice is genuinely tricky.

3.1. Considerations 🌸

The source address used SHOULD NOT cause the ICMP packet to be discarded. It SHOULD NOT come from [RFC1918] or [RFC6598] address space, because that space is likely to get hit by unicast Reverse Path Forwarding (uRPF) [RFC3704] filtering 💀

IPv4/IPv6 translation is meant for places where IPv4 addresses might not be easy to get. So it's not really appropriate to give IPv4-translatable IPv6 addresses to every internal point in the IPv6 network that might originate ICMPv6 messages 🍓

Another thing to think about with source selection: the IPv4 recipients of the ICMP message should be able to tell apart different IPv6 network origins of ICMPv6 messages. That's useful for something like a traceroute diagnostic tool that gives you a bit of network-level visibility across the IPv4/IPv6 translator 👑 This means the translator either needs a pool of IPv4 addresses to map the source addresses of ICMPv6 packets from different origins, or it needs to carry the IPv6 source address info so others can do the mapping. Right now, TRACEROUTE and MTR [MTR] are the only consumers of translated ICMPv6 messages that actually care about the ICMPv6 source address 🫶

3.2. Recommendations 💜

The recommended approach to source selection is to use a single (or small pool of) public IPv4 address as the source address of the translated ICMP message, and to use the ICMP extension [RFC5837] to include the IPv6 address as an Interface IP Address Sub-Object ✨

4. ICMP Extension 🌈

If you're using either a single public IPv4 address (the translator's IPv4 interface address or loopback address) or a pool of public IPv4 addresses, the translator SHOULD implement the ICMP extension defined by [RFC5837]. The ICMP message SHOULD include the Interface IP Address Sub-Object and specify the source IPv6 addresses of the original ICMPv6 🧚 When an enhanced traceroute app is being used, it can work out the real IPv6 source addresses that generated the ICMPv6 messages. So it'd be able to improve visibility toward the origin, instead of just blackholing things at or beyond the translator 🔥 Down the road, a new ICMP extension could also be considered, one whose presence says the packet was translated and that the source address belongs to the translator and not the originating node 👑

5. Stateless Address Mapping Algorithm 💅

If a pool of public IPv4 addresses is configured on the translator, it is RECOMMENDED to randomly pick the IPv4 source address from that pool. Random selection lowers the chance that two ICMP messages triggered by the same TRACEROUTE end up with the same source address, which could otherwise falsely make it look like there's a routing loop 🌀

[RFC5837] extensions and an enhanced traceroute app, if used, will reveal the IPv6 source addresses that generated the original ICMPv6 messages 🦋

6. Security Considerations 💀

This document recommends generating IPv4 ICMP messages from IPv6 ICMP messages. Otherwise these messages would have been discarded 😭 New considerations aren't expected to come out of this change. But, just like with a bunch of ICMP messages, a spoofed source address could cause replies to land on hosts that weren't expecting them, using the translator's facility to get there. This one is a real thing, bestie, so take it seriously 🚨

7. Acknowledgments 🫶

The authors want to thank these contributors: Kevin Yin, Chris Metz, Neeraj Gupta, and Joel Jaeggli. The authors also want to thank Ronald Bonica, Ray Hunter, George Wes, Yu Guanghui, Sowmini Varadhan, David Farmer, Fred Baker, Leo Vegoda, Joel Jaeggli, Henrik Levkowetz, Randy Bush, and Warren Kumari for their comments and suggestions 💖

8. References 📚

8.1. Normative References 🎀

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de 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.

[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.

[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.

[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010.

[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.

[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.

[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.

8.2. Informative References 🧚

[MTR] "BitWizard B.V. - The Linux Experts", http://www.bitwizard.nl/mtr/.

Authors' Addresses 🌸

Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China

Phone: +86 10-62785983 EMail: xing@cernet.edu.cn

Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China

Phone: +86 10-62785983 EMail: congxiao@cernet.edu.cn

Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 United States

EMail: dwing@cisco.com

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

Geoff Huston APNIC

EMail: gih@apnic.net

That's the whole thing, bestie 🌈💖 Go be a main character in your networking era 💅✨

📦 where this page comes from