draft-ietf-v6ops-siit-eam-01.txt   draft-ietf-v6ops-siit-eam-02.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: January 01, 2016 June 30, 2015 Expires: April 14, 2016 October 12, 2015
Explicit Address Mappings for Stateless IP/ICMP Translation Explicit Address Mappings for Stateless IP/ICMP Translation
draft-ietf-v6ops-siit-eam-01 draft-ietf-v6ops-siit-eam-02
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 January 01, 2016. This Internet-Draft will expire on April 14, 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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . 5 3. Explicit Address Mapping Algorithm . . . . . . . . . . . . . 5
3.1. Explicit Address Mapping Table . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . 6 3.3. IP Address Translation Procedure . . . . . . . . . . . . 7
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 . . . . . . . 7 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 . . . . . . . . . . . . 9 4.2.2. Intrinsic Hairpinning Support . . . . . . . . . . . . 9
5. Overlapping Explicit Address Mappings . . . . . . . . . . . . 10 5. Overlapping Explicit Address Mappings . . . . . . . . . . . . 10
6. Lack of Checksum Neutrality . . . . . . . . . . . . . . . . . 11 6. Lack of Checksum Neutrality . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 13
A.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2. IVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.2. IVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.3. SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.3. SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Example IP Address Translations . . . . . . . . . . 15 Appendix B. Example IP Address Translations . . . . . . . . . . 15
B.1. Hairpinning Examples . . . . . . . . . . . . . . . . . . 15 B.1. Hairpinning Examples . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 Translation using the Explicit Address Mapping Table does not replace
most use cases, it is expected that both algorithms are used in [RFC6052]. For most use cases, it is expected that both algorithms
concert. The Explicit Address Mapping algorithm is used only when a are used in concert. The Explicit Address Mapping algorithm is used
mapping matching the address to be translated exists. If no matching only when a mapping matching the address to be translated exists. If
mapping exists, the [RFC6052] algorithm will be used instead. Thus, no matching mapping exists, the [RFC6052] algorithm will be used
when translating an individual IP packet, an SIIT implementation instead. Thus, when translating an individual IP packet, an SIIT
might translate one of the two IP address fields according to an EAM, implementation might translate one of the two IP address fields
while the other IP address field is translated according to according to an EAM, while the other IP address field is translated
[RFC6052]. according to [RFC6052].
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.
skipping to change at page 4, line 39 skipping to change at page 4, line 39
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
assign IPv4-translatable IPv6 addresses as secondary addresses on the assign IPv4-translatable IPv6 addresses as secondary addresses on the
nodes that want to communicate with IPv4 nodes through SIIT only. nodes that want to communicate with IPv4 nodes through SIIT only.
However, doing so may result in a new set of undesired properties: However, doing so may result in a new set of undesired consequences:
Routing complexity: Routing complexity:
The IPv4-translatable IPv6 addresses must be routed throughout the The IPv4-translatable IPv6 addresses must be routed throughout the
IPv6 network separately from the primary (non-IPv4-translatable) IPv6 network separately from the primary (non-IPv4-translatable)
IPv6 addresses used by the nodes. It might be impossible to IPv6 addresses used by the nodes. It might be impossible to
aggregate these routes, as two adjacent IPv4-translatable IPv6 aggregate these routes, as two adjacent IPv4-translatable IPv6
addresses might not be assigned to two adjacent IPv6 nodes. As a addresses might not be assigned to two adjacent IPv6 nodes. As a
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
skipping to change at page 6, line 43 skipping to change at page 6, line 43
| 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.
When translating a packet between IPv4 and IPv6, an SIIT Unless otherwise specified in Section 4, an SIIT implementation MUST
implementation MUST individually translate each IP address it individually translate each IP address it encounters in the packet's
encounters in the packet's IP headers (including any IP headers IP headers (including any IP headers contained within ICMP errors)
contained within ICMP errors) according to Section 3.3. See according to Section 3.3.
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.
skipping to change at page 9, line 40 skipping to change at page 9, line 45
outer 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: MUST behave as follows when receiving an IPv6 packet:
If all the conditions in either of the two sets below is true, the If all the conditions in either of the two sets below is true, the
packet is to be hairpinned. The implementation MUST immediately packet is to be hairpinned. The implementation MUST immediately
(i.e., prior to forwarding it to the IPv4 network) translate the (i.e., prior to forwarding it to the IPv4 network) translate the
packet back to IPv6. During the second translation pass, the packet back to IPv6. During the second translation pass, the
behaviour specified in Section 4.2.1 MUST be applied, and the Hop behaviour specified in Section 4.2.1 MUST be applied, and the Hop
Limit field SHOULD NOT be decremented. Limit field SHOULD NOT be decremented.
Condition set A: Condition set A:
skipping to change at page 12, line 7 skipping to change at page 11, line 48
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].
7. 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].
8. 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.
this section prior to publication.
9. 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 Fred Valuable reviews, suggestions, and other feedback was given by Fred
Baker, Mohamed Boucadair, Cameron Byrne, Brian E Carpenter, Ray Baker, Mohamed Boucadair, Cameron Byrne, Brian E Carpenter, Ray
Hunter, Michael Richardson, Hemant Singh, and Andrew Yourtchenko. Hunter, Michael Richardson, Dan Romascanu, Hemant Singh, and Andrew
Yourtchenko.
10. References 10. References
10.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, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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. DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>.
[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, DOI 10.17487/RFC6145, April 2011,
<http://www.rfc-editor.org/info/rfc6145>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-v6ops-siit-dc] [I-D.ietf-v6ops-siit-dc]
Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
IPv6 Data Centre Environments", draft-ietf-v6ops-siit- IPv6 Data Centre Environments", draft-ietf-v6ops-siit-
dc-01 (work in progress), June 2015. dc-02 (work in progress), August 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, DOI 10.17487/
RFC4213, October 2005,
<http://www.rfc-editor.org/info/rfc4213>.
[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, 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 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011. 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 [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, DOI 10.17487/
RFC6219, May 2011,
<http://www.rfc-editor.org/info/rfc6219>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[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, DOI 10.17487/RFC6791, November 2012,
<http://www.rfc-editor.org/info/rfc6791>.
[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, DOI 10.17487/RFC6877, April 2013,
<http://www.rfc-editor.org/info/rfc6877>.
[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, DOI
August 2014. 10.17487/RFC7335, August 2014,
<http://www.rfc-editor.org/info/rfc7335>.
Appendix A. Use Cases Appendix A. Use Cases
The following subsections lists some use cases that at the time of The following subsections lists some use cases that at the time of
writing leverage SIIT with the EAM algorithm. writing leverage SIIT with the EAM algorithm.
A.1. 464XLAT A.1. 464XLAT
When the CLAT component in the 464XLAT [RFC6877] architecture does When the CLAT component in the 464XLAT [RFC6877] architecture does
not have a dedicated IPv6 prefix assigned, it may instead use "one not have a dedicated IPv6 prefix assigned, it may instead use "one
 End of changes. 26 change blocks. 
41 lines changed or deleted 54 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/