Softwire Working Group Y. Lee Internet-Draft Comcast Intended status: Informational October 18, 2009 Expires: April 21, 2010 UDP Encapsulation of 6rd draft-lee-softwire-6rd-udp-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 21, 2010. Copyright Notice Copyright (c) 2009 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 Lee Expires April 21, 2010 [Page 1] Internet-Draft 6RD Over UDP October 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo specifies the UDP encapsulation to IPv6 Rapid Deployment (6rd) protocol [I-D.ietf-softwire-ipv6-6rd] which enables hosts behind unmodified Home Gateway device to access 6rd service. Requirements Language 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 RFC 2119 [RFC2119]. Lee Expires April 21, 2010 [Page 2] Internet-Draft 6RD Over UDP October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. 6rd Host . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Home Gateway . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. 6rd Prefix . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. 6rd Border Router . . . . . . . . . . . . . . . . . . . . 6 3.5. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6.1. Host Model . . . . . . . . . . . . . . . . . . . . . . 7 3.6.2. Server Model . . . . . . . . . . . . . . . . . . . . . 8 4. 6rd Prefix UDP Encapsulation . . . . . . . . . . . . . . . . . 9 4.1. UDP-Encapsulated 6rd Header . . . . . . . . . . . . . . . 9 5. 6rd Border Router Discovery . . . . . . . . . . . . . . . . . 10 5.1. Manual Discovery . . . . . . . . . . . . . . . . . . . . . 10 5.2. Automatic Discovery . . . . . . . . . . . . . . . . . . . 10 6. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Comparison to the Classic 6rd . . . . . . . . . . . . . . . . 10 7.1. Outside Initiated Traffic . . . . . . . . . . . . . . . . 11 7.2. Stateless vs. Stateful 6rd Border Router . . . . . . . . . 11 7.3. 6rd Prefix . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Comparison to Softwire Hub-and-Spoke and Teredo . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Lee Expires April 21, 2010 [Page 3] Internet-Draft 6RD Over UDP October 2009 1. Introduction 6rd protocol [I-D.ietf-softwire-ipv6-6rd] enables service providers to rapidly deploy IPv6 over IPv4 network. In [I-D.despres-6rd], it describes the 6rd architecture to enable a service provider to deploy IPv6 connectivity on an IPv4 network for 1.5 million residential customers. The architecture involves two major components: (1) the 6rd relays (6rd Border Router) in the ISP network and (2) 6rd CPE (6rd CE) in the customer premise. The 6rd CE in the customer home is a NAT [RFC3022] device which shares a single Subscribe IPv4 address [I-D.ietf-softwire-ipv6-6rd] to multiple internal IPv4 hosts. Note that the subscriber IPv4 address can be either public or private. If private address is used, the ISP will provide NAT function in the provider network. Details is described in [I-D.despres-6rd] Section 4. The 6rd CE is also an IPv6 router which advertises an IPv6 prefix (6rd Prefix) to the internal IPv6 hosts. The 6rd Prefix consists of two part: the 6rd SP Prefix and the Subscriber IPv4 address. The 6rd CE learns the 6rd SP Prefix from DHCP [I-D.ietf-softwire-ipv6-6rd] and appends the Subscriber IPv4 address to form the 6rd Prefix. Then, the 6rd CE advertises the 6rd Prefix to the customer's home network via Router Advertisement [RFC4861]. This architecture fits well to those ISPs who manage the customers' Home Gateways (HGW). When the ISP is ready to deploy the 6rd, a new firmware which contains the 6rd CE implementation will be pushed to the managed HGW. For the ISPs who don't manage the customers' HWGs, they can't upgrade the customer's HWGs to support 6rd. This memo specific a UDP encapsulation to encapsulate 6rd over UDP which enables ISP to deploy 6rd to hosts behind unmodified HWG. There are two scenarios in which the ISP can use this specification. 1. First deployment scenario is the O/S in the host implements this specification. When the host sends an IPv6 datagram, it first encapsulates the IPv6 datagram in an IPv4 header following the procedure defined in [I-D.despres-6rd]. Then, it encapsulates the IPv4 datagram with a standard UDP header [RFC0768] Details of the UDP encapsulation is described in Section 4. 2. Second deployment scenario is a dedicated server implements this specification. The server is connected to the unmodified HGW's LAN interface. Once the server establishes IPv4 connectivity, it will initiate the 6rd discovery procedure and construct the 6rd Prefix. Finally, it advertises the 6rd Prefix via Router Advertisement to the HGW LAN so that IPv6 datagram will use the server as a gateway to establish IPv6 sessions. This enables the IPv6 hosts connecting to the HGW's LAN to enjoy 6rd service Lee Expires April 21, 2010 [Page 4] Internet-Draft 6RD Over UDP October 2009 without additional configuration. 2. Terminology This documents users terms defined in [I-D.ietf-softwire-ipv6-6rd]. In addition, we defines the following new terms: o HGW: is referred to the edge device installed in customer home. It typically provides NAT function to the home equipments. The HGW in this context is unaware of 6rd. o 6rd BR-Id: is referred to the identifier embedded in the 6rd SP Prefix. This field is ranged from 8-bit to 16-bit appears right after the 6rd SP Prefix. Each 6rd BR is assigned a unique 6rd BR-ID. o 6rd SP-BR Prefix: is formed by concatenating 6rd SP prefix and 6rd BR-Id. The 6rd host uses the 6rd SP-BR and the Subscriber IPv4 Address to form the 6rd Prefix. o Internal IPv4 address: is referred to the private IPv4 address assigned by the HGW to the host. This address is a [RFC1918] address. 3. Overview 3.1. 6rd Host Before the host can use 6rd, it needs to discover three pieces of information: the 6rd SP-BR Prefix, the Subscriber IPv4 address, and the 6rd BR IPv4 address. The host concatenates the 6rd SP-BR Prefix and the Subscriber IPv4 address to form the 6rd Prefix. When the 6rd host wants to initiate an IPv6 session to an outside IPv6 host, the first encapsulates is to encapsulate the IPv6 datagram with an IPv4 header. The IPv4 header source address will be the internal IPv4 address assigned by the HGW. The destination address will be the 6rd BR's IPv4 address. The second encapsulate is to encapsulate the IPv4 datagram in a UDP header. The UDP source port is any available UDP port; the destination port is an IANA defined port. The host implemented this specification is provisioned with the IPv4 address of the 6rd BR. Section 5 contains more discussion of the 6rd BR discovery process. Lee Expires April 21, 2010 [Page 5] Internet-Draft 6RD Over UDP October 2009 3.2. Home Gateway The HGW in this specification is a typical HGW found in retailed stores. In the WAN side, it connects to the ISP and runs DHCP client. The ISP offers an IPv4 address, a default gateway, and list of DNS servers to the HGW. In the LAN side, it runs DHCP server and offers [RFC1918] address to the hosts on the LAN. The HGW provides standard NAT [RFC3022] functions to allow multiple hosts to share a single Subscriber IPv4 address. When a host connects to the HGW, the host requests the Internal IPv4 address and the Internal IPv4 Gateway via DHCP. The HGW is not aware of the 6rd service. 3.3. 6rd Prefix In order to construct the 6rd Prefix, the host must discover the 6rd SP-BR Prefix and the Subscriber IPv4 address assigned to the HGW. More discussion of discovering 6rd SP-BR Prefix can be found in Section 5. How to discover the Subscriber IPv4 Address is out of scope of the document. Hosts implemented this specification may support the 6rd Delegated Prefix procedure defined in [I-D.ietf-softwire-ipv6-6rd]. 3.4. 6rd Border Router The 6rd BR implemented this specification is assigned a 6rd BR-Id. Each 6rd BR has a unique BR-Id. The 6rd BR in this specification is stateful. This is a new requirement in contrast to the stateless 6rd deployment with the 6rd CE. The reason for this stateful requirement is when the 6rd BR de-capsulates the IPv4 header, the NAT-ed UDP Source Port is lost. This information is needed to encapsulate the returned datagram for the session to the HGW. 3.5. Procedure When the 6rd host wants to send an IPv6 datagram to an IPv6 destination, it puts the 6rd Prefix in the source IPv6 address field. Then it encapsulates the IPv6 datagram with an IPv4 header. The IPv4 header contains the 6rd BR in the destination address field and the Internal IPv4 address in the source address field. Then the host encapsulates the IPv4 datagram with a UDP header. The source port can be any available port and the destination port is the well-known port assigned by IANA. When the HWG receives the first UDP datagram, it will NAT the source port and source IPv4 address to create a NAT binding in its table. Then, the HWG forwards the IPv4 UDP datagram to the 6rd BR. This specification contains no new requirement to the HWG. Lee Expires April 21, 2010 [Page 6] Internet-Draft 6RD Over UDP October 2009 When the 6rd BR receives the UDP datagram, it will de-capsulate the UDP header and IPv4 header. It will use the information in the IPv4 UDP header, the IPv6 TCP/UDP header, and the IPv6 header to create a binding in its table. Then, the 6rd BR will forward the IPv6 datagram to the outside IPv6 destination. 3.6. Examples 3.6.1. Host Model This example explains how the Host Model works. Both 6rd Host A and 6rd Host B learn the 6rd SP-BR prefix. They also learn the Subscriber IPv4 address by some external mechanism. Host A and Host B create the 6rd Prefix by concatenating 6rd SP-BR prefix and the Subscriber IPv4 address. 3.6.1.1. Outbound Flow When Host A initiates a session in IPv6, it will first encapsulate the IPv6 datagram in an IPv4 header where the source address is the Internal IPv4 address and the destination address it he 6rd BR IPv4 address. Then, Host A will add a UDP header to the datagram where the source port can be any available port and the destination port is the well-known port defined by IANA. When the HWG receives the first UDP datagram, it performs classic NAT function on the UDP datagram and forwards the NAT-ed UDP datagram to the 6rd BR. For each new UDP session, the 6rd BR creates a binding. The binding contains: IPv4 UDP source port, IPv6 source address, and IPv6 destination IPv6 TCP/UDP source port, and IPv6 TCP/UDP destination port. Note that the 6rd is required to remember the sessions from the HWG in order to use the correct IPv4 UDP port to encapsulate the returned datagrams. 3.6.1.2. Inbound Flow When the 6rd BR receives an IPv6 datagram, it checks the IPv4 source address. If the source address belongs to one of its own, it checks its binding table to see any match of the TCP/UDP destination port in the IPv6 transport header. If a match is found, the 6rd BR will use the IPv4 UDP port stored in the table and encapsulate the IPv6 datagram to UDP and IPv4 and forward the datagram to the Subscriber IPv4 Address of the HWG. When the HWG receives the datagram, the HGW replaces the destination port and destination IP address with the information stored in the NAT table, and forward the datagram to the 6rd host. Lee Expires April 21, 2010 [Page 7] Internet-Draft 6RD Over UDP October 2009 | IPv6 | Global Internet +-----+ | | 6rd Border Router +-----+ | +----------------------+ | | | ISP IPv4 Network | | | | | +----------------------+ | Subscriber IPv4 +-----+ | | Unmodified HGW +-----+ | Internal IPv4 _________ | | +===+ +===+ 6rd Host A | | | | 6rd Host B +===+ +===+ Figure 1 3.6.2. Server Model This example is very similar to the Host Model. Instead of the host implementing this specification, only the server device is required to implement this specification. The server will use the same mechanism described in the Host Model to construct the 6rd Prefix. When the server is ready to provide the 6rd service, it will announce the 6rd Prefix in the Router Advertisement. Client A and Client B will receive the 6rd Prefix and auto-config the IPv6 interface using the 6rd Prefix. Lee Expires April 21, 2010 [Page 8] Internet-Draft 6RD Over UDP October 2009 | IPv6 | Global Internet +-----+ | | 6rd Border Router +-----+ | +----------------------+ | | | ISP IPv4 Network | | | | | +----------------------+ | +-----+ | | Unmodified HGW +-----+ | ____________________________________ | -- 6rd --> | | | Prefix | | +===+ +---+ +---+ | s | | c | | c | +===+ +---+ +---+ server client A client B Figure 2 4. 6rd Prefix UDP Encapsulation 4.1. UDP-Encapsulated 6rd Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6rd Datagram | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee Expires April 21, 2010 [Page 9] Internet-Draft 6RD Over UDP October 2009 Where o the Source Port is any available port. o the Destination Port must be the well-known port assigned by IANA. o this specification does not introduce new requirement to the IPv4 UDP Length and Checksum. 5. 6rd Border Router Discovery In the classic 6rd framework, the 6rd CE connects directly to the ISP. The ISP uses DHCP to pass the 6rd SP Prefix and the 6rd BR address to the CPE CE. In this specification, the 6rd host is not directly connected to the ISP. Between the ISP and the 6rd host, there is a HWG which is unaware of 6rd. The ISP can't use DHCP to pass the necessary information to the 6rd hosts. In this specification, we suggest two discovery mechanisms. 5.1. Manual Discovery The ISP gives the customers the 6rd SP Prefix and 6rd BR information. If the customers want to start the 6rd service, they must enter the information manually. This method is only feasible in very small scale deployment and not recommended for any large scale deployment. 5.2. Automatic Discovery The ISP uses RADIUS [RFC2865] or DIAMETER [RFC3588] to distribute the 6rd SP-BR Prefix and 6rd BR IPv4 address information. When the customer starts the 6rd service, he/she must authenticate him/herself to the ISP. Upon a successful authentication, he/she will be given the 6rd SP-BR Prefix and 6rd BR address through either RADIUS or DIAMETER response. 6. MTU Similar to other tunnel encapsulation, this specification reduces the effect MTU size. The encapsulation overhead is 20-byte for IPv4 header and 8-byte for UDP. The host and 6rd BR must account for this overhead. 7. Comparison to the Classic 6rd This specification is considered more restrictive than the classic Lee Expires April 21, 2010 [Page 10] Internet-Draft 6RD Over UDP October 2009 6rd. There are three major areas: 7.1. Outside Initiated Traffic In the classic 6rd model, 6rd CE is the IPv6 router of its managed prefix. Outside initiated IPv6 traffic to the inside host will be routed to the 6rd CE. After de-capsulating the IPv4 header, the 6rd CE will forward the IPv6 datagrams to the host based upon the IPv6 destination address in the IPv6 header. This allows outside host to initiate IPv6 session to the inside host. In the UDP encapsulation mode, the IPv4 HGW is unaware of the IPv6 session. It will drop the UDP encapsulated datagram if there is no existing session in the NAT table associated to incoming datagram. This will prevent the outside host from initiating IPv6 session to the inside host. 7.2. Stateless vs. Stateful 6rd Border Router In the classic 6rd architecture, the 6rd BRs are stateless. All 6rd BRs announces the same set of 6rd Prefixes. For both egress and ingress sessions, routers can pick any 6rd BR to forward the traffic. In fact, the communication path between the 6rd CE and outside host can be asymmetric. As such, the 6rd CE could use 6rd BR1 for forwarding path and the destination network could use 6rd BR2 for returning path. In the UDP encapsulation mode, the 6rd BRs are stateful. The reason is when the 6rd BR de-capsulates the IPv4 header, the NAT-ed UDP Source Port information is lost. This information is needed to encapsulate the datagrams for the ingress session back to the HGW. Thus, when the 6rd BR de-capsulates the IPv4 header, it will remember the UDP Source Port and create a binding table for the session. This requirement mandates the communication path between the 6rd host and 6rd BR must be symmetric. For example: If the 6rd host chose 6rd BR1 for forwarding path, the return path must also use the 6rd BR1. 7.3. 6rd Prefix In the classic 6rd architecture, the 6rd BR announces the 6rd SP Prefix to the public Internet. The outside host can pick any 6rd BR to communicate to the IPv6 hosts behind the 6rd CE. In the UDP encapsulation mode, the session between the 6rd host and outside host must use the same 6rd BR. So the 6rd BR must announce a more specific 6rd Prefix than the 6rd SP Prefix so that the outside host will choose the correct 6rd BR when it responds to the inside 6rd host. Hence, each 6rd BR is given an 6rd BR-ID. The 6rd BR will Lee Expires April 21, 2010 [Page 11] Internet-Draft 6RD Over UDP October 2009 form the 6rd SP-BR Prefix by concatenating the 6rd SP prefix and the BR-ID. During 6rd host bootstrapping, the 6rd host will be given this specific prefix. The 6rd host will use it to construct the 6rd prefix by combining the 6rd SP-BR prefix and the Subscriber IPv4 address. 8. Comparison to Softwire Hub-and-Spoke and Teredo Softwire Hub-and-Spoke [RFC5571] and Teredo [RFC4380] are two protocols that provide IPv6 connectivity to hosts behind typical HGW. Softwire Hub-and-Spoke uses L2TPv2 over UDP [RFC2661] for the tunnel protocol; Teredo defines its own tunneling protocol for UDP encapsulation. This specification provides similar functionality. The upside for this specification is that it does not require control channel between the 6rd host and 6rd BR. The downside is UDP encapsulation does not allow outside host to initiate session to the 6rd host. Besides, this specification require external bootstrapping process to pass provisioning information to the 6rd host. This specification can support both classic 6rd and UDP encapsulation of 6rd in the 6rd BR. In a deployment scenario where customers have mixed 6rd CE and typical HGW, this specification potentially saves operation cost by deploying only one type of network equipments. 9. IANA Considerations This specification requests IANA to assign a UDP port for the 6rd UDP encapsulation. 10. Security Considerations TBD 11. Acknowledgements TBD 12. References 12.1. Normative References [I-D.despres-6rd] Despres, R., "IPv6 Rapid Deployment on IPv4 Lee Expires April 21, 2010 [Page 12] Internet-Draft 6RD Over UDP October 2009 infrastructures (6rd)", draft-despres-6rd-03 (work in progress), April 2009. [I-D.ietf-softwire-ipv6-6rd] Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider Networks", draft-ietf-softwire-ipv6-6rd-00 (work in progress), August 2009. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., Toutain, L., and J. Tremblay, "Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)", RFC 5571, June 2009. 12.2. Informative References [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., Lee Expires April 21, 2010 [Page 13] Internet-Draft 6RD Over UDP October 2009 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. Author's Address Yiu L. Lee Comcast Email: yiu_lee@cable.comcast.com URI: http://www.comcast.com Lee Expires April 21, 2010 [Page 14]