RFC 7757

Explicit Address Mappings for Stateless IP/ICMP Translation

📅 published February 2016, from ietf

🎀 RFC 7757: Explicit Address Mappings for Stateless IP/ICMP Translation 🦋

okay bestie, settle in because this one is lowkey a masterpiece 💅✨ It's an IETF Standards Track document (so it's the real deal, not just an idea doc 👑), published February 2016 by T. Anderson (Redpill Linpro) and A. Leiva Popper (NIC Mexico). It updates RFC 6145 🌸, which is the SIIT spec, and its ISSN is 2070-1721 🍓.

This is part 1 of 4, so more is coming, no sign-off yet! 🫶

1. Introduction ✨

Abstract

So the big idea is this: it extends SIIT (the Stateless IP/ICMP Translation Algorithm) with a brand-new Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145 💖. The whole point is that stateless IP/ICMP translation now works between arbitrary IPv6 endpoints that aren't IPv4-translatable and IPv4 🧚.

Status of This Memo

It's an Internet Standards Track document 🎀. It came out of the IETF, it has consensus from the IETF community, it got public review, and the IESG approved it for publication 👑. If you want the full story on Internet Standards, check out Section 2 of RFC 5741 💜. Info about status, errata, and feedback lives at http://www.rfc-editor.org/info/rfc7757.

Copyright (c) 2016 IETF Trust and the document authors, all rights reserved 🌈. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date, so read those carefully because they're about your rights 🙈. Any code pulled out of this document has to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and it comes with no warranty as described in that license 💅.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
3.  Explicit Address Mapping Algorithm  . . . . . . . . . . . . .   5
  3.1.  Explicit Address Mapping Table  . . . . . . . . . . . . .   5
  3.2.  Explicit Address Mapping Specification  . . . . . . . . .   6
  3.3.  IP Address Translation Procedure  . . . . . . . . . . . .   6
    3.3.1.  Address Translation Steps: IPv4 to IPv6 . . . . . . .   7
    3.3.2.  Address Translation Steps: IPv6 to IPv4 . . . . . . .   7
4.  Hairpinning of IPv6 Traffic . . . . . . . . . . . . . . . . .   8
  4.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   8
  4.2.  Recommendation  . . . . . . . . . . . . . . . . . . . . .   9
    4.2.1.  Simple Hairpinning Support  . . . . . . . . . . . . .   9
    4.2.2.  Intrinsic Hairpinning Support . . . . . . . . . . . .   9
5.  Overlapping Explicit Address Mappings . . . . . . . . . . . .  10
6.  Lack of Checksum Neutrality . . . . . . . . . . . . . . . . .  11
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
Appendix A.  Use Cases  . . . . . . . . . . . . . . . . . . . . .  14
  A.1.  464XLAT . . . . . . . . . . . . . . . . . . . . . . . . .  14
  A.2.  IVI . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
  A.3.  SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . .  15
Appendix B.  Example IP Address Translations  . . . . . . . . . .  15
  B.1.  Hairpinning Examples  . . . . . . . . . . . . . . . . . .  16
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1. Introduction 💫

SIIT, from [RFC6145], says that when you translate IPv4 addresses to IPv6 and back, all addresses MUST be translated using the algorithm in [RFC6052]. This doc gives you an alternative to that: IP addresses get translated according to a table of Explicit Address Mappings that's configured on the stateless translator 🦋. The best part? It removes the old rule that IPv6 nodes talking to IPv4 nodes through SIIT had to be configured with IPv4-translatable IPv6 addresses 🥹.

Translation using the Explicit Address Mapping Table does not replace [RFC6052] 🙅‍♀️. For most use cases, both algorithms are expected to work together 🤝. EAM only kicks in when a mapping matching the address exists. If there's no matching mapping, [RFC6052] takes over 💜. So when translating one packet, an SIIT implementation might translate one of the two IP address fields with an EAM, while the other field goes through [RFC6052] 🌸.

