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]