draft-ietf-v6ops-siit-eam-00.txt   draft-ietf-v6ops-siit-eam-01.txt 
IPv6 Operations T. Anderson IPv6 Operations T. Anderson
Internet-Draft Redpill Linpro Internet-Draft Redpill Linpro
Updates: 6145 (if approved) A. Leiva Popper Updates: 6145 (if approved) A. Leiva Popper
Intended status: Standards Track NIC Mexico Intended status: Standards Track NIC Mexico
Expires: November 10, 2015 May 09, 2015 Expires: January 01, 2016 June 30, 2015
Explicit Address Mappings for Stateless IP/ICMP Translation Explicit Address Mappings for Stateless IP/ICMP Translation
draft-ietf-v6ops-siit-eam-00 draft-ietf-v6ops-siit-eam-01
Abstract Abstract
This document extends the Stateless IP/ICMP Translation Algorithm This document extends the Stateless IP/ICMP Translation Algorithm
(SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally (SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally
updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP
translation between arbitrary (non-IPv4-translatable) IPv6 endpoints translation between arbitrary (non-IPv4-translatable) IPv6 endpoints
and IPv4. and IPv4.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2015. This Internet-Draft will expire on January 01, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Explicit Address Mapping Algorithm . . . . . . . . . . . . . 6 3. Explicit Address Mapping Algorithm . . . . . . . . . . . . . 5
3.1. Explicit Address Mapping Table . . . . . . . . . . . . . 6 3.1. Explicit Address Mapping Table . . . . . . . . . . . . . 5
3.2. Explicit Address Mapping Specification . . . . . . . . . 6 3.2. Explicit Address Mapping Specification . . . . . . . . . 6
3.3. IP Address Translation Procedure . . . . . . . . . . . . 7 3.3. IP Address Translation Procedure . . . . . . . . . . . . 6
3.3.1. Address Translation Steps: IPv4 to IPv6 . . . . . . . 7 3.3.1. Address Translation Steps: IPv4 to IPv6 . . . . . . . 7
3.3.2. Address Translation Steps: IPv6 to IPv4 . . . . . . . 8 3.3.2. Address Translation Steps: IPv6 to IPv4 . . . . . . . 7
4. Hairpinning of IPv6 Traffic . . . . . . . . . . . . . . . . . 8 4. Hairpinning of IPv6 Traffic . . . . . . . . . . . . . . . . . 8
4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8
4.2. Recommendation . . . . . . . . . . . . . . . . . . . . . 9 4.2. Recommendation . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Simple Hairpinning Support . . . . . . . . . . . . . 9 4.2.1. Simple Hairpinning Support . . . . . . . . . . . . . 9
4.2.2. Intrinsic Hairpinning Support . . . . . . . . . . . . 10 4.2.2. Intrinsic Hairpinning Support . . . . . . . . . . . . 9
5. Lack of Checksum Neutrality . . . . . . . . . . . . . . . . . 10 5. Overlapping Explicit Address Mappings . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Lack of Checksum Neutrality . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
A.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 13
A.2. IVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.3. SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.2. IVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Example IP Address Translations . . . . . . . . . . 14 A.3. SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Example IP Address Translations . . . . . . . . . . 15
B.1. Hairpinning Examples . . . . . . . . . . . . . . . . . . 15 B.1. Hairpinning Examples . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145] The Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]
specifies that when translating IPv4 addresses to IPv6 and vice specifies that when translating IPv4 addresses to IPv6 and vice
versa, all addresses must be translated using the algorithm specified versa, all addresses must be translated using the algorithm specified
in [RFC6052]. This document specifies an alternative to the in [RFC6052]. This document specifies an alternative to the
[RFC6052] algorithm, where IP addresses are translated according to a [RFC6052] algorithm, where IP addresses are translated according to a
table of Explicit Address Mappings configured on the stateless table of Explicit Address Mappings configured on the stateless
translator. This removes the previous constraint that IPv6 nodes translator. This removes the previous constraint that IPv6 nodes
that communicate with IPv4 nodes through SIIT must be configured with that communicate with IPv4 nodes through SIIT must be configured with
IPv4-translatable IPv6 addresses. IPv4-translatable IPv6 addresses.
The Explicit Address Mapping Table does not replace [RFC6052]. For The Explicit Address Mapping Table does not replace [RFC6052]. For
most use cases, it is expected that both algorithms are used in most use cases, it is expected that both algorithms are used in
concert. The Explicit Address Mapping algorithm is used only when a concert. The Explicit Address Mapping algorithm is used only when a
mapping matching the address to be translated exists. If no matching mapping matching the address to be translated exists. If no matching
skipping to change at page 3, line 29 skipping to change at page 3, line 31
1.1. Terminology 1.1. Terminology
This document makes use of the following terms: This document makes use of the following terms:
EAM EAM
An Explicit Address Mapping, as specified in Section 3.2. An Explicit Address Mapping, as specified in Section 3.2.
EAMT EAMT
The Explicit Address Mapping Table, as specified in Section 3.1. The Explicit Address Mapping Table, as specified in Section 3.1.
Inner (header or address) Refers to an IP header located inside the Inner (header or address)
payload of an ICMP error packet, or to an IP address within that Refers to an IP header located inside the payload of an ICMP error
header. Compare "Outer". packet, or to an IP address within that header. Compare "Outer".
Outer (header or address) Refers to the first IP header in a packet, Outer (header or address)
or to an IP address within that header. In other words, an IP Refers to the first IP header in a packet, or to an IP address
header or address that is NOT "Inner". If a reference is made to within that header. In other words, an IP header or address that
an IP header or address without the "Inner" or "Outer" qualifier, is NOT "Inner". If a reference is made to an IP header or address
it should be considered as "Outer". without the "Inner" or "Outer" qualifier, it should be considered
as "Outer".
SIIT SIIT
The Stateless IP/ICMP Translation algorithm, as specified in The Stateless IP/ICMP Translation algorithm, as specified in
[RFC6145]. [RFC6145].
XLAT XLAT
Short for "translation". Short for "translation".
IPv4-converted IPv6 addresses IPv4-converted IPv6 addresses
As defined in Section 1.3 of [RFC6052]. As defined in Section 1.3 of [RFC6052].
skipping to change at page 4, line 22 skipping to change at page 4, line 23
mechanisms typically put constraints on what IPv6 addresses can be mechanisms typically put constraints on what IPv6 addresses can be
assigned to IPv6 nodes that want to communicate with IPv4 assigned to IPv6 nodes that want to communicate with IPv4
destinations using an algorithmic mapping". In practice, this means destinations using an algorithmic mapping". In practice, this means
that the IPv6 nodes must be configured with IPv4-translatable IPv6 that the IPv6 nodes must be configured with IPv4-translatable IPv6
addresses. For the reasons discussed below, some environments may addresses. For the reasons discussed below, some environments may
find that the use of IPv4-translatable IPv6 addresses is not desired find that the use of IPv4-translatable IPv6 addresses is not desired
or even possible. or even possible.
Limited availability: Limited availability:
The number of IPv4-translatable IPv6 addresses available to an The number of IPv4-translatable IPv6 addresses available to an
operator is equal to the number of IPv4 addresses he assigns to operator is equal to the number of IPv4 addresses that is assigned
the SIIT function. IPv4 addresses are scarce, and as a result an to the SIIT function. IPv4 addresses are scarce, and as a result
operator might not have enough IPv4-translatable IPv6 addresses to an operator might not have enough IPv4-translatable IPv6 addresses
number his entire IPv6 infrastructure. to number the entire IPv6 infrastructure.
Restricted format: Restricted format:
IPv4-translatable IPv6 addresses must conform to the format IPv4-translatable IPv6 addresses must conform to the format
specified in Section 2.2 of [RFC6052]. This format is not specified in Section 2.2 of [RFC6052]. This format is not
compatible with other common IPv6 address formats, such as the compatible with other common IPv6 address formats, such as the
EUI-64 based IPv6 address format used by IPv6 Stateless Address EUI-64 based IPv6 address format used by IPv6 Stateless Address
Autoconfiguration [RFC4862]. Autoconfiguration [RFC4862].
An operator could overcome the above two problems by building an IPv6 An operator could overcome the above two problems by building an IPv6
network using regular (non-IPv4-translatable) IPv6 addresses, and network using regular (non-IPv4-translatable) IPv6 addresses, and
skipping to change at page 5, line 20 skipping to change at page 5, line 9
result, in order to support SIIT, the IPv6 network might need to result, in order to support SIIT, the IPv6 network might need to
carry a large number of extraneous routes. These routes must be carry a large number of extraneous routes. These routes must be
separately injected into the IPv6 routing topology somehow. Any separately injected into the IPv6 routing topology somehow. Any
intermediate devices in the IPv6 network such as a firewall might intermediate devices in the IPv6 network such as a firewall might
require special configuration in order to treat the require special configuration in order to treat the
IPv4-translatable IPv6 address the same as the primary IPv6 IPv4-translatable IPv6 address the same as the primary IPv6
address, for example by requiring that any ACL entries involving address, for example by requiring that any ACL entries involving
the primary IPv6 address of a node must be duplicated. the primary IPv6 address of a node must be duplicated.
Operational complexity: Operational complexity:
The IPv4-translatable IPv6 addresses must not only be assigned to The IPv4-translatable IPv6 addresses not only have to be assigned
the IPv6 nodes participating in SIIT; all applications and to the IPv6 nodes participating in SIIT; all applications and
services on those nodes must also be configured to use them. For services on those nodes must also be configured to use them. For
example, if the IPv6 node is a load balancer, it might require a example, if the IPv6 node is a load balancer, it might require a
separate Virtual Server definition using the IPv4-translatable separate Virtual Server definition using the IPv4-translatable
IPv6 address in addition to one using the service's primary IPv6 IPv6 address in addition to one using the service's primary IPv6
address. A web server might require specific configuration to address. A web server might require specific configuration to
listen for connections on both the IPv4-translatable and the listen for connections on both the IPv4-translatable and the
primary IPv6 address. A High-Availability cluster service must be primary IPv6 address. A High-Availability cluster service must be
set up to fail over both addresses between cluster nodes, and set up to fail over both addresses between cluster nodes, and
depending on how the IPv6 network learns the location of the depending on how the IPv6 network learns the location of the
IPv4-translatable IPv6 address, the fail-over mechanism used for IPv4-translatable IPv6 address, the fail-over mechanism used for
the two addresses might be completely different. Service the two addresses might be completely different. Service
monitoring must be done for both the IPv4-translatable and the monitoring must be done for both the IPv4-translatable and the
primary IPv6 address, and any trouble-shooting procedures must be primary IPv6 address, and any trouble-shooting procedures must be
extended to involve both addresses. extended to involve both addresses. Finally, the Default Address
Selection Policy Table [RFC6724] on the IPv6 nodes might need to
be altered in order to ensure that outbound sessions towards the
IPv4 Internet are sourced from an IPv4-translatable IPv6 address.
In short, the use of IPv4-translatable IPv6 addresses in parallel In short, the use of IPv4-translatable IPv6 addresses in parallel
with regular IPv6 addresses is in many ways analogous to the use of with regular IPv6 addresses is in many ways analogous to the use of
Dual Stack [RFC4213]. While no actual IPv4 packets are used, the Dual Stack [RFC4213]. While no actual IPv4 packets are used, the
IPv4-translatable IPv6 addresses creates a secondary "stack" in the IPv4-translatable IPv6 addresses creates a secondary "stack" in the
infrastructure that must be treated and operated separately from the infrastructure that must be treated and operated separately from the
primary one. This increases the complexity of the overall primary one. This increases the complexity of the overall
infrastructure, in turn increasing operational overhead, and reducing infrastructure, in turn increasing operational overhead, and reducing
reliability. An operator who for such reasons finds the use Dual reliability. An operator who for such reasons finds the use Dual
Stack unappealing, might feel the same way about using SIIT with Stack unappealing, might feel the same way about using SIIT with
IPv4-translatable IPv6 addresses. IPv4-translatable IPv6 addresses.
3. Explicit Address Mapping Algorithm 3. Explicit Address Mapping Algorithm
This normative section defines the EAM algorithm. SIIT This normative section defines the EAM algorithm. SIIT
implementations are REQUIRED to support the specifications herein. implementations MUST support the specifications herein.
3.1. Explicit Address Mapping Table 3.1. Explicit Address Mapping Table
An SIIT implementation MUST include an Explicit Address Mapping Table An SIIT implementation MUST include an Explicit Address Mapping Table
(EAMT). By default, the EAMT SHOULD be empty. The operator MUST be (EAMT). By default, the EAMT SHOULD be empty. The operator MUST be
able to populate the EAMT using the implementation's normal able to populate the EAMT using the implementation's normal
configuration interfaces. The implementation MAY additionally configuration interfaces. The implementation MAY additionally
support other ways of populating the EAMT. support other ways of populating the EAMT.
The EAMT consists of the following columns: The EAMT consists of the following columns:
skipping to change at page 6, line 42 skipping to change at page 6, line 29
3.2. Explicit Address Mapping Specification 3.2. Explicit Address Mapping Specification
An EAM consists of an IPv4 Prefix and an IPv6 Prefix. The prefix An EAM consists of an IPv4 Prefix and an IPv6 Prefix. The prefix
length MAY be omitted, in which case the implementation MUST assume length MAY be omitted, in which case the implementation MUST assume
it to be 32 for IPv4 and 128 for IPv6. Figure 1 illustrates an EAMT it to be 32 for IPv4 and 128 for IPv6. Figure 1 illustrates an EAMT
containing examples of valid EAMs. containing examples of valid EAMs.
Example EAMT Example EAMT
+---+----------------+----------------------+ +---+----------------+----------------------+
| # | IPv4 Prefix | IPv6 Prefix | | # | IPv4 Prefix | IPv6 Prefix |
+---+----------------+----------------------+ +---+----------------+----------------------+
| 1 | 192.0.2.1 | 2001:db8:aaaa:: | | 1 | 192.0.2.1 | 2001:db8:aaaa:: |
| 2 | 192.0.2.2/32 | 2001:db8:bbbb::b/128 | | 2 | 192.0.2.2/32 | 2001:db8:bbbb::b/128 |
| 3 | 192.0.2.16/28 | 2001:db8:cccc::/124 | | 3 | 192.0.2.16/28 | 2001:db8:cccc::/124 |
| 4 | 192.0.2.128/26 | 2001:db8:dddd::/64 | | 4 | 192.0.2.128/26 | 2001:db8:dddd::/64 |
| 5 | 192.0.2.192/31 | 64:ff9b::/127 | | 5 | 192.0.2.192/31 | 64:ff9b::/127 |
+---+----------------+----------------------+ +---+----------------+----------------------+
Figure 1 Figure 1
An EAM's IPv4 Prefix value MUST have an identical or smaller number An EAM's IPv4 Prefix value MUST have an identical or smaller number
of suffix bits than its corresponding IPv6 Prefix value. of suffix bits than its corresponding IPv6 Prefix value.
Overlapping EAMs SHOULD be considered an error, and attempts to
insert them into the EAMT SHOULD be blocked. The behaviour of an
SIIT implementation when overlapping EAMs are present in the EAMT is
left undefined.
When translating a packet between IPv4 and IPv6, an SIIT When translating a packet between IPv4 and IPv6, an SIIT
implementation MUST individually translate each IP address it implementation MUST individually translate each IP address it
encounters in the packet's IP headers (including any IP headers encounters in the packet's IP headers (including any IP headers
contained within ICMP errors) according to Section 3.3. See contained within ICMP errors) according to Section 3.3. See
Section 4 for certain exceptions to this rule. Section 4 for certain exceptions to this rule.
3.3. IP Address Translation Procedure 3.3. IP Address Translation Procedure
This section describes step-by-step how an SIIT implementation This section describes step-by-step how an SIIT implementation
translates addresses between IPv4 and IPv6. Only the outcome of the translates addresses between IPv4 and IPv6. Only the outcome of the
algorithm described should be considered normative, that is, an SIIT algorithm described should be considered normative, that is, an SIIT
implementation MAY implement the exact procedure differently than implementation MAY implement the exact procedure differently than
what is described here, but the outcome of the algorithm MUST be the what is described here, but the outcome of the algorithm MUST be the
same. same.
For concrete examples of IP addresses translations, refer to For concrete examples of IP addresses translations, refer to
Appendix B. Appendix B.
3.3.1. Address Translation Steps: IPv4 to IPv6 3.3.1. Address Translation Steps: IPv4 to IPv6
1. The EAMT is searched for an EAM entry containing an IPv4 Prefix 1. The IPv4 Prefix column of the EAMT is searched for the EAM entry
identical to that of the IPv4 address being translated. The IPv4 that shares the longest common prefix with the IPv4 address being
Prefix and IPv6 Prefix values of the EAM entry found is from now translated. The IPv4 Prefix and IPv6 Prefix values of the EAM
on referred to as EAM4 and EAM6, respectively. entry found is from now on referred to as EAM4 and EAM6,
respectively.
2. If no matching EAM entry is found, the EAM algorithm is aborted. 2. If no matching EAM entry is found, the EAM algorithm is aborted.
The SIIT implementation MUST proceed to translate the address in The SIIT implementation MUST proceed to translate the address in
accordance with [RFC6145] (and its updates). accordance with [RFC6145] (and its updates).
3. The prefix bits of EAM4 are removed from IPv4 address being 3. The prefix bits of EAM4 are removed from IPv4 address being
translated. The remaining suffix bits from the IPv4 address translated. The remaining suffix bits from the IPv4 address
being translated are stored in a temporary buffer. being translated are stored in a temporary buffer.
4. The prefix bits of EAM6 are prepended to the temporary buffer. 4. The prefix bits of EAM6 are prepended to the temporary buffer.
5. If the temporary buffer at this point does not contain a 128-bit 5. If the temporary buffer at this point does not contain a 128-bit
value, it is padded with trailing zeroes so that it reaches a value, it is padded with trailing zeroes so that it reaches a
length of 128 bits. length of 128 bits.
6. The contents of the temporary buffer is the translated IPv6 6. The contents of the temporary buffer is the translated IPv6
address. address.
3.3.2. Address Translation Steps: IPv6 to IPv4 3.3.2. Address Translation Steps: IPv6 to IPv4
1. The EAMT is searched for an EAM entry containing an IPv6 Prefix 1. The IPv6 Prefix column of the EAMT is searched for the EAM entry
identical to that of the IPv6 address being translated. The IPv4 that shares the longest common prefix with the IPv6 address being
Prefix and IPv6 Prefix values of the EAM entry found is from now translated. The IPv4 Prefix and IPv6 Prefix values of the EAM
on referred to as EAM4 and EAM6, respectively. entry found is from now on referred to as EAM4 and EAM6,
respectively.
2. If no matching EAM entry is found, the EAM algorithm is aborted. 2. If no matching EAM entry is found, the EAM algorithm is aborted.
The SIIT implementation MUST proceed to translate the address in The SIIT implementation MUST proceed to translate the address in
accordance with [RFC6145] (and its updates). accordance with [RFC6145] (and its updates).
3. The prefix bits of EAM6 are removed from IPv6 address being 3. The prefix bits of EAM6 are removed from IPv6 address being
translated. The remaining suffix bits from the IPv6 address translated. The remaining suffix bits from the IPv6 address
being translated are stored in a temporary buffer. being translated are stored in a temporary buffer.
4. The prefix bits of EAM4 are prepended to the temporary buffer. 4. The prefix bits of EAM4 are prepended to the temporary buffer.
skipping to change at page 10, line 8 skipping to change at page 9, line 30
be used in order to translate the source address in the IPv4 be used in order to translate the source address in the IPv4
header. header.
2. If the packet is an ICMPv4 error: The EAM algorithm MUST NOT be 2. If the packet is an ICMPv4 error: The EAM algorithm MUST NOT be
used when translating the destination address in the inner IPv4 used when translating the destination address in the inner IPv4
header. header.
3. If the packet is an ICMPv4 error whose outer IPv4 source address 3. If the packet is an ICMPv4 error whose outer IPv4 source address
is equal to its inner IPv4 destination address: The EAM algorithm is equal to its inner IPv4 destination address: The EAM algorithm
MUST NOT be used in order to translate the source address in the MUST NOT be used in order to translate the source address in the
IPv4 header. outer IPv4 header.
Rule #2 and #3 are cumulative. Rule #2 and #3 are cumulative.
The addresses in question MUST instead be translated according to The addresses in question MUST instead be translated according to
[RFC6145], as if they did not match any EAM. [RFC6145], as if they did not match any EAM.
4.2.2. Intrinsic Hairpinning Support 4.2.2. Intrinsic Hairpinning Support
When the intrinsic hairpinning feature is enabled, the translator When the intrinsic hairpinning feature is enabled, the translator
behaves as follows when receiving an IPv6 packet: behaves as follows when receiving an IPv6 packet:
skipping to change at page 10, line 45 skipping to change at page 10, line 18
Condition set B: Condition set B:
B1. The packet is an ICMPv4 error B1. The packet is an ICMPv4 error
B2. The inner source address was translated using the [RFC6052] B2. The inner source address was translated using the [RFC6052]
algorithm algorithm
B3. The inner source address is found in the EAMT B3. The inner source address is found in the EAMT
5. Lack of Checksum Neutrality 5. Overlapping Explicit Address Mappings
The algorithm specified in Section 3 relies on making a lookup in the
EAMT in order 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 will not be symmetric. This may in
some cases make bi-directional communication impossible.
The example EAMT in Figure 2 could be thought of as implementing IVI
(Appendix A.2) (EAM #1), but additionally with a single exception in
the style of SIIT-DC (Appendix A.3) (EAM #2). The IPv4 Prefixes of
the two EAMs overlap, while the IPv6 Prefixes do not. This results
in a situation where the IPv6 address 2001:db8:ffc6:3364:4000:: will
be translated (according to EAM #1) to the IPv4 address
198.51.100.64. However, when this IPv4 address is translated back to
IPv6, it will be translated (according to EAM #2) to the IPv6 address
2001:db8::abcd. Because the IPv4-to-IPv6 translation in this example
does not mirror the corresponding IPv6-to-IPv4 translation, bi-
directional communication involving the IPv6 address
2001:db8:ffc6:3364:4000:: might fail. In order to help avoid such
situations, implementations MAY warn the operator when a new EAM that
overlaps with a previously existing one is inserted into the EAMT.
EAMT containing overlapping IPv4 Prefixes
+---+------------------+--------------------+
| # | 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
In Figure 3, the IPv6 Prefixes of the two EAMs are identical. The
behaviour of the stateless translator when translating an IPv6 packet
that contains the address 2001:db8::1 to IPv4 is in this case
unspecified. In order to prevent this situation from occurring,
implementations MAY refuse to insert a new EAM, whose IPv4 or IPv6
Prefix value is identical to that of an already existing EAM, into
the EAMT.
EAMT containing identical IPv6 prefixes
+---+-----------------+-----------------+
| # | 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
6. Lack of Checksum Neutrality
When one or both of the address fields in an IP/ICMP packet are When one or both of the address fields in an IP/ICMP packet are
translated according to EAM, the translation can not be relied upon translated according to EAM, the translation can not be relied upon
to be checksum neutral, even if the well-known prefix 64:ff9b::/96 is to be checksum neutral, even if the well-known prefix 64:ff9b::/96 is
used. This consideration is discussed in more detail in Section 4.1 used. This consideration is discussed in more detail in Section 4.1
of [RFC6052]. of [RFC6052].
6. Security Considerations 7. Security Considerations
The EAM algorithm does not introduce any new security issues beyond The EAM algorithm does not introduce any new security issues beyond
those that are already discussed in Section 7 of [RFC6145]. those that are already discussed in Section 7 of [RFC6145].
7. IANA Considerations 8. IANA Considerations
This draft makes no request of the IANA. The RFC Editor may remove This draft makes no request of the IANA. The RFC Editor may remove
this section prior to publication. this section prior to publication.
8. Acknowledgements 9. Acknowledgements
This document was conceived due to comments made by Dave Thaler in This document was conceived due to comments made by Dave Thaler in
the v6ops session at IETF 91 as well as e-mail discussions between the v6ops session at IETF 91 as well as e-mail discussions between
Fred Baker and the author. Fred Baker and the author.
Valuable reviews, suggestions, and other feedback was given by Valuable reviews, suggestions, and other feedback was given by Fred
Mohamed Boucadair, Cameron Byrne, Brian E Carpenter, Michael Baker, Mohamed Boucadair, Cameron Byrne, Brian E Carpenter, Ray
Richardson, and Andrew Yourtchenko. Hunter, Michael Richardson, Hemant Singh, and Andrew Yourtchenko.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
9.2. Informative References 10.2. Informative References
[I-D.ietf-v6ops-siit-dc] [I-D.ietf-v6ops-siit-dc]
tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
Data Centre Environments", draft-ietf-v6ops-siit-dc-00 IPv6 Data Centre Environments", draft-ietf-v6ops-siit-
(work in progress), December 2014. dc-01 (work in progress), June 2015.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011. IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
China Education and Research Network (CERNET) IVI China Education and Research Network (CERNET) IVI
Translation Design and Deployment for the IPv4/IPv6 Translation Design and Deployment for the IPv4/IPv6
Coexistence and Transition", RFC 6219, May 2011. Coexistence and Transition", RFC 6219, May 2011.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. [RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G.
Huston, "Stateless Source Address Mapping for ICMPv6 Huston, "Stateless Source Address Mapping for ICMPv6
Packets", RFC 6791, November 2012. Packets", RFC 6791, November 2012.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC Combination of Stateful and Stateless Translation", RFC
6877, April 2013. 6877, April 2013.
[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,
August 2014. August 2014.
skipping to change at page 12, line 47 skipping to change at page 13, line 48
Service Continuity Prefix [RFC7335]): Service Continuity Prefix [RFC7335]):
Example EAMT for an 464XLAT CLAT Example EAMT for an 464XLAT CLAT
+---+--------------+-------------------------------+ +---+--------------+-------------------------------+
| # | IPv4 Prefix | IPv6 Prefix | | # | IPv4 Prefix | IPv6 Prefix |
+---+--------------+-------------------------------+ +---+--------------+-------------------------------+
| 1 | 192.0.0.1/32 | CLAT_claimed_IPv6_address/128 | | 1 | 192.0.0.1/32 | CLAT_claimed_IPv6_address/128 |
+---+--------------+-------------------------------+ +---+--------------+-------------------------------+
Figure 2 Figure 4
In this particular use case, the EAM algorithm is used to translate In this particular use case, the EAM algorithm is used to translate
IPv6 destination addresses to IPv4, and conversely, IPv4 source IPv6 destination addresses to IPv4, and conversely, IPv4 source
addresses to IPv6. Other addresses are translated using [RFC6052]. addresses to IPv6. Other addresses are translated using [RFC6052].
Note that this is the exact opposite of the SIIT-DC use case
(Appendix A.3).
A.2. IVI A.2. IVI
IVI [RFC6219] describes a stateless translation model that embeds IVI [RFC6219] describes a stateless translation model that embeds
IPv4 addresses in a 40-bit translation prefix where bits 33-40 are IPv4 addresses in a 40-bit translation prefix where bits 33-40 are
required to be 1. The embedded IPv4 address is located in bits 41-72 required to be 1. The embedded IPv4 address is located in bits 41-72
of the IPv6 address. Bits 73-128 are required to be 0. of the IPv6 address. Bits 73-128 are required to be 0.
The location of the eight least significant IPv4 address bits makes The location of the eight least significant IPv4 address bits makes
the IVI address mapping differ from [RFC6052]. the IVI address mapping differ from [RFC6052].
Example EAMT for IVI Example EAMT for IVI
+---+-------------+--------------------+ +---+-------------+--------------------+
| # | IPv4 Prefix | IPv6 Prefix | | # | IPv4 Prefix | IPv6 Prefix |
+---+-------------+--------------------+ +---+-------------+--------------------+
| 1 | 0.0.0.0/0 | 2001:db8:ff00::/40 | | 1 | 0.0.0.0/0 | 2001:db8:ff00::/40 |
+---+-------------+--------------------+ +---+-------------+--------------------+
Figure 3 Figure 5
In this particular use case, all addresses are translated according In this particular use case, all addresses are translated according
to the EAM algorithm. In other words, [RFC6052] mapping is not used to the EAM algorithm. In other words, [RFC6052] mapping is not used
at all. at all.
A.3. SIIT-DC A.3. SIIT-DC
SIIT-DC [I-D.ietf-v6ops-siit-dc] describes the use of SIIT to SIIT-DC [I-D.ietf-v6ops-siit-dc] describes the use of SIIT to
facilitate connectivity from the IPv4 Internet to services hosted in facilitate connectivity from the IPv4 Internet to services hosted in
an IPv6-only data centre. In order to avoid the constraints relating an IPv6-only data centre. In order to avoid the constraints relating
to the use of IPv4-translatable IPv6 addresses discussed in Section 2 to the use of IPv4-translatable IPv6 addresses discussed in Section 2
the stateless IPv4/IPv6 translators are provisioned with an EAMT the stateless IPv4/IPv6 translators are provisioned with an EAMT
containing one entry per IPv6-only service that are to be made containing one entry per IPv6-only service that are to be made
available from the IPv4 Internet, for example (assuming available from the IPv4 Internet, for example (assuming
2001:db8:aaaa::1 and 2001:db8:bbbb::1 are assigned to load balancers 2001:db8:aaaa::1 and 2001:db8:bbbb::1 are assigned to load balancers
or servers that provides the IPv6-only services in question): or servers that provides the IPv6-only services in question):
Example EAMT for SIIT-DC Example EAMT for SIIT-DC
+---+--------------+----------------------+ +---+----------------+----------------------+
| # | IPv4 Prefix | IPv6 Prefix | | # | IPv4 Prefix | IPv6 Prefix |
+---+--------------+----------------------+ +---+----------------+----------------------+
| 1 | 192.0.2.1/32 | 2001:db8:aaaa::1/128 | | 1 | 203.0.113.1/32 | 2001:db8:aaaa::1/128 |
| 2 | 192.0.2.2/32 | 2001:db8:bbbb::1/128 | | 2 | 203.0.113.2/32 | 2001:db8:bbbb::1/128 |
+---+--------------+----------------------+ +---+----------------+----------------------+
Figure 4 Figure 6
In this particular use case, the EAM algorithm is used to translate In this particular use case, the EAM algorithm is used to translate
IPv4 destination addresses to IPv6, and conversely, IPv6 source IPv4 destination addresses to IPv6, and conversely, IPv6 source
addresses to IPv4. Other addresses are translated using [RFC6052]. addresses to IPv4. Other addresses are translated using [RFC6052].
Note that this is the exact opposite of the 464XLAT use case
(Appendix A.1).
Appendix B. Example IP Address Translations Appendix B. Example IP Address Translations
Figure 5 demonstrates how a set of example IP addresses are Figure 7 demonstrates how a set of example IP addresses are
translated given the example EAMT in Figure 1. Implementors may use translated given the example EAMT in Figure 1. Implementors may use
the examples given to develop test cases to validate correct the examples given to develop test cases to validate correct
operation. Note that the address translations are bidirectional, so operation. Note that the address translations are bidirectional, so
a single row in the table describes two address translations: IPv4 to a single row in the table describes two address translations: IPv4 to
IPv6, and IPv6 to IPv4. IPv6, and IPv6 to IPv4.
It is also assumed that the [RFC6052] translation prefix is It is also assumed that the [RFC6052] translation prefix is
configured to be 64:ff9b::/96. configured to be 64:ff9b::/96.
Example IP Address Translations Example IP Address Translations
skipping to change at page 14, line 50 skipping to change at page 15, line 39
| 192.0.2.24 | 2001:db8:cccc::8 | 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.31 | 2001:db8:cccc::f | According to EAM #3 |
| 192.0.2.128 | 2001:db8:dddd:: | According to EAM #4 | | 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.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.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.191 | 2001:db8:dddd:0:fc00:: | According to EAM #4 |
| 192.0.2.193 | 64:ff9b::1 | According to EAM #5 | | 192.0.2.193 | 64:ff9b::1 | According to EAM #5 |
| 192.0.2.200 | 64:ff9b::c000:2c8 | According to RFC 6052 | | 192.0.2.200 | 64:ff9b::c000:2c8 | According to RFC 6052 |
+--------------+------------------------+-----------------------+ +--------------+------------------------+-----------------------+
Figure 5 Figure 7
B.1. Hairpinning Examples B.1. Hairpinning Examples
The following examples show how hairpinned IPv6 packets between the The following examples show how hairpinned IPv6 packets between the
IPv6 nodes 2001:db8:aaaa:: and 2001:db8:bbbb::b are translated IPv6 nodes 2001:db8:aaaa:: and 2001:db8:bbbb::b are translated
according to Section 4. As in Appendix B, the EAMT in Figure 1 is according to Section 4. As in Appendix B, the EAMT in Figure 1 is
used and the [RFC6052] translation prefix is 64:ff9b::/96. In used and the [RFC6052] translation prefix is 64:ff9b::/96. In
addition, the [RFC6791] pool is assumed to contain only the single addition, the [RFC6791] pool is assumed to contain only the single
address 198.51.100.1. address 198.51.100.1.
Hairpinning of a normal IPv6 packet Hairpinning of a normal IPv6 packet
+--------------+--------------------+---------------------+ +--------------+--------------------+---------------------+
| XLAT Stage | Source Address | Destination Address | | XLAT Stage | Source Address | Destination Address |
+--------------+--------------------+---------------------+ +--------------+--------------------+---------------------+
| Initial | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | | Initial | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 |
+--------------+--------------------+---------------------+ +--------------+--------------------+---------------------+
| Intermediate | 192.0.2.1 | 192.0.2.2 | | Intermediate | 192.0.2.1 | 192.0.2.2 |
+--------------+--------------------+---------------------+ +--------------+--------------------+---------------------+
| Final | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | | Final | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b |
+--------------+--------------------+---------------------+ +--------------+--------------------+---------------------+
Figure 6 Figure 8
Figure 6 illustrates how a normal (i.e., not an ICMP error) IPv6 Figure 8 illustrates how a normal (i.e., not an ICMP error) IPv6
packet sent from 2001:db8:aaaa:: towards 64:ff9b::192.0.2.2 is is packet sent from 2001:db8:aaaa:: towards 64:ff9b::192.0.2.2 is is
hairpinned. In this example, rule #1 in Section 4.2.1 was applied in hairpinned. In this example, rule #1 in Section 4.2.1 was applied in
order to disable the EAM algorithm when translating the intermediate order to disable the EAM algorithm when translating the intermediate
IPv4 source address to IPv6. IPv4 source address to IPv6.
Hairpinning of a host-originated ICMPv6 error Hairpinning of a router-originated ICMPv6 error
+--------------+-------+-----------------------+--------------------+ +--------------+-------+-----------------------+--------------------+
| XLAT Stage | Loc. | Source Address | Destination Addr. | | XLAT Stage | Loc. | Source Address | Destination Addr. |
+--------------+-------+-----------------------+--------------------+ +--------------+-------+-----------------------+--------------------+
| Initial | Inner | 2001:db8::1234 | 64:ff9b::192.0.2.1 | | Initial | Outer | 2001:db8::1234 | 64:ff9b::192.0.2.1 |
| | Outer | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | | | Inner | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b |
+--------------+-------+-----------------------+--------------------+ +--------------+-------+-----------------------+--------------------+
| Intermediate | Inner | 198.51.100.1 | 192.0.2.1 | | Intermediate | Outer | 198.51.100.1 | 192.0.2.1 |
| | Outer | 192.0.2.1 | 192.0.2.2 | | | Inner | 192.0.2.1 | 192.0.2.2 |
+--------------+-------+-----------------------+--------------------+ +--------------+-------+-----------------------+--------------------+
| Final | Inner | 64:ff9b::198.51.100.1 | 2001:db8:aaaa:: | | Final | Outer | 64:ff9b::198.51.100.1 | 2001:db8:aaaa:: |
| | Outer | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | | | Inner | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 |
+--------------+-------+-----------------------+--------------------+ +--------------+-------+-----------------------+--------------------+
Figure 7 Figure 9
Figure 7 illustrates the hairpinning of an ICMPv6 error sent by an Figure 9 illustrates the hairpinning of an ICMPv6 error sent by an
arbitrary IPv6 router (2001:db8::1234) in response to the packet arbitrary IPv6 router (2001:db8::1234) in response to the packet
Figure 6. In this example, rule #2 in Section 4.2.1 was applied in Figure 8. In this example, rule #2 in Section 4.2.1 was applied in
order to disable the EAM algorithm when translating the intermediate order to disable the EAM algorithm when translating the intermediate
inner IPv4 source address to IPv6. inner IPv4 destination address to IPv6.
Hairpinning of a host-originated ICMPv6 error Hairpinning of a host-originated ICMPv6 error
+--------------+-------+-----------------------+--------------------+ +--------------+-------+--------------------+--------------------+
| XLAT Stage | Loc. | Source Address | Destination Addr. | | XLAT Stage | Loc. | Source Address | Destination Addr. |
+--------------+-------+-----------------------+--------------------+ +--------------+-------+--------------------+--------------------+
| Initial | Inner | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 | | Initial | Outer | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 |
| | Outer | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | | | Inner | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b |
+--------------+-------+-----------------------+--------------------+ +--------------+-------+--------------------+--------------------+
| Intermediate | Inner | 192.0.2.2 | 192.0.2.1 | | Intermediate | Outer | 192.0.2.2 | 192.0.2.1 |
| | Outer | 192.0.2.1 | 192.0.2.2 | | | Inner | 192.0.2.1 | 192.0.2.2 |
+--------------+-------+-----------------------+--------------------+ +--------------+-------+--------------------+--------------------+
| Final | Inner | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: | | Final | Outer | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: |
| | Outer | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | | | Inner | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 |
+--------------+-------+-----------------------+--------------------+ +--------------+-------+--------------------+--------------------+
Figure 8 Figure 10
Figure 8 illustrates the hairpinning of an ICMPv6 error sent by the Figure 10 illustrates the hairpinning of an ICMPv6 error sent by the
original destination host itself in response to the packet Figure 6. original destination host itself in response to the packet Figure 8.
In this example, rules #2 and #3 in Section 4.2.1 were both applied In this example, rules #2 and #3 in Section 4.2.1 were both applied
in order to disable the EAM algorithm when translating the in order to disable the EAM algorithm when translating the
intermediate inner IPv4 destination address and the intermediate intermediate inner IPv4 destination address and the intermediate
outer IPv4 destination address to IPv6. outer IPv4 destination address to IPv6.
Hairpinning of normal response packet Hairpinning of normal response packet
+--------------+--------------------+---------------------+ +--------------+--------------------+---------------------+
| XLAT Stage | Source Address | Destination Address | | XLAT Stage | Source Address | Destination Address |
+--------------+--------------------+---------------------+ +--------------+--------------------+---------------------+
| Initial | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 | | Initial | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 |
+--------------+--------------------+---------------------+ +--------------+--------------------+---------------------+
| Intermediate | 192.0.2.2 | 192.0.2.1 | | Intermediate | 192.0.2.2 | 192.0.2.1 |
+--------------+--------------------+---------------------+ +--------------+--------------------+---------------------+
| Final | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: | | Final | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: |
+--------------+--------------------+---------------------+ +--------------+--------------------+---------------------+
Figure 9 Figure 11
Figure 9 illustrates how 2001:db8:bbbb::b's response to the packet in Figure 11 illustrates how 2001:db8:bbbb::b's response to the packet
Figure 6 is hairpinned in the exact same fashion as the initial in Figure 8 is hairpinned in the exact same fashion as the initial
packet. Again, rule #1 in Section 4.2.1 was applied in order to packet. Again, rule #1 in Section 4.2.1 was applied in order to
disable the EAM algorithm when translating the intermediate IPv4 disable the EAM algorithm when translating the intermediate IPv4
source address to IPv6. The example is included in order to source address to IPv6. The example is included in order to
illustrate how the addresses in the packet initially sent by illustrate how the addresses in the packet initially sent by
2001:db8:aaaa:: matches those in the translated response packet sent 2001:db8:aaaa:: matches those in the translated response packet sent
by 2001:db8:bbbb::b, thus facilitating bi-directional communication. by 2001:db8:bbbb::b, thus facilitating bi-directional communication.
Authors' Addresses Authors' Addresses
Tore Anderson Tore Anderson
Redpill Linpro Redpill Linpro
Vitaminveien 1A Vitaminveien 1A
0485 Oslo 0485 Oslo
Norway Norway
Phone: +47 959 31 212 Phone: +47 959 31 212
Email: tore@redpill-linpro.com Email: tore@redpill-linpro.com
URI: http://www.redpill-linpro.com URI: http://www.redpill-linpro.com
 End of changes. 56 change blocks. 
114 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/