1.1. Terminology 📚

This doc uses these terms, and they're giving clarity ✨:

  • EAM: An Explicit Address Mapping, as specified in Section 3.2.
  • EAMT: The Explicit Address Mapping Table, as specified in Section 3.1.
  • Inner (header or address): Refers to an IP header sitting inside the payload of an ICMP error packet, or to an IP address within that header. Compare with "Outer".
  • Outer (header or address): Refers to the first IP header in a packet, or to an IP address within that header. In other words, a header or address that is NOT "Inner". If a reference is made to an IP header or address without the "Inner" or "Outer" qualifier, it SHOULD be considered as "Outer".
  • SIIT: The Stateless IP/ICMP Translation Algorithm, as specified in [RFC6145].
  • XLAT: Short for "translation" 💅.
  • IPv4-Converted IPv6 Addresses: As defined in Section 1.3 of [RFC6052].
  • IPv4-Translatable IPv6 Addresses: As defined in Section 1.3 of [RFC6052].

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] 🎀. Yes, these ones are the official BCP 14 words, so they're serious 🫡.

Up next in part 2: the problem statement, which is honestly a whole saga 🥲💜

3.1. Explicit Address Mapping Table

okay so the EAMT is basically a conceptual table 💅 where each row is one EAM 🦋. Every EAM describes a mapping between IPv4 and IPv6 prefixes/addresses ✨. An operator is the one who fills the table in, so the two address families actually have a map to follow 🗺️

The EAMT has these columns:

  • IPv4 Prefix
  • IPv6 Prefix

SIIT implementations MAY include other columns to support proprietary extensions to the EAM algorithm 🎀

