Internet DRAFT - draft-sun-softwire-lw4over6-dhcpv6

draft-sun-softwire-lw4over6-dhcpv6





Network Working Group                                             C. Xie
Internet-Draft                                                    Q. Sun
Intended status: Standards Track                           China Telecom
Expires: January 9, 2014                                          Y. Lee
                                                                 Comcast
                                                                 T. Tsou
                                               Huawei Technologies (USA)
                                                                 Y. Chen
                                                     Tsinghua University
                                                            July 8, 2013


    Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for
                           Lightweight 4over6
                 draft-sun-softwire-lw4over6-dhcpv6-00

Abstract

   Lightweight 4over6 [I-D.ietf-softwire-lw4over6] is an extension to
   DS-Lite which moves the Network Address Translation function from the
   DS-Lite AFTR to the B4.  It can be deployed in a DS-Lite network to
   gradually reduce the load of Carrier Grade NAT in the AFTR.  However,
   when DS-Lite and lw4over6 co-exist in the same network, B4 elemtns
   and lwB4 elements may want to signal the DHCPv6 server the type of
   AFTR (i.e.  AFTR or lwAFTR) they request.  In this memo, a new DHCPv6
   option is proposed for lwB4 element to request the IPv6 address of
   its corresponding lwAFTR.

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 January 9, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the



Xie, et al.              Expires January 9, 2014                [Page 1]

Internet-Draft         DHCPv6 Option for lw4over6              July 2013


   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
   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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Application Scenario  . . . . . . . . . . . . . . . . . . . . . 3
   4.  The lwAFTR-Name DHCPv6 Option . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8


























Xie, et al.              Expires January 9, 2014                [Page 2]

Internet-Draft         DHCPv6 Option for lw4over6              July 2013


1.  Introduction

   Lightweight 4over6 (lw4o6) [I-D.ietf-softwire-lw4over6] defines a
   model for providing IPv4 access over an IPv6 network in which the
   Network Address Translation (NAT) function is performed by the
   Customer-Premises Equipment (CPE) instead of being centralized on a
   Carrier-Grade NAT (CGN).  It removes the requirement for a Carrier
   Grade NAT function in the AFTR, and reduces the amount of centralized
   state in the AFTR.

   The DHCPv4 over DHCPv6 Transport [I.D-ietf-dhc-dhcpv4-over-dhcpv6]
   and Dynamic Host Configuration Protocol (DHCP) Option for Port Set
   [I.D-sun-dhc-port-set-option] can be used for lwB4 to be provisoned
   with the public IPv4 address and port set.  To discover the lwAFTR's
   FQDN, [I-D.ietf-softwire-lw4over6] re-uses the DS-Lite DHCPv6 option
   defined in [RFC6334].  However, for operators who have deployed DS-
   Lite and will deploy lw4over6 in the same network using the same
   DHCPv6 option, the DHCPv6 server will not be able to distinguish
   between DS-Lite subscriber and lw4over6 subscriber.

   In this memo, we define a new DHCPv6 option for lwB4
   [I-D.ietf-softwire-lw4over6] to request the DHCPv6 server its
   corresponding lwAFTR.  This new DHCPv6 option enables the DHCPv6
   server to distinguish between DS-Lite subscriber and lw4over6
   subscriber and offer the requested resources to the subscribers.
   This removes the requirement to pre-provision the subscriber type
   (i.e., DS-Lite or lw4over6) in the provision system.  This option is
   particularly helpful in a scenario where operators offer both DS-Lite
   and lw4over6 in the same network.


2.  Terminology

   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 [RFC2119].

   Terminology defined in [I-D.ietf-softwire-lw4over6] is used
   extensively in this document.


3.  Application Scenario

   There are several possible deployment scenarios in which DS-Lite and
   lw4over6 co-exist in the same network.

   In scenario 1, DS-Lite and lw4over6 are deployed in the same AFTR
   (depicted in Figure1).



Xie, et al.              Expires January 9, 2014                [Page 3]

Internet-Draft         DHCPv6 Option for lw4over6              July 2013


                    +---------------+--------------|
                    +               |              |
+---------+  +------+---+        +--+--+           |
|  Host   |  | LW 4over6|        |     |           |
|         |--| Initiator| ======-| BNG | === +-------------+   +-----------+
+---------+  +----------+        +--|--+     |LW 4over6    |   |   IPv4    |
                                             |  lwAFTR     |   | Internet  |
