RFC 2765

Stateless IP/ICMP Translation Algorithm (SIIT)

📅 published February 2000, from ietf

RFC 2765: Stateless IP/ICMP Translation Algorithm (SIIT) 💖

Part 1 of 6 🧚

okay bestie, this is RFC 2765 and it's a Standards Track doc from the Network Working Group 🎀 It was written by E. Nordmark at Sun Microsystems and dated February 2000 🌸 The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Status of this Memo

this one is an Internet standards track protocol spec for the Internet community 🗣️ it's asking for discussion and suggestions for improvements 💅 for the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📖 and distribution of this memo is unlimited 🦋

Copyright Notice

Abstract

okay so this doc specifies a transition mechanism algorithm that comes in addition to the mechanisms already specified in [TRANS-MECH] 🦋 The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network, and it does this without requiring any per-connection state in those "boxes" 🫶 This new algorithm can be part of a solution that lets IPv6 hosts, which don't have a permanently assigned IPv4 address, talk to IPv4-only hosts 💜 The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts 🙈

Acknowledgements

this doc is a product of the NGTRANS working group 🎀 some of the text was pulled from an old Internet Draft called "IPAE: The SIPP Interoperability and Transition Mechanism," which was written by R. Gilligan, E. Nordmark, and B. Hinden 🌸 George Tsirtsis made the figures for Section 1 🧚 and Keith Moore gave the document a careful review 💖

   1.  Introduction and Motivation..............................    2
      1.1.  Applicability and Limitations.......................    5
      1.2.  Assumptions.........................................    7
      1.3.  Impact Outside the Network Layer....................    7
   2.  Terminology..............................................    8
      2.1.  Addresses...........................................    9
      2.2.  Requirements........................................    9
   3.  Translating from IPv4 to IPv6............................    9
      3.1.  Translating IPv4 Headers into IPv6 Headers..........   11
      3.2.  Translating UDP over IPv4...........................   13
      3.3.  Translating ICMPv4 Headers into ICMPv6 Headers......   13
      3.4.  Translating ICMPv4 Error Messages into ICMPv6.......   16
      3.5.  Knowing when to Translate...........................   16
   4.  Translating from IPv6 to IPv4............................   17
      4.1.  Translating IPv6 Headers into IPv4 Headers..........   18
      4.2.  Translating ICMPv6 Headers into ICMPv4 Headers......   20
      4.3.  Translating ICMPv6 Error Messages into ICMPv4.......   22
      4.4.  Knowing when to Translate...........................   22
   5.  Implications for IPv6-Only Nodes.........................   22
   6.  Security Considerations..................................   23
   References...................................................   24
   Author's Address.............................................   25
   Full Copyright Statement.....................................   26

1. Introduction and Motivation ✨

the transition mechanisms in [TRANS-MECH] cover the case of dual IPv4/IPv6 hosts talking to both dual hosts and IPv4-only hosts 🦋 which is needed early in the transition to IPv6 🌈 the dual hosts get both an IPv4 address and one or more IPv6 addresses 💜 okay here's the thing: as the number of globally unique IPv4 addresses gets smaller and smaller while the Internet grows, people will want to use the huge IPv6 address space 😭 and they won't want every new Internet node to need a permanently assigned IPv4 address 💅

there are a few different scenarios where IPv6-only hosts might need to talk to IPv4-only hosts 🫶 these IPv6 hosts might be IPv4-capable, meaning they include an IPv4 implementation but don't get an IPv4 address, or they might not include an IPv4 implementation at all 🧚

A completely new network with new devices that all support IPv6. In this case it might be handy to not have to configure the routers in the new network to route IPv4, since none of the hosts there have IPv4 addresses. But these new IPv6 devices might still occasionally need to talk to some IPv4 nodes out on the Internet 🌸
An existing network where a large number of IPv6 devices are added. The IPv6 devices might have both an IPv4 and an IPv6 protocol stack, but there isn't enough global IPv4 address space to give each one a permanent IPv4 address 😭 In this case it's more likely that the routers in the network already route IPv4 and get upgraded to dual routers 💖

however, there are other potential solutions in this area 👑

If there is no IPv4 routing inside the network, meaning the cloud that contains the new devices, some possible solutions are to either use the translators specified in this document at the boundary of the cloud, or to use Application Layer Gateways (ALG) on dual nodes at the cloud's boundary. The ALG solution is less flexible, since it's application protocol specific, and it's also less robust, since an ALG box is likely to be a single point of failure for a connection using that box 🙈
Otherwise, if IPv4 routing is supported inside the cloud and the implementations support both IPv6 and IPv4, it might be enough to have a mechanism for allocating a temporary address IPv4 and use IPv4 end to end when communicating with IPv4-only nodes 🦋 However, it would seem that such a solution would require the pool of temporary IPv4 addresses to be partitioned across all the subnets in the cloud. That would either need a larger pool of IPv4 addresses, or cause cases where communication fails because there's no available IPv4 address for the node's subnet 💀

this document specifies an algorithm that is one of the components needed to make IPv6-only nodes interoperate with IPv4-only nodes ✨ The other components, which this document doesn't specify, are a mechanism for the IPv6-only node to somehow acquire a temporary IPv4 address, and a mechanism for providing routing (perhaps using tunneling) to and from the temporary IPv4 address assigned to the node 🎀

