doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc7757.txt b/doc/rfc/rfc7757.txt
new file mode 100644
index 0000000..213fceb
--- /dev/null
+++ b/doc/rfc/rfc7757.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       T. Anderson
+Request for Comments: 7757                                Redpill Linpro
+Updates: 6145                                            A. Leiva Popper
+Category: Standards Track                                     NIC Mexico
+ISSN: 2070-1721                                            February 2016
+
+
+      Explicit Address Mappings for Stateless IP/ICMP Translation
+
+Abstract
+
+   This document extends the Stateless IP/ICMP Translation Algorithm
+   (SIIT) with an Explicit Address Mapping (EAM) algorithm and formally
+   updates RFC 6145.  The EAM algorithm facilitates stateless IP/ICMP
+   translation between arbitrary (non-IPv4-translatable) IPv6 endpoints
+   and IPv4.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7757.
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                    [Page 1]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Explicit Address Mapping Algorithm  . . . . . . . . . . . . .   5
+     3.1.  Explicit Address Mapping Table  . . . . . . . . . . . . .   5
+     3.2.  Explicit Address Mapping Specification  . . . . . . . . .   6
+     3.3.  IP Address Translation Procedure  . . . . . . . . . . . .   6
+       3.3.1.  Address Translation Steps: IPv4 to IPv6 . . . . . . .   7
+       3.3.2.  Address Translation Steps: IPv6 to IPv4 . . . . . . .   7
+   4.  Hairpinning of IPv6 Traffic . . . . . . . . . . . . . . . . .   8
+     4.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   8
+     4.2.  Recommendation  . . . . . . . . . . . . . . . . . . . . .   9
+       4.2.1.  Simple Hairpinning Support  . . . . . . . . . . . . .   9
+       4.2.2.  Intrinsic Hairpinning Support . . . . . . . . . . . .   9
+   5.  Overlapping Explicit Address Mappings . . . . . . . . . . . .  10
+   6.  Lack of Checksum Neutrality . . . . . . . . . . . . . . . . .  11
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
+   Appendix A.  Use Cases  . . . . . . . . . . . . . . . . . . . . .  14
+     A.1.  464XLAT . . . . . . . . . . . . . . . . . . . . . . . . .  14
+     A.2.  IVI . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
+     A.3.  SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . .  15
+   Appendix B.  Example IP Address Translations  . . . . . . . . . .  15
+     B.1.  Hairpinning Examples  . . . . . . . . . . . . . . . . . .  16
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19
+
+1.  Introduction
+
+   The Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]
+   specifies that when translating IPv4 addresses to IPv6 and vice
+   versa, all addresses must be translated using the algorithm specified
+   in [RFC6052].  This document specifies an alternative to the
+   algorithm specified in [RFC6052], where IP addresses are translated
+   according to a table of Explicit Address Mappings configured on the
+   stateless translator.  This removes the previous constraint that IPv6
+   nodes that communicate with IPv4 nodes through SIIT must be
+   configured with IPv4-translatable IPv6 addresses.
+
+   Translation using the Explicit Address Mapping Table does not replace
+   [RFC6052].  For most use cases, it is expected that both algorithms
+   are used in concert.  The Explicit Address Mapping algorithm is used
+   only when a mapping matching the address to be translated exists.  If
+   no matching mapping exists, the algorithm specified in [RFC6052] will
+
+
+
+Anderson & Leiva Popper      Standards Track                    [Page 2]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+   be used instead.  Thus, when translating an individual IP packet, an
+   SIIT implementation might translate one of the two IP address fields
+   according to an EAM, while the other IP address field is translated
+   according to [RFC6052].
+
+1.1.  Terminology
+
+   This document makes use of the following terms:
+
+   EAM:
+      An Explicit Address Mapping, as specified in Section 3.2.
+
+   EAMT:
+      The Explicit Address Mapping Table, as specified in Section 3.1.
+
+   Inner (header or address):
+      Refers to an IP header located inside the payload of an ICMP error
+      packet or to an IP address within that header.  Compare with
+      "Outer".
+
+   Outer (header or address):
+      Refers to the first IP header in a packet or to an IP address
+      within that header.  In other words, an IP header or address that
+      is NOT "Inner".  If a reference is made to an IP header or address
+      without the "Inner" or "Outer" qualifier, it should be considered
+      as "Outer".
+
+   SIIT:
+      The Stateless IP/ICMP Translation Algorithm, as specified in
+      [RFC6145].
+
+   XLAT:
+      Short for "translation".
+
+   IPv4-Converted IPv6 Addresses:
+      As defined in Section 1.3 of [RFC6052].
+
+   IPv4-Translatable IPv6 Addresses:
+      As defined in Section 1.3 of [RFC6052].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                    [Page 3]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+2.  Problem Statement
+
+   Section 3.2.1 of [RFC6144] notes that "stateless translation
+   mechanisms typically put constraints on what IPv6 addresses can be
+   assigned to IPv6 nodes that want to communicate with IPv4
+   destinations using an algorithmic mapping."  In practice, this means
+   that the IPv6 nodes must be configured with IPv4-translatable IPv6
+   addresses.  For the reasons discussed below, some environments may
+   find that the use of IPv4-translatable IPv6 addresses is not desired
+   or even possible.
+
+   Limited availability:
+      The number of IPv4-translatable IPv6 addresses available to an
+      operator is equal to the number of IPv4 addresses that is assigned
+      to the SIIT function.  IPv4 addresses are scarce, and as a result,
+      an operator might not have enough IPv4-translatable IPv6 addresses
+      to number the entire IPv6 infrastructure.
+
+   Restricted format:
+      IPv4-translatable IPv6 addresses must conform to the format
+      specified in Section 2.2 of [RFC6052].  This format is not
+      compatible with other common IPv6 address formats, such as the
+      IPv6 address format based on the 64-bit Extended Unique Identifier
+      (EUI-64) and used by IPv6 Stateless Address Autoconfiguration
+      [RFC4862].
+
+   An operator could overcome the above two problems by building an IPv6
+   network using regular (non-IPv4-translatable) IPv6 addresses and
+   assigning IPv4-translatable IPv6 addresses as secondary addresses on
+   the nodes that want to communicate with IPv4 nodes through SIIT only.
+   However, doing so may result in a new set of undesired consequences:
+
+   Routing complexity:
+      The IPv4-translatable IPv6 addresses must be routed throughout the
+      IPv6 network separately from the primary (non-IPv4-translatable)
+      IPv6 addresses used by the nodes.  It might be impossible to
+      aggregate these routes, as two adjacent IPv4-translatable IPv6
+      addresses might not be assigned to two adjacent IPv6 nodes.  As a
+      result, in order to support SIIT, the IPv6 network might need to
+      carry a large number of extraneous routes.  These routes must be
+      separately injected into the IPv6 routing topology somehow.  Any
+      intermediate devices in the IPv6 network such as a firewall might
+      require special configuration in order to treat the
+      IPv4-translatable IPv6 address the same as the primary IPv6
+      address, for example, by requiring that any Access Control List
+      (ACL) entries involving the primary IPv6 address of a node must be
+      duplicated.
+
+
+
+
+Anderson & Leiva Popper      Standards Track                    [Page 4]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+   Operational complexity:
+      The IPv4-translatable IPv6 addresses not only have to be assigned
+      to the IPv6 nodes participating in SIIT, but also all applications
+      and services on those nodes must be configured to use them.  For
+      example, if the IPv6 node is a load balancer, it might require a
+      separate virtual server definition using the IPv4-translatable
+      IPv6 address in addition to one using the service's primary IPv6
+      address.  A web server might require specific configuration to
+      listen for connections on both the IPv4-translatable and the
+      primary IPv6 address.  A high-availability cluster service must be
+      set up to fail over both addresses between cluster nodes, and
+      depending on how the IPv6 network learns the location of the
+      IPv4-translatable IPv6 address, the fail-over mechanism used for
+      the two addresses might be completely different.  Service
+      monitoring must be done for both the IPv4-translatable and the
+      primary IPv6 address, and any troubleshooting procedures must be
+      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
+   with regular IPv6 addresses is in many ways analogous to the use of
+   dual stack [RFC4213].  While no actual IPv4 packets are used, the
+   IPv4-translatable IPv6 addresses create a secondary "stack" in the
+   infrastructure that must be treated and operated separately from the
+   primary one.  This increases the complexity of the overall
+   infrastructure, in turn increasing operational overhead and reducing
+   reliability.  An operator who for such reasons finds the use of dual
+   stack unappealing might feel the same way about using SIIT with
+   IPv4-translatable IPv6 addresses.
+
+3.  Explicit Address Mapping Algorithm
+
+   This normative section defines the EAM algorithm and formally updates
+   Sections 4.1 and 5.1 of [RFC6145].  Specifically, when the EAM
+   algorithm is applied, it supplants the requirement in [RFC6145] that
+   states that a translator operating in the stateless mode must
+   translate the Source Address and Destination Address IP header fields
+   according to Section 2.3 of [RFC6052].
+
+3.1.  Explicit Address Mapping Table
+
+   An SIIT implementation includes an EAMT, a conceptual table in which
+   each row represents an EAM.  Each EAM describes a mapping between
+   IPv4 and IPv6 prefixes/addresses.  An operator populates the EAMT to
+   provide the mappings between the two address families.
+
+
+
+
+Anderson & Leiva Popper      Standards Track                    [Page 5]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+   The EAMT consists of the following columns:
+
+   o  IPv4 Prefix
+
+   o  IPv6 Prefix
+
+   SIIT implementations MAY include other columns in order to support
+   proprietary extensions to the EAM algorithm.
+
+   Throughout this document, figures representing the EAMT contain an
+   Index column using the pound sign as the header.  This column is not
+   a required part of this specification; it is included only as a
+   convenience to the reader.
+
+3.2.  Explicit Address Mapping Specification
+
+   An EAM consists of an IPv4 prefix and an IPv6 prefix.  The prefix
+   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
+   containing examples of valid EAMs.
+
+               +---+----------------+----------------------+
+               | # |  IPv4 Prefix   |     IPv6 Prefix      |
+               +---+----------------+----------------------+
+               | 1 | 192.0.2.1      | 2001:db8:aaaa::      |
+               | 2 | 192.0.2.2/32   | 2001:db8:bbbb::b/128 |
+               | 3 | 192.0.2.16/28  | 2001:db8:cccc::/124  |
+               | 4 | 192.0.2.128/26 | 2001:db8:dddd::/64   |
+               | 5 | 192.0.2.192/29 | 2001:db8:eeee:8::/62 |
+               | 6 | 192.0.2.224/31 | 64:ff9b::/127        |
+               +---+----------------+----------------------+
+
+                          Figure 1: Example EAMT
+
+   An EAM's IPv4 prefix value MUST have an identical or smaller number
+   of suffix bits than its corresponding IPv6 prefix value.
+
+   Unless otherwise specified in Section 4, an SIIT implementation MUST
+   individually translate each IP address it encounters in the packet's
+   IP headers (including any IP headers contained within ICMP errors)
+   according to Section 3.3.
+
+3.3.  IP Address Translation Procedure
+
+   This section describes step by step how an SIIT implementation
+   translates addresses between IPv4 and IPv6.  Only the outcome of the
+   algorithm described should be considered normative, that is, an SIIT
+   implementation may implement the exact procedure differently than
+
+
+
+Anderson & Leiva Popper      Standards Track                    [Page 6]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+   what is described here, but the outcome of the algorithm MUST be the
+   same.
+
+   For concrete examples of IP address translations, refer to
+   Appendix B.
+
+3.3.1.  Address Translation Steps: IPv4 to IPv6
+
+   1.  The IPv4 prefix column of the EAMT is searched for the EAM entry
+       that shares the longest common prefix with the IPv4 address being
+       translated.  The IPv4 prefix and IPv6 prefix values of the EAM
+       entry 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.
+       The SIIT implementation MUST proceed to translate the address in
+       accordance with [RFC6145] (and its updates).
+
+   3.  The prefix bits of EAM4 are removed from the IPv4 address being
+       translated.  The remaining suffix bits from the IPv4 address
+       being translated are stored in a 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
+       value, it is padded with trailing zeros so that it reaches a
+       length of 128 bits.
+
+   6.  The contents of the temporary buffer is the translated IPv6
+       address.
+
+3.3.2.  Address Translation Steps: IPv6 to IPv4
+
+   1.  The IPv6 prefix column of the EAMT is searched for the EAM entry
+       that shares the longest common prefix with the IPv6 address being
+       translated.  The IPv4 prefix and IPv6 prefix values of the EAM
+       entry 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.
+       The SIIT implementation MUST proceed to translate the address in
+       accordance with [RFC6145] (and its updates).
+
+   3.  The prefix bits of EAM6 are removed from the IPv6 address being
+       translated.  The remaining suffix bits from the IPv6 address
+       being translated are stored in a temporary buffer.
+
+   4.  The prefix bits of EAM4 are prepended to the temporary buffer.
+
+
+
+Anderson & Leiva Popper      Standards Track                    [Page 7]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+   5.  If the temporary buffer at this point does not contain a 32-bit
+       value, any trailing bits are discarded so that the buffer is
+       reduced to a length of 32 bits.
+
+   6.  The contents of the temporary buffer is the translated IPv4
+       address.
+
+4.  Hairpinning of IPv6 Traffic
+
+4.1.  Problem Statement
+
+   Two IPv6 nodes that are both covered by EAMs might in certain
+   circumstances attempt to communicate through a stateless translator
+   rather than using native IPv6 directly.  This happens if one of the
+   nodes initiates traffic towards the IPv4-converted IPv6 address whose
+   embedded IPv4 address matches an EAM that covers the other node.
+   Special consideration is required in order to make this communication
+   pattern work in a bidirectional fashion.  This is illustrated by the
+   example below.
+
+   Assume that a stateless translator is configured with a translation
+   prefix of 64:ff9b::/96 (per [RFC6052]) and the EAMT shown in
+   Figure 1.  The IPv6 node 2001:db8:aaaa:: transmits an IPv6 packet
+   towards 64:ff9b::192.0.2.2, which reaches the translator and is
+   translated into an IPv4 packet with source address 192.0.2.1 and
+   destination address 192.0.2.2.  This destination address is found in
+   the EAMT, so the packet loops back into the translation function and
+   is translated back to an IPv6 packet with source address
+   2001:db8:aaaa:: and destination address 2001:db8:bbbb::b.
+
+   While this packet will reach its destination just fine, a problem
+   will occur when 2001:db8:bbbb::b responds to it.  The response packet
+   will have a source address of 2001:db8:bbbb::b and a destination
+   address of 2001:db8:aaaa:: and will be routed directly to its
+   destination without being subjected to any form of translation.
+   Because the source address of this response packet (2001:db8:bbbb::b)
+   is not equal to the destination address of the initial outgoing
+   packet (64:ff9b::192.0.2.2), the packet will most likely be discarded
+   by 2001:db8:aaaa::, and bidirectional communication will most likely
+   fail.
+
+   The above scenario could be made to work by ensuring that the
+   stateless translator is hairpinning the traffic in both directions.
+   Section 4.2 describes how this is accomplished.  The resulting
+   address translations are demonstrated step by step in Appendix B.1.
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                    [Page 8]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+4.2.  Recommendation
+
+   An SIIT implementation SHOULD include a feature that ensures that
+   hairpinned IPv6 traffic is supported.  The feature SHOULD be enabled
+   by default.  The following two subsections describe two alternate
+   ways to implement this feature.  An implementation MAY support both
+   approaches.
+
+4.2.1.  Simple Hairpinning Support
+
+   When the simple hairpinning feature is enabled, the translator
+   employs the following rules when translating from IPv4 to IPv6:
+
+   1.  If the packet is not an ICMPv4 error: The EAM algorithm MUST NOT
+       be used in order to translate the source address in the IPv4
+       header.
+
+   2.  If the packet is an ICMPv4 error: The EAM algorithm MUST NOT be
+       used when translating the destination address in the inner IPv4
+       header.
+
+   3.  If the packet is an ICMPv4 error whose outer IPv4 source address
+       is equal to its inner IPv4 destination address: The EAM algorithm
+       MUST NOT be used in order to translate the source address in the
+       outer IPv4 header.
+
+   Rules #2 and #3 are cumulative.
+
+   The addresses in question MUST instead be translated according to
+   [RFC6145], as if they did not match any EAM.
+
+4.2.2.  Intrinsic Hairpinning Support
+
+   When the intrinsic hairpinning feature is enabled, the translator
+   employs the following rules after having translated an IPv6 packet to
+   IPv4:
+
+   If all the conditions in either of the two sets below are true, the
+   packet is to be hairpinned.  The implementation MUST immediately
+   (i.e., prior to forwarding it to the IPv4 network) translate the
+   packet back to IPv6.  During the second translation pass, the
+   behavior specified in Section 4.2.1 MUST be applied, and the Hop
+   Limit field SHOULD NOT be decremented.
+
+
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                    [Page 9]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+   Condition set A:
+
+      A1.  The packet is not an ICMPv4 error.
+
+      A2.  The destination address was translated using the algorithm in
+           [RFC6052].
+
+      A3.  The destination address is found in the EAMT.
+
+   Condition set B:
+
+
+      B1.  The packet is an ICMPv4 error.
+
+      B2.  The inner source address was translated using the algorithm
+           in [RFC6052].
+
+      B3.  The inner source address is found in the EAMT.
+
+5.  Overlapping Explicit Address Mappings
+
+   The algorithm 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 bidirectional communication impossible.
+
+   EAM #1 in the example EAMT (Figure 2) could be thought of as
+   implementing IVI (Appendix A.2), while EAM #2 introduces a single
+   exception in the style of SIIT-DC (Appendix A.3).  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, bidirectional 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.
+
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                   [Page 10]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+               +---+------------------+--------------------+
+               | # |   IPv4 Prefix    |    IPv6 Prefix     |
+               +---+------------------+--------------------+
+               | 1 | 0.0.0.0/0        | 2001:db8:ff00::/40 |
+               | 2 | 198.51.100.64/32 | 2001:db8::abcd/128 |
+               +---+------------------+--------------------+
+
+            Figure 2: EAMT Containing Overlapping IPv4 Prefixes
+
+   In Figure 3, the IPv6 prefixes of the two EAMs are identical.  The
+   behavior of the stateless translator when 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.
+
+                 +---+-----------------+-----------------+
+                 | # |   IPv4 Prefix   |   IPv6 Prefix   |
+                 +---+-----------------+-----------------+
+                 | 1 | 198.51.100.8/32 | 2001:db8::1/128 |
+                 | 2 | 198.51.100.9/32 | 2001:db8::1/128 |
+                 +---+-----------------+-----------------+
+
+             Figure 3: EAMT Containing Identical IPv6 Prefixes
+
+6.  Lack of Checksum Neutrality
+
+   When one or both of the address fields in an IP/ICMP packet are
+   translated according to the EAM algorithm, the translation cannot be
+   relied upon 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 of [RFC6052].
+
+7.  Security Considerations
+
+   The EAM algorithm does not introduce any new security issues beyond
+   those that are already discussed in Section 7 of [RFC6145].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                   [Page 11]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+8.  References
+
+8.1.  Normative References
+
+   [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>.
+
+   [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>.
+
+8.2.  Informative References
+
+   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", RFC 4213,
+              DOI 10.17487/RFC4213, October 2005,
+              <http://www.rfc-editor.org/info/rfc4213>.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862,
+              DOI 10.17487/RFC4862, September 2007,
+              <http://www.rfc-editor.org/info/rfc4862>.
+
+   [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>.
+
+   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
+              "Default Address Selection for Internet Protocol Version 6
+              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
+              <http://www.rfc-editor.org/info/rfc6724>.
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                   [Page 12]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+   [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>.
+
+   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
+              Combination of Stateful and Stateless Translation",
+              RFC 6877, DOI 10.17487/RFC6877, April 2013,
+              <http://www.rfc-editor.org/info/rfc6877>.
+
+   [RFC7335]  Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,
+              DOI 10.17487/RFC7335, August 2014,
+              <http://www.rfc-editor.org/info/rfc7335>.
+
+   [RFC7755]  Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
+              IPv6 Data Center Environments", RFC 7755,
+              DOI 10.17487/RFC7755, February 2016,
+              <http://www.rfc-editor.org/info/rfc7755>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                   [Page 13]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+Appendix A.  Use Cases
+
+   The following subsections describe some use cases that at the time of
+   writing leverage SIIT with the EAM algorithm.
+
+A.1.  464XLAT
+
+   When the customer-side translator (CLAT) component in the 464XLAT
+   [RFC6877] architecture does not have a dedicated IPv6 prefix
+   assigned, it may instead use "one interface IPv6 address that is
+   claimed by the CLAT."  This IPv6 address might not be
+   IPv4-translatable.  If this is the case, the CLAT essentially
+   implements the EAM algorithm using an EAMT as follows (assuming the
+   CLAT's IPv4 address is picked from the IPv4 Service Continuity Prefix
+   [RFC7335]):
+
+           +---+--------------+-------------------------------+
+           | # | IPv4 Prefix  |          IPv6 Prefix          |
+           +---+--------------+-------------------------------+
+           | 1 | 192.0.0.1/32 | CLAT_claimed_IPv6_address/128 |
+           +---+--------------+-------------------------------+
+
+                 Figure 4: Example EAMT for a 464XLAT CLAT
+
+   In this particular use case, the EAM algorithm is used to translate
+   IPv6 destination addresses to IPv4, and conversely, IPv4 source
+   addresses to IPv6.  Other addresses are translated using [RFC6052].
+
+A.2.  IVI
+
+   IVI [RFC6219] describes a stateless translation model that embeds
+   IPv4 addresses in a 40-bit translation prefix where bits 33-40 are
+   required to be 1.  The embedded IPv4 address is located in bits 41-72
+   of the IPv6 address.  Bits 73-128 are required to be 0.
+
+   The location of the eight least significant IPv4 address bits makes
+   the IVI address mapping differ from [RFC6052].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                   [Page 14]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+                 +---+-------------+--------------------+
+                 | # | IPv4 Prefix |    IPv6 Prefix     |
+                 +---+-------------+--------------------+
+                 | 1 | 0.0.0.0/0   | 2001:db8:ff00::/40 |
+                 +---+-------------+--------------------+
+
+                      Figure 5: Example EAMT for IVI
+
+   In this particular use case, all addresses are translated according
+   to the EAM algorithm.  In other words, [RFC6052] mapping is not used
+   at all.
+
+A.3.  SIIT-DC
+
+   SIIT-DC [RFC7755] describes the use of SIIT to facilitate
+   connectivity from the IPv4 Internet to services hosted in an
+   IPv6-only data center.  In order to avoid the constraints relating to
+   the use of IPv4-translatable IPv6 addresses discussed in Section 2,
+   the stateless IPv4/IPv6 translators are provisioned with an EAMT
+   containing one entry per IPv6-only service that are to be made
+   available from the IPv4 Internet, for example (assuming
+   2001:db8:aaaa::1 and 2001:db8:bbbb::1 are assigned to load balancers
+   or servers that provide the IPv6-only services in question):
+
+               +---+----------------+----------------------+
+               | # |  IPv4 Prefix   |     IPv6 Prefix      |
+               +---+----------------+----------------------+
+               | 1 | 203.0.113.1/32 | 2001:db8:aaaa::1/128 |
+               | 2 | 203.0.113.2/32 | 2001:db8:bbbb::1/128 |
+               +---+----------------+----------------------+
+
+                    Figure 6: Example EAMT for SIIT-DC
+
+   In this particular use case, the EAM algorithm is used to translate
+   IPv4 destination addresses to IPv6, and conversely, IPv6 source
+   addresses to IPv4.  Other addresses are translated using [RFC6052].
+
+Appendix B.  Example IP Address Translations
+
+   Figure 7 demonstrates how a set of example IP addresses are
+   translated given the example EAMT in Figure 1.  Implementors may use
+   the examples given to develop test cases to validate correct
+   operation.  Note that the address translations are bidirectional, so
+   a single row in the table describes two address translations: IPv4 to
+   IPv6 and IPv6 to IPv4.
+
+   It is also assumed that the translation prefix is configured to be
+   64:ff9b::/96 (per [RFC6052]).
+
+
+
+Anderson & Leiva Popper      Standards Track                   [Page 15]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+     +--------------+------------------------+-----------------------+
+     | IPv4 Address |      IPv6 Address      |        Comment        |
+     +--------------+------------------------+-----------------------+
+     | 192.0.2.1    | 2001:db8:aaaa::        | According to EAM #1   |
+     | 192.0.2.2    | 2001:db8:bbbb::b       | According to EAM #2   |
+     | 192.0.2.16   | 2001:db8:cccc::        | According to EAM #3   |
+     | 192.0.2.24   | 2001:db8:cccc::8       | According to EAM #3   |
+     | 192.0.2.31   | 2001:db8:cccc::f       | According to EAM #3   |
+     | 192.0.2.128  | 2001:db8:dddd::        | According to EAM #4   |
+     | 192.0.2.152  | 2001:db8:dddd:0:6000:: | According to EAM #4   |
+     | 192.0.2.183  | 2001:db8:dddd:0:dc00:: | According to EAM #4   |
+     | 192.0.2.191  | 2001:db8:dddd:0:fc00:: | According to EAM #4   |
+     | 192.0.2.195  | 2001:db8:eeee:9:8000:: | According to EAM #5   |
+     | 192.0.2.225  | 64:ff9b::1             | According to EAM #6   |
+     | 192.0.2.248  | 64:ff9b::c000:2f8      | According to RFC 6052 |
+     +--------------+------------------------+-----------------------+
+
+                 Figure 7: Example IP Address Translations
+
+B.1.  Hairpinning Examples
+
+   The following examples show how hairpinned IPv6 packets between the
+   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
+   used, and the translation prefix is 64:ff9b::/96 (per [RFC6052]).  In
+   addition, the [RFC6791] pool is assumed to contain only the single
+   address 198.51.100.1.
+
+        +--------------+--------------------+---------------------+
+        |  XLAT Stage  |   Source Address   | Destination Address |
+        +--------------+--------------------+---------------------+
+        | Initial      | 2001:db8:aaaa::    | 64:ff9b::192.0.2.2  |
+        +--------------+--------------------+---------------------+
+        | Intermediate | 192.0.2.1          | 192.0.2.2           |
+        +--------------+--------------------+---------------------+
+        | Final        | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b    |
+        +--------------+--------------------+---------------------+
+
+               Figure 8: Hairpinning of a Normal IPv6 Packet
+
+   Figure 8 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
+   hairpinned.  In this example, rule #1 in Section 4.2.1 was applied in
+   order to disable the EAM algorithm when translating the intermediate
+   IPv4 source address to IPv6.
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                   [Page 16]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+   +--------------+-------+-----------------------+--------------------+
+   |  XLAT Stage  | Loc.  |    Source Address     | Destination Addr.  |
+   +--------------+-------+-----------------------+--------------------+
+   | Initial      | Outer | 2001:db8::1234        | 64:ff9b::192.0.2.1 |
+   |              | Inner | 64:ff9b::192.0.2.1    | 2001:db8:bbbb::b   |
+   +--------------+-------+-----------------------+--------------------+
+   | Intermediate | Outer | 198.51.100.1          | 192.0.2.1          |
+   |              | Inner | 192.0.2.1             | 192.0.2.2          |
+   +--------------+-------+-----------------------+--------------------+
+   | Final        | Outer | 64:ff9b::198.51.100.1 | 2001:db8:aaaa::    |
+   |              | Inner | 2001:db8:aaaa::       | 64:ff9b::192.0.2.2 |
+   +--------------+-------+-----------------------+--------------------+
+
+         Figure 9: Hairpinning of a Router-Originated ICMPv6 Error
+
+   Figure 9 illustrates the hairpinning of an ICMPv6 error sent by an
+   arbitrary IPv6 router (2001:db8::1234) in response to the packet 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
+   inner IPv4 destination address to IPv6.
+
+    +--------------+-------+--------------------+--------------------+
+    |  XLAT Stage  | Loc.  |   Source Address   | Destination Addr.  |
+    +--------------+-------+--------------------+--------------------+
+    | Initial      | Outer | 2001:db8:bbbb::b   | 64:ff9b::192.0.2.1 |
+    |              | Inner | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b   |
+    +--------------+-------+--------------------+--------------------+
+    | Intermediate | Outer | 192.0.2.2          | 192.0.2.1          |
+    |              | Inner | 192.0.2.1          | 192.0.2.2          |
+    +--------------+-------+--------------------+--------------------+
+    | Final        | Outer | 64:ff9b::192.0.2.2 | 2001:db8:aaaa::    |
+    |              | Inner | 2001:db8:aaaa::    | 64:ff9b::192.0.2.2 |
+    +--------------+-------+--------------------+--------------------+
+
+         Figure 10: Hairpinning of a Host-Originated ICMPv6 Error
+
+   Figure 10 illustrates the hairpinning of an ICMPv6 error sent by the
+   original destination host itself in response to the packet in
+   Figure 8.  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 intermediate inner IPv4 destination address and the intermediate
+   outer IPv4 source address to IPv6.
+
+
+
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                   [Page 17]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+        +--------------+--------------------+---------------------+
+        |  XLAT Stage  |   Source Address   | Destination Address |
+        +--------------+--------------------+---------------------+
+        | Initial      | 2001:db8:bbbb::b   | 64:ff9b::192.0.2.1  |
+        +--------------+--------------------+---------------------+
+        | Intermediate | 192.0.2.2          | 192.0.2.1           |
+        +--------------+--------------------+---------------------+
+        | Final        | 64:ff9b::192.0.2.2 | 2001:db8:aaaa::     |
+        +--------------+--------------------+---------------------+
+
+             Figure 11: Hairpinning of Normal Response Packet
+
+   Figure 11 illustrates how the response from 2001:db8:bbbb::b to the
+   packet 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 disable the EAM algorithm when translating the intermediate IPv4
+   source address to IPv6.  The example is included in order to
+   illustrate how the addresses in the packet initially sent by
+   2001:db8:aaaa:: match those in the translated response packet sent by
+   2001:db8:bbbb::b, thus facilitating bidirectional communication.
+
+Acknowledgements
+
+   This document was conceived due to comments made by Dave Thaler in
+   the V6OPS session at IETF 91 as well as email discussions between
+   Fred Baker and the authors.
+
+   Valuable reviews, suggestions, and other feedback was given by Fred
+   Baker, Mohamed Boucadair, Cameron Byrne, Brian E.  Carpenter, Brian
+   Haberman, Ray Hunter, Alvaro Retana, Michael Richardson, Dan
+   Romascanu, Hemant Singh, and Andrew Yourtchenko.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                   [Page 18]
+
+RFC 7757             SIIT Explicit Address Mappings        February 2016
+
+
+Authors' Addresses
+
+   Tore Anderson
+   Redpill Linpro
+   Vitaminveien 1A
+   0485 Oslo
+   Norway
+
+   Phone: +47 959 31 212
+   Email: tore@redpill-linpro.com
+   URI:   http://www.redpill-linpro.com
+
+
+   Alberto Leiva Popper
+   NIC Mexico
+   Av. Eugenio Garza Sada 427 L4-6
+   Monterrey, Nuevo Leon  64840
+   Mexico
+
+   Email: ydahhrk@gmail.com
+   URI:   http://www.nicmexico.mx/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anderson & Leiva Popper      Standards Track                   [Page 19]
+