+---------+  +------+---+        +--+--+     |DS-Lite AFTR |   |           |
|  Host   |--| DS-Lite  | =======|     | ====+-------------+   +-----------+
|         |  |    B4    |        | BNG |           |
+---------+  +----------+        +--|--+           |
                    +               |              |
                    +---------------+--------------+

        Figure 1: DS-Lite Coexistence scenario with Integrated AFTR

   The AFTR needs to distinguish the traffic from two transition
   mechanisms.  The first option is to distinguish using the client's
   source IPv4 address.  Two transition mechanisms can share the same
   tunnel endpoint address.  However, this requires the network element
   to examine every packet and may introduce significant overhead to the
   AFTR element.  The second option is to use separate tunnel endpoint
   addresses for DS-Lite and lw4over6.  This can be easily supported in
   the network element.  The second option is more practical and
   recommended.  This option requires the B4 element to discover the
   AFTR's FQDN and lwB4 element to discover lwAFTR's FQDN.

   In scenario 2, DS-Lite AFTR and lw4over6 lwAFTR do not co-locate in
   the same network element (as depicted in Figure2) and are usually
   configured with different tunnel endpoint address.  Similar to
   scenario 1 option 2, lwB4 also needs to discover a the lwAFTR's FQDN
   rather than the AFTR's FQDN.

                    +---+---------------+-----------------|
                    +                   |                 |
+---------+  +------+---+        +------+-----+           |
|  Host   |  | LW 4over6|        |    BNG     |           |
|         |--| Initiator| ======-|DS-Lite AFTR| === +------------+   +-----------+
+---------+  +----------+        +------+-----+     |LW 4over6   |   |   IPv4    |
                                                    |   lwAFTR   |---| Internet  |
+---------+  +------+---+        +------+-----+     |            |   |           |
|  Host   |--| DS-Lite  | =======|    BNG     | ====+------------+   +-----------+
|         |  |    B4    |        |DS-Lite AFTR|           |
+---------+  +----------+        +------+-----+           |
                    +                   |                 |
                    +-------------------+-----------------+

        Figure 2: DS-Lite Coexistence scenario with Seperated AFTR



Xie, et al.              Expires January 9, 2014                [Page 4]

Internet-Draft         DHCPv6 Option for lw4over6              July 2013


   There are two possible solutions for an lw4over6 lwB4 to discover its
   the lwAFTR's IPv6 address.

   1.  Subscriber Type Pre-configuration

   In this approach, the operator must pre-provision the subscriber type
   (e.g.  Alice is lw4over6 subscriber and Bob is DS-Lite subscriber) in
   the provisioning system, this information will be used to instruct
   the DHCPv6 server to offer AFTR or lwAFTR to the subscriber in the
   DHCPv6 reply.

+----+-----+   +----+-----+        +------+------+        +------+------+
|    B4    |   |   lwB4   |        |    BNG      |        |    AAA      |
|  DS-Lite |   | lw4over6 | ======-|DHCPv6 Server|        |             |
+----+-----+   +----+-----+        +------+------+        +------+------+
     |              |   dhcpv6 option64   |                      |
     |              |-------------------->|   subscriber type    |
     |              |                     |   identification     |
     |              |                     |--------------------->|
     |              |                     | lw4over6.example.com |
     |              |lw4over6.example.com |<---------------------|
     |              |<--------------------|                      |
     |      dhcpv6 option64               |                      |
     |----------------------------------->|                      |
     |                                    |   subscriber type    |
     |                                    |   identification     |
     |                                    |--------------------->|
     |                                    | dslite.example.com   |
     |                                    |<---------------------|
     |       dslite.example.com           |                      |
     |<-----------------------------------|                      |

          Figure 3: Workflow of Subscriber Type Pre-configuration

   This approach requires operators to pre-provision static subscriber
   information in the provisioning system.  This requires modification
   in the provisioning system to include this new subscriber
   information.  Besides, when a subscriber migrates from DS-Lite to
   lw4over6, this will require update in the provisioning system.

   2. lw4over6 DHCPv6 option

   This approach is to use a new DHCPv6 option for lw4over6 lwB4.

   The DHCPv6 server can identify a lw4over6 subscriber by the lw4over6
   DHCPv6 request and offer lwAFTR's FQDN (depicted in the Figure4) to
   the lwB4 element.