the temporary IPv4 address will be used as an IPv4-translated IPv6 address, and the packets will travel through a stateless IP/ICMP translator 💜 That translator translates the packet headers between IPv4 and IPv6, and it translates the addresses in those headers between IPv4 addresses on one side and IPv4-translated or IPv4-mapped IPv6 addresses on the other side 🌈

this spec doesn't cover how an IPv6 node can acquire a temporary IPv4 address, or how that temporary address gets registered in the DNS 🙈 The DHCP protocol, perhaps with some extensions, could probably be used to acquire temporary addresses with short leases, but that's outside the scope of this document 🧚 Also, the mechanism for routing this IPv4-translated IPv6 address in the site isn't specified here either 🫶

the figures below show how the Stateless IP/ICMP Translation algorithm (SIIT) can be used first for small networks (for example, a single subnet) and later for a site that has IPv6-only hosts in a dual IPv4/IPv6 network 💖 This use assumes a mechanism for the IPv6 nodes to acquire a temporary address from the pool of IPv4 addresses 🌸 Note that SIIT probably won't be very useful later in the transition, when most of the Internet is IPv6 and there are only small islands of IPv4 nodes 😭 That's because such use would either require the IPv6 nodes to acquire temporary IPv4 addresses from a "distant" SIIT box run by a different administration, or require the IPv6 routing to contain routes for IPv6-mapped addresses 💀

the latter is known to be a very bad idea, because of the size of the IPv4 routing table that would potentially get injected into IPv6 routing in the form of IPv4-mapped addresses 🚨

                                     ___________
                                    /           \
      [IPv6 Host]---[SIIT]---------< IPv4 network>--[IPv4 Host]
                       |            \___________/
                (pool of IPv4 addresses)

      IPv4-translatable ->          IPv4->IPv4 addresser
      IPv4-mapped

Figure 1. Using SIIT for a single IPv6-only subnet. 🍓

                     ___________              ___________
                    /           \            /           \
      [IPv6 Host]--< Dual network>--[SIIT]--< IPv4 network>--[IPv4 Host]
                    \___________/     |      \___________/
                             (pool of IPv4 addresses)

      IPv4-translatable ->                     IPv4->IPv4 addresser
      IPv4-mapped

Figure 2. Using SIIT for an IPv6-only or dual cloud (e.g. a site) which contains some IPv6-only hosts as well as IPv4 hosts. 🌈

the protocol translators are assumed to fit around some piece of topology that includes some IPv6-only nodes, and that may also include IPv4 nodes as well as dual nodes 👑 There has to be a translator on each path used by routing the "translatable" packets in and out of this cloud, so that those packets always get translated ✨ This doesn't require a translator at every physical connection between the cloud and the rest of the Internet, since the routing can be used to deliver the packets to the translator 🦋

the IPv6-only node that talks to an IPv4 node through a translator will see an IPv4-mapped address for the peer, and it will use an IPv4-translatable address as its local address for that communication 💜 When the IPv6-only node sends packets, the IPv4-mapped address tells the translator that it needs to translate the packets 🫶 When the IPv4 node sends packets, they get translated to have the IPv4-translatable address as a destination 🧚 It's not possible to use an IPv4-mapped or an IPv4-compatible address as a destination, since that would either route the packet back to the translator (for the IPv4-mapped address) or make the packet get encapsulated in IPv4 (for the IPv4-compatible address) 💀 So this specification introduces the brand new notion of an IPv4-translatable address 🌸✨

1.1. Applicability and Limitations 🌸

okay so this whole algorithm assumes the IPv6 network is somehow well connected, like, when an IPv6 node wants to talk to another IPv6 node there's an IPv6 path between them 🛣️. Tunneling schemes can provide that path, but those mechanisms and how you use them are outside this doc, bestie.

The IPv6 protocol [IPv6] was designed so the TCP and UDP pseudo-header checksums aren't affected by the translations here, which means the translator doesn't need to touch normal TCP and UDP headers 💅. The only exceptions are unfragmented IPv4 UDP packets, which need a UDP checksum computed, since UDP in IPv6 requires a pseudo-header checksum. ICMPv6 also has a pseudo-header checksum but ICMPv4 doesn't, so the translator has to modify the checksum in ICMP messages. ICMP error messages also carry an IP header in their payload, so the translator needs to rewrite those parts so the receiver can understand the included IP header 🙈. Still, all of the translator's operations, including path MTU discovery, are stateless. Each packet is handled independently and no state is kept from one packet to the next. That means redundant translator boxes need zero coordination, and a given TCP connection can send its two directions through different translator boxes 🦋.

The translating function in this document doesn't translate any IPv4 options, and it doesn't translate IPv6 routing headers, hop-by-hop extension headers, or destination options headers. It could be possible to define a translation between IPv4 and IPv6 source routing, but that translation wouldn't be semantically correct because of the slight differences between the two. Source routing through a header translator might also be limited, since all the IPv6-only routers would need an IPv4-translated IPv6 address. That's because an IPv4-only node will send a source route option containing only IPv4 addresses 🧭.

