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]