Xie, et al.              Expires January 9, 2014                [Page 5]

Internet-Draft         DHCPv6 Option for lw4over6              July 2013


   +----+-----+   +----+-----+           +------+------+
   |    B4    |   |   lwB4   |           |    BNG      |
   |  DS-Lite |   | lw4over6 | =========-|DHCPv6 Server|
   +----+-----+   +----+-----+           +------+------+
        |              | dhcpv6 option(lw4over6)|
        |              |----------------------->|
        |              |  lw4over6.example.com  |
        |              |<-----------------------|
        |                                       |
        |         dhcpv6 option64               |
        |-------------------------------------->|
        |         dslite.example.com            |
        |<--------------------------------------|

               Figure 4: Workflow of lw4over6 DHCPv6 option

   The new DHCPv6 option enables the DHCPv6 server to offer the lwAFTR's
   FQDN to lwB4, the provisioning system does not need to be upgraded to
   identify the subscriber's type.  At migration, operators simply
   configure the B4 element to support NAT and this new DHCPv6 option,
   and this will be done.

   Therefore, a new lw4over6 DHCPv6 option is recommended.


4.  The lwAFTR-Name DHCPv6 Option

   The format of lwAFTR-Name option is the same as DS-Lite AFTR-Name
   option with a new option-code.  It is shown in Figure5.


        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
       +-------------------------------+-------------------------------+
       |    OPTION_lwAFTR_NAME: X      |          option-len           |
       +-------------------------------+-------------------------------+
       |                                                               |
       |                  tunnel-endpoint-name (FQDN)                  |
       |                                                               |
       +---------------------------------------------------------------+

           OPTION_lwAFTR_NAME: TBD

                 option-len: Length of the tunnel-endpoint-name field in
                             octets.

       tunnel-endpoint-name: A fully qualified domain name of the lwAFTR
                             tunnel endpoint.



Xie, et al.              Expires January 9, 2014                [Page 6]

Internet-Draft         DHCPv6 Option for lw4over6              July 2013


           Figure 5: Format of lwAFTR-Name DHCPv6 Option Format

   The server behavior and the client behavior is exactly the same with
   DS-Lite AFTR-Name DHCPv6 Option ([RFC6334] section 4 and section5).


5.  IANA Considerations

   IANA is requested to allocate single DHCPv6 option code referencing
   this document, delineating OPTION_lwAFTR_NAME.


6.  Acknowledgements

   The authors would like to thank the following individuals who have
   participated in the drafting, review, and discussion of this memo: TO
   BE COMPLETED


7.  References

7.1.  Normative References

   [I-D.ietf-pcp-port-set]
              Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T.,
              and S. Perreault, "Port Control Protocol (PCP) Extension
              for Port Set Allocation", draft-ietf-pcp-port-set-00 (work
              in progress), March 2013.

   [I-D.ietf-softwire-lw4over6]
              Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
              Farrer, "Lightweight 4over6: An Extension to the DS-Lite
              Architecture", draft-ietf-softwire-lw4over6-00 (work in
              progress), April 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
              RFC 6334, August 2011.

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              April 2013.



Xie, et al.              Expires January 9, 2014                [Page 7]

Internet-Draft         DHCPv6 Option for lw4over6              July 2013


7.2.  Informative References

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.


Authors' Addresses

   Chongfeng Xie
   China Telecom
   P.R.China

   Phone: 86 10 58552116
   Email: xiechf@ctbri.com.cn


   Qiong Sun
   China Telecom
   P.R.China

   Phone: 86 10 58552936
   Email: sunqiong@ctbri.com.cn


   Yiu L. Lee
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   USA

   Email: yiu_lee@cable.comcast.com


   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA 95050
   USA

   Phone: +1 408 330 4424
   Email: Tina.Tsou.Zouting@huawei.com









Xie, et al.              Expires January 9, 2014                [Page 8]

Internet-Draft         DHCPv6 Option for lw4over6              July 2013


   Yuchi Chen
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: peng-wu@foxmail.com











































Xie, et al.              Expires January 9, 2014                [Page 9]