At first sight, it might look like IPsec [IPv6-SA, IPv6-ESP, IPv6-AH] can't cross the translator 😭. But the translator doesn't modify any headers above the logical IP layer (IP headers, IPv6 fragment headers, and ICMP messages), so packets encrypted with ESP in Transport mode can be carried through it. [Note that this assumes that the key management can operate between the IPv6-only node and the IPv4-only node.] The AH computation covers parts of the IPv4 header fields, such as IP addresses and the identification field, which are fields that are either immutable or predictable by the sender [IPv6-AUTH]. The SIIT algorithm is specified so those IPv4 fields can be predicted by the IPv6 sender, but the IPv6 receiver can't determine the value of the IPv4 Identification field in packets sent by the IPv4 node. So with the translation algorithm as specified here, end-to-end AH through the translator isn't possible.

For ESP Tunnel mode to work through the translator, the IPv6 node would have to be able to both parse and generate "inner" IPv4 headers, since the inner IP is encrypted together with the transport protocol. So in practice, only ESP Transport mode is relatively easy to make work through a translator 🔐.

IPv4 multicast addresses can't be mapped to IPv6 multicast addresses. For example, ::ffff:224.1.2.3 is an IPv4-mapped IPv6 address with a class D address, but it is not an IPv6 multicast address 🙅‍♀️. The IP/ICMP header translation in this memo works for multicast packets in theory, but this address mapping limitation makes it impossible to apply the techniques in this memo to multicast traffic.

1.2. Assumptions

The IPv6 nodes using the translator must have an IPv4-translated IPv6 address while they're communicating with IPv4-only nodes 🎀.

The algorithm assumes there's an IPv4 address pool used to generate IPv4-translated addresses. Routing needs to be able to route any IPv4 packets, whether they were generated "outside" or "inside" the translator, that are destined to addresses in this pool towards the translator. This implies the address pool can't be assigned to subnets. It must be separated from the IPv4 subnets used on the "inside" of the translator 🗺️.

Fragmented IPv4 UDP packets that don't contain a UDP checksum (meaning the UDP checksum field is zero) aren't of significant use over wide areas of the Internet, so they won't be translated by the translator 🚫. An informal trace [MILLER] in the backbone showed that out of 34,984,468 IP packets, there were 769 fragmented UDP packets with a zero checksum. But all of them were due to malicious or broken behavior: a port scan, and first fragments of IP packets that are not a multiple of 8 bytes 👀.

1.3. Impact Outside the Network Layer

The potential existence of stateless IP/ICMP translators is already taken care of, from a protocol perspective, in [IPv6]. However, an IPv6 node that wants to use translators needs some additional logic in its network layer 🧠.

The network layer in an IPv6-only node, when the application hands it either an IPv4 destination address or an IPv4-mapped IPv6 destination address, is likely to drop the packet and return some error message to the application 😩. To take advantage of translators, such a node should instead send an IPv6 packet where the destination address is the IPv4-mapped address and the source address is the node's temporarily assigned IPv4-translated address. If the node doesn't have a temporarily assigned IPv4-translated address, it should acquire one using mechanisms that aren't discussed in this document.

The above also applies to a dual IPv4/IPv6 implementation node that isn't configured with any IPv4 address ✨.

There are no extra changes needed in applications to operate through a translator beyond what applications already need to do to operate on a dual node 💖. Applications that have been modified to work on a dual node already have the mechanisms to tell whether they're communicating with an IPv4 or an IPv6 peer. So if applications need to change their behavior depending on the type of peer, like ftp deciding whether to fall back to using the PORT/PASV command when EPRT/EPSV fails (as specified in [FTPEXT]), they already have to do that on dual nodes, and the presence of translators doesn't add anything. For example, when using the socket API [BSDAPI], applications know the peer is IPv6 if they get an AF_INET6 address from the name service and the address is not an IPv4-mapped address (i.e., IN6_IS_ADDR_V4MAPPED returns false). If that isn't the case, meaning the address is AF_INET or an IPv4-mapped IPv6 address, the peer is IPv4 🧚.

One way of viewing the translator, which helps clarify why applications don't need to know a translator is being used, is to look at the information passed from the transport layer down to the network layer. If the transport passes down an IPv4 address (whether or not it's in the IPv4-mapped encoding), that means at some point there will be IPv4 packets generated. On a dual node, the IPv4 packets are generated in the sending node. On an IPv6-only node, conceptually the only difference is that the IPv4 packet is generated by the translator. All the information the transport layer passed to the network layer will be conveyed to the translator in some form. That form just "happens" to be in the form of an IPv6 header 💅.

2. Terminology ✨

This document uses the terminology defined in [IPv6] and [TRANS-MECH], with these clarifications 🌈:

IPv4 capable node: A node which has an IPv4 protocol stack. For the stack to be usable, the node must be assigned one or more IPv4 addresses.
IPv4 enabled node: A node which has an IPv4 protocol stack and is assigned one or more IPv4 addresses. Both IPv4-only and IPv6/IPv4 nodes are IPv4 enabled.
IPv6 capable node: A node which has an IPv6 protocol stack. For the stack to be usable, the node must be assigned one or more IPv6 addresses.
IPv6 enabled node: A node which has an IPv6 protocol stack and is assigned one or more IPv6 addresses. Both IPv6-only and IPv6/IPv4 nodes are IPv6 enabled.

