draft-ietf-l2vpn-radius-pe-discovery-00.txt   draft-ietf-l2vpn-radius-pe-discovery-01.txt 
Network Working Group J. Heinanen Network Working Group J. Heinanen
Internet-Draft TutPro Inc. Internet-Draft TutPro Inc.
draft-ietf-l2vpn-radius-pe-discovery-00.txt G. Weber, Ed. Expires: August 23, 2005 G. Weber, Ed.
Expires: August 2004 Cisco Systems W. Townsley
February 2004 S. Booth
W. Luo
Cisco Systems
February 19, 2005
Using RADIUS for PE-Based VPN Discovery Using RADIUS for PE-Based VPN Discovery
draft-ietf-l2vpn-radius-pe-discovery-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026 [1]. of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes how in PE-based VPNs, a PE of a VPN can use This document describes a strategy by which Provider Equipment (PE)
RADIUS to authenticate its CEs and discover the other PEs of the VPN. can be dynamically provisioned for inclusion in PE-based Layer 2
Virtual Private Networks (L2VPNs). This layered strategy utilizes
the Remote Authentication Dial In User Service (RADIUS) protocol as a
centralized control mechanism and can be used in conjunction with
other proposed mechanisms. The mechanisms described in this document
enhance those established by RFC 2868 and conform to those described
by the L2VPN Framework.
Conventions used in this document Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Information Model . . . . . . . . . . . . . . . . . . . . . 3
5. New RADIUS Attributes . . . . . . . . . . . . . . . . . . . 6
5.1 Router-Distinguisher . . . . . . . . . . . . . . . . . . . 6
5.2 VPN-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3 Attachment-Individual-ID . . . . . . . . . . . . . . . . . 7
5.4 Per-Hop-Behavior . . . . . . . . . . . . . . . . . . . . . 8
5.5 PE-Router-ID . . . . . . . . . . . . . . . . . . . . . . . 9
5.6 PE-Address . . . . . . . . . . . . . . . . . . . . . . . . 9
5.7 PE-Record . . . . . . . . . . . . . . . . . . . . . . . . 10
6. New Values for Existing RADIUS Attributes . . . . . . . . . 11
6.1 Service-Type . . . . . . . . . . . . . . . . . . . . . . . 11
6.2 User-Name . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Table of Attributes . . . . . . . . . . . . . . . . . . . . 12
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1 Normative References . . . . . . . . . . . . . . . . . . 14
11.2 Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 17
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2]. document are to be interpreted as described in [RFC2119].
Table of Contents This document uses terminology from [I-D.ietf-l2vpn-l2-framework] and
[I-D.ietf-l2vpn-signaling].
1. Introduction...................................................2 2. Acronyms
2. Site Identification............................................2
3. RADIUS configuration...........................................3
4. PE Configuration...............................................4
5. Protocol Operation.............................................4
5.1 Connecting a CE to a VPN at a PE...........................4
5.2 Disconnecting a CE from a VPN at a PE......................5
5.3 PE Failure Detection and Recovery..........................6
6. Scaling Limits.................................................6
7. Compliance with PPVPN L2 Requirements..........................6
8. Security Considerations........................................7
9. References.....................................................7
10. Acknowledgments...............................................8
11. Author's Addresses............................................8
12. Full Copyright................................................8
1. Introduction AII: Attachment Individual Identifier
AC: Attachment Circuit
AGI: Attachment Group Identifier
AS: Automonous System
CE: Customer Equipment
L2VPN: Layer 2 Provider Provisioned Virtual Private Network
NAI Network Access Identifier
NAS: Network Access Server
PE: Provider Equipment
SAI: Source Attachment Identifier
SAII: Source Attachment Individual Identifier
RADIUS: Remote Authentication Dial In User Service
TAI: Target Attachment Identifier
TAII: Target Attachment Individual Identifier
VPLS: Virtual Private LAN Service
VPN: Virtual Private Network
VPWS: Virtual Private Wire Service
3. Introduction
This document describes how in PE-based VPNs a PE of a VPN can use This document describes how in PE-based VPNs a PE of a VPN can use
Radius [3,4] to authenticate its CEs and discover the other PEs of RADIUS [RFC2865] to authenticate its CEs and discover the other PEs
the VPN. In Radius terms, the CEs are users and PEs are Network of the VPN. In RADIUS terms, the CEs are users and the PEs are
Access Servers (NAS) implementing Radius client function. Network Access Servers (NAS) implementing RADIUS client
functionality.
A VPN can span multiple Autonomous Systems (AS) and multiple A VPN can span multiple Autonomous Systems (AS) and multiple
providers. Each PE, however, only needs to be a Radius client to providers. Each PE, however, only needs to be a RADIUS client to
Radius of the "local" provider. In case of a CE belongs to a RADIUS server of the "local" provider. In the case in which a CE
"foreign" VPN, Radius of the local provider acts as a proxy client to belongs to a "foreign" VPN, the RADIUS server of the local provider
Radius of the foreign provider. acts as a proxy client to RADIUS of the foreign provider.
2. Site Identification 4. Information Model
Each CE (a VPN site) is identified by a "user name" of the form This document presents a model wherein authorization for
participation in a PE-based VPN can be divided into three different
layers of access.
[provider/]site@vpn o CE or AC Authorization
o VPN Authorization
o Pseudowire Authorization
"provider" identifier, if present, denotes a provider that is the The first layer is AC authorization, in which a first sign of life on
administrative owner of the VPN. It is needed only if a CE connects a particular AC triggers an authorization resulting in provisioning
to a VPN at a PE that does not belong to the owner of the VPN and is information particular to the circuit in question. Once the AC is
then used by Radius of the PE to proxy requests to Radius of the authorized, its VPN membership is authorized separately. This
owner of the VPN. authorization step may result in a number of pseudowire specific
connections; each of which may be authorized separately. The
relationships between these three data representations are shown in
the diagram below.
"site" identifier denotes a site in a VPN identified by "vpn". As an Using a layered approach allows the different stages of authorization
example, to be satisfied by separate means based on deployment scenario. It
also allows one model to apply to various deployment architectures
including VPLS and VPWS. If all three authorization stages are
accommodated by a RADIUS server, the stages may be combined into a
single transaction instead of having three separate transactions.
providerX/atlanta@vpnY.domainZ.net +--------+
could denote a CE called "atlanta" in a VPN identified by | |
"vpnY.domainZ.net", which is owned by providerX. | CE |
| |
+--------+
|
+-------------------------+---------------------------+
| | |
| VPN +--------+ |
| | | |
| | PE | |
| | | |
| +--------+ |
| | |
| | |
| +------------------------------------------+ |
| | +-------------------------+ | |
| | PE | +-------------------+ | | |
| | Next Hop | | Pseudowire | | | |
| | +--------+ +-| Per hop behavior| | | |
| | | | | ... | | | |
| | | AII-----+ +-------------------+ | | |
| | | AII-----+ +-------------------+ | | |
| | | ... | | Pseudowire | | | |
| | | +-| Per hop behavior| | | |
| | | | ... | | | |
| | | +-------------------+ | | |
| | | ... | | |
| | +----------------------------------+ | |
| +------------------------------------------+ |
| +------------------------------------------+ |
| | +-------------------------+ | |
| | PE | +-------------------+ | | |
| | Next Hop | | Pseudowire | | | |
| | +--------+ +-| Per hop behavior| | | |
| | | | | ... | | | |
| | | AII-----+ +-------------------+ | | |
| | | AII-----+ +-------------------+ | | |
| | | ... | | Pseudowire | | | |
| | | +-| Per hop behavior| | | |
| | | | ... | | | |
| | | +-------------------+ | | |
| | | ... | | |
| | +----------------------------------+ | |
| +------------------------------------------+ |
| ... |
+-----------------------------------------------------+
o Each pseudowire may have its own per-hop behavior and arbitrary
configuration information
o Each pseudowire is associated with an AII
o Each PE includes an arbitrary number of AIIs
o Each PE has one associated next hop address
o The VPN includes an arbitrary number of PEs
3. RADIUS configuration The following two sections define how the components of this data
model may be represented as RADIUS attributes so the components of
this information model may be communicated from a centralized
location out into the network elements.
Each "provider" has a single Radius that stores all information 5. New RADIUS Attributes
regarding VPNs that belong to the provider. For reliable operation
of this protocol, each Radius should consist of more than one
physical Radius server. For correct operation of this protocol, all
these physical servers MUST at all times share the same database
content.
For each VPN, Radius of the provider to which the VPN belongs to MUST This document defines several new RADIUS Attributes which are
at all times be configured with a set of "users" that correspond to described in detail in this section.
the potential CEs of the VPN, i.e., CEs that are currently allowed to
be connected to the VPN at some PE. User information includes site
identifier, password, and VPN identifier:
<site, password, vpn> 5.1 Router-Distinguisher
User information MAY also include other information, such as a list This attribute represents a Router Distinguisher as described in
of PEs to which the CE is allowed to connect to and QoS information [I-D.ietf-l3vpn-rfc2547bis]. It MAY be included in an Access-Request
regarding the CE's connection to the VPN. message. This attribute MUST NOT be included in Access-Request
messages that also include a "VPN-ID" attribute.
In addition to the above manually configured information, Radius A summary of the Router-Distinguisher attribute format is shown
keeps dynamically track of the PEs and CEs of a VPN in a database below. The fields are transmitted from left to right.
table that has the following fields:
<vpn, PE IP addess, site, timestamp> 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
received from the PE any Radius request: Type
<PE IP address, timestamp> (TBA) for Router-Distinguisher.
Timestamp tells the most recent time when the PE has authenticated Length
the site to the VPN. It is used by Radius to detect if a PE has
failed for a longer period of time or has been taken improperly out
of use, and if so, to clean up the site and PE from its database.
The PEs MAY also have pre-configured attributes telling, for example, >= 7
that a PE is a hub of a VPN.
If dynamic PE discovery capability of this protocol is not used, Text
Radius MUST be configured for each VPN with a list of its PEs. Such
a degenerate use of this protocol is not discussed further in this
memo.
In order to allow queries about CEs that are connected PEs of a The Text field is composed of three colon separated parts: a type, an
"foreign" provider, the Radius servers of this foreign provider MUST administrator, and an assigned number.
be configured as clients in the Radius of the VPN owner.
4. PE Configuration Where the type is "0", the administrator contains a 16-bit Autonomous
Each PE MUST be configured with the information about the Radius System Number (ASN), and the assigned number is a 32-bit value
servers of local Radius to which to send requests to. For assigned by enterprise responsible for the ASN, e.g. "0:114:23".
reliability reasons, each PE SHOULD have available more than one
physical Radius server.
5. Protocol Operation Where the type is "1", the administrator contains an IP address, and
the assigned number is a 16-bit value assigned by the enterprise
controlling the IP address space, e.g. "1:1.2.3.4:10001".
5.1 Connecting a CE to a VPN at a PE Where the type is "2", the administrator contains a 32-bit ASN, and
the assigned number is a 16-bit value assigned by the enterprise
responsible for the ASN, e.g. "2:70000:216".
When a CE is to be connected to a VPN at a PE, the PE issues a Radius 5.2 VPN-ID
Access-Request using the user name and password of the CE. The PE
has either learned this information from the CE via an authentication
protocol, for example, 802.1x/EAP, or it has been configured in the
PE.
Service-Type of the Access-Request is VPN-Login (value TBD). This attribute represents a VPN-ID as described in [RFC2685]. It MAY
be included in an Access-Request message. This attribute MUST NOT be
included in Access-Request messages that also include a
Router-Distinguisher attribute.
If authentication succeeds and possible other (VPN or provider) A summary of the VPN-ID attribute format is shown below. The fields
specific preconditions are met (for example, the CE is allowed to are transmitted from left to right.
connect to the particular PE and it is not already connected to some
other PE), Radius inserts a
<vpn, PE IP address, site, timestamp> 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
record in its database (replacing a possible earlier record that only Type
differs by the timestamp value) and responds with an Access-Accept.
Access-Accept includes as reply items a Session-Timeout attribute and
one or more PE-List attributes that contain all unique PE IP
addresses in the set
<vpn, *, *> (TBA) for VPN-ID.
and possibly other CE specific information, e.g., QoS parameters. Length
Session-Timeout attribute tells to the PE for how long time Radius >= 5
considers the CE as connected to the VPN at the PE unless the PE re-
authenticates the CE. The value of the timestamp in
<vpn, PE IP address, site, timestamp> Text
record is the time of the Access-Accept plus the number of seconds in The Text field is composed of two colon separated parts: a VPN
the Session-Timeout attribute. authority Organizationally Unique Identifier, and a VPN index, e.g.
"101:14".
PE-List attribute contains a list of PE IP addresses. It is only 5.3 Attachment-Individual-ID
used in Access-Accept packets and has the following format:
This attribute indicates a Attachment-Individual-ID as described in
[I-D.ietf-l2vpn-signaling].
A summary of the Attachment-Individual-ID attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ... | Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type Type
TBD for PE-List (TBA) for Attachment-Individual-ID.
Length Length
16 + N * 4 bytes, where 1 <= N <= 63. >= 3
String Text
N IP Addresses of PEs (the most significant octet first in each The Text field is an encoding of the Source Attachment Individual
address). Identifier, e.g. "2".
After receiving the Access-Accept, the PE considers the CE as 5.4 Per-Hop-Behavior
connected to the VPN and issues a Start Accounting-Request.
If authentication fails or some pre-conditions are not met, Radius This attribute indicates a Per-Hop-Behavior as described in
responds with Access-Reject. [RFC3140].
If a PE wants for some reason to get from Radius an up-to-date list A summary of the Per-Hop-Behavior attribute format is shown below.
of PEs in a particular VPN, it can at any time issue a new Access- The fields are transmitted from left to right.
Request for any one of its CEs that belongs to the VPN. In order to
keep the CE connected to the VPN at the PE, the PE MUST issue a new
Access-Request before the number of seconds returned by Radius in
Session-Timeout attribute of the most recent Access-Accept has
elapsed.
Note that this document does not define any protocol mechanisms by 0 1 2 3
which the other PEs of the VPN would be notified that a new CE was 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
connected to the VPN at the PE or that a new PE became associated +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
with the VPN. Such mechanisms belong to the VPN solution documents | Type | Length | Value
that utilize the discovery protocol defined in this memo. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2 Disconnecting a CE from a VPN at a PE Type
When a CE is to be disconnected from the VPN at a PE, the PE issues a (TBA) for Per-Hop-Behavior.
Stop Accounting-Request. After receiving the request, Radius removes
the
<vpn, PI IP address, site> Length
record from its database and responds with an Accounting-Response.
The PE considers the CE as disconnected from the VPN at the PE when
it has received the Accounting-Response.
Note that this document does not define any protocol mechanisms by 6
which the other PEs of the VPN would be notified that a CE was
disconnected from the VPN at the PE or that the PE is not anymore
associated with the VPN. Such mechanisms belong to the VPN solution
documents that utilize the PE discovery protocol defined in this
memo.
5.3 PE Failure Detection and Recovery Integer
When a PE recovers from a failure, it re-authenticates all CEs The lower 16-bits of the value contains the Per-Hop-Behavior value as
connected to it in all VPNs and thus re-discovers all other PEs in described in [RFC3140].
all those VPNs.
6. Scaling Limits 5.5 PE-Router-ID
Since Radius protocol operates over UDP, the maximum UDP payload size This attribute typically indicates an IPv4 address for a particular
available for Radius attributes is limited to about 1500 - 40 = 1460 PE member of a VPN, though it may be some arbitrary value assigned by
octets assuming that UDP fragmentation is not supported. The most the owner of the ID space.
space consuming message is Access-Accept response, which contains a
list of IP addresses of the PEs of a VPN. This limits the number of
PEs in a VPN to about 350.
Besides the packet size, another factor limiting scalability of this A summary of the PE-Router-ID attribute format is shown below. The
protocol might be the periodic re-authentication of CEs as required fields are transmitted from left to right.
by the Session-Timeout reply attribute. For example, if a provider
has 3600 VPN sites and uses a Session-Timeout value of 1 hour, then
Radius will get on the average of 1 Access-Requests per second.
7. Compliance with PPVPN L2 Requirements 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document covers a PE discovery and CE authentication solution Type
for provider based VPNs. Thus only a small subset of the complete
PPVPN L2 requirements listed in [5] are applicable to this document.
The solution described in this document fulfills all the requirements (TBA) for PE-Router-ID.
of section 6.3 of [5] on "Discovering L2VPN Related Information". In
particular:
(1) Radius based discovery allows PEs to dynamically discover Length
information about other PEs of a VPN with minimal or even with
no configuration in the PEs.
(2) Unauthorized access to the VPN can be prevented by 6
authentication that is an integral part of Radius.
(3) VPN membership information is only distributed to the PEs that Address
have sites that are members of the VPN.
Other aspects mentioned on section 6.3 of [5], such as propagation of Typically, the value indicates the IPv4 address of a particular PE
membership changes in a "timely manner" and no manual reconfiguration member of a VPN.
of the other PEs, are not directly covered in this document. They
belong to VPN solution specifications that apply Radius based PE
discovery and CE authentication, such as the one described in [6].
The Radius based solution described in this document also complies 5.6 PE-Address
with all applicable generic requirements listed in [5]. In
particular:
(1) The PEs of a VPN can be associated with topology and tunneling This attribute indicates an IPv4 address for a particular PE member
protocol information. of a VPN. In relation to the PE for which a CE is joining the VPN,
this would be the initial's PE's next hop address.
(2) VPN sites can be associated with QoS and access control A summary of the PE-Address attribute format is shown below. The
information. fields are transmitted from left to right.
(3) Radius has been widely implemented by existing PEs and has 0 1 2 3
very good interoperability record. 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(4) Multi-provider/multi-AS VPNs are readily supported without any Type
extra complications.
(5) CEs of a VPN require either no configuration or minimal (TBA) for PE-Address.
configuration (user name/password).
(6) There is no practical limit on the number of VPNs and, with Length
hierarchical implementation, each VPN can have a very large
number of PEs and CEs.
(7) Radius based provisioning systems are readily available and are 6
easily adaptable to PE discovery.
In summary, Radius provides a good directory based alternative to Address
PPVPN PE discovery and a natural means to authenticate VPN CEs.
8. Security Considerations The value indicates the IPv4 address of a particular PE member of a
VPN.
Security of Radius based VPN discovery depends on the security of 5.7 PE-Record
Radius that is covered in [3] and [4]. In multi-provider operation,
secure tunnels SHOULD be used to carry Radius traffic between
providers.
9. References This attribute represents a single element within a particular PE's
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP description. A group of PE-Records combine to form a complete PE
9, RFC 2026, October 1996. description when returned during VPN authorization.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement A summary of the PE-Record attribute format is shown below. The
Levels", BCP 14, RFC 2119, March 1997. fields are transmitted from left to right.
3 C. Rigney, et al., "Remote Authentication Dial In User Service 0 1 2
(RADIUS)". RFC 2865, June 2000. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
4 C. Rigney, "RADIUS Accounting". RFC 2866, June 2000. Type
5 W. Augustun, Y. Serbest, "Service Requirements for Layer 2 (TBA) for PE-Record.
Provider Provisioned Virtual Private Networks". draft-augustyn-
ppvpn-l2vpn-requirements-02.txt, February 2003.
6 J. Heinanen, "Radius/L2TP Based VPLS". draft-ietf-l2vpn-l2tp- Length
radius-vpls-00.txt, January 2004.
10. Acknowledgments >= 8
The authors would like to thank Mark Duffy, Joel Halpern, and Mark Text
Townsley for their constructive comments on earlier versions of this
memo.
11. Author's Addresses The Text field contains an AII prefixed by a PE-Router-ID and
separated by a colon, e.g. "1.1.1.1:14" where the PE-Router-ID is
1.1.1.1 and the AII is 14. This represents a particular pseudowire.
The value is optionally suffixed by a colon separated list of
attribute value pairs containing pseudowire-specific configuration,
e.g. "1.1.1.1:14:PHB=256".
6. New Values for Existing RADIUS Attributes
6.1 Service-Type
This document defines one new value for an existing RADIUS attribute.
The Service-Type attribute is defined in Section 5.6 of RFC 2865
[RFC2865], as follows:
This Attribute indicates the type of service the user has requested,
or the type of service to be provided. It MAY be used in both
Access-Request and Access-Accept packets.
A NAS is not required to implement all of these service types, and
MUST treat unknown or unsupported Service-Types as though an Access-
Reject had been received instead.
A summary of the Service-Type Attribute format is shown below.
The fields are transmitted from left to right.
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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
6 for Service-Type.
Length
6
Value
The Value field is four octets.
This document defines one new value for the Service-Type
attribute.
(TBA) L2VPN
The semantics of the L2VPN service are as follows:
L2VPN A CE is requesting to join a VPN.
6.2 User-Name
This attribute defined by [RFC2865] takes a value depending on which
layer of VPN authorization is occurring.
o For CE/AC authorization, the User-Name value contains either a
Network Access Identifier (NAI) associated with the CE [RFC2486],
or an implementation dependent AC name.
o For VPN authorization, the User-Name value contains the VPN-ID or
a Router-Distinguisher.
o For pseudowire authorization, the User-Name value contains a
PE-Router-ID.
7. Table of Attributes
The following tables provide a guide to which attributes may be found
in which kinds of packets, and in what quantity.
CE/AC Authorization
Request Accept Reject Challenge # Attribute
---------------------------------------------------------------------
0 0-1 0 0 TBA Router-Distinguisher
0 0-1 0 0 TBA VPN-ID
VPN Authorization
Request Accept Reject Challenge # Attribute
---------------------------------------------------------------------
0-1 0 0 0 TBA Router-Distinguisher
0-1 0 0 0 TBA VPN-ID
0 0+ 0 0 TBA Attachment-Individual-ID
0 0-1 0 0 TBA Per-Hop-Behavior
0 0-1 0 0 TBA PE-Router-ID
0 0-1 0 0 TBA PE-Address
0 0+ 0 0 TBA PE-Record
Pseudowire Authorization
VPN Authorization
Request Accept Reject Challenge # Attribute
---------------------------------------------------------------------
0-1 0 0 0 TBA Router-Distinguisher
0-1 0 0 0 TBA VPN-ID
1 0 0 0 TBA Attachment-Individual-ID
0 0-1 0 0 TBA Per-Hop-Behavior
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in a packet.
0+ Zero or more instances of this attribute MAY be present in
a packet.
0-1 Zero or one instance of this attribute MAY be present in
a packet.
1 Exactly one instance of this attribute MUST be present in
a packet.
8. Examples
CE/AC Authorization
Request
User-Name = "providerX/atlanta@vpnY.domainZ.net" (CE NAI)
NAS-IP-Address = "1.1.1.1"
Response
VPN-ID = "100:14"
Request
User-Name = "ATM14.0.1" (AC Name)
NAS-IP-Address = "1.1.1.1"
Response
Router-Distinguisher = "1:1.2.3.4:10001"
VPN Authorization
Request
User-Name = "100:14" (VPN-ID)
NAS-IP-Address = "1.1.1.1"
Response
PE-Record = "2.2.2.2:14" (PE-Router-ID:AII)
PE-Record = "2.2.2.2:15"
PE-Record = "3.3.3.3:24"
PE-Record = "3.3.3.3:25"
Request
User-Name = "100:14" (VPN-ID)
NAS-IP-Address = "1.1.1.1"
Response
PE-Record = "2.2.2.2:14:PHB=256"
Pseudowire Authorization
Request
User-Name = "2.2.2.2" (PE-Router-ID)
NAS-IP-Address = "1.1.1.1"
Attachment-Individual-ID = "14"
VPN-ID = "100:14"
Response
Per-Hop-Behavior = "256"
9. Security Considerations
[TBD]
10. IANA Considerations
[TBD]
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.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks
Identifier", RFC 2685, September 1999.
11.2 Informative References
[I-D.ietf-l2vpn-signaling]
Rosen, E. and V. Radoaca, "Provisioning Models and
Endpoint Identifiers in L2VPN Signaling",
Internet-Draft draft-ietf-l2vpn-signaling-02, September
2004.
[I-D.ietf-pwe3-control-protocol]
Martini, L., "Pseudowire Setup and Maintenance using LDP",
Internet-Draft draft-ietf-pwe3-control-protocol-14,
November 2004.
[I-D.ietf-l3vpn-rfc2547bis]
Rosen, E., "BGP/MPLS IP VPNs",
Internet-Draft draft-ietf-l3vpn-rfc2547bis-03, October
2004.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[I-D.ietf-l2vpn-l2-framework]
Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)",
Internet-Draft draft-ietf-l2vpn-l2-framework-05, June
2004.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[RFC3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140, June
2001.
Authors' Addresses
Juha Heinanen Juha Heinanen
TutPro Inc. TutPro Inc.
Utsjoki, Finland Utsjoki
Finland
Email: jh@tutpro.com Email: jh@tutpro.com
Greg Weber Greg Weber (editor)
Cisco Systems Cisco Systems
San Jose, California 10850 Murdock Road
Knoxville, TN 37932
US
Email: gdweber@cisco.com Email: gdweber@cisco.com
12. Full Copyright W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
US
Copyright (C) The Internet Society (2004). All Rights Reserved. Email: mark@townsley.net
This document and translations of it may be copied and furnished to Skip Booth
others, and derivative works that comment on or otherwise explain it Cisco Systems
or assist in its implementation may be prepared, copied, published 7025 Kit Creek Road
and distributed, in whole or in part, without restriction of any Research Triangle Park, NC 27709
kind, provided that the above copyright notice and this paragraph are US
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Email: ebooth@cisco.com
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an Wei Luo
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Cisco Systems
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 170 West Tasman Drive
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION San Jose, CA 95134
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF US
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Email: luo@cisco.com
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/