RFC 7915
IP/ICMP Translation Algorithm
5. Translating from IPv6 to IPv4
When an IP/ICMP translator receives an IPv6 datagram addressed to a destination towards the IPv4 domain, it translates the IPv6 header of the received IPv6 packet into an IPv4 header. The original IPv6 header on the packet is removed and replaced by an IPv4 header. Since the ICMPv6 [RFC4443], TCP [RFC793], UDP [RFC768], and DCCP [RFC4340] headers contain checksums that cover the IP header, if the address mapping algorithm is not checksum neutral, the checksum MUST be evaluated before translation and the ICMP and transport-layer headers MUST be updated. The data portion of the packet is left unchanged. The IP/ICMP translator then forwards the packet based on the IPv4 destination address.
+-------------+ +-------------+ | IPv6 | | IPv4 | | Header | | Header | +-------------+ +-------------+ | Fragment | | Transport | | Header | ===> | Layer | |(if present) | | Header | +-------------+ +-------------+ | Transport | | | | Layer | ~ Data ~ | Header | | | +-------------+ +-------------+ | | ~ Data ~ | | +-------------+ Figure 5: IPv6-to-IPv4 Translation There are some differences between IPv6 and IPv4 (in the areas of fragmentation and the minimum link MTU) that affect the translation. An IPv6 link has to have an MTU of 1280 bytes or greater. The corresponding limit for IPv4 is 68 bytes. Path MTU discovery across a translator relies on ICMP Packet Too Big messages being received and processed by IPv6 hosts. The difference in the minimum MTUs of IPv4 and IPv6 is accommodated as follows: o When translating an ICMPv4 "Fragmentation Needed" packet, the indicated MTU in the resulting ICMPv6 "Packet Too Big" will never be set to a value lower than 1280. This ensures that the IPv6 nodes will never have to encounter or handle Path MTU values lower than the minimum IPv6 link MTU of 1280. See Section 4.2. o When the resulting IPv4 packet is smaller than or equal to 1260 bytes, the translator MUST send the packet with a cleared Don't Fragment bit. Otherwise, the packet MUST be sent with the Don't Fragment bit set. See Section 5.1. This approach allows Path MTU Discovery to operate end-to-end for paths whose MTU are not smaller than the minimum IPv6 MTU of 1280 (which corresponds to an MTU of 1260 in the IPv4 domain). On paths that have IPv4 links with MTU < 1260, the IPv4 router(s) connected to those links will fragment the packets in accordance with Section 2.3 of [RFC791].
Other than the special rules for handling fragments and path MTU discovery, the actual translation of the packet header consists of a simple translation as defined below. Note that ICMPv6 packets require special handling in order to translate the contents of ICMPv6 error messages and also to remove the ICMPv6 pseudo-header checksum. The translator SHOULD make sure that the packets belonging to the same flow leave the translator in the same order in which they arrived.5.1. Translating IPv6 Headers into IPv4 Headers
If there is no IPv6 Fragment Header, the IPv4 header fields are set as follows: Version: 4 Internet Header Length: 5 (no IPv4 options) Type of Service (TOS) Octet: By default, copied from the IPv6 Traffic Class (all 8 bits). According to [RFC2474], the semantics of the bits are identical in IPv4 and IPv6. However, in some IPv4 environments, these bits 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 IPv6 traffic class and always set the IPv4 TOS Octet to a specified value. In addition, if the translator is at an administrative boundary, the filtering and update considerations of [RFC2475] may be applicable. Total Length: Payload length value from the IPv6 header, plus the size of the IPv4 header. Identification: Set according to a Fragment Identification generator at the translator. Flags: The More Fragments flag is set to zero. The Don't Fragment (DF) flag is set as follows: If the size of the translated IPv4 packet is less than or equal to 1260 bytes, it is set to zero; otherwise, it is set to one. Fragment Offset: All zeros. Time to Live: Time to Live is derived from the Hop Limit value in 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 (as any router) MUST check for zero and send the ICMPv4
"TTL Exceeded" or ICMPv6 "Hop Limit Exceeded" error.
Protocol: The IPv6-Frag (44) header is handled as discussed in
Section 5.1.1. ICMPv6 (58) is changed to ICMPv4 (1), and the
payload is translated as discussed in Section 5.2. The IPv6
headers HOPOPT (0), IPv6-Route (43), and IPv6-Opts (60) are
skipped over during processing as they have no meaning in IPv4.
For the first 'next header' that does not match one of the cases
above, its Next Header value (which contains the transport
protocol number) is copied to the protocol field in the IPv4
header. This means that all transport protocols are translated.
Note: Some translated protocols will fail at the receiver for
various reasons: some are known to fail when translated (e.g.,
IPsec Authentication Header (51)), and others will fail
checksum validation if the address translation is not checksum
neutral [RFC6052] and the translator does not update the
transport protocol's checksum (because the translator doesn't
support recalculating the checksum for that transport protocol;
see Section 5.5).
Header Checksum: Computed once the IPv4 header has been created.
Source Address: Mapped to an IPv4 address based on the algorithms
presented in Section 6.
If the translator gets an illegal source address (e.g., ::1,
etc.), the translator SHOULD silently drop the packet.
Destination Address: Mapped to an IPv4 address based on the
algorithms presented in Section 6.
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, those IPv6 extension headers MUST be
ignored (i.e., there is no attempt to translate the extension
headers) and the packet translated normally. However, the Total
Length field and the Protocol field are 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.
5.1.1. IPv6 Fragment Processing
If the IPv6 packet contains a Fragment Header, the header fields are set as above with the following exceptions: Total Length: If the Next Header field of the Fragment Header is an extension header (except ESP, but including the Authentication Header (AH)), then the packet SHOULD be dropped and logged. For other cases, the Total Length MUST be set to Payload Length value from IPv6 header, minus the length of the extension headers up to the Fragmentation 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 IPv4 More Fragments (MF) flag is copied from the M flag in the IPv6 Fragment Header. The IPv4 Don't Fragment (DF) flag is cleared (set to zero), allowing this packet to be further fragmented by IPv4 routers. Fragment Offset: If the Next Header field of the Fragment Header is not an extension header (except ESP), then Fragment Offset MUST be copied from the Fragment Offset field of the IPv6 Fragment Header. If the Next Header field of the Fragment Header is an extension header (except ESP), then the packet SHOULD be dropped and logged. Protocol: For ICMPv6 (58), it is changed to ICMPv4 (1); otherwise, extension headers are skipped, and the Next Header field is copied from the last IPv6 header. If an IPv6 packet that is smaller than or equal to 1280 bytes results (after translation) in an IPv4 packet that is larger than the MTU of the next-hop interface, then the translator MUST perform IPv4 fragmentation on that packet such that it can be transferred over the constricting link.5.2. Translating ICMPv6 Headers into ICMPv4 Headers
If a non-checksum-neutral translation address is being used, ICMPv6 messages MUST have their ICMPv4 checksum field be updated as part of the translation since ICMPv6 (unlike ICMPv4) includes a pseudo-header in the checksum just like UDP and TCP. In addition, all ICMP packets MUST have the Type translated and, for ICMP error messages, the included IP header MUST also be translated.
The actions needed to translate various ICMPv6 messages are:
ICMPv6 informational messages:
Echo Request and Echo Reply (Type 128 and 129): Adjust the Type
values to 8 and 0, 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 to 3, and adjust
the ICMP checksum both to take the type/code change into
account and to exclude the ICMPv6 pseudo-header.
Translate the Code as follows:
Code 0 (No route to destination): Set the Code to 1 (Host
unreachable).
Code 1 (Communication with destination administratively
prohibited): Set the Code to 10 (Communication with
destination host administratively prohibited).
Code 2 (Beyond scope of source address): Set the Code to 1
(Host unreachable). Note that this error is very unlikely
since an IPv4-translatable source address is typically
considered to have global scope.
Code 3 (Address unreachable): Set the Code to 1 (Host
unreachable).
Code 4 (Port unreachable): Set the Code to 3 (Port
unreachable).
Other Code values: Silently drop.
Packet Too Big (Type 2): Translate to an ICMPv4 Destination
Unreachable (Type 3) with Code 4, and adjust the ICMPv4
checksum both to take the type change into account and to
exclude the ICMPv6 pseudo-header. The MTU field MUST 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, i.e., minimum((MTU value in the
Packet Too Big Message)-20, MTU_of_IPv4_nexthop,
(MTU_of_IPv6_nexthop)-20).
See also the requirements in Section 7.
Time Exceeded (Type 3): Set the Type to 11, and adjust the ICMPv4
checksum both to take the type change into account and to
exclude the ICMPv6 pseudo-header. The Code is unchanged.
Parameter Problem (Type 4): Translate the Type and Code as
follows, and adjust the ICMPv4 checksum both to take the type/
code change into account and to exclude the ICMPv6 pseudo-
header.
Translate the Code as follows:
Code 0 (Erroneous header field encountered): Set to Type 12,
Code 0, and update the pointer as defined in Figure 6. (If
the Original IPv6 Pointer Value is not listed or the
Translated IPv4 Pointer Value is listed as "n/a", silently
drop the packet.)
Code 1 (Unrecognized Next Header type encountered): Translate
this to an ICMPv4 protocol unreachable (Type 3, Code 2).
Code 2 (Unrecognized IPv6 option encountered): Silently drop.
Unknown error messages: Silently drop.
+--------------------------------+--------------------------------+ | Original IPv6 Pointer Value | Translated IPv4 Pointer Value | +--------------------------------+--------------------------------+ | 0 | Version/Traffic Class | 0 | Version/IHL, Type Of Ser | | 1 | Traffic Class/Flow Label | 1 | Type Of Service | | 2,3 | Flow Label | n/a | | | 4,5 | Payload Length | 2 | Total Length | | 6 | Next Header | 9 | Protocol | | 7 | Hop Limit | 8 | Time to Live | | 8-23| Source Address | 12 | Source Address | |24-39| Destination Address | 16 | Destination Address | +--------------------------------+--------------------------------+ Figure 6: Pointer Value for Translating from IPv6 to IPv4 ICMP Error Payload: If the received ICMPv6 packet contains an ICMPv6 Extension [RFC4884], the translation of the ICMPv6 packet will cause the ICMPv4 packet to change length. When this occurs, the ICMPv6 Extension length attribute MUST be adjusted accordingly (e.g., shorter due to the translation from IPv6 to IPv4). For extensions not defined in [RFC4884], the translator passes the extensions as opaque bit strings and any IPv6 address literals contained therein will not be translated to IPv4 address literals; this may cause problems with processing of those ICMP extensions.5.3. Translating ICMPv6 Error Messages into ICMPv4
There are some differences between the ICMPv4 and the ICMPv6 error message formats as detailed above. The ICMP error messages containing the packet in error MUST be translated just like a normal IP packet (except that the TTL/Hop Limit value of the inner IPv4/IPv6 packet are not decremented). The translation of this "packet in error" is likely to change the length of the datagram; thus, the Total Length field in the outer IPv4 header MUST be updated.
+-------------+ +-------------+ | IPv6 | | IPv4 | | Header | | Header | +-------------+ +-------------+ | ICMPv6 | | ICMPv4 | | Header | | Header | +-------------+ +-------------+ | IPv6 | ===> | IPv4 | | Header | | Header | +-------------+ +-------------+ | Partial | | Partial | | Transport- | | Transport- | | Layer | | Layer | | Header | | Header | +-------------+ +-------------+ Figure 7: IPv6-to-IPv4 ICMP Error Translation The translation of the inner IP header can be done by invoking the function that translated the outer IP headers. This process MUST stop at the first embedded header and drop the packet if it contains more embedded headers.5.4. Generation of ICMPv6 Error Messages
If the IPv6 packet is discarded, then the translator SHOULD send back an ICMPv6 error message to the original sender of the packet, unless the discarded packet is itself an ICMPv6 message. The ICMPv6 message MUST have Type 1 (Destination Unreachable) and Code 1 (Communication with destination administratively prohibited), unless otherwise specified in this document or [RFC6146]. The translator SHOULD allow an administrator to configure whether the ICMPv6 error messages are sent, rate-limited, or not sent.5.5. Transport-Layer Header Translation
If the address translation algorithm is not checksum neutral (see Section 4.1 of [RFC6052]), the recalculation and updating of the transport-layer headers that contain pseudo-headers need to be performed. Translators MUST do this for TCP, UDP, and ICMP. Other transport protocols (e.g., DCCP) are OPTIONAL to support. In order to ease debugging and troubleshooting, translators MUST forward all transport protocols as described in the "Protocol" step of Section 5.1.
5.6. Knowing When to Translate
If the IP/ICMP translator also provides a normal forwarding function, and the destination address is reachable by a more specific route without translation, the router MUST forward it without translating it. When an IP/ICMP translator receives an IPv6 datagram addressed to an IPv6 address representing a host in the IPv4 domain, the IPv6 packet MUST be translated to IPv4.6. Mapping of IP Addresses
The translator MUST support the stateless address mapping algorithm defined in [RFC6052], which is the default behavior. A workflow example is shown in Appendix A of this document. Note that [RFC7136] updates [RFC4291], which allows the use of unicast addresses without u-bit, as long as they're not derived from an IEEE MAC-layer address. Therefore, the address mapping algorithm defined in [RFC6219] also complies with the IPv6 address architecture. The stateless translator SHOULD support the explicit address mapping algorithm defined in [RFC7757]. The stateless translator SHOULD support [RFC6791] for handling ICMP/ ICMPv6 packets. Implementations may support both stateless and stateful translation modes (e.g., Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) [RFC6146]). Implementations may support stateless NAT64 function, e.g., MAP-T Customer Edge (CE) or MAP-T Border Relay (BR) [RFC7599].7. Special Considerations for ICMPv6 Packet Too Big
A number of studies [ATOMIC] indicate that it not unusual for networks to drop ICMPv6 Packet Too Big error messages. Such packet drops will result in PMTUD black holes [RFC2923], which can only be overcome with Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821].8. 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 that are used to make the packets reach the translator.
There are potential issues that might arise by deriving an IPv4 address from an IPv6 address -- particularly addresses like broadcast or loopback addresses and the non-IPv4-translatable IPv6 addresses, etc. [RFC6052] addresses these issues. The IPsec Authentication Header [RFC4302] cannot be used for NAT44 or NAT64. As with the network address translation of IPv4 to IPv4, packets with tunnel mode Encapsulating Security Payload (ESP) can be translated since tunnel mode ESP does not depend on header fields prior to the ESP header. Similarly, transport mode ESP will fail with IPv6-to- IPv4 translation unless checksum-neutral addresses are used. In both cases, the IPsec ESP endpoints will normally detect the presence of the translator and encapsulate ESP in UDP packets [RFC3948].9. References
9.1. Normative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>. [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <http://www.rfc-editor.org/info/rfc1812>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, <http://www.rfc-editor.org/info/rfc3948>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>. [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, <http://www.rfc-editor.org/info/rfc4884>. [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <http://www.rfc-editor.org/info/rfc5382>. [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>. [RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. Huston, "Stateless Source Address Mapping for ICMPv6 Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012, <http://www.rfc-editor.org/info/rfc6791>.
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <http://www.rfc-editor.org/info/rfc7757>.9.2. Informative References
[ATOMIC] Gont, F., LIU, S., and T. Anderson, "Generation of IPv6 Atomic Fragments Considered Harmful", Work in Progress, draft-ietf-6man-deprecate-atomfrag-generation-06, April 2016. [Err3059] RFC Errata, Erratum ID 3059, RFC 6145. [Err3060] RFC Errata, Erratum ID 3060, RFC 6145. [Err3061] RFC Errata, Erratum ID 3061, RFC 6145. [Err4090] RFC Errata, Erratum ID 4090, RFC 6145. [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", Work in Progress, draft-ietf-6man- rfc2460bis-04, March 2016. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>. [RFC2474] 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, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000, <http://www.rfc-editor.org/info/rfc2923>.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, <http://www.rfc-editor.org/info/rfc3307>. [RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, DOI 10.17487/RFC3590, September 2003, <http://www.rfc-editor.org/info/rfc3590>. [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>. [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, DOI 10.17487/RFC3849, July 2004, <http://www.rfc-editor.org/info/rfc3849>. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>. [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>. [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, <http://www.rfc-editor.org/info/rfc5737>. [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, <http://www.rfc-editor.org/info/rfc6144>. [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, DOI 10.17487/RFC6219, May 2011, <http://www.rfc-editor.org/info/rfc6219>.
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, <http://www.rfc-editor.org/info/rfc6691>. [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>. [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, <http://www.rfc-editor.org/info/rfc7599>.
Appendix A. Stateless Translation Workflow Example
A stateless translation workflow example is depicted in the following figure. The documentation address blocks 2001:db8::/32 [RFC3849], 192.0.2.0/24, and 198.51.100.0/24 [RFC5737] are used in this example. +--------------+ +--------------+ | IPv4 network | | IPv6 network | | | +-------+ | | | +----+ |-----| XLAT |---- | +----+ | | | H4 |-----| +-------+ |--| H6 | | | +----+ | | +----+ | +--------------+ +--------------+ Figure 8: Stateless Translation Workflow A translator (XLAT) connects the IPv6 network to the IPv4 network. This XLAT uses the Network-Specific Prefix (NSP) 2001:db8:100::/40 defined in [RFC6052] to represent IPv4 addresses in the IPv6 address space (IPv4-converted addresses) and to represent IPv6 addresses (IPv4-translatable addresses) in the IPv4 address space. In this example, 192.0.2.0/24 is the IPv4 block of the corresponding IPv4-translatable addresses. Based on the address mapping rule, the IPv6 node H6 has an IPv4-translatable IPv6 address 2001:db8:1c0:2:21:: (address mapping from 192.0.2.33). The IPv4 node H4 has IPv4 address 198.51.100.2. The IPv6 routing is configured in such a way that the IPv6 packets addressed to a destination address in 2001:db8:100::/40 are routed to the IPv6 interface of the XLAT. The IPv4 routing is configured in such a way that the IPv4 packets addressed to a destination address in 192.0.2.0/24 are routed to the IPv4 interface of the XLAT.A.1. H6 Establishes Communication with H4
The steps by which H6 establishes communication with H4 are: 1. H6 performs the destination address mapping, so the IPv4-converted address 2001:db8:1c6:3364:2:: is formed from 198.51.100.2 based on the address mapping algorithm [RFC6052]. 2. H6 sends a packet to H4. The packet is sent from a source address 2001:db8:1c0:2:21:: to a destination address 2001:db8:1c6:3364:2::.
3. The packet is routed to the IPv6 interface of the XLAT (since
IPv6 routing is configured that way).
4. The XLAT receives the packet and performs the following actions:
* The XLAT translates the IPv6 header into an IPv4 header using
the IP/ICMP Translation Algorithm defined in this document.
* The XLAT includes 192.0.2.33 as the source address in the
packet and 198.51.100.2 as the destination address in the
packet. Note that 192.0.2.33 and 198.51.100.2 are extracted
directly from the source IPv6 address 2001:db8:1c0:2:21::
(IPv4-translatable address) and destination IPv6 address
2001:db8:1c6:3364:2:: (IPv4-converted address) of the received
IPv6 packet that is being translated.
5. The XLAT sends the translated packet out of its IPv4 interface,
and the packet arrives at H4.
6. H4 node responds by sending a packet with destination address
192.0.2.33 and source address 198.51.100.2.
7. The packet is routed to the IPv4 interface of the XLAT (since
IPv4 routing is configured that way). The XLAT performs the
following operations:
* The XLAT translates the IPv4 header into an IPv6 header using
the IP/ICMP Translation Algorithm defined in this document.
* The XLAT includes 2001:db8:1c0:2:21:: as the destination
address in the packet and 2001:db8:1c6:3364:2:: as the source
address in the packet. Note that 2001:db8:1c0:2:21:: and
2001:db8:1c6:3364:2:: are formed directly from the destination
IPv4 address 192.0.2.33 and the source IPv4 address
198.51.100.2 of the received IPv4 packet that is being
translated.
8. The translated packet is sent out of the IPv6 interface to H6.
The packet exchange between H6 and H4 continues until the session is
finished.
A.2. H4 Establishes Communication with H6
The steps by which H4 establishes communication with H6 are: 1. H4 performs the destination address mapping, so 192.0.2.33 is formed from the IPv4-translatable address 2001:db8:1c0:2:21:: based on the address mapping algorithm [RFC6052]. 2. H4 sends a packet to H6. The packet is sent from a source address 198.51.100.2 to a destination address 192.0.2.33. 3. The packet is routed to the IPv4 interface of the XLAT (since IPv4 routing is configured that way). 4. The XLAT receives the packet and performs the following actions: * The XLAT translates the IPv4 header into an IPv6 header using the IP/ICMP Translation Algorithm defined in this document. * The XLAT includes 2001:db8:1c6:3364:2:: as the source address in the packet and 2001:db8:1c0:2:21:: as the destination address in the packet. Note that 2001:db8:1c6:3364:2:: (IPv4-converted address) and 2001:db8:1c0:2:21:: (IPv4-translatable address) are obtained directly from the source IPv4 address 198.51.100.2 and destination IPv4 address 192.0.2.33 of the received IPv4 packet that is being translated. 5. The XLAT sends the translated packet out its IPv6 interface, and the packet arrives at H6. 6. H6 node responds by sending a packet with destination address 2001:db8:1c6:3364:2:: and source address 2001:db8:1c0:2:21::. 7. The packet is routed to the IPv6 interface of the XLAT (since IPv6 routing is configured that way). The XLAT performs the following operations: * The XLAT translates the IPv6 header into an IPv4 header using the IP/ICMP Translation Algorithm defined in this document. * The XLAT includes 198.51.100.2 as the destination address in the packet and 192.0.2.33 as the source address in the packet. Note that 198.51.100.2 and 192.0.2.33 are formed directly from the destination IPv6 address 2001:db8:1c6:3364:2:: and source IPv6 address 2001:db8:1c0:2:21:: of the received IPv6 packet that is being translated.
8. The translated packet is sent out the IPv4 interface to H4. The packet exchange between H4 and H6 continues until the session is finished.Acknowledgements
Gandhar Gokhale, Wesley Eddy, and Fernando Gont submitted and handled the errata reports on [RFC6145]. Fernando Gont, Will (Shucheng) Liu, and Tore Anderson provided the security analysis and the suggestions for updates concerning atomic fragments. In addition, Tore Anderson and Alberto Leiva provided the proposal of the Explicit Address Mapping (EAM) algorithm.Authors' Addresses
Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China Phone: +86 10-62785983 Email: congxiao@cernet.edu.cn Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China Phone: +86 10-62785983 Email: xing@cernet.edu.cn Fred Baker Cisco Systems Santa Barbara, California 93117 United States Phone: +1-408-526-4257 Email: fred@cisco.com
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 Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fgont@si6networks.com URI: http://www.si6networks.com