2.1. Addresses 🦋

In addition to the forms of addresses defined in [ADDR-ARCH], this document also introduces a new form, the IPv4-translated address. This is needed to avoid using IPv4-compatible addresses outside their intended use with automatic tunneling. So the address forms are:

IPv4-mapped: An address of the form 0::ffff:a.b.c.d which refers to a node that is not IPv6-capable. In addition to its use in the API, this protocol uses IPv4-mapped addresses in IPv6 packets to refer to an IPv4 node.
IPv4-compatible: An address of the form 0::0:a.b.c.d which refers to an IPv6/IPv4 node that supports automatic tunneling. Such addresses are not used in this protocol.
IPv4-translated: An address of the form 0::ffff:0:a.b.c.d which refers to an IPv6-enabled node. Note that the prefix 0::ffff:0:0:0/96 is chosen to checksum to zero, to avoid any changes to the transport protocol's pseudo-header checksum 🔥.

2.2. Requirements 👑

The keywords 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 [KEYWORDS] 🫶.

3. Translating from IPv4 to IPv6 ✨

okay so bestie, when an IPv4-to-IPv6 translator gets an IPv4 datagram addressed to a destination that lies outside of the attached IPv4 island, it translates that packet's IPv4 header into an IPv6 header 💅 then it forwards the packet based on the IPv6 destination address 🦋 the original IPv4 header gets removed and replaced by an IPv6 header. except for ICMP packets, the transport layer header and data portion stay exactly as they are 🫶

        +-------------+                 +-------------+
        |    IPv4     |                 |    IPv6     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |  Transport  |                 |  Fragment   |
        |   Layer     |      ===>       |   Header    |
        |   Header    |                 |(not always) |
        +-------------+                 +-------------+
        |             |                 |  Transport  |
        ~    Data     ~                 |   Layer     |
        |             |                 |   Header    |
        +-------------+                 +-------------+
                                        |             |
                                        ~    Data     ~
                                        |             |
                                        +-------------+

                    IPv4-to-IPv6 Translation

so one big difference between IPv4 and IPv6 is that path MTU discovery is mandatory in IPv6 but optional in IPv4 🌸 that means IPv6 routers will never fragment a packet. only the sender can do fragmentation, bestie 🍓

when the IPv4 node does path MTU discovery (by setting the DF bit in the header), it can work end-to-end, i.e. across the translator 🧚 in that case, either IPv4 or IPv6 routers might send back ICMP "packet too big" messages to the sender. when those ICMP errors come from IPv6 routers, they pass through a translator, which translates the ICMP error into a form the IPv4 sender can understand 💖 and in this case an IPv6 fragment header only shows up if the IPv4 packet is already fragmented.

but when the IPv4 sender does not do path MTU discovery, the translator has to make sure the packet doesn't exceed the path MTU on the IPv6 side 😭 it does this by fragmenting the IPv4 packet so it fits in a 1280 byte IPv6 packet, since IPv6 guarantees that 1280 byte packets never need to be fragmented ✨ also, when the IPv4 sender does not perform path MTU discovery, the translator MUST always include an IPv6 fragment header to show that the sender allows fragmentation. that's needed in case the packet goes through an IPv6-to-IPv4 translator later 🎀

these rules make sure that when packets get fragmented, either by the sender or by IPv4 routers, the low-order 16 bits of the fragment identification are carried end-to-end so packets are reassembled correctly 👑 the rules also use the presence of an IPv6 fragment header to signal that the sender might not be using path MTU discovery, which means the packet should not have the DF flag set if it's later translated back to IPv4 💅

other than the special fragment and path MTU discovery rules, translating the packet header is just a simple mapping, defined below 🦋 and yes, ICMP packets need special handling to translate the content of ICMP error messages and to add the ICMP pseudo-header checksum 🙈

3.1. Translating IPv4 Headers into IPv6 Headers ✨

okay this is the part where we actually map the headers 🫶 if the DF flag is not set and the IPv4 packet would turn into an IPv6 packet bigger than 1280 bytes, the IPv4 packet MUST be fragmented before it gets translated 😭 since IPv4 packets with DF not set always get a fragment header added, they must be fragmented so their length (excluding the IPv4 header) is at most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the Fragment header) 🧮 then each resulting fragment gets translated on its own, using the logic below 💖

if the DF bit is set and the packet is not a fragment (i.e., the MF flag is not set and the Fragment Offset is zero), there's no need to add a fragment header 🌈 the IPv6 header fields get set like this:

