Network Working Group B. Sarikaya
Internet-Draft F. Xia
Intended status: Standards Track Huawei USA
Expires: April 24, 2009 October 21, 2008
RADIUS Prefix Authorization Application
draft-sarikaya-radext-prefix-authorization-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 24, 2009.
Sarikaya & Xia Expires April 24, 2009 [Page 1]
Internet-Draft RADIUS Prefix Authorization Application October 2008
Abstract
This document specifies a RADIUS application for prefix
authorization. Using RADIUS protocol, a client requests prefixes
from a server; the client gives back the prefixes to the server; the
client is responsible for renewing the prefixes when the lifetime
expires. The RADIUS server can also renumber prefixes. RADIUS
clients can be home agents in MIPv6 and NEMO scenario, local mobile
anchors in Proxy MIPv6 scenario, or common access routers.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5
3.1. Prefix Request . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Prefix Release . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Prefix Renew . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Prefix Renumbering . . . . . . . . . . . . . . . . . . . . 7
4. Use of Existing RADIUS Attributes . . . . . . . . . . . . . . 8
4.1. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. NAS-Port-Type . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Message Authenticator . . . . . . . . . . . . . . . . . . 9
5. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Authorized-Prefix Attribute . . . . . . . . . . . . . . . 9
5.2. Prefix-Authorization Attribute . . . . . . . . . . . . . . 11
5.3. Authorized-UserID Attribute . . . . . . . . . . . . . . . 12
5.4. Authorized-UserID-Prefix Attribute . . . . . . . . . . . . 12
6. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 14
7. Diameter Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Registration of New AVPs . . . . . . . . . . . . . . . . . 14
8.2. New Registry: Prefix Authorization Type . . . . . . . . . 14
8.3. Addition of Existing Values . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative references . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Sarikaya & Xia Expires April 24, 2009 [Page 2]
Internet-Draft RADIUS Prefix Authorization Application October 2008
1. Introduction
Prefix assignment for an IPv6 node (host or router) is essential to
IPv6 address formulation. Even though IPv6 address space is large
enough, it still makes sense for operators to manage addresses in a
central way, e.g. using central DHCPv6 servers or AAA servers.
Authorizing the use of a prefix that a central server has by a prefix
user needs communication between different network entities.
[RFC4968] provides different IPv6 link models that are suitable for
802.16e [802.16e] based networks and provides analysis of various
considerations for each link model and the applicability of each link
model under different deployment scenarios. As to IPv6 addressing,
there are two models, shared link model and point-to-point link
model. In the former model, an IPv6 prefix is shared by multiple
MNs. While in the latter model, a prefix is only assigned to one MN.
Different MNs can't share a prefix, and an MN can have multiple
prefixes. [RFC5121] specifies the addressing and operation of IPv6
over the IPv6 specific part of the packet convergence sub-layer of
IEEE Std 802.16e [802.16e], and point-to-point link model is
recommended. Also, 3GPP and 3GPP2 have earlier adopted the point-to-
point link model [RFC3314].
When an MN attaches an Access Router(AR), the AR requests one or more
prefixes for the MN. When the MN detaches the AR, the prefixes
should be released. When an operator wants to renumber its network,
prefixes with different lifetimes are advertised to the MN. Using
the mechanism defined in this document, AR can offload prefix
management to a dedicated server. The prefix management method
defined in this document is applicable to this scenario.
Proxy Mobile IPv6 protocol enables mobility support to a host without
requiring its participation in any mobility related signaling
[RFC5213]. Point-to-point access link is supported. It assumes that
the mobile node and the Mobile Access Gateway (MAG) are the only two
nodes on the access link. Proxy Binding Update and Proxy Binding
Acknowledgement are used by Local Mobility Anchor (LMA) to allocate
the prefixes for the mobile node to MAG. How LMA gets these prefixes
from external servers is out the scope of PMIPv6 protocol. The
prefix management method defined here is also applicable to this
scenario.
[RFC3633] defines Prefix Delegation options to provide a mechanism
for automated delegation of IPv6 prefixes using the Dynamic Host
Configuration Protocol (DHCP). [I-D.ietf-nemo-dhcpv6-pd] describes
how DHCPv6 PD can be used by mobile routers and home agents in
network mobility.
Sarikaya & Xia Expires April 24, 2009 [Page 3]
Internet-Draft RADIUS Prefix Authorization Application October 2008
In DHCPv6 PD, the delegating router can receive the prefixes from AAA
server and Delegated-IPv6-Prefix RADIUS attribute was defined for
this purpose [RFC4818]. In this case AAA server passively delegates
the prefixes to the delegating router and it does not have any
control over these prefixes in cases such as renumbering. This
document proposes a new RADIUS application for prefix authorization
using RADIUS [RFC2865] and [I-D.ietf-radext-design]. This new
application enables full prefix authorization functionality to the
AAA servers.
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].
Authorized User IDs and Prefixes: A collection of prefixes assigned
to AAA client. Each has an associated User Identity. This
concept is captured in Authorized-UserID-Prefix attribute defined
in Section 5.4. An AAA client may have more than one Authorized-
UserID-Prefix assigned to it; for example, one for each of access
user's interface. Also each interface may be assigned more than
one prefixes.
User identifier: An identifier chosen by the client. Each user has
an user identifier, which is chosen to be unique among all user
identifiers for users belonging to that client. This concept is
captured in Authorized-UserID attribute defined in Section 5.3.
Aggregate Prefix: In Point-to-Point Link Model, AR should broadcast
the prefixes (MNs route information) dynamically upstream, and
this causes high routing protocol traffic (OSPF, etc.). To solve
the problem, route aggregation should be used. For example, each
AR can be assigned a /48 prefix, while an MN's /64 prefix is
derived from the /48 prefix extension. The main, higher-level
prefix is called the Aggregate Prefix. An AR only broadcasts the
aggregate prefix upstream. Aggregate prefix is a pool of
dedicated prefixes.
Dedicated Prefix: A unique prefix used by MN in Point-to-Point Link
Model. A dedicated prefix belongs to an aggregate prefix.
Dedicated prefix information never be broadcasted by routing
protocol. In this memo, AAA client requests dedicated prefix
along with the corresponding aggregate prefix from AAA server.
Using the corresponding aggregate prefix information, AAA client
broadcasts upstream MN's route information.
Sarikaya & Xia Expires April 24, 2009 [Page 4]
Internet-Draft RADIUS Prefix Authorization Application October 2008
Prefix Authorization Client (PA Client): RADIUS Client which is
responsible for exchange with a RADIUS Server to fulfill prefix
request, release, renew and reconfiguration functions. In this
document, it can be a HA for allocating prefix for mobile router,
or a local mobility anchor (LMA) in Proxy Mobile IPv6 (PMIPv6)
scenario for managing dedicated prefix of MN, or an access router
in point-to-point link model.
Prefix Authorization Server (PA Server): RADIUS Server which is
responsible for exchange with a RADIUS Client to fulfill prefix
request, release, renew and reconfiguration functions. In this
document, it can be collocated with a RADIUS authentication
server, or it can be a separated server managing prefixes.
Prefix Authorization User (PA User): The end user of prefixes. In
this document, it can be MN which configures it's prefixes from
LMA in PMIPv6 scenario, or a mobile router, or MN which requests
it's prefix in a visited network.
3. Protocol Description
Figure 1 shows the architecture of the solution described in this
document.
PA Client PA Server
+----+ +--------+ +-------------+
| | | | RADIUS EAP | +--------+ |
| PA |<--->| AR or |<--------------------------->|AAA-EAP | |
|User| | LMA or| (Authentication) | +--------+ |
| | | HA | | |
+----+ | | | |
| |RADIUS Prefix Authorization| +---------+ |
| |<--------------------------->| AAA-PA | |
| | (Authorization) | +---------+ |
+--------+ +-------------+
Figure 1: Architecture Overview
The use of EAP and the existence of the RADIUS EAP application
[RFC3579] has made the RADIUS community to separate the act of
authentication from authorization, and in this case, prefix
management is a type of authorization. This way, the peer (MN) and
AAA client first run an EAP method with the AAA server using RADIUS
EAP application, followed by a service authorization process for
prefixes. To explicitly authorize the prefixes, in this document, we
define a new RADIUS application. The application uses RADIUS
Sarikaya & Xia Expires April 24, 2009 [Page 5]
Internet-Draft RADIUS Prefix Authorization Application October 2008
messages defined in [RFC2865] and in [RFC5176].
3.1. Prefix Request
A PA Client sends an Access-Request message containing identity of
the user to a PA server for prefix request. The client is identified
using Authorized-UserID in Authorized-UserID-Prefix attribute defined
in this document. Access-Request message MUST contain Authorized-
UserID-Prefix attribute. The client MAY request an aggregate prefix,
and then MAY subnet the prefix to the users. It is also possible
that the client only requests a dedicated prefix. The PA server
allocates one or more prefixes for the client using Access-Accept.
Lifetime of prefixes is included in Valid Lifetime field of
Authorized-UserID-Prefix in this message. The lifetime value
included is the value proposed by PA Client.
Access-Request MUST contain Prefix-Authorization type attribute. The
value MUST be set to Request.
PA Server replies with Access-Accept to PA Client. PA server MUST
include Authorized-UserID-Prefix attribute in Access-Accept. The
server authorizes prefixes included in Authorized-UserID-Prefix to PA
Client. The prefixes can be used during Valid Lifetime period.
Access-Accept MUST contain Prefix-Authorization type attribute. The
value MUST be set to Request.
PA Server replies with Access-Accept if the prefix request can be
satisfied. In case of a prefix request that can not be fullfilled by
PA Server, PA Server sends Access-Reject. Reception of an Access-
Reject indicates an unsuccessful prefix request made by PA Client.
Reply-Message attribute indicates the failure message. Prefix-
Authorization type attribute MUST be set to Request.
3.2. Prefix Release
When a PA User detaches a PA Client, the prefixes allocated to the
user should be released. Access-Request is sent by a PA Client to a
PA Server. The server replies with Access-Accept to confirm the
reception and process of the prefix release.
PA User and the prefixes to be released are identified in Access-
Request and Access-Accept using Authorized-UserID-Prefix attribute.
Multiple occurrences of this attribute can be included to release
multiple prefixes authorized to the same user or to release prefixes
authorized to more than one user.
Access-Request MUST contain Prefix-Authorization type attribute. The
Sarikaya & Xia Expires April 24, 2009 [Page 6]
Internet-Draft RADIUS Prefix Authorization Application October 2008
value MUST be set to Release. Access-Accept MUST contain Prefix-
Authorization type attribute. The value MUST be set to Release.
PA Server replies with Access-Accept if the prefix release request
can be satisfied. In case of a prefix release request that can not
be fullfilled by PA Server, PA Server sends Access-Reject. Reception
of an Access-Reject indicates an unsuccessful prefix release request
made by PA Client. Reply-Message attribute indicates the failure
message. Prefix-Authorization type attribute MUST be set to Release.
3.3. Prefix Renew
When the lifetime of prefixes will expire, a PA client renews the
prefix using Access-Request message. A PA server sends Access-Accept
with the new lifetime of the prefixes.
PA User and the prefixes to be renewed are identified in Access-
Request and Access-Accept using Authorized-UserID-Prefix attribute.
Multiple occurrences of this attribute can be included to renew
multiple prefixes authorized to the same user or to renew prefixes
authorized to more than one user.
Access-Request MUST contain Prefix-Authorization type attribute. The
value MUST be set to Renew. Access-Accept MUST contain Prefix-
Authorization type attribute. The value MUST be set to Renew.
PA Server replies with Access-Accept if the prefix renew request can
be satisfied. In case of a prefix renew request that can not be
fullfilled by PA Server, PA Server sends Access-Reject. Reception of
an Access-Reject indicates an unsuccessful prefix renew request made
by PA Client. Reply-Message attribute indicates the failure message.
Prefix-Authorization type attribute MUST be set to Renew.
3.4. Prefix Renumbering
Renumbering is an important feature of IPv6. A PA Server sends
Change-of-Authorization-Request message to initiate prefix
renumbering process. Once the message is received, a PA client
replies with Change-of-Authorization-ACK and then starts the prefix
renumber interactions to acquire new prefixes and reduce the lifetime
of the old prefixes. The server sends Access-Accept with new
prefixes, at the same time the old prefixes are also included in the
message while the lifetime is reduced. The procedure is illustrated
in Figure 2.
Sarikaya & Xia Expires April 24, 2009 [Page 7]
Internet-Draft RADIUS Prefix Authorization Application October 2008
+----------+ +----------+
| RADIUS | | RADIUS |
| Client | | Server |
+----------+ +----------+
| |
| |
| Change-of-Authorization-Request |
|<----------------------------------|
| |
| Change-of-Authorization-ACK |
|---------------------------------->|
| |
| Access-Request |
|---------------------------------->|
| Access-Accept |
|<--------------------------------- |
Figure 2: Renumbering
Change-of-Authorization Request and Change-of-Authorization-ACK MUST
contain Prefix-Authorization type with value set to Renumber.
Access-Request MUST contain Prefix-Authorization type attribute. The
value MUST be set to Renumber. Access-Accept MUST contain Prefix-
Authorization type attribute. The value MUST be set to Renumber.
PA Server replies with Access-Accept if the prefix renumber request
can be satisfied. In case of a prefix renumber request that can not
be fullfilled by PA Server, PA Server sends Access-Reject. Reception
of an Access-Reject indicates an unsuccessful prefix renumber request
made by PA Client. Reply-Message attribute indicates the failure
message. Prefix-Authorization type attribute MUST be set to
Renumber.
4. Use of Existing RADIUS Attributes
This section defines existing attributes that are used in the
messages of prefix authorization application.
4.1. Service-Type
PA Client uses Session-Type to indicate that the session is for
prefix authorization by setting the Session-Type attribute to
"Authorize Only".
Sarikaya & Xia Expires April 24, 2009 [Page 8]
Internet-Draft RADIUS Prefix Authorization Application October 2008
4.2. NAS-Port-Type
NAS-Port-Type is used by AAA server (PA-Server) to distinguish the
source of the Access-Request.
When the Access-Request originates from an MIP6 HA or PMIP6 LMA, NAS-
Port-Type MUST be included and its value set to HA6 as in
[I-D.ietf-mip6-radius].
When the Access-Request originates from an access router such as
ASN-GW of WiMAX or Serving Gateway of 3GPP, NAS-Port-Type MUST be
included and its value set to AR6 (IANA-TBD1).
4.3. Message Authenticator
Message-Authenticator attribute defined in [RFC3579] MUST be used to
protect all messages used in Prefix Authorization application. In
the messages used for renumbering, Message-Authenticator attribute is
calculated as described in [RFC5176].
5. New Attributes
This section defines new attributes.
5.1. Authorized-Prefix Attribute
The Authorized-Prefix (Ext-Type TBD) contains prefix information.
This attribute is defined as an extended attribute
[I-D.ietf-radext-extended-attributes] with a Tag value of zero.
Each prefix belongs to an aggregate prefix whose length is given in
Agg Prefix Len. A dedicated prefix is an extension of an aggregate
prefix. For example, if PA Client applies a /48 aggregate prefix,
both aggregate prefix length and prefix length are /48. If PA Server
allocates a /64 dedicated prefix belonging to a /48 aggregate prefix
to PA Client, aggregate prefix length in the attribute SHOULD be /48
while prefix length SHOULD be /64. PA Client broadcasts aggregate
prefix information upstream for traffic routing.
Sarikaya & Xia Expires April 24, 2009 [Page 9]
Internet-Draft RADIUS Prefix Authorization Application October 2008
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 (26) | Length | Vendor-Id (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (0) |M| Tag (0) | Ext-Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type | Ext-Length | Reserved |Agg prefix len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Valid Lifetime
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+ +
| |
+ Prefix +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Tag Tag MUST be set to zero.
Ext-Type Type for Authorized-Prefix Attribute. To be assigned by IANA.
Ext-Length The length, 26.
M More bit MUST be set to zero.
Reserved
These bits are reserved. These bits MUST be set to zero by the sender and MUST BE ignored by the receiver.
Agg prefix len
8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges from 0
to 128.
Prefix Length
8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges from 0
to 128.
Valid Lifetime
32-bit unsigned integer. The length of time in seconds
(relative to the time the packet is sent). A value of
all one bits (0xffffffff) represents infinity.
Sarikaya & Xia Expires April 24, 2009 [Page 10]
Internet-Draft RADIUS Prefix Authorization Application October 2008
Prefix A prefix.
5.2. Prefix-Authorization Attribute
Prefix-Authorization attribute contains the type of prefix
authorization operation needed by PA Client. The possible values are
Request, Renew and Release.
Prefix-Authorization attribute is defined as an extended attribute
[I-D.ietf-radext-extended-attributes] with a Tag value of zero.
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 (26) | Length | Vendor-Id (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (0) |M| Tag (0) | Ext-Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type | Ext-Length | Prefix Authorization Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tag Tag MUST be set to zero.
Ext-Type To be assigned by IANA.
Ext-Length The length, 7.
M More bit MUST be set to zero.
Prefix Authorization Type
1 Request
2 Release
3 Renew
4 Renumber
Sarikaya & Xia Expires April 24, 2009 [Page 11]
Internet-Draft RADIUS Prefix Authorization Application October 2008
5.3. Authorized-UserID Attribute
Authorized prefix user's are identified using Authorized-UserID
attribute. This attribute is defined as an extended attribute
[I-D.ietf-radext-extended-attributes] with a Tag value of zero.
Prefix Authorization User ID is a 64 bits unsigned value. Prefix
Authorization server manages prefixes based on Prefix Authorization
User IDs.
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 (26) | Length | Vendor-Id (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (0) |M| Tag (0) | Ext-Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type | Ext-Length | Prefix Authorization User ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tag Tag MUST be set to zero.
Ext-Type Prefix Authorization User ID type. To be assigned by IANA.
Ext-Length The length, 11.
M More bit MUST be set to zero.
Prefix Authorization User ID
64 bits unsigned value
5.4. Authorized-UserID-Prefix Attribute
The Authorized-UserID-Prefix (Type TBD) is an extended attribute
[I-D.ietf-radext-extended-attributes]. This attribute carries
prefixes for users. The user is identified using Authorized-UserID
(TBD2) attribute. It should be set to a 64-bit value identifying the
user of the prefix(es). For example, link layer identifier of the
interface which will receive the prefixes could be used as the user
Sarikaya & Xia Expires April 24, 2009 [Page 12]
Internet-Draft RADIUS Prefix Authorization Application October 2008
id.
The second component of Authorized-UserID-Prefix is Authorized-Prefix
defined in Section 5.1 which defines the prefix for Authorized-
Prefix-UserID.
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 (26) | Length (44) | Vendor-Id (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) |M| Tag | Ext-Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type (TBD) | Ext-Length(11)| Prefix Authorization User ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type (TBD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length(25)| Reserved |Agg prefix len | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Overall length = 7 + 11 + 25
M More bit MUST be set to zero.
Tag To be assigned by IANA
Ext-Type TBD for Authorized-Prefix-User-ID
Ext-Length Length = 3 + 8
Other fields are as described in <xref target="Prefix Delegation"/>
Sarikaya & Xia Expires April 24, 2009 [Page 13]
Internet-Draft RADIUS Prefix Authorization Application October 2008
6. Table of Attributes
The following tables provides a guide to which attributes may be
found in RADIUS messages and in what number. The following defines
the meaning of the notation used in the following tables:
0 An instance of this attribute MUST NOT be present.
1 Exactly one instance of this attribute MUST be present
0-1 Zero or one instance of this attribute MAY be present.
0+ Zero or more instance of this attriubte MAY be present
The table below describes the RADIUS messages used for bootstrapping
and are exchanged between the NAS and the RADIUS Server.
Request Accept Reject CoA Request Type Attribute
1 1 1 1 PREFIX Prefix-Authorization
AUTHORIZATION-TYPE
0+ 0+ 0+ 0+ Group Authorized-UserID-Prefix
7. Diameter Considerations
All the attributes defined in this specification are extended
attributes. Diameter compatibility of extended attributes is
discussed in [I-D.ietf-radext-extended-attributes].
8. IANA considerations
8.1. Registration of New AVPs
This specification defines the following new RADIUS attributes which
are all extended attributes [I-D.ietf-radext-extended-attributes].
Prefix-Authorization is set to PREFIX-AUTHORIZATION-TYPE
Authorized-UserID is set to AUTHORIZED-USERID-TYPE
Authorized-UserID-Prefix is set to AUTHORIZED-USERID-PREFIX-TYPE
8.2. New Registry: Prefix Authorization Type
This specification needs new values for AUTHORIZED-PREFIX-TYPE. The
value field is 4 octets. The current values are listed in
Sarikaya & Xia Expires April 24, 2009 [Page 14]
Internet-Draft RADIUS Prefix Authorization Application October 2008
Section 5.2.
8.3. Addition of Existing Values
This specification requires a new value of AR6 to be assigned to NAS-
Port-Type(61).
9. Security Considerations
This document describes the extension of RADIUS for Prefix
Authorization. The security considerations of the RADIUS protocol
itself have been discussed in [RFC2865] and in [RFC5176]. Use of the
attributes defined in this document MUST take into consideration the
security issues and requirements of the RADIUS Base protocol.
10. Acknowledgements
Madjid Nakhjiri provided help on RADIUS for which we are grateful.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176,
Sarikaya & Xia Expires April 24, 2009 [Page 15]
Internet-Draft RADIUS Prefix Authorization Application October 2008
January 2008.
[I-D.ietf-mip6-radius]
Lior, A., Chowdhury, K., and H. Tschofenig, "RADIUS Mobile
IPv6 Support", draft-ietf-mip6-radius-05 (work in
progress), July 2008.
[I-D.ietf-radext-extended-attributes]
Li, Y., Lior, A., and G. Zorn, "Extended Remote
Authentication Dial In User Service (RADIUS) Attributes",
draft-ietf-radext-extended-attributes-04 (work in
progress), July 2008.
11.2. Informative references
[802.16e] Institute of Electrical and Electronics Engineer,
"Amendment for Physical and Medium Access Control Layers
for Combined Fixed and Mobile Operation in Licensed
Bands", IEEE 802.16e/D12.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Based Networks", RFC 4968, August 2007.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007.
[I-D.ietf-nemo-dhcpv6-pd]
Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for
NEMO", draft-ietf-nemo-dhcpv6-pd-03 (work in progress),
December 2007.
[I-D.ietf-radext-design]
Weber, G. and A. DeKok, "RADIUS Design Guidelines",
draft-ietf-radext-design-05 (work in progress),
August 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
Sarikaya & Xia Expires April 24, 2009 [Page 16]
Internet-Draft RADIUS Prefix Authorization Application October 2008
Authors' Addresses
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Sarikaya & Xia Expires April 24, 2009 [Page 17]
Internet-Draft RADIUS Prefix Authorization Application October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Sarikaya & Xia Expires April 24, 2009 [Page 18]