Network Working Group C. Xie
Internet-Draft Q. Sun
Intended status: Standards Track China Telecom
Expires: January 9, 2014 Q. Sun
Tsinghua University
C. Zhou
Huawei Technologies
T. Tsou
Huawei Technologies (USA)
July 8, 2013
Radius Extension for Lightweight 4over6
draft-sun-softwire-lw4over6-radext-00
Abstract
lightweight 4over6(lw4over6) [I-D.ietf-softwire-lw4over6] is an
extension to DS-Lite in which the amount of state maintained in
lwAFTR has been reduced to per-subscriber-level. The lwB4 needs to
be provisioned with the public IPv4 address and port set it is
allowed to use. 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 provison with the public IPv4 address and port set.
However, in many networks, the configuration information may be
stored in Authentication Authorization and Accounting (AAA) servers
while user configuration is mainly from Broadband Network Gateway
(BNG). This document defines a Remote Authentication Dial In User
Service (RADIUS) attribute that carries lightweight 4over6
configuration information from AAA server to BNG.
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."
Xie, et al. Expires January 9, 2014 [Page 1]
Internet-Draft Radius Extension for Lightweight 4over6 July 2013
This Internet-Draft will expire on January 9, 2014.
Copyright Notice
Copyright (c) 2013 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
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.
Xie, et al. Expires January 9, 2014 [Page 2]
Internet-Draft Radius Extension for Lightweight 4over6 July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Lightweight 4over6 configuration process with RADIUS . . . . . 4
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. lw4o6_binding Attribute . . . . . . . . . . . . . . . . . 7
5. Table of attributes . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Xie, et al. Expires January 9, 2014 [Page 3]
Internet-Draft Radius Extension for Lightweight 4over6 July 2013
1. Introduction
Lightweight 4over6 (lw4over6) [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). Lightweight 4over6 features keeping per-
subscriber binding state in the service provider's network. This
per-subscriber binding state is assigned by the provisioning system
and should be syncronized between lwAFTR. [I.D-ietf-dhc-dhcpv4-over-
dhcpv6] has defined a unified server to distribute IPv4 information
through IPv6-only network. It can be combined with [I.D-sun-dhc-
port-set-option] to provision the public IPv4 address and and port-
set.
In many networks, user configuration information may be managed by
AAA (Authentication, Authorization, and Accounting) servers. Current
AAA servers communicate using the Remote Authentication Dial In User
Service (RADIUS) [RFC2865] protocol. In a fixed line broadband
network, the Broadband Network Gateways (BNGs) act as the access
gateway of users. For lw4over6 case, the BNGs are assumed to embed a
DHCPv4-over-DHCPv6 server function which allows them to locally
handle any DHCPv4-over-DHCPv6 requests issued by hosts. The
operators may per-configure subscriber's binding state in AAA server
which then passes the information to a BNG and in turn populates the
mapping of the subscribe.
This document defines a new RADIUS attribute that can be used in
lightweight 4over6 to carry subscriber's binding state.
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. Lightweight 4over6 configuration process with RADIUS
The below Figure 1 illustrates how the RADIUS protocol and DHCPv4-
over-DHCPv6 cooperate to provide lwB4 with the binding state.
Xie, et al. Expires January 9, 2014 [Page 4]
Internet-Draft Radius Extension for Lightweight 4over6 July 2013
lwB4 BNG lwAFTR AAA
| | Server
|--PPP LCP Config-Request---->| | |
| | | |
|<--PPP LCP Config-ACK ------| | |
|--PPP IPv6CP Config-Request->| | |
|<-PPP IPv6CP Config-ACK ----| | |
|-------DHCPv6 Solicit------->| | |
|<------DHCPv6 Advertisement--| | |
|-------DHCPv6 Request------->| | |
|<------DHCPv6 Reply----------| | |
| | | |
|--------BOOTREQUESTV6------->| | |
| ( DHCPDISCOVER with |-------Access-Request------->|
| OPTION_PORT_SET) | (lw4o6 attr) |
| | |<-Configuration-|
| | | (Optional) |
| | |-----ACK------->|
| |<------Access-Reply----------|
| | (lw4o6 attr) |
|<-------BOOTREPLYV6--------- | | |
| (DHCPOFFER with | | |
| OPTION_PORT_SET) | | |
DHCPv4-over-DHCPv6 RADIUS
Figure 1: Lightweight 4over6 configuration process with RADIUS case 1
BNGs act as a client of RADIUS and as a Unified server. The lwB4
will firstly get the IPv6 address via DHCPv6 process. It then
initiates a BOOTREQUESTV6 DHCPDISCOVER request with PORT_SET Option.
Since the lwB4 has known the address of the Unified server in
advance, it is recommanded to send the BOOTREQUESTV6 message using
unicast address. When receving the BOOTREQUESTV6 from lwB4, the BNG
SHOULD intercept the subscriber's IPv6 address and stored locally.
Then, the BNG SHOULD initiate a RADIUS Access-Request message, in
which the User-Name attribute (1) SHOULD be filled by the lwB4 MAC
address, to the RADIUS server,the User-password attribute (2) SHOULD
be filled by the shared lw4over6 password that has been preconfigured
on the DHCPv6 server to get lw4over6 attribute. The IPv6 address in
lw4o6 attribute should be filled by the subscriber's IPv6 address.
The AAA server will then determine the IPv4 address and Port Set for
the subscriber.
The subscriber's binding state should be syncronized between AAA
server and lwAFTR. If the bindings are pre-configured statically in
both AAA server and lwAFTR, the AAA server does not need to configure
lwAFTR anymore. Otherwise, if the bindings are locally creately in
Xie, et al. Expires January 9, 2014 [Page 5]
Internet-Draft Radius Extension for Lightweight 4over6 July 2013
AAA server on-demand, it should inform the lwAFTR with the
subscriber's binding state using [I-D.zhou-dime-4over6-provisioning]
or COA requests.
Figure 2 describes another scenario -- later re-authorization -- in
which the authorization operation is not coupled with authentication.
Authorization relevant to lw4o6 is done independently after the
authentication process.
lwB4 BNG lwAFTR AAA
| | Server
|--------BOOTREQUESTV6------->| | |
| ( DHCPREQUEST with |-------Access-Request------->|
| OPTION_PORT_SET) | (lw4o6 attr) |
| | |<-Configuration-|
| | | (Optional) |
| | |-----ACK------->|
| |<------Access-Reply----------|
| | (lw4o6 attr) |
|<-------BOOTREPLYV6--------- | | |
| (DHCPACK with | | |
| OPTION_PORT_SET) | | |
DHCPv4-over-DHCPv6 RADIUS
Figure 2: Lightweight 4over6 configuration process with RADIUS case 2
In this scenario, it is also recommanded that unicast IPv6 address is
used in BOOTREQUESTV6 and BOOTREPLYV6. The Access-Request packet
SHOULD contain a Service- Type attribute (6) with the value Authorize
Only (17); thus, according to [RFC5080], the Access-Request packet
MUST contain a State attribute that it obtains from the previous
authentication process.
In both above-mentioned scenarios, Message-Authenticator (type 80)
[RFC2865] SHOULD be used to protect both Access-Request and Access-
Accept messages.
After receiving the lw4over6-binding attribute in the initial Access-
Accept, the BNG SHOULD store the received lw4over6 configuration
parameters locally. When the lw4over6 CE sends a DHCP Request
message to request an extension of the lifetime for the assigned
address, the BNG does not have to initiate a new Access-Request
towards the AAA server to request the lw4o6 binding state. The BNG
could retrieve the previously stored lw4o6 configuration parameters
and use them in its reply. The BNG will then inform the AAA server
with updated lifetime.
Xie, et al. Expires January 9, 2014 [Page 6]
Internet-Draft Radius Extension for Lightweight 4over6 July 2013
If the BNG does not receive the lw4over6-binding attribute in the
Access-Accept or if the BNG receives an Access-Reject, the tunnel
cannot be established.
4. Attributes
This section defines the lw4o6_binding attribute that is used in both
above-mentioned scenarios. The attribute design follows [RFC6158]
and refers to [RFC6929].
4.1. lw4o6_binding Attribute
The lw4o6_binding RADIUS attribute contains the subscriber's binding
information including IPv6 address, IPv4 address and the port-set.
The BNG SHALL use the binding entry returned in the RADIUS
lw4o6_binding attribute to populate the DHCPv4-over-dhcpv6 requests.
If the BNG includes the lw4o6_binding attribute, but the AAA server
does not recognize it, this attribute MUST be ignored by the AAA
server.
If the BNG does not receive the lw4o6_binding attribute in the
Access-Accept message and there is the unified server in BNG is not
configured to allocate the port-set by itself, the unified SHOULD not
response and the tunnel can not be established.
When the Access-Request message is triggered by a DHCP Rebind
message, if the binding attribute received in the Access-Accept
message is different from the currently used one for that session,
the BNG MUST force the lwB4 to re-establish the tunnel using the new
binding information received in the Access-Accept message.
The lw4o6_binding Attribute is structured as follows:
Xie, et al. Expires January 9, 2014 [Page 7]
Internet-Draft Radius Extension for Lightweight 4over6 July 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Set Index | Port Set Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
2
Port Set Index:
Port Set Index identifies a set of ports assigned
to a device. The first k bits on the left of the 2-octet
field is the Port Set Index value, with the rest of the
field right padding zeros.
Port Set Mask:
Port Set Mask indicates the position of the bits
used to build the mask. The first k bits on the left is
padding ones while the remained (16-k) bits of the 2-octet
field on the right is padding zeros.
IPv4 address
The translated IPv4 address for a subscriber.
IPv6 address
The IPv6 address for a subscriber.
Figure 3: Lightweight 4over6 Attribute
5. Table of attributes
The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.
Xie, et al. Expires January 9, 2014 [Page 8]
Internet-Draft Radius Extension for Lightweight 4over6 July 2013
Request Accept Reject Challenge Accounting # Attribute
Request
0-1 0-1 0 0 0-1 TBD1 lw4o6-binding
0-1 0-1 0 0 0-1 1 User-Name
0-1 0 0 0 0 2 User-Password
0-1 0-1 0 0 0-1 6 Service-Type
0-1 0-1 0-1 0-1 0-1 80 Message-Authenticator
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in
packet.
0-1 Zero or one instance of this attribute MAY be present in
packet.
1 Exactly one instance of this attribute MUST be present in
packet.
Figure 4: Lightweight 4over6 Attribute Table
6. Security Considerations
TO BE COMPLETED
7. IANA Considerations
This document has no IANA actions.
8. 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
9. References
9.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.
Xie, et al. Expires January 9, 2014 [Page 9]
Internet-Draft Radius Extension for Lightweight 4over6 July 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.
9.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
Xie, et al. Expires January 9, 2014 [Page 10]
Internet-Draft Radius Extension for Lightweight 4over6 July 2013
Qi Sun
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: sunqibupt@gmail.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathy.zhou@huawei.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 11]