Version: 6
Traffic Class: By default, copied from IP Type Of Service and Precedence field (all 8 bits are copied). According to [DIFFSERV] the semantics of the bits are identical in IPv4 and IPv6. However, in some IPv4 environments these fields might be used with the old semantics of "Type Of Service and Precedence". An implementation of a translator SHOULD provide the ability to ignore the IPv4 "TOS" and always set the IPv6 traffic class to zero. 🍓
Flow Label: 0 (all zero bits) 🌸
Payload Length: Total length value from IPv4 header, minus the size of the IPv4 header and IPv4 options, if present. 🦋
Next Header: Protocol field copied from IPv4 header 🧚
Hop Limit: TTL value copied from IPv4 header. Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv4 TTL (before the translation) or the IPv6 Hop Limit (after the translation). As part of decrementing the TTL or Hop Limit, the translator (as any router) needs to check for zero and send the ICMPv4 or ICMPv6 "ttl exceeded" error. 💅
Source Address: The low-order 32 bits is the IPv4 source address. The high-order 96 bits is the IPv4-mapped prefix (::ffff:0:0/96) ✨
Destination Address: The low-order 32 bits is the IPv4 destination address. The high-order 96 bits is the IPv4-translated prefix (0::ffff:0:0:0/96) 👑

if IPv4 options are present in the IPv4 packet, they're ignored, i.e., there's no attempt to translate them 🙈 however, if an unexpired source route option is present, the packet MUST instead be discarded, and an ICMPv4 "destination unreachable/source route failed" (Type 3/Code 5) error message SHOULD be returned to the sender. 😭

if there's a need to add a fragment header (the DF bit is not set, or the packet is a fragment), the header fields are set as above with these exceptions 🎀

IPv6 fields:
- Payload Length: Total length value from IPv4 header, plus 8 for the fragment header, minus the size of the IPv4 header and IPv4 options, if present. 🫶
- Next Header: Fragment Header (44). 🌈
Fragment header fields:
- Next Header: Protocol field copied from IPv4 header. 💖
- Fragment Offset: Fragment Offset copied from the IPv4 header. 🦋
- M flag: More Fragments bit copied from the IPv4 header. 🧚
- Identification: The low-order 16 bits copied from the Identification field in the IPv4 header. The high-order 16 bits set to zero. ✨

3.2. Translating UDP over IPv4 🦋

okay so if a UDP packet has a zero UDP checksum, a valid checksum has to be calculated to translate the packet 🧮 a stateless translator can't do this for fragmented packets, but [MILLER] says fragmented UDP packets with a zero checksum seem to only be used for malicious purposes 💀 so this isn't believed to be a noticeable limitation, bestie 🙈

when a translator gets the first fragment of a fragmented UDP IPv4 packet and the checksum field is zero, the translator SHOULD drop the packet and generate a system management event that specifies at least the IP addresses and port numbers in the packet 🚨 when it receives fragments other than the first, it SHOULD silently drop the packet, since there's no port information to log 🫶

and when a translator gets an unfragmented UDP IPv4 packet with a zero checksum field, the translator MUST compute the missing UDP checksum as part of translating the packet 💅 the translator SHOULD also keep a counter of how many UDP checksums it generates this way 🌸

3.3. Translating ICMPv4 Headers into ICMPv6 Headers 🎀

okay so every ICMP message that gets translated needs its checksum field updated 🧮 because ICMPv6 has a pseudo-header checksum, just like UDP and TCP, and ICMPv4 doesn't. no cap, that's a whole vibe change 💅

all ICMP packets also need their Type value translated, and for ICMP error messages the IP header inside the packet needs translating too 🫶

here's the tea on what to do with each ICMPv4 message ✨

ICMPv4 query messages:
- Echo and Echo Reply (Type 8 and Type 0): adjust the type to 128 and 129, respectively, and adjust the ICMP checksum to take the type change into account and include the ICMPv6 pseudo-header 🏓
- Information Request/Reply (Type 15 and Type 16): obsoleted in ICMPv4. Silently drop 🙈
- Timestamp and Timestamp Reply (Type 13 and Type 14): obsoleted in ICMPv6. Silently drop 🙈
- Address Mask Request/Reply (Type 17 and Type 18): obsoleted in ICMPv6. Silently drop 🙈
- ICMP Router Advertisement (Type 9): single hop message. Silently drop 👋
- ICMP Router Solicitation (Type 10): single hop message. Silently drop 👋
- Unknown ICMPv4 types: silently drop 💀
IGMP messages:
- ngl this one's a little more nuanced 🧠 While the MLD messages [MLD] are the logical IPv6 counterparts of the IPv4 IGMP messages, all the "normal" IGMP messages are single-hop messages, so the translator should silently drop them. Other IGMP messages might be used by multicast routing protocols, and since setting up router adjacencies across IPv4/IPv6 translators would be a configuration error, those packets should also be silently dropped 🚫
ICMPv4 error messages:
- Destination Unreachable (Type 3): for everything not explicitly listed below, set the Type to 1. Then translate the Code field like this:
  - Code 0, 1 (net, host unreachable): set Code to 0 (no route to destination) 🗺️
  - Code 2 (protocol unreachable): translate to an ICMPv6 Parameter Problem (Type 4, Code 1) and make the Pointer point to the IPv6 Next Header field 🎯
  - Code 3 (port unreachable): set Code to 4 (port unreachable) 🔌
  - Code 4 (fragmentation needed and DF set): translate to an ICMPv6 Packet Too Big message (Type 2) with code 0. The MTU field needs to be adjusted for the difference between the IPv4 and IPv6 header sizes. Note that if the IPv4 router did not set the MTU field (i.e. the router does not implement [PMTUv4]), then the translator must use the plateau values specified in [PMTUv4] to figure out a likely path MTU and include that path MTU in the ICMPv6 packet. (Use the greatest plateau value that is less than the returned Total Length field.) 📏
  - Code 5 (source route failed): set Code to 0 (no route to destination). Note that this error is unlikely since source routes are not translated 🤷
  - Code 6, 7: set Code to 0 (no route to destination) 🗺️
  - Code 8: set Code to 0 (no route to destination) 🗺️
  - Code 9, 10 (communication with destination host administratively prohibited): set Code to 1 (communication with destination administratively prohibited) 🚧
  - Code 11, 12: set Code to 0 (no route to destination) 🗺️
