draft-ietf-v6ops-siit-eam-02.txt   draft-ietf-v6ops-siit-eam-03.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: April 14, 2016 October 12, 2015 Expires: April 22, 2016 October 20, 2015
Explicit Address Mappings for Stateless IP/ICMP Translation Explicit Address Mappings for Stateless IP/ICMP Translation
draft-ietf-v6ops-siit-eam-02 draft-ietf-v6ops-siit-eam-03
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 April 14, 2016. This Internet-Draft will expire on April 22, 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 5, line 42 skipping to change at page 5, line 42
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, and formally
implementations MUST support the specifications herein. updates Section 4.1 and Section 5.1 of [RFC6145]. Specifically, when
the EAM algorithm is applied, it supplants [RFC6145]'s requirement
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 3.1. Explicit Address Mapping Table
An SIIT implementation includes an EAMT, a conceptual table in which
An SIIT implementation MUST include an Explicit Address Mapping Table each row represents an EAM. Each EAM describes a mapping between
(EAMT). By default, the EAMT SHOULD be empty. The operator MUST be IPv4 and IPv6 prefixes/addresses. An operator populates the EAMT to
able to populate the EAMT using the implementation's normal provide the mappings between the two address families.
configuration interfaces. The implementation MAY additionally
support other ways of populating the EAMT.
The EAMT consists of the following columns: The EAMT consists of the following columns:
o IPv4 Prefix o IPv4 Prefix
o IPv6 Prefix o IPv6 Prefix
SIIT implementations MAY include other columns in order to support SIIT implementations MAY include other columns in order to support
proprietary extensions to the EAM algorithm. proprietary extensions to the EAM algorithm.
skipping to change at page 7, line 10 skipping to change at page 7, line 10
Unless otherwise specified in Section 4, an SIIT implementation MUST Unless otherwise specified in Section 4, an SIIT implementation MUST
individually translate each IP address it encounters in the packet's individually translate each IP address it encounters in the packet's
IP headers (including any IP headers contained within ICMP errors) IP headers (including any IP headers contained within ICMP errors)
according to Section 3.3. according to Section 3.3.
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 IPv4 Prefix column of the EAMT is searched for the EAM entry 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 that shares the longest common prefix with the IPv4 address being
skipping to change at page 9, line 20 skipping to change at page 9, line 20
4.2. Recommendation 4.2. Recommendation
An SIIT implementation SHOULD include a feature that ensures that An SIIT implementation SHOULD include a feature that ensures that
hairpinned IPv6 traffic is supported. The feature SHOULD be enabled hairpinned IPv6 traffic is supported. The feature SHOULD be enabled
by default. The following two subsections describe two alternate by default. The following two subsections describe two alternate
ways to implement this feature. An implementation MAY support both ways to implement this feature. An implementation MAY support both
approaches. approaches.
4.2.1. Simple Hairpinning Support 4.2.1. Simple Hairpinning Support
When the simple hairpinning feature is enabled, the translator MUST When the simple hairpinning feature is enabled, the translator
behave according to the following rules when translating from IPv4 to employs the following rules when translating from IPv4 to IPv6:
IPv6:
1. If the packet is not an ICMPv4 error: The EAM algorithm MUST NOT 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 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
skipping to change at page 9, line 45 skipping to change at page 9, line 44
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
MUST behave as follows when receiving an IPv6 packet: employs the following rules 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 9 skipping to change at page 12, line 9
8. IANA Considerations 8. IANA Considerations
This draft makes no request of the IANA. This draft makes no request of the IANA.
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, Brian
Hunter, Michael Richardson, Dan Romascanu, Hemant Singh, and Andrew Haberman, Ray Hunter, Alvaro Retana, Michael Richardson, Dan
Yourtchenko. 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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 12, line 36 skipping to change at page 12, line 36
[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, DOI 10.17487/RFC6145, April 2011, Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
<http://www.rfc-editor.org/info/rfc6145>. <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-02 (work in progress), August 2015. dc-03 (work in progress), October 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, DOI 10.17487/ for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/
RFC4213, October 2005, RFC4213, October 2005,
<http://www.rfc-editor.org/info/rfc4213>. <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, DOI 10.17487/ Address Autoconfiguration", RFC 4862, DOI 10.17487/
RFC4862, September 2007, RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <http://www.rfc-editor.org/info/rfc4862>.
 End of changes. 10 change blocks. 
20 lines changed or deleted 21 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/