Throughout this document, the figures that show the EAMT have an Index column with a pound sign (#) as the header. This column isn't a required part of the spec 🙈 it's just there so you can follow along easily 💖

3.2. Explicit Address Mapping Specification

an EAM is an IPv4 prefix paired with an IPv6 prefix 🌸 The prefix length MAY be left out, and if it is, the implementation MUST assume it's 32 for IPv4 and 128 for IPv6. Figure 1 shows an EAMT with examples of valid EAMs ✨

           +---+----------------+----------------------+
           | # |  IPv4 Prefix   |     IPv6 Prefix      |
           +---+----------------+----------------------+
           | 1 | 192.0.2.1      | 2001:db8:aaaa::      |
           | 2 | 192.0.2.2/32   | 2001:db8:bbbb::b/128 |
           | 3 | 192.0.2.16/28  | 2001:db8:cccc::/124  |
           | 4 | 192.0.2.128/26 | 2001:db8:dddd::/64   |
           | 5 | 192.0.2.192/29 | 2001:db8:eeee:8::/62 |
           | 6 | 192.0.2.224/31 | 64:ff9b::/127        |
           +---+----------------+----------------------+

                      Figure 1: Example EAMT

the rule here is that an EAM's IPv4 prefix value MUST have an identical or smaller number of suffix bits than its corresponding IPv6 prefix value 👑

Unless Section 4 says otherwise, an SIIT implementation MUST individually translate each IP address it runs into in the packet's IP headers (this includes any IP headers inside ICMP errors) according to Section 3.3 🫶

3.3. IP Address Translation Procedure

this section walks through, step by step, how an SIIT implementation translates addresses between IPv4 and IPv6 🦋 Only the outcome of the algorithm should be considered normative. That means an SIIT implementation may do the exact procedure differently than what's written here, but the outcome of the algorithm MUST be the same ✨

For concrete examples of address translations, check out Appendix B 🍓

3.3.1. Address Translation Steps: IPv4 to IPv6

  1. The IPv4 prefix column of the EAMT is searched for the EAM entry that shares the longest common prefix with the IPv4 address being translated. The IPv4 prefix and IPv6 prefix values of the EAM entry that's found are from now on referred to as EAM4 and EAM6, respectively.
  2. If no matching EAM entry is found, the EAM algorithm is aborted. The SIIT implementation MUST proceed to translate the address in accordance with [RFC6145] (and its updates) 💀
  3. The prefix bits of EAM4 are removed from the IPv4 address being translated. The remaining suffix bits from that IPv4 address are stored in a temporary buffer 🧚
  4. The prefix bits of EAM6 are prepended to the temporary buffer.
  5. If the temporary buffer doesn't contain a 128-bit value at this point, it gets padded with trailing zeros so it reaches a length of 128 bits.
  6. The contents of the temporary buffer are the translated IPv6 address 🎉

3.3.2. Address Translation Steps: IPv6 to IPv4

  1. The IPv6 prefix column of the EAMT is searched for the EAM entry that shares the longest common prefix with the IPv6 address being translated. The IPv4 prefix and IPv6 prefix values of the EAM entry that's found are from now on referred to as EAM4 and EAM6, respectively.
  2. If no matching EAM entry is found, the EAM algorithm is aborted. The SIIT implementation MUST proceed to translate the address in accordance with [RFC6145] (and its updates) 💀
  3. The prefix bits of EAM6 are removed from the IPv6 address being translated. The remaining suffix bits from that IPv6 address are stored in a temporary buffer 🧚
  4. The prefix bits of EAM4 are prepended to the temporary buffer.
  5. If the temporary buffer doesn't contain a 32-bit value at this point, any trailing bits get discarded so the buffer is reduced to a length of 32 bits.
  6. The contents of the temporary buffer are the translated IPv4 address 🎉

4. Hairpinning of IPv6 Traffic ✨

4.1. Problem Statement

okay this one is so iconic 😭 Two IPv6 nodes that are both covered by EAMs might, in certain circumstances, try to talk to each other through a stateless translator instead of just using native IPv6 💅 This happens when one node starts traffic toward the IPv4-converted IPv6 address whose embedded IPv4 address matches an EAM that covers the other node. Special consideration is required to make this communication pattern work in both directions 🔁 Here's an example:

Say a stateless translator is set up with a translation prefix of 64:ff9b::/96 (per [RFC6052]) and the EAMT in Figure 1 🌈 The IPv6 node 2001:db8:aaaa:: sends an IPv6 packet toward 64:ff9b::192.0.2.2. That packet reaches the translator and gets translated into an IPv4 packet with source address 192.0.2.1 and destination address 192.0.2.2. This destination address is in the EAMT, so the packet loops back into the translation function and gets translated back to an IPv6 packet with source address 2001:db8:aaaa:: and destination address 2001:db8:bbbb::b.

the packet does reach its destination just fine 🥰 but things get messy when 2001:db8:bbbb::b responds 💀 The response packet has a source address of 2001:db8:bbbb::b and a destination address of 2001:db8:aaaa::, and it's routed directly to its destination without any translation at all. Since that response's source address (2001:db8:bbbb::b) doesn't equal the destination address of the original outgoing packet (64:ff9b::192.0.2.2), the packet will most likely get discarded by 2001:db8:aaaa::, and bidirectional communication will most likely fail 😩

The scenario above could be made to work if the stateless translator hairpins the traffic in both directions 🔄 Section 4.2 explains how that's done, and Appendix B.1 walks through the resulting address translations step by step 📝

4.2. Recommendation

An SIIT implementation SHOULD include a feature that makes sure hairpinned IPv6 traffic is supported. The feature SHOULD be enabled by default 💖 The next two subsections describe two alternate ways to build this feature. An implementation MAY support both approaches 🫶

4.2.1. Simple Hairpinning Support

when simple hairpinning is enabled, the translator follows these rules when translating from IPv4 to IPv6 🎀

  1. If the packet is not an ICMPv4 error: the EAM algorithm MUST NOT be used to translate the source address in the IPv4 header.
  2. If the packet is an ICMPv4 error: the EAM algorithm MUST NOT be used when translating the destination address in the inner IPv4 header.
  3. If the packet is an ICMPv4 error whose outer IPv4 source address equals its inner IPv4 destination address: the EAM algorithm MUST NOT be used to translate the source address in the outer IPv4 header.

Rules #2 and #3 are cumulative 🧠

The addresses in question MUST instead be translated according to [RFC6145], as if they didn't match any EAM 💅

4.2.2. Intrinsic Hairpinning Support

when intrinsic hairpinning is enabled, the translator follows these rules after it has translated an IPv6 packet to IPv4 ✨

If all the conditions in either of the two sets below are true, the packet is to be hairpinned. The implementation MUST immediately (i.e., before forwarding it to the IPv4 network) translate the packet back to IPv6. During that second translation pass, the behavior specified in Section 4.2.1 MUST be applied, and the Hop Limit field SHOULD NOT be decremented 🔥

Condition set A:

  • A1. The packet is not an ICMPv4 error.
  • A2. The destination address was translated using the algorithm in [RFC6052].
  • A3. The destination address is found in the EAMT.

Condition set B:

  • B1. The packet is an ICMPv4 error.
  • B2. The inner source address was translated using the algorithm in [RFC6052].
  • B3. The inner source address is found in the EAMT.

5. Overlapping Explicit Address Mappings 🌸

The algorithm in Section 3 relies on looking up the EAMT to find the EAM entry that shares the longest common prefix with the address being translated 🔍 Operators should note that configuring EAMs with overlapping or identical IPv4 or IPv6 prefixes in the EAMT may create configurations where the IPv4-to-IPv6 and IPv6-to-IPv4 address translations aren't symmetric. In some cases, this may make bidirectional communication impossible 😬

EAM #1 in the example EAMT (Figure 2) could be thought of as implementing IVI (Appendix A.2), while EAM #2 adds a single exception in the style of SIIT-DC (Appendix A.3) 🧚 The IPv4 prefixes of the two EAMs overlap, but the IPv6 prefixes don't. So the IPv6 address 2001:db8:ffc6:3364:4000:: gets translated (according to EAM #1) to the IPv4 address 198.51.100.64. When that IPv4 address is translated back to IPv6, it gets translated (according to EAM #2) to the IPv6 address 2001:db8::abcd. Because the IPv4-to-IPv6 translation here doesn't mirror the IPv6-to-IPv4 translation, bidirectional communication involving 2001:db8:ffc6:3364:4000:: might fail 💔 To help avoid situations like this, implementations MAY warn the operator when a new EAM that overlaps with an existing one is inserted into the EAMT 🚨

           +---+------------------+--------------------+
           | # |   IPv4 Prefix    |    IPv6 Prefix     |
           +---+------------------+--------------------+
           | 1 | 0.0.0.0/0        | 2001:db8:ff00::/40 |
           | 2 | 198.51.100.64/32 | 2001:db8::abcd/128 |
           +---+------------------+--------------------+

        Figure 2: EAMT Containing Overlapping IPv4 Prefixes

In Figure 3, the IPv6 prefixes of the two EAMs are identical 👯 The behavior of the stateless translator when it translates an IPv6 packet containing the address 2001:db8::1 to IPv4 is unspecified in this case 🤷 To keep this situation from happening, implementations MAY refuse to insert a new EAM into the EAMT if its IPv4 or IPv6 prefix value is identical to that of an EAM that already exists 🛡️

             +---+-----------------+-----------------+
             | # |   IPv4 Prefix   |   IPv6 Prefix   |
             +---+-----------------+-----------------+
             | 1 | 198.51.100.8/32 | 2001:db8::1/128 |
             | 2 | 198.51.100.9/32 | 2001:db8::1/128 |
             +---+-----------------+-----------------+

         Figure 3: EAMT Containing Identical IPv6 Prefixes

6. Lack of Checksum Neutrality ✨

okay so when one or both of the address fields in an IP/ICMP packet get translated with the EAM algorithm, the translation can't be counted on to be checksum neutral 💀. And that's true even if you're using the well-known prefix 64:ff9b::/96. The full tea on this is in Section 4.1 of [RFC6052] 🫶.

7. Security Considerations 🔒

bestie, the EAM algorithm doesn't add any new security issues 🙅‍♀️. Everything that's already a concern is covered in Section 7 of [RFC6145], so go read that for the full picture 🥹.

8. References 📚

8.1. Normative References

8.2. Informative References

Appendix A. Use Cases 🌸

okay these are the real-world use cases that, at the time of writing, use SIIT with the EAM algorithm 🦋.

A.1. 464XLAT

When the customer-side translator (CLAT) component in the 464XLAT [RFC6877] architecture doesn't have a dedicated IPv6 prefix assigned, it may instead use "one interface IPv6 address that is claimed by the CLAT." That IPv6 address might not be IPv4-translatable. If that's the case, the CLAT basically implements the EAM algorithm using an EAMT like this (assuming the CLAT's IPv4 address is picked from the IPv4 Service Continuity Prefix [RFC7335]) 🧚:

        +---+--------------+-------------------------------+
        | # | IPv4 Prefix  |          IPv6 Prefix          |
        +---+--------------+-------------------------------+
        | 1 | 192.0.0.1/32 | CLAT_claimed_IPv6_address/128 |
        +---+--------------+-------------------------------+

              Figure 4: Example EAMT for a 464XLAT CLAT

In this use case, the EAM algorithm translates IPv6 destination addresses to IPv4, and the other way around, IPv4 source addresses to IPv6 ✨. Other addresses get translated using [RFC6052].

A.2. IVI

IVI [RFC6219] describes a stateless translation model that embeds IPv4 addresses in a 40-bit translation prefix, where bits 33-40 are required to be 1. The embedded IPv4 address lives in bits 41-72 of the IPv6 address. Bits 73-128 are required to be 0 🌈.

The location of the eight least significant IPv4 address bits is what makes the IVI address mapping differ from [RFC6052] 👀.

              +---+-------------+--------------------+
              | # | IPv4 Prefix |    IPv6 Prefix     |
              +---+-------------+--------------------+
              | 1 | 0.0.0.0/0   | 2001:db8:ff00::/40 |
              +---+-------------+--------------------+

                   Figure 5: Example EAMT for IVI

In this use case, every address gets translated according to the EAM algorithm. Basically, [RFC6052] mapping isn't used at all 💅.

A.3. SIIT-DC

SIIT-DC [RFC7755] describes using SIIT to get connectivity from the IPv4 Internet to services hosted in an IPv6-only data center 🖥️. To avoid the constraints around IPv4-translatable IPv6 addresses that were discussed in Section 2, the stateless IPv4/IPv6 translators get provisioned with an EAMT. It has one entry per IPv6-only service that should be available from the IPv4 Internet. For example (assuming 2001:db8:aaaa::1 and 2001:db8:bbbb::1 are assigned to load balancers or servers that provide the IPv6-only services in question) 🍓:

            +---+----------------+----------------------+
            | # |  IPv4 Prefix   |     IPv6 Prefix      |
            +---+----------------+----------------------+
            | 1 | 203.0.113.1/32 | 2001:db8:aaaa::1/128 |
            | 2 | 203.0.113.2/32 | 2001:db8:bbbb::1/128 |
            +---+----------------+----------------------+

                 Figure 6: Example EAMT for SIIT-DC

In this use case, the EAM algorithm translates IPv4 destination addresses to IPv6, and the reverse, IPv6 source addresses to IPv4 🔁. Other addresses get translated using [RFC6052].

Appendix B. Example IP Address Translations 🎀

Figure 7 shows how a set of example IP addresses get translated using the example EAMT in Figure 1 🔍. Implementors can use these examples to build test cases and check that things are working correctly 🧪. Heads up: the address translations are bidirectional, so one row in the table describes two translations, IPv4 to IPv6 and IPv6 to IPv4 💜.

The translation prefix is also assumed to be configured as 64:ff9b::/96 (per [RFC6052]) 🌸.

  +--------------+------------------------+-----------------------+
  | IPv4 Address |      IPv6 Address      |        Comment        |
  +--------------+------------------------+-----------------------+
  | 192.0.2.1    | 2001:db8:aaaa::        | According to EAM #1   |
  | 192.0.2.2    | 2001:db8:bbbb::b       | According to EAM #2   |
  | 192.0.2.16   | 2001:db8:cccc::        | According to EAM #3   |
  | 192.0.2.24   | 2001:db8:cccc::8       | According to EAM #3   |
  | 192.0.2.31   | 2001:db8:cccc::f       | According to EAM #3   |
  | 192.0.2.128  | 2001:db8:dddd::        | According to EAM #4   |
  | 192.0.2.152  | 2001:db8:dddd:0:6000:: | According to EAM #4   |
  | 192.0.2.183  | 2001:db8:dddd:0:dc00:: | According to EAM #4   |
  | 192.0.2.191  | 2001:db8:dddd:0:fc00:: | According to EAM #4   |
  | 192.0.2.195  | 2001:db8:eeee:9:8000:: | According to EAM #5   |
  | 192.0.2.225  | 64:ff9b::1             | According to EAM #6   |
  | 192.0.2.248  | 64:ff9b::c000:2f8      | According to RFC 6052 |
  +--------------+------------------------+-----------------------+

               Figure 7: Example IP Address Translations

B.1. Hairpinning Examples 🎀

okay so this is the part where we watch hairpinned IPv6 packets actually get translated. the two IPv6 nodes are 2001:db8:aaaa:: and 2001:db8:bbbb::b, and the translation follows Section 4 🦋. same as Appendix B, the EAMT in Figure 1 is in play, and the translation prefix is 64:ff9b::/96 (per [RFC6052]). on top of that, the [RFC6791] pool is assumed to hold just one address, 198.51.100.1. tiny pool, big drama 💅

     +--------------+--------------------+---------------------+
     |  XLAT Stage  |   Source Address   | Destination Address |
     +--------------+--------------------+---------------------+
     | Initial      | 2001:db8:aaaa::    | 64:ff9b::192.0.2.2  |
     +--------------+--------------------+---------------------+
     | Intermediate | 192.0.2.1          | 192.0.2.2           |
     +--------------+--------------------+---------------------+
     | Final        | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b    |
     +--------------+--------------------+---------------------+

            Figure 8: Hairpinning of a Normal IPv6 Packet

Figure 8 is the main character moment 🌸 It shows how a normal packet (not an ICMP error) sent from 2001:db8:aaaa:: toward 64:ff9b::192.0.2.2 gets hairpinned. the bit to watch is rule #1 in Section 4.2.1, which turns off the EAM algorithm when the intermediate IPv4 source address is translated back to IPv6. that's the plot twist ✨

+--------------+-------+-----------------------+--------------------+
|  XLAT Stage  | Loc.  |    Source Address     | Destination Addr.  |
+--------------+-------+-----------------------+--------------------+
| Initial      | Outer | 2001:db8::1234        | 64:ff9b::192.0.2.1 |
|              | Inner | 64:ff9b::192.0.2.1    | 2001:db8:bbbb::b   |
+--------------+-------+-----------------------+--------------------+
| Intermediate | Outer | 198.51.100.1          | 192.0.2.1          |
|              | Inner | 192.0.2.1             | 192.0.2.2          |
+--------------+-------+-----------------------+--------------------+
| Final        | Outer | 64:ff9b::198.51.100.1 | 2001:db8:aaaa::    |
|              | Inner | 2001:db8:aaaa::       | 64:ff9b::192.0.2.2 |
+--------------+-------+-----------------------+--------------------+

      Figure 9: Hairpinning of a Router-Originated ICMPv6 Error

Figure 9 is the ICMPv6 error plot 👀 an arbitrary IPv6 router (2001:db8::1234) sends the error back in response to the packet from Figure 8. the energy here is rule #2 in Section 4.2.1, which disables the EAM algorithm when the intermediate inner IPv4 destination address gets translated to IPv6. no notes, just vibes 🧚

 +--------------+-------+--------------------+--------------------+
 |  XLAT Stage  | Loc.  |   Source Address   | Destination Addr.  |
 +--------------+-------+--------------------+--------------------+
 | Initial      | Outer | 2001:db8:bbbb::b   | 64:ff9b::192.0.2.1 |
 |              | Inner | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b   |
 +--------------+-------+--------------------+--------------------+
 | Intermediate | Outer | 192.0.2.2          | 192.0.2.1          |
 |              | Inner | 192.0.2.1          | 192.0.2.2          |
 +--------------+-------+--------------------+--------------------+
 | Final        | Outer | 64:ff9b::192.0.2.2 | 2001:db8:aaaa::    |
 |              | Inner | 2001:db8:aaaa::    | 64:ff9b::192.0.2.2 |
 +--------------+-------+--------------------+--------------------+

      Figure 10: Hairpinning of a Host-Originated ICMPv6 Error

Figure 10 is the version where the ICMPv6 error comes from the original destination host itself, responding to the packet from Figure 8 🫶 this one is a double-rule moment. rules #2 and #3 in Section 4.2.1 both get applied to turn off the EAM algorithm, once for the intermediate inner IPv4 destination address and once for the intermediate outer IPv4 source address. two rules, one slay 🔥

     +--------------+--------------------+---------------------+
     |  XLAT Stage  |   Source Address   | Destination Address |
     +--------------+--------------------+---------------------+
     | Initial      | 2001:db8:bbbb::b   | 64:ff9b::192.0.2.1  |
     +--------------+--------------------+---------------------+
     | Intermediate | 192.0.2.2          | 192.0.2.1           |
     +--------------+--------------------+---------------------+
     | Final        | 64:ff9b::192.0.2.2 | 2001:db8:aaaa::     |
     +--------------+--------------------+---------------------+

          Figure 11: Hairpinning of Normal Response Packet

Figure 11 is the glow-up ending 🌈 the response from 2001:db8:bbbb::b to the packet in Figure 8 gets hairpinned in the exact same way as the initial packet. rule #1 in Section 4.2.1 shows up again to turn off the EAM algorithm when the intermediate IPv4 source address is translated to IPv6. the point of the example is that the addresses in the original packet from 2001:db8:aaaa:: line up perfectly with the ones in the translated response from 2001:db8:bbbb::b, which is what makes two-way communication work 💜

Acknowledgements ✨

this doc was basically born from comments Dave Thaler made in the V6OPS session at IETF 91, plus email chats between Fred Baker and the authors 🌸

big thanks to the people who gave valuable reviews, suggestions, and other feedback: Fred Baker, Mohamed Boucadair, Cameron Byrne, Brian E. Carpenter, Brian Haberman, Ray Hunter, Alvaro Retana, Michael Richardson, Dan Romascanu, Hemant Singh, and Andrew Yourtchenko 🫶

Authors' Addresses 🦋

Tore Anderson 💖

Redpill Linpro
Vitaminveien 1A
0485 Oslo
Norway

Phone: +47 959 31 212
Email: tore@redpill-linpro.com
URI:   http://www.redpill-linpro.com

Alberto Leiva Popper 🍓

NIC Mexico
Av. Eugenio Garza Sada 427 L4-6
Monterrey, Nuevo Leon  64840
Mexico

Email: ydahhrk@gmail.com
URI:   http://www.nicmexico.mx/
📦 where this page comes from