- Redirect (Type 5): single hop message. Silently drop 👋
- Source Quench (Type 4): obsoleted in ICMPv6. Silently drop 🙈
- Time Exceeded (Type 11): set the Type field to 3. The Code field stays the same ⏰
- Parameter Problem (Type 12): set the Type field to 4. The Pointer needs to be updated so it points to the corresponding field in the translated, included IP header 🧩

3.4. Translating ICMPv4 Error Messages into ICMPv6 🦋

there are some differences between the IPv4 and IPv6 ICMP error message formats, as we just covered 💅 on top of that, ICMP error messages contain the IP header of the packet that caused the error, and that inner header needs to be translated just like a normal IP header 🪞 translating this "packet in error" will probably change the length of the datagram, so the Payload Length field in the outer IPv6 header might need updating too 📦

+-------------+ +-------------+

IPv4		IPv6
Header		Header

+-------------+ +-------------+

ICMPv4		ICMPv6
Header		Header

+-------------+ +-------------+

IPv4	===>	IPv6
Header		Header

+-------------+ +-------------+

Partial		Partial
Transport		Transport
Layer		Layer
Header		Header

+-------------+ +-------------+

IPv4-to-IPv6 ICMP Error Translation

the inner IP header gets translated by recursively invoking the same function that translated the outer IP headers 🔁 it's giving inception 🌀

3.5. Knowing when to Translate 🧭

the translator is assumed to know the pool(s) of IPv4 addresses used to represent the internal IPv6-only nodes 🏠 so if the IPv4 destination field holds an address that falls within one of these configured sets of prefixes, the packet needs to be translated to IPv6 💖

4. Translating from IPv6 to IPv4 ✨

when an IPv6-to-IPv4 translator gets an IPv6 datagram addressed to an IPv4-mapped IPv6 address, it translates the IPv6 header of that packet into an IPv4 header 🦋 then it forwards the packet based on the IPv4 destination address. the original IPv6 header is removed and replaced by the IPv4 header. Except for ICMP packets, the transport layer header and data portion of the packet stay unchanged 🫶

+-------------+ +-------------+

IPv6		IPv4
Header		Header

+-------------+ +-------------+

Fragment		Transport
Header	===>	Layer
(if present)		Header

+-------------+ +-------------+

Transport
Layer	~ Data ~
Header

+-------------+ +-------------+

~ Data ~

+-------------+

IPv6-to-IPv4 Translation

okay the fragmentation and MTU stuff is where it gets spicy 🌶️ there are some differences between IPv6 and IPv4 when it comes to fragmentation and the minimum link MTU, and those affect translation. An IPv6 link has to have an MTU of 1280 bytes or greater. The matching limit for IPv4 is 68 bytes. So unless there were special measures, end-to-end path MTU discovery wouldn't work when the path includes an IPv6-to-IPv4 translator, because the IPv6 node might get ICMP "packet too big" messages from an IPv4 router reporting an MTU below 1280 💔 however, [IPv6] requires that IPv6 nodes handle such an ICMP "packet too big" message by lowering the path MTU to 1280 and including an IPv6 fragment header with each packet 🙌 this lets end-to-end path MTU discovery work across the translator as long as the path MTU is 1280 bytes or greater. When the path MTU drops below the 1280 limit, the IPv6 sender will originate 1280-byte packets, which will be fragmented by IPv4 routers along the path after being translated to IPv4 🧩

the only drawback is that PMTU can't be used for optimal UDP fragmentation (as opposed to avoiding fragmentation altogether) at the sender 😤 the presence of an IPv6 Fragment header is read as meaning it's OK to fragment the packet on the IPv4 side. So if a UDP application wants to send large packets regardless of the PMTU, the sender can only determine the path MTU on the IPv6 side of the translator. If the path MTU on the IPv4 side of the translator is smaller, the IPv6 sender won't receive any ICMP "too big" errors and can't adjust the size of the fragments it's sending 🥺

apart from the special rules for fragments and path MTU discovery, translating the packet header is just a simple mapping, defined below 🍓 Note that ICMP packets need special handling to translate the content of ICMP error messages and to add the ICMP pseudo-header checksum 🔥

4.1. Translating IPv6 Headers into IPv4 Headers ✨

okay bestie, if there's no IPv6 Fragment header, here's how the IPv4 header fields get set 💖

