draft-ietf-v6ops-siit-dc-01.txt   draft-ietf-v6ops-siit-dc-02.txt 
IPv6 Operations T. Anderson IPv6 Operations T. Anderson
Internet-Draft Redpill Linpro Internet-Draft Redpill Linpro
Intended status: Informational June 28, 2015 Intended status: Informational August 11, 2015
Expires: December 30, 2015 Expires: February 12, 2016
SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments
draft-ietf-v6ops-siit-dc-01 draft-ietf-v6ops-siit-dc-02
Abstract Abstract
This document describes the use of the Stateless IP/ICMP Translation This document describes the use of the Stateless IP/ICMP Translation
(SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this
deployment model, traffic from legacy IPv4-only clients on the deployment model, traffic from legacy IPv4-only clients on the
Internet is translated to IPv6 when reaches the IDC operator's Internet is translated to IPv6 upon reaching the IDC operator's
network infrastructure. From that point on, it is treated just as if network infrastructure. From that point on, it may be treated the
it was traffic from any other IPv6-capable end user. This same as traffic from native IPv6 end users. The IPv6 endpoints may
facilitates a single-stack IPv6-only network infrastructure, as well be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses.
as efficient utilisation of public IPv4 addresses. This facilitates a single-stack IPv6-only network infrastructure, as
well as efficient utilisation of public IPv4 addresses.
The primary audience is IDC operators who are deploying IPv6, running The primary audience is IDC operators who are deploying IPv6, running
out of available IPv4 addresses, and/or feel that dual stack causes out of available IPv4 addresses, and/or feel that dual stack causes
undesirable operational complexity. undesirable operational complexity.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 30, 2015. This Internet-Draft will expire on February 12, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Single Stack IPv6 Operation . . . . . . . . . . . . . . . 3 1.1. Single Stack IPv6 Operation . . . . . . . . . . . . . . . 3
1.2. Stateless Operation . . . . . . . . . . . . . . . . . . . 4 1.2. Stateless Operation . . . . . . . . . . . . . . . . . . . 4
1.3. IPv4 Address Conservation . . . . . . . . . . . . . . . . 4 1.3. IPv4 Address Conservation . . . . . . . . . . . . . . . . 4
1.4. Clients' IPv4 Source Addresses Visible to Applications . 5 1.4. Clients' IPv4 Source Addresses Visible to Applications . 5
1.5. Compatible with Standard IPv4 and IPv6 Stacks . . . . . . 5 1.5. Compatible with Standard IPv4 and IPv6 Stacks . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 7 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 7
3.1. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9
4. Deployment Considerations and Guidelines . . . . . . . . . . 10 4. Deployment Considerations and Guidelines . . . . . . . . . . 10
4.1. Application/Device Support for IPv6 . . . . . . . . . . . 10 4.1. Application/Device Support for IPv6 . . . . . . . . . . . 10
4.2. Application Support for NAT . . . . . . . . . . . . . . . 10 4.2. Application Support for NAT . . . . . . . . . . . . . . . 10
4.3. Application Communication Pattern . . . . . . . . . . . . 10 4.3. Application Communication Pattern . . . . . . . . . . . . 10
4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 11 4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 11
4.5. Routing Considerations . . . . . . . . . . . . . . . . . 12 4.5. Routing Considerations . . . . . . . . . . . . . . . . . 12
4.6. Location of the SIIT-DC Border Relays . . . . . . . . . . 12 4.6. Location of the SIIT-DC Border Relays . . . . . . . . . . 12
4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 13 4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 13
skipping to change at page 14, line 45 skipping to change at page 14, line 45
translating an IPv4 packet with the Don't Fragment flag set to 0. translating an IPv4 packet with the Don't Fragment flag set to 0.
This happens even though the resulting IPv6 packet isn't actually This happens even though the resulting IPv6 packet isn't actually
fragmented into several pieces, resulting in an IPv6 Atomic Fragment fragmented into several pieces, resulting in an IPv6 Atomic Fragment
[RFC6946]. These Atomic Fragments are generally not useful in an IDC [RFC6946]. These Atomic Fragments are generally not useful in an IDC
environment, and it is therefore recommended that this behaviour is environment, and it is therefore recommended that this behaviour is
disabled in the BRs. To this end, Section 4 of RFC6145 [RFC6145] disabled in the BRs. To this end, Section 4 of RFC6145 [RFC6145]
notes that the "translator MAY provide a configuration function that notes that the "translator MAY provide a configuration function that
allows the translator not to include the Fragment Header for the non- allows the translator not to include the Fragment Header for the non-
fragmented IPv6 packets". fragmented IPv6 packets".
Note that [I-D.ietf-6man-deprecate-atomfrag-generation] seeks to Note that IPv6 Atomic Fragments are currently being deprecated by
update [RFC6145], making the functionality described above as the RFC6145bis [I-D.bao-v6ops-rfc6145bis]. As a result, a BR that
standard and only mode of operation. conforms to the updated standard is required to behave as recommended
above.
In IPv6, the Identification value is located inside the Fragmentation In IPv6, the Identification value is located inside the Fragmentation
header. That means that if the generation of IPv6 Atomic Fragments header. That means that if the generation of IPv6 Atomic Fragments
is disabled, the IPv4 Identification value will be lost during is disabled, the IPv4 Identification value will be lost during
translation to IPv6. This could potentially confuse some diagnostic translation to IPv6. This could potentially confuse some diagnostic
tools. tools.
4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6 4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6
Section 5 of RFC2460 [RFC2460] specifies that the minimum IPv6 link Section 5 of RFC2460 [RFC2460] specifies that the minimum IPv6 link
skipping to change at page 16, line 27 skipping to change at page 16, line 24
the Don't Fragment flag in the resulting IPv4 packet will be set the Don't Fragment flag in the resulting IPv4 packet will be set
to 0. This ensures that in the eventuality that the path contains to 0. This ensures that in the eventuality that the path contains
an IPv4 link with an MTU smaller than 1260, the IPv4 router an IPv4 link with an MTU smaller than 1260, the IPv4 router
connected to that link will have the responsibility to fragment connected to that link will have the responsibility to fragment
the packet before forwarding it towards its destination. the packet before forwarding it towards its destination.
In summary, this approach could be seen as prompting the IPv4 In summary, this approach could be seen as prompting the IPv4
protocol itself to provide the "link-specific fragmentation and protocol itself to provide the "link-specific fragmentation and
reassembly at a layer below IPv6" required for links that "cannot reassembly at a layer below IPv6" required for links that "cannot
convey a 1280-octet packet in one piece", to paraphrase Section 5 of convey a 1280-octet packet in one piece", to paraphrase Section 5 of
RFC2460 [RFC2460]. Note that RFC2460 [RFC2460].
[I-D.ietf-6man-deprecate-atomfrag-generation] seeks to update
[RFC6145], making the approach described above as the standard and Note that IPv6 Atomic Fragments are currently being deprecated by
only mode of operation. RFC6145bis [I-D.bao-v6ops-rfc6145bis]. As a result, a BR that
conforms to the updated standard is required to behave as suggested
above.
4.10. IPv4-translatable IPv6 Service Addresses 4.10. IPv4-translatable IPv6 Service Addresses
SIIT-DC is designed so that the IPv6 Service Addresses are not SIIT-DC is designed so that the IPv6 Service Addresses are not
required to be IPv4-translatable IPv6 addresses. Section 2 of I-D required to be IPv4-translatable IPv6 addresses. Section 2 of I-D
.ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam] discusses why it is .ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam] discusses why it is
desirable to avoid requiring the use of IPv4-translatable IPv6 desirable to avoid requiring the use of IPv4-translatable IPv6
addresses. addresses.
It is however quite possible to deploy SIIT-DC in combination with It is however quite possible to deploy SIIT-DC in combination with
skipping to change at page 17, line 51 skipping to change at page 17, line 51
Translation Prefix that is distinct from and not a subset of the IPv6 Translation Prefix that is distinct from and not a subset of the IPv6
prefixes used elsewhere in the network infrastructure. prefixes used elsewhere in the network infrastructure.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-v6ops-siit-eam] [I-D.ietf-v6ops-siit-eam]
Anderson, T. and A. Leiva, "Explicit Address Mappings for Anderson, T. and A. Leiva, "Explicit Address Mappings for
Stateless IP/ICMP Translation", draft-ietf-v6ops-siit- Stateless IP/ICMP Translation", draft-ietf-v6ops-siit-
eam-00 (work in progress), May 2015. eam-01 (work in progress), June 2015.
[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>.
[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>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-6man-deprecate-atomfrag-generation] [I-D.bao-v6ops-rfc6145bis]
Gont, F., LIU, S., and T. Anderson, "Deprecating the Li, X., Bao, C., Baker, F., Anderson, T., and F. Gont, "IP
Generation of IPv6 Atomic Fragments", draft-ietf-6man- /ICMP Translation Algorithm (rfc6145bis)", draft-bao-
deprecate-atomfrag-generation-01 (work in progress), April v6ops-rfc6145bis-01 (work in progress), August 2015.
2015.
[I-D.ietf-v6ops-siit-dc-2xlat] [I-D.ietf-v6ops-siit-dc-2xlat]
Anderson, T., "SIIT-DC: Dual Translation Mode", draft- Anderson, T. and S. Steffann, "SIIT-DC: Dual Translation
ietf-v6ops-siit-dc-2xlat-00 (work in progress), January Mode", draft-ietf-v6ops-siit-dc-2xlat-01 (work in
2015. progress), June 2015.
[I-D.taylor-v6ops-fragdrop] [I-D.taylor-v6ops-fragdrop]
Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", draft-taylor-v6ops-fragdrop-02 (work in What It Implies", draft-taylor-v6ops-fragdrop-02 (work in
progress), December 2013. progress), December 2013.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI
1981. 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, October 1985. 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<http://www.rfc-editor.org/info/rfc959>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations", RFC
2663, August 1999. 2663, DOI 10.17487/RFC2663, August 1999,
<http://www.rfc-editor.org/info/rfc2663>.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991, November 2000. Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/
RFC2991, November 2000,
<http://www.rfc-editor.org/info/rfc2991>.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. DOI 10.17487/RFC2993, November 2000,
<http://www.rfc-editor.org/info/rfc2993>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January Address Translator (Traditional NAT)", RFC 3022, DOI
2001. 10.17487/RFC3022, January 2001,
<http://www.rfc-editor.org/info/rfc3022>.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002. Application Design Guidelines", RFC 3235, DOI 10.17487/
RFC3235, January 2002,
<http://www.rfc-editor.org/info/rfc3235>.
[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>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011. DOI 10.17487/RFC6147, April 2011,
<http://www.rfc-editor.org/info/rfc6147>.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for All IP-Capable Nodes", BCP 177, "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
RFC 6540, April 2012. RFC 6540, DOI 10.17487/RFC6540, April 2012,
<http://www.rfc-editor.org/info/rfc6540>.
[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>.
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content Providers and Application Service Providers", RFC Content Providers and Application Service Providers", RFC
6883, March 2013. 6883, DOI 10.17487/RFC6883, March 2013,
<http://www.rfc-editor.org/info/rfc6883>.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
6946, May 2013. 6946, DOI 10.17487/RFC6946, May 2013,
<http://www.rfc-editor.org/info/rfc6946>.
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
Internet Numbers Registry System", RFC 7020, August 2013. Internet Numbers Registry System", RFC 7020, DOI 10.17487/
RFC7020, August 2013,
<http://www.rfc-editor.org/info/rfc7020>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June Protocol (HTTP/1.1): Message Syntax and Routing", RFC
2014. 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
Appendix A. Complete SIIT-DC IDC topology example Appendix A. Complete SIIT-DC IDC topology example
Figure 4 attempts to "tie it all together" and show a more complete Figure 4 attempts to "tie it all together" and show a more complete
SIIT-DC topology, in order to better demonstrate its advantageous SIIT-DC topology, in order to better demonstrate its advantageous
properties discussed in Section 1. These are discussed in more properties discussed in Section 1. These are discussed in more
detail below. detail below.
Example SIIT-DC IDC topology Example SIIT-DC IDC topology
 End of changes. 34 change blocks. 
54 lines changed or deleted 84 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/