Softwire Working Group Y. Lee Internet-Draft Comcast Intended status: Informational P. Kapoor Expires: November 29, 2010 Xavient May 28, 2010 UDP Encapsulation of 6rd draft-lee-softwire-6rd-udp-01 Abstract This memo specifies the UDP encapsulation to IPv6 Rapid Deployment (6rd) protocol 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 November 29, 2010. Copyright Notice Copyright (c) 2010 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 Lee & Kapoor Expires November 29, 2010 [Page 1] Internet-Draft 6RD Over UDP May 2010 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. 6rd UDP Host . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Home Gateway . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. 6rd Border Router . . . . . . . . . . . . . . . . . . . . 6 3.4. 6rd UDP Delegated Prefix . . . . . . . . . . . . . . . . . 6 3.5. 6rd UDP Host Delegated Prefix . . . . . . . . . . . . . . 6 3.6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6.1. Outbound Flow from the 6rd UDP Host . . . . . . . . . 7 3.6.2. Inbound Flow from the Subscriber IPv6 Host . . . . . . 8 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7.1. Host Model . . . . . . . . . . . . . . . . . . . . . . 8 3.7.2. Server Model . . . . . . . . . . . . . . . . . . . . . 9 4. 6rd Prefix UDP Encapsulation . . . . . . . . . . . . . . . . . 10 4.1. UDP-Encapsulated 6rd Header . . . . . . . . . . . . . . . 10 5. 6rd Border Router Discovery . . . . . . . . . . . . . . . . . 11 5.1. Manual Discovery . . . . . . . . . . . . . . . . . . . . . 11 5.2. Automatic Discovery . . . . . . . . . . . . . . . . . . . 11 6. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Comparison to the Classic 6rd . . . . . . . . . . . . . . . . 12 7.1. 6rd Prefix Length . . . . . . . . . . . . . . . . . . . . 12 7.2. Additional 6rd BR Operation . . . . . . . . . . . . . . . 12 7.3. Life Time of 6rd Delegated Prefix . . . . . . . . . . . . 12 8. Comparison to Softwire Hub-and-Spoke and Teredo . . . . . . . 12 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Lee & Kapoor Expires November 29, 2010 [Page 2] Internet-Draft 6RD Over UDP May 2010 1. Introduction 6rd protocol [I-D.ietf-softwire-ipv6-6rd] enables service providers to rapidly deploy IPv6 over IPv4 network. In [RFC5569], 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 external IPv4 address to multiple internal IPv4 hosts. Note that the external 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 [RFC5569] Section 4. The 6rd CE is also an IPv6 router which advertises an IPv6 prefix (6rd Delegated Prefix) to the internal IPv6 hosts. The 6rd Delegated Prefix consists of two part: the 6rd Prefix and the external IPv4 address. The 6rd CE learns the 6rd Prefix, IPv4MaskLen, and 6rdPrefixLen from DHCP [I-D.ietf-softwire-ipv6-6rd] and calculate the 6rd Delegated Prefix. Then, the 6rd CE advertises the 6rd Delegated Prefix to the customer's home network via Router Advertisement [RFC4861] or DHCPv6 [RFC3315]. The 6rd specification fits well to those ISPs who manage the customers' home gateway (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 do not manage the customers' HWG, they cannot 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. The host is connect to the unmodified HGW's LAN interface. One the host establishes IPv4 connectivity, it initiates the 6rd discovery procedure Section 5 and construct the 6rd Delegated Prefix. When the host sends an IPv6 datagram, it encapsulates the IPv4 datagram with a standard UDP header [RFC0768], then it encapsulates the IPv6 datagram in an IPv4 header following the procedure defined in [RFC5569]. 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 initiates the 6rd discovery procedure Section 5 and construct the 6rd Delegated Prefix. Then, it advertises the 6rd Prefix via Lee & Kapoor Expires November 29, 2010 [Page 3] Internet-Draft 6RD Over UDP May 2010 Router Advertisement or DHCPv6 to the HGW LAN so that IPv6 datagram will use the server as a gateway to establish IPv6 sessions. This enables the hosts connecting to the HGW's LAN to access 6rd service without additional configuration. This specification defines the udp encapsulation that allows to deploy 6rd behind a 6rd unaware NAT-ed gateway. The general mechanism is still stateless and requires little change to the IPv4 networking. 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 External IPv4 address: is referred to the external IPv4 address assigned by the ISP to the HGW. This address can be either a public IPv4 address of a private [RFC1918] address. o Internal IPv4 address: is referred to the internal IPv4 address assigned by the HGW to the 6rd host. This address is a [RFC1918] address. o 6rd UDP Host: is the host implemented this specification. o 6rd UDP Delegated Prefix: is referred to the 6rd Delegated Prefix [I-D.ietf-softwire-ipv6-6rd] generated by the 6rd BR to identify the host implemented this specification. The 6rd UDP Delegated Prefix is different from the 6rd Delegated Prefix in which the 16- bit udp source port information is part of the 6rd delegated prefix calculation. o 6rd UDP Host Delegated Prefix: is referred to the 6rd Delegated Prefix used by the host. This is different from the 6rd UDP Delegated Prefix in which the 16-bit udp source port information in the IPv6 address will be replaced by zeros. 3. Overview Lee & Kapoor Expires November 29, 2010 [Page 4] Internet-Draft 6RD Over UDP May 2010 3.1. 6rd UDP Host Before the host can use 6rd, it needs to discover five pieces of information: the 6rd prefix, the external IPv4 address, the IPv4MaskLen, the 6rdPreflixLen, and the 6rd BR IPv4 address. Section 5 discusses the process to discover the information. The host calculates the 6rd UDP Host Delegated Prefix following the procedure described in Section 3.5. The 6rd udp host implemented this specification must be able to encapsulate and de-capsulate udp and IPv4 headers when sending and receiving IPv6 datagrams. It must also allocate an available udp port during startup. This port must be used in the 6rd encapsulation during the life time of the process. When the host wants to initiate an IPv6 session to an outside IPv6 host, the first encapsulates is to append the IPv6 datagram with an udp header. The udp source port is the udp port allocated at startup; the destination port is an IANA defined port. The second encapsulate is to append the IPv4 header. The source address will be the internal IPv4 address assigned by the HGW; the destination address will be the 6rd BR's IPv4 address. Since 6rd udp host is behind the HGW, it must send a keepalive message to the 6rd BR to maintain the udp NAT binding alive. The keepalive is a simple udp packet which has special IPv6 destination address so that the 6rd BR will rsecognize this is a keepalive packet. When the 6rd receives this special udp datagram, it must discard the datagram and sends a response to the 6rd udp host. In the response, the IPv6 address contains only the 6rd udp delegated prefix and zero-pad the rest of the bits. When the 6rd udp host receives this datagram. It must discard it. The 6rd udp host must send the keepalive frequent enough to keep the binding. 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 external 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. Lee & Kapoor Expires November 29, 2010 [Page 5] Internet-Draft 6RD Over UDP May 2010 3.3. 6rd Border Router The 6rd BR implemented this specification must be configured to receive UDP packet on port XXXX (TBD) in its IPv4 interface facing the 6rd udp hosts. When it receives a udp packet, it de-capsulates the udp header and extract the udp source port information. Then it replaces the 16-bit zero-padded bit to the udp source port information and forms the 6rd delegated prefix. The 6rd BR must be pre-configured with the IPv4MaxLen and 6rdPrefixLen. When the 6rd BR receives an IPv6 packet in its IPv6 interface, it must extract the 16-bit udp source port from the IPv6 destination address and use it to construct the udp header for encapsulation. The 6rd BR must also zero-pad the 16-bit udp source port information in the IPv6 destination address before sending to the 6rd udp host. This procedure is equivalent to NAT66 [I-D.mrw-behave-nat66] operation where the 6rd BR performs the stateless NAT function to embed the NAT-ed udp port information into the 6rd prefix. 3.4. 6rd UDP Delegated Prefix In order to keep 6rd BR operation stateless and to make 6rd implementations co-exist with the HGW NAT at the same time, this specification defines a new 6rd delegated prefix [I-D.ietf-softwire-ipv6-6rd] calculation procedure which is slightly different from the classic 6rd delegated prefix calculation. This specification proposes to include the 16-bit UDP source port information in the 6rd delegated prefix. The 6rd udp delegated prefix is calculated by concatenating the 6rd prefix, a consecutive set of bits from the CE IPv4 address, and the 16-bit udp source port. The sum of the number of bits must be less than or equal to 64. For example, the 6rd prefix is 2001:DB8::/32; the IPv4 address is 192.0.1.100/24; the IPv4MaskLen is 16; the 6rdPrefixLen is 32; and the source UDP is 12345. The 6rd udp delegated prefix is 2001:DB8: 0164:3039::/64 The 6rd udp delegated prefix is generated and used by 6rd BR. 3.5. 6rd UDP Host Delegated Prefix Since the 6rd Host calculating the delegrated prefix is behind the NAT, it does not know the NAT-ed udp source port. When the 6rd constructs the 6rd UDP Delegated Prefix, it will not populate the 16- bit UDP source port information. Instead, it will zero-pad the 16- Lee & Kapoor Expires November 29, 2010 [Page 6] Internet-Draft 6RD Over UDP May 2010 bit field. This will also ensure that the 6rd udp host delegated prefix will not change if the old NAT-ed binding in the HGW expires and a new binding is formed. Following the previous example, the 6rd host udp delegated prefix behind the HGW is 2001:DB8:0164::/64 The 6rd udp host delegated prefix is used by the 6rd udp host. 3.6. Procedures 3.6.1. Outbound Flow from the 6rd UDP Host 3.6.1.1. 6rd UDP Host When the 6rd udp operation on the host starts, it must allocate an available udp port. This port is used in the source udp port of the udp encapsulation. When the 6rd host wants to send an IPv6 datagram to an IPv6 destination, it puts the 6rd udp host delegated prefix in the source IPv6 address field. Then the host encapsulates the IPv6 datagram with a udp header. The source port is the udp port allocated during the startup process and the destination port is the well-known port assigned by IANA. Then, the host encapsulates the udp 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. The datagram is passed to the relevant routing mechanism. 3.6.1.2. Home Gateway When the HGW receives the first udp datagram, it NATs the source port and source IPv4 address to create a NAT binding in its table. Then, the HGW forwards the IPv4 udp datagram to the 6rd BR. Any subsequent udp datagram designating the same udp port and IPv4 address from the same udp port and IPv4 address will use the same NAT binding. This specification contains no new requirement to the HGW. 3.6.1.3. 6rd Border Router When the 6rd BR receives the udp datagram, it de-capsulates the IPv4 and udp headers, and extracts the 16-bit udp source port information in the udp header. Then, it calculates a new IPv6 source address by replacing the 6rd udp host delegated prefix with the 6rd udp delegated prefix. Then, the 6rd BR forwards the IPv6 datagram to the IPv6 destination. Lee & Kapoor Expires November 29, 2010 [Page 7] Internet-Draft 6RD Over UDP May 2010 3.6.2. Inbound Flow from the Subscriber IPv6 Host 3.6.2.1. 6rd Border Router When the 6rd BR receives the IPv6 datagram, it extracts the 16-bit udp destination port information from the IPv6 destination address. It calculates the new IPv6 destination address by replacing the 6rd udp delegated address with the 6rd udp host delegated address. It also constructs the udp header by putting the extracted 16-bit into the destination port and XXXX (TBD) in the source port. Finally, the 6rd BR extracts the IPv4 address from the IPv6 destination address, encapsulate the IPv6 datagram with the udp header and IPv4 header, and forward it to the provider network. 3.6.2.2. Home Gateway When the HGW receives the IPv4 datagram, it performs the standard NAT function by replacing the destination IPv4 address and udp destination port to the address and port stored in the NAT binding table. Then, it forwards the datagram to the host in the LAN. This specification contains no new requirement to the HGW. 3.6.2.3. 6rd UDP Host When the 6rd host receives the datagram. It de-capsulates the udp and IPv4 headers and forwards the IPv6 datagram to its IPv6 interface or to connected destination. 3.7. Examples 3.7.1. Host Model This example explains how the Host Model works. Both 6rd Host A and 6rd Host B learn the 6rd prefix via static or dynamic configuration. They also learn the external IPv4 address by some external mechanism. Host A and Host B create the 6rd delegated prefix by concatenating 6rd prefix, the external IPv4 address, and pads 16-bit at the end of the external IPv4 address. The resulting 6rd udp host delegated prefix must be less than or equal to 64. Lee & Kapoor Expires November 29, 2010 [Page 8] Internet-Draft 6RD Over UDP May 2010 | IPv6 | Global Internet +-----+ | | 6rd Border Router +-----+ | +----------------------+ | | | ISP IPv4 Network | | | | | +----------------------+ | External IPv4 Address +-----+ | | Unmodified HGW +-----+ | Internal IPv4 Address _________ | | +===+ +===+ 6rd Host A | | | | 6rd Host B +===+ +===+ Figure 1 3.7.2. Server Model This example is very similar to the Host Model. Instead of the host implementing this specification, only a server device is required to implement this specification. The server uses the same mechanism described in the Host Model to construct the 6rd udp host delegated prefix. When the server is ready to provide the 6rd service, it announces the 6rd udp host delegated prefix in the Router Advertisement. Client A and Client B receive the 6rd udp host delegated Prefix and auto-config the IPv6 interface. Lee & Kapoor Expires November 29, 2010 [Page 9] Internet-Draft 6RD Over UDP May 2010 | IPv6 | Global Internet +-----+ | | 6rd Border Router +-----+ | +----------------------+ | | | ISP IPv4 Network | | | | | +----------------------+ | External IPv4 Address +-----+ | | Unmodified HGW +-----+ | Internal IPv4 Address ______________________________________ | -- 6rd --> | | | UDP Host | | +===+ Delegated +---+ +---+ | s | Prefix | c | | c | +===+ +---+ +---+ Server Client A Client B Figure 2 In this model, Client A and B are ordinary IPv6 hosts unaware of any 6rd specific knowledge. They learn the prefix and default router (which is the Server) via standard RA. 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 & Kapoor Expires November 29, 2010 [Page 10] Internet-Draft 6RD Over UDP May 2010 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where o Source Port is any available port. o 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 Prefix, IPv4MaskLen, 6rdPrefixLen, 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 HGW 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 Prefix, IPv4MaskLen, 6rdPreflixLen, 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 Prefix, IPv4MaskLen, 6rdPrefixlen, and 6rd BR 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 necessary parameters through either RADIUS or DIAMETER response. 6. MTU Similar to other tunnel encapsulations, 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 Lee & Kapoor Expires November 29, 2010 [Page 11] Internet-Draft 6RD Over UDP May 2010 overhead. 7. Comparison to the Classic 6rd This specification is considered more restrictive than the classic 6rd. There are three major areas: 7.1. 6rd Prefix Length In the classic 6rd model, the maximum 6rd Prefix length can be as long as 32 + IPv4MaskLen. In this specification, the maximum 6rd Prefix length is 16 + IPv4MaskLen due to encapsulating the udp source port information in the 6rd udp delegated prefix. 7.2. Additional 6rd BR Operation In the classic 6rd architecture, the 6rd BR does a simple de- capsulation and encapsulation. When the 6rd BR receives a udp datagram from the ISP network, the 6rd BR must calculate a new IPv6 source address after the de-capsulation. The new IPv6 source address contains the 6rd udp delegated prefix in which the udp source port information is embedded in it. When the 6rd BR receives an IPv6 datagram from the IPv6 Internet, it reverses the process by replacing the 6rd udp delegated prefix to the 6rd host udp delegated prefix. This is a stateless NAT66 [I-D.mrw-behave-nat66] operation. 7.3. Life Time of 6rd Delegated Prefix In classic 6rd model, the life time of the 6rd delegate prefix is bounced by the life time of the external IPv4 address. The life time of the external IPv4 address could be hours or even days. In this specification, the life time of the 6rd udp delegated prefix is bounced by the life time of the NAT binding in the HGW. The HGW can expire the udp binding if there is no traffic passing for few seconds. This specification requires the 6rd udp host to send keepalive to the 6rd BR to refresh the binding frequently. However, the 6rd host udp delegated prefix used in the LAN will not suffer from the same short-lived interval. Since the 6rd host udp delegated prefix does not contain the udp port information, its life time is equal to 6rd delegated prefix which is bounced by the life time of the IPv4 external 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. Lee & Kapoor Expires November 29, 2010 [Page 12] Internet-Draft 6RD Over UDP May 2010 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 benefit of this specification is that the operation is stateless and requires no control protocol. However, this specification require external bootstrapping process to pass provisioning information to the 6rd udp host. 9. Deployment Considerations The same 6rd BR can support both classic 6rd and 6rd UDP encapsulation. To achieve this, the classic 6rd and 6rd udp encapsulation must use different 6rd prefixes. 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 equipment. This specification also useful for operator to speedup the 6rd deployment process by offering users a softwire download of 6rd udp host which works behind their home gateways, and for users who do not want to change their home gateways. 10. IANA Considerations This specification requests IANA to assign a UDP port for the 6rd UDP encapsulation. 11. Security Considerations TBD 12. Acknowledgements TBD 13. References 13.1. Normative References [I-D.ietf-softwire-ipv6-6rd] Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", draft-ietf-softwire-ipv6-6rd-10 (work in progress), May 2010. Lee & Kapoor Expires November 29, 2010 [Page 13] Internet-Draft 6RD Over UDP May 2010 [I-D.mrw-behave-nat66] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address Translation (NAT66)", draft-mrw-behave-nat66-02 (work in progress), March 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. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. [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. 13.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, Lee & Kapoor Expires November 29, 2010 [Page 14] Internet-Draft 6RD Over UDP May 2010 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 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. Authors' Addresses Yiu L. Lee Comcast Email: yiu_lee@cable.comcast.com URI: http://www.comcast.com Prashant Kapoor Xavient Email: pkapoor@xavient.com URI: http://www.xavient.com Lee & Kapoor Expires November 29, 2010 [Page 15]