Version: 4 💅
Internet Header Length: 5 (no IPv4 options) 🎀
Type of Service and Precedence: By default, this gets copied from the IPv6 Traffic Class (all 8 bits) 🦋. According to [DIFFSERV], the semantics of the bits are identical in IPv4 and IPv6. BUT in some IPv4 environments these bits might still be using the old semantics of "Type Of Service and Precedence", so it's a whole thing 🙈. An implementation of a translator SHOULD provide the ability to ignore the IPv6 traffic class and always set the IPv4 "TOS" to zero.
Total Length: The payload length value from the IPv6 header, plus the size of the IPv4 header 📏
Identification: All zero 🌸
Flags: The More Fragments flag is set to zero. The Don't Fragments flag is set to one 🚫
Fragment Offset: All zero 🫶
Time to Live: The Hop Limit value gets copied from the IPv6 header. Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv6 Hop Limit (before the translation) or the IPv4 TTL (after the translation). As part of decrementing the TTL or Hop Limit, the translator (like any router) needs to check for zero and send the ICMPv4 or ICMPv6 "ttl exceeded" error 😭
Protocol: The Next Header field gets copied from the IPv6 header 🧚
Header Checksum: Computed once the IPv4 header has been created ✨
Source Address: If the IPv6 source address is an IPv4-translated address, then the low-order 32 bits of the IPv6 source address get copied to the IPv4 source address. Otherwise, the source address is set to 0.0.0.0. The whole point of 0.0.0.0 is to avoid completely dropping things like ICMPv6 error messages sent by IPv6-only routers, which makes things like traceroute show something for the IPv6-only hops 🗺️
Destination Address: IPv6 packets that get translated have an IPv4-mapped destination address. So the low-order 32 bits of the IPv6 destination address get copied to the IPv4 destination address 🎯

If any of an IPv6 hop-by-hop options header, destination options header, or routing header with the Segments Left field equal to zero are present in the IPv6 packet, they're ignored, i.e., there's no attempt to translate them. However, the Total Length field and the Protocol field would have to be adjusted to "skip" these extension headers 🦘

If a routing header with a non-zero Segments Left field is present, then the packet MUST NOT be translated. And an ICMPv6 parameter problem/ erroneous header field encountered (Type 4/Code 0) error message, with the Pointer field indicating the first byte of the Segments Left field, SHOULD be returned to the sender 🚨

If the IPv6 packet contains a Fragment header, the header fields are set as above with the following exceptions:

Total Length: The payload length value from the IPv6 header, minus 8 for the Fragment header, plus the size of the IPv4 header 🧮
Identification: Copied from the low-order 16 bits in the Identification field in the Fragment header 🪪
Flags: The More Fragments flag is copied from the M flag in the Fragment header. The Don't Fragments flag is set to zero, allowing this packet to be fragmented by IPv4 routers 🧩
Fragment Offset: Copied from the Fragment Offset field in the Fragment header 🍓
Protocol: The Next Header value gets copied from the Fragment header 💜

4.2. Translating ICMPv6 Headers into ICMPv4 Headers 🌈

All ICMP messages that get translated require the ICMP checksum field to be updated as part of the translation, since ICMPv6 (unlike ICMPv4) has a pseudo-header checksum just like UDP and TCP. It's giving extra steps 💅

Also, all ICMP packets need to have the Type value translated, and for ICMP error messages the included IP header needs translating too 👀

Here's what needs to happen for each ICMPv6 message:

ICMPv6 informational messages:
- Echo Request and Echo Reply (Type 128 and 129): Adjust the type to 0 and 8, respectively, and adjust the ICMP checksum both to take the type change into account and to exclude the ICMPv6 pseudo-header 🏓
- MLD Multicast Listener Query/Report/Done (Type 130, 131, 132): Single hop message. Silently drop 🤫
- Neighbor Discover messages (Type 133 through 137): Single hop message. Silently drop 🤫
- Unknown informational messages: Silently drop 🤫
ICMPv6 error messages:
- Destination Unreachable (Type 1): Set the Type field to 3. Translate the Code field as follows:
  - Code 0 (no route to destination): Set Code to 1 (host unreachable).
  - Code 1 (communication with destination administratively prohibited): Set Code to 10 (communication with destination host administratively prohibited).
  - Code 2 (beyond scope of source address): Set Code to 1 (host unreachable). Note that this error is very unlikely, since the IPv4-translatable source address is considered to have global scope 🌍
  - Code 3 (address unreachable): Set Code to 1 (host unreachable).
  - Code 4 (port unreachable): Set Code to 3 (port unreachable).
- Packet Too Big (Type 2): Translate to an ICMPv4 Destination Unreachable with code 4. The MTU field needs to be adjusted for the difference between the IPv4 and IPv6 header sizes, taking into account whether or not the packet in error includes a Fragment header 📐
- Time Exceeded (Type 3): Set the Type to 11. The Code field is unchanged ⏰
- Parameter Problem (Type 4): If the Code is 1, translate this to an ICMPv4 protocol unreachable (Type 3, Code 2). Otherwise, set the Type to 12 and the Code to zero. The Pointer needs to be updated to point to the corresponding field in the translated included IP header 🎯
- Unknown error messages: Silently drop 🤫

4.3. Translating ICMPv6 Error Messages into ICMPv4 🧁

