--- 1/draft-ietf-v6ops-siit-dc-2xlat-01.txt 2015-10-12 06:15:03.967400759 -0700 +++ 2/draft-ietf-v6ops-siit-dc-2xlat-02.txt 2015-10-12 06:15:04.003401635 -0700 @@ -1,19 +1,19 @@ IPv6 Operations T. Anderson Internet-Draft Redpill Linpro Intended status: Informational S. Steffann -Expires: December 30, 2015 S.J.M. Steffann Consultancy - June 28, 2015 +Expires: April 14, 2016 S.J.M. Steffann Consultancy + October 12, 2015 SIIT-DC: Dual Translation Mode - draft-ietf-v6ops-siit-dc-2xlat-01 + draft-ietf-v6ops-siit-dc-2xlat-02 Abstract This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Centre Environments architecture (SIIT-DC), which allows applications, protocols, or nodes that are incompatible with IPv6, and/or Network Address Translation to operate correctly in an SIIT-DC environment. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 April 14, 2016. Copyright Notice Copyright (c) 2015 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 @@ -54,39 +54,38 @@ 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 4 3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 5 - 3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 6 - 3.2.1. Edge Router "On A Stick" . . . . . . . . . . . . . . 7 - 3.2.2. Edge Router that Bridges IPv6 Packets . . . . . . . . 8 + 3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 7 + 3.2.1. Edge Router "On A Stick" . . . . . . . . . . . . . . 8 + 3.2.2. Edge Router that Bridges IPv6 Packets . . . . . . . . 9 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9 4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10 5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10 5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 10 5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 8.1. Address Spoofing . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 15 - A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 15 + A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 16 A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where IPv4-only users can access IPv6-only services through a stateless translator called an SIIT-DC Border Relay (BR). This approach has certain limitations, however. In particular, the following cases will work poorly or not at all: @@ -114,45 +113,48 @@ translations and forward them to the IPv4 client. The node or application is thus provided with "virtual" IPv4 Internet connectivity that retains end-to-end transparency for the IPv4 addresses. 2. Terminology This document makes use of the following terms: SIIT-DC Border Relay (BR) - A device or a logical function that translates traffic between - IPv4 clients and IPv6 services. See [I-D.ietf-v6ops-siit-dc]. + A device or a logical function that performs stateless protocol + translation between IPv4 and IPv6. It MUST do so in accordance + with [RFC6145] and [I-D.ietf-v6ops-siit-eam]. SIIT-DC Edge Relay (ER) A device or logical function that provides "native" IPv4 - connectivity to IPv4-only nodes or applications. It functions in - the same way as a BR, but is located close to the IPv4-only nodes/ - applications it is supporting rather than on the network border. + connectivity to IPv4-only devices or application software. It is + very similar in function to a BR, but is typically located close + to the IPv4-only component(s) it is supporting rather than on the + IDC's outer network border. An ER may be either Node-Based + (Section 3.1) or Network-Based (Section 3.2). IPv4 Service Address - An IPv4 address representing an IPv6 service, with which IPv4-only - clients communicates. It is coupled with an IPv6 Service Address - using an EAM. Packets sent to this address is translated to IPv6 - by the BR and possibly back to IPv4 again by the ER, and vice - versa in the opposite direction. + An IPv4 address representing a node or service located in an IPv6 + network. It is coupled with an IPv6 Service Address using an EAM. + Packets sent to this address is translated to IPv6 by the BR, and + possibly back to IPv4 by an ER, before reaching the node or + service. IPv6 Service Address An IPv6 address assigned to an application, node, or service; either directly or indirectly (through an ER). It is coupled with an IPv4 Service Address using an EAM. IPv4-only clients communicates with the IPv6 Service Address through SIIT-DC. Explicit Address Mapping (EAM) A bi-directional coupling between an IPv4 Service Address and an - IPv6 Service Address configured in an BR/ER. When translating + IPv6 Service Address configured in a BR or ER. When translating between IPv4 and IPv6, the BR/ER changes the address fields in the translated packet's IP header according to any matching EAM. The EAM algorithm is specified in [I-D.ietf-v6ops-siit-eam]. Translation Prefix An IPv6 prefix into which the entire IPv4 address space is mapped, according to the algorithm in [RFC6052]. The Translation Prefix is routed to the BR's IPv6 interface. When translating between IPv4 and IPv6, an BR/ER will insert/remove the Translation Prefix into/from the address fields in the translated packet's IP header, @@ -390,25 +391,25 @@ Discovery [RFC4861] messages for them) and routed through the translation function before being forwarded out its downstream interface as IPv4 packets. The downstream network segment thus becomes dual-stacked. 4. Deployment Considerations 4.1. IPv6 Path MTU The IPv6 Path MTU between the ER and the BR will typically be larger - than the default value defined in Section 4 of [RFC6145] (1280), as - it will typically contained within a single administrative domain. - Therefore, it is RECOMMENDED that the IPv6 Path MTU configured in the - ER is raised accordingly. It is RECOMMENDED that the ER and the BR - use identical configured IPv6 Path MTU values. + than the default value defined in Section 4 of [RFC6145] (1280 + bytes), as it will typically contained within a single administrative + domain. Therefore, it is RECOMMENDED that the IPv6 Path MTU + configured in the ER is raised accordingly. It is RECOMMENDED that + the ER and the BR use identical configured IPv6 Path MTU values. 4.2. IPv4 MTU In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the IPv4 MTU used by applications or nodes is equal to the configured IPv6 Path MTU - 20, so that an maximum-sized IPv4 packet can fit in an unfragmented IPv6 packet. This ensures that the application may do its part in avoiding IP-level fragmentation from occurring, e.g., by segmenting/fragmenting outbound packets at the application layer, and advertising the maximum size its peer may use for inbound packets @@ -442,25 +443,25 @@ Although SIIT-DC is primarily intended to facilitate communication between IPv4-only nodes on the Internet and services located in an IPv6-only IDC network, an IPv4-only node or application located behind an ER might need to communicate with other nodes or services in the IDC. The IPv4-only node or application will need to so through the ER, as it will typically be incapable to contact IPv6 destinations directly. The following subsections discusses various methods on how to facilitate such communication. 5.1. Hairpinning by the SIIT-DC Border Relay - If the BR supports hairpinning as described in Section 4.2 of I-D - .ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam], the easiest solution - is to make the target service available through SIIT-DC in the normal - way, that is, by provisioning an EAM to the BR that assigns an IPv4 - Service Address with the target service's IPv6 Service Address. + If the BR supports hairpinning as described in Section 4.2 of + [I-D.ietf-v6ops-siit-eam], the easiest solution is to make the target + service available through SIIT-DC in the normal way, that is, by + provisioning an EAM to the BR that assigns an IPv4 Service Address + with the target service's IPv6 Service Address. This allows the IPv4-only node or application to transmit packets destined for the target service's IPv4 Service Address, which the ER will then translate to a corresponding IPv4-converted IPv6 address by inserting the Translation Prefix [RFC6052]. When this IPv6 packet reaches the BR, it will be hairpinned and transmitted back to the target service's IPv6 Service Address (where it could possibly pass through another ER before reaching the target service). Return traffic from the target service will be hairpinned in the same fashion. @@ -564,36 +565,34 @@ 6. Acknowledgements The author would like to especially thank the authors of 464XLAT [RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne. The architecture described by this document is merely an adaptation of their work to a data centre environment, and could not have happened without them. The author would like also to thank the following individuals for their contributions, suggestions, corrections, and criticisms: Fred - Baker, Tobias Brox, Ray Hunter, Shucheng LIU (Will), Andrew - Yourtchenko. + Baker, Tobias Brox, Olafur Gudmundsson, Christer Holmberg, Ray + Hunter, Shucheng LIU (Will), Andrew Yourtchenko. 7. IANA Considerations - This draft makes no request of the IANA. The RFC Editor may remove - this section prior to publication. + This draft makes no request of the IANA. 8. Security Considerations This section discusses security considerations specific to the use of an ER. See the Security Considerations section in - [I-D.ietf-v6ops-siit-dc] for additional security considerations - applicable to the SIIT-DC architecture in general. + [I-D.ietf-v6ops-siit-dc] for security considerations applicable to + the SIIT-DC architecture in general. -8.1. Address Spoofing If the ER receives an IPv4 packet from the application/node from a source address it does not have an EAM for, both the source and destination addresses will be rewritten according to [RFC6052]. After undergoing the reverse translation in the BR, the resulting IPv4 packet routed to the IPv4 network will have a spoofed IPv4 source address. The ER SHOULD therefore ensure that ingress filtering [RFC2827] is used on the ER's IPv4 interface, so that such packets are immediately discarded. If the ER receives an IPv6 packet with both the source and @@ -607,79 +606,94 @@ IPv6 Service Addresses, or 2) after translation from IPv6 to IPv4, equal to any of its local IPv4 Service Addresses. 9. References 9.1. Normative References [I-D.ietf-v6ops-siit-dc] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments", draft-ietf-v6ops-siit- - dc-00 (work in progress), December 2014. + dc-02 (work in progress), August 2015. [I-D.ietf-v6ops-siit-eam] Anderson, T. and A. Leiva, "Explicit Address Mappings for 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 - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ + RFC2119, March 1997, + . 9.2. Informative References [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or - converting network protocol addresses to 48.bit Ethernet - address for transmission on Ethernet hardware", STD 37, - RFC 826, November 1982. + Converting Network Protocol Addresses to 48.bit Ethernet + Address for Transmission on Ethernet Hardware", STD 37, + RFC 826, DOI 10.17487/RFC0826, November 1982, + . - [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and - E. Lear, "Address Allocation for Private Internets", BCP - 5, RFC 1918, February 1996. + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, + . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC - 2131, March 1997. + 2131, DOI 10.17487/RFC2131, March 1997, + . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, March 1997. + Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, + . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source - Address Spoofing", BCP 38, RFC 2827, May 2000. + Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, + May 2000, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, - September 2007. + DOI 10.17487/RFC4861, September 2007, + . [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, - October 2010. + DOI 10.17487/RFC6052, October 2010, + . [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, + . [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts - Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. + Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/ + RFC6535, February 2012, + . - [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 - (IPv6)", RFC 6724, September 2012. + (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, + . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC - 6877, April 2013. + 6877, DOI 10.17487/RFC6877, April 2013, + . - [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, - August 2014. + [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, DOI + 10.17487/RFC7335, August 2014, + . Appendix A. Examples: Network-Based IPv4 Connectivity - A.1. Subnet with IPv4 Service Addresses + One relatively straight-forward way to provide IPv4 connectivity between the ER and the IPv4 node(s) it serves is to ensure the IPv4 Service Address(es) can be enclosed within a larger IPv4 prefix. The ER may then claim one address in this prefix for itself, and use it to provide an IPv4 default router address. The ER may then proceed to assign the IPv4 Service Address(es) to its downstream node(s) using DHCPv4 [RFC2131]. For example, if the IPv4 Service Addresses are 192.0.2.26 and 192.0.2.27, the ER would configure the address 192.0.2.25/29 on its IPv4-facing interface and would add the two IPv4 Service Addresses to its DHCPv4 pool.