There are some differences between the IPv4 and IPv6 ICMP error message formats, as detailed above. On top of that, ICMP error messages contain the IP header for the packet in error, and that header needs to be translated just like a normal IP header. This "packet in error" translation is likely to change the length of the datagram, so the Total Length field in the outer IPv4 header might need updating too 📦

        +-------------+                 +-------------+
        |    IPv6     |                 |    IPv4     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |   ICMPv6    |                 |   ICMPv4    |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |    IPv6     |      ===>       |    IPv4     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |   Partial   |                 |   Partial   |
        |  Transport  |                 |  Transport  |
        |   Layer     |                 |   Layer     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+

              IPv6-to-IPv4 ICMP Error Translation

The translation of the inner IP header can be done by recursively invoking the function that translated the outer IP headers 🔁

4.4. Knowing when to Translate 🔍

When the translator receives an IPv6 packet with an IPv4-mapped destination address, the packet will be translated to IPv4 ✨

5. Implications for IPv6-Only Nodes 🌟

An IPv6-only node that works through SIIT translators needs some modifications beyond a normal IPv6-only node 🛠️

As specified in Section 1.3, application protocols need to handle operation on a dual stack node. In addition, the protocol stack needs to be able to:

Determine when an IPv4-translatable address needs to be allocated, and when the allocation needs to be refreshed/renewed. This can presumably be done without involving the applications, by e.g. handling this under the socket API. For instance, when the connect or sendto socket calls are invoked, they could check if the destination is an IPv4-mapped address and, in that case, allocate/refresh the IPv4-translatable address 🔄
Ensure, as part of the source address selection mechanism, that when the destination address is an IPv4-mapped address, the source address MUST be an IPv4-translatable address. And an IPv4-translatable address MUST NOT be used with other forms of IPv6 destination addresses 🚦
Should the peer have AAAA/A6 address records, the application (or resolver) SHOULD never fall back to looking for A address records, even if communication fails using the available AAAA/A6 records. The reason for this restriction is to prevent traffic between two IPv6 nodes (which have AAAA/A6 records in the DNS) from accidentally going through SIIT translators twice: from IPv6 to IPv4 and then back to IPv6 again. It's considered preferable to instead signal a failure to communicate to the application 🙅‍♀️

6. Security Considerations 🔐

The use of stateless IP/ICMP translators does not introduce any new security issues beyond the security issues that are already present in the IPv4 and IPv6 protocols, and in the routing protocols which are used to make the packets reach the translator 🛡️

As the Authentication Header [IPv6-AUTH] is specified to include the IPv4 Identification field, and the translating function is not able to always preserve the Identification field, it is not possible for an IPv6 endpoint to compute AH on received packets that have been translated from IPv4 packets. Thus, AH does not work through a translator 😤

Packets with ESP can be translated, since ESP does not depend on header fields prior to the ESP header. Note that ESP transport mode is easier to handle than ESP tunnel mode. In order to use ESP tunnel mode, the IPv6 node needs to be able to generate an inner IPv4 header when transmitting packets, and remove such an IPv4 header when receiving packets 🧠

References 📚

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[IPv6] Deering, S. and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[ADDR-ARCH] Deering, S. and R. Hinden, Editors, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.

[TRANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.

[DISCOVERY] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

[IPv6-SA] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[IPv6-AUTH] Atkinson, R., "IP Authentication Header", RFC 2402, November 1998.

[IPv6-ESP] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.

[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.

[IGMP] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.

[PMTUv4] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.

[PMTUv6] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.

[DIFFSERV] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

[MLD] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.

[FTPEXT] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 and NATs.", RFC 2428, September 1998.

[MILLER] G. Miller, Email to the ngtrans mailing list on 26 March 1999.

[BSDAPI] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999.

Author's Address 💌

Erik Nordmark
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
USA

Phone: +1 650 786 5166
Fax:   +1 650 786 5896
EMail: nordmark@sun.com

Full Copyright Statement 🎀

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 🌸

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ♾️

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from

ietf: rfc2765 2000-02
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms

RFC 2765

RFC 2765: Stateless IP/ICMP Translation Algorithm (SIIT) 💖

Status of this Memo

Copyright Notice

Abstract

Acknowledgements

Table of Contents

1. Introduction and Motivation ✨

1.1. Applicability and Limitations 🌸

1.2. Assumptions

1.3. Impact Outside the Network Layer

2. Terminology ✨

2.1. Addresses 🦋

2.2. Requirements 👑

3. Translating from IPv4 to IPv6 ✨

3.1. Translating IPv4 Headers into IPv6 Headers ✨

3.2. Translating UDP over IPv4 🦋

3.3. Translating ICMPv4 Headers into ICMPv6 Headers 🎀

3.4. Translating ICMPv4 Error Messages into ICMPv6 🦋

3.5. Knowing when to Translate 🧭

4. Translating from IPv6 to IPv4 ✨

4.1. Translating IPv6 Headers into IPv4 Headers ✨

4.2. Translating ICMPv6 Headers into ICMPv4 Headers 🌈

4.3. Translating ICMPv6 Error Messages into ICMPv4 🧁

4.4. Knowing when to Translate 🔍

5. Implications for IPv6-Only Nodes 🌟

6. Security Considerations 🔐

References 📚

Author's Address 💌

Full Copyright Statement 🎀

Acknowledgement 🫶