Network Working Group                                        J. Heinanen
Internet-Draft                                               TutPro Inc.
   draft-ietf-l2vpn-radius-pe-discovery-00.txt
Expires: August 23, 2005                                   G. Weber, Ed.
   Expires: August 2004
                                                             W. Townsley
                                                                S. Booth
                                                                  W. Luo
                                                           Cisco Systems
                                                       February 2004 19, 2005

                Using RADIUS for PE-Based VPN Discovery
              draft-ietf-l2vpn-radius-pe-discovery-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with subject to all provisions
   of Section 10 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 RFC2026 [1].
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   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
   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 August 23, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes how a strategy by which Provider Equipment (PE)
   can be dynamically provisioned for inclusion in PE-based VPNs, a PE of Layer 2
   Virtual Private Networks (L2VPNs).  This layered strategy utilizes
   the Remote Authentication Dial In User Service (RADIUS) protocol as a VPN can use
   RADIUS to authenticate its CEs
   centralized control mechanism and discover the other PEs of the VPN.

Conventions 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.

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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [2].

Table of Contents

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

   This document uses terminology from a VPN at a PE......................5
      5.3 PE Failure Detection [I-D.ietf-l2vpn-l2-framework] 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.
   [I-D.ietf-l2vpn-signaling].

2.  Acronyms

   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
   Radius [3,4]
   RADIUS [RFC2865] to authenticate its CEs and discover the other PEs
   of the VPN.  In Radius RADIUS terms, the CEs are users and the PEs are
   Network Access Servers (NAS) implementing Radius RADIUS client function.
   functionality.

   A VPN can span multiple Autonomous Systems (AS) and multiple
   providers.  Each PE, however, only needs to be a Radius RADIUS client to
   Radius
   RADIUS server of the "local" provider.  In the case of in which a CE
   belongs to a "foreign" VPN, Radius the RADIUS server of the local provider
   acts as a proxy client to
   Radius RADIUS of the foreign provider.

2. Site Identification

   Each CE (a VPN site) is identified by

4.  Information Model

   This document presents a "user name" of the form

       [provider/]site@vpn

   "provider" identifier, if present, denotes model wherein authorization for
   participation in a provider that is the
   administrative owner PE-based VPN can be divided into three different
   layers of the VPN.  It is needed only if a access.

   o  CE connects
   to or AC Authorization
   o  VPN Authorization
   o  Pseudowire Authorization

   The first layer is AC authorization, in which a VPN at first sign of life on
   a PE that does not belong particular AC triggers an authorization resulting in provisioning
   information particular to the owner of circuit in question.  Once the VPN and AC is
   then used by Radius of the PE to proxy requests to Radius of the
   owner of the VPN.

   "site" identifier denotes a site in a VPN identified by "vpn".  As an
   example,

       providerX/atlanta@vpnY.domainZ.net
   could denote a CE called "atlanta" in a
   authorized, its VPN identified by
   "vpnY.domainZ.net", which membership is owned by providerX.

3. RADIUS configuration

   Each "provider" has authorized separately.  This
   authorization step may result in a single Radius that stores all information
   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 number of this protocol, all
   these physical servers MUST at all times share the same database
   content.

   For pseudowire specific
   connections; each VPN, Radius of the provider to which the VPN belongs to MUST
   at all times may be configured with authorized separately.  The
   relationships between these three data representations are shown in
   the diagram below.

   Using a set of "users" that correspond to layered approach allows the potential CEs different stages of the VPN, i.e., CEs that are currently allowed authorization
   to be connected to the VPN at some PE.  User information includes site
   identifier, password, and VPN identifier:

      <site, password, vpn>

   User information MAY satisfied by separate means based on deployment scenario.  It
   also include other information, such as a list
   of PEs to which the CE is allowed to connect to and QoS information
   regarding the CE's connection allows one model to the VPN.

   In addition apply to the above manually configured information, Radius
   keeps dynamically track of the PEs various deployment architectures
   including VPLS and CEs of a VPN in a database
   table that has the following fields:

      <vpn, PE IP addess, site, timestamp>

   received from the PE any Radius request:

      <PE IP address, timestamp>

   Timestamp tells the most recent time when the PE has authenticated
   the site to the VPN.  It is used VPWS.  If all three authorization stages are
   accommodated 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 RADIUS server, the site and PE from its database.

   The PEs MAY also have pre-configured attributes telling, for example,
   that a PE is stages may be combined into a hub
   single transaction instead of a VPN.

   If dynamic having three separate transactions.

                                  +--------+
                                  |        |
                                  |   CE   |
                                  |        |
                                  +--------+
                                       |
             +-------------------------+---------------------------+
             |                         |                           |
             |  VPN               +--------+                       |
             |                    |        |                       |
             |                    |   PE discovery capability of this protocol   |                       |
             |                    |        |                       |
             |                    +--------+                       |
             |                         |                           |
             |                         |                           |
             |     +------------------------------------------+    |
             |     |              +-------------------------+ |    |
             |     | 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 not used,
   Radius MUST be configured for each VPN associated with a list an AII
   o  Each PE includes an arbitrary number of its PEs.  Such
   a degenerate use AIIs
   o  Each PE has one associated next hop address
   o  The VPN includes an arbitrary number of this protocol is not discussed further in this
   memo.

   In order to allow queries about CEs that are connected PEs of a
   "foreign" provider,

   The following two sections define how the Radius servers components of this foreign provider MUST data
   model may be configured represented as clients in RADIUS attributes so the Radius components of the VPN owner.

4. PE Configuration
   Each PE MUST be configured with the
   this information about model may be communicated from a centralized
   location out into the Radius
   servers of local Radius to which to send requests to.  For
   reliability reasons, each PE SHOULD have available more than one
   physical Radius server. network elements.

5. Protocol Operation  New RADIUS Attributes

   This document defines several new RADIUS Attributes which are
   described in detail in this section.

5.1 Connecting a CE to a VPN at  Router-Distinguisher

   This attribute represents a PE

   When Router Distinguisher as described in
   [I-D.ietf-l3vpn-rfc2547bis].  It MAY be included in an Access-Request
   message.  This attribute MUST NOT be included in Access-Request
   messages that also include a CE "VPN-ID" attribute.

   A summary of the Router-Distinguisher attribute format is shown
   below.  The fields are transmitted from left to right.

       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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Type

         (TBA) for Router-Distinguisher.

      Length

         >= 7

      Text

   The Text field is to be connected to a VPN at composed of three colon separated parts: a PE, type, an
   administrator, and an assigned number.

   Where the PE issues a Radius
   Access-Request using type is "0", the user name administrator contains a 16-bit Autonomous
   System Number (ASN), and password of the CE.  The PE
   has either learned this information from the CE via an authentication
   protocol, assigned number is a 32-bit value
   assigned by enterprise responsible for example, 802.1x/EAP, or it has been configured in the
   PE.

   Service-Type of ASN, e.g.  "0:114:23".

   Where the Access-Request type is VPN-Login (value TBD).

   If authentication succeeds "1", the administrator contains an IP address, and possible other (VPN or provider)
   specific preconditions are met (for example,
   the CE assigned number is allowed to
   connect to a 16-bit value assigned by the particular PE and it enterprise
   controlling the IP address space, e.g.  "1:1.2.3.4:10001".

   Where the type is not already connected to some
   other PE), Radius inserts "2", the administrator contains a

      <vpn, PE IP address, site, timestamp>

   record in its database (replacing 32-bit ASN, and
   the assigned number is a possible earlier record that only
   differs 16-bit value assigned by the timestamp value) and responds with an Access-Accept.
   Access-Accept includes as reply items enterprise
   responsible for the ASN, e.g.  "2:70000:216".

5.2  VPN-ID

   This attribute represents a Session-Timeout VPN-ID as described in [RFC2685].  It MAY
   be included in an Access-Request message.  This attribute and
   one or more PE-List attributes that contain all unique PE IP
   addresses MUST NOT be
   included in Access-Request messages that also include a
   Router-Distinguisher attribute.

   A summary of the set

      <vpn, *, *>

   and possibly other CE specific information, e.g., QoS parameters.

   Session-Timeout VPN-ID attribute tells format is shown below.  The fields
   are transmitted from left to the PE right.

       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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Type

         (TBA) for how long time Radius
   considers the CE as connected to the VPN-ID.

      Length

         >= 5

      Text

   The Text field is composed of two colon separated parts: a VPN at the PE unless the PE re-
   authenticates
   authority Organizationally Unique Identifier, and a VPN index, e.g.
   "101:14".

5.3  Attachment-Individual-ID

   This attribute indicates a Attachment-Individual-ID as described in
   [I-D.ietf-l2vpn-signaling].

   A summary of the CE. Attachment-Individual-ID attribute format is shown
   below.  The fields are transmitted from left to right.

       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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Type

         (TBA) for Attachment-Individual-ID.

      Length

         >= 3

      Text

   The value of the timestamp in

      <vpn, PE IP address, site, timestamp>

   record Text field is the time of the Access-Accept plus the number an encoding of seconds in the Session-Timeout attribute.

   PE-List Source Attachment Individual
   Identifier, e.g.  "2".

5.4  Per-Hop-Behavior

   This attribute contains indicates a list of PE IP addresses.  It is only
   used Per-Hop-Behavior as described in Access-Accept packets and has
   [RFC3140].

   A summary of the following format: Per-Hop-Behavior 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     |  String ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             Value
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Value (cont)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

      TBD

         (TBA) for PE-List Per-Hop-Behavior.

      Length

      16 + N * 4 bytes, where 1 <= N <= 63.

      String

      N IP Addresses

         6

      Integer

   The lower 16-bits of PEs (the most significant octet first in each
      address).

   After receiving the Access-Accept, the PE considers value contains the CE Per-Hop-Behavior value as
   connected to the VPN and issues a Start Accounting-Request.

   If authentication fails or some pre-conditions are not met, Radius
   responds with Access-Reject.

   If
   described in [RFC3140].

5.5  PE-Router-ID

   This attribute typically indicates an IPv4 address for a particular
   PE wants for some reason to get from Radius an up-to-date list member of PEs in a particular VPN, though it can at any time issue a new Access-
   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 may be some arbitrary value assigned 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
   which owner of the other PEs ID space.

   A summary of the VPN would be notified that a new CE was
   connected PE-Router-ID 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

         (TBA) for PE-Router-ID.

      Length

         6

      Address

   Typically, the VPN at value indicates the PE or that IPv4 address of a new particular PE became associated
   with the VPN.  Such mechanisms belong to the VPN solution documents
   that utilize the discovery protocol defined in this memo.

5.2 Disconnecting a CE from
   member of a VPN at VPN.

5.6  PE-Address

   This attribute indicates an IPv4 address for a particular PE

   When member
   of a CE is VPN.  In relation to be disconnected from the VPN at a PE, the PE issues for which a
   Stop Accounting-Request.  After receiving the request, Radius removes
   the

      <vpn, PI IP address, site>
   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 is joining the Accounting-Response.

   Note that VPN,
   this document does not define any protocol mechanisms by
   which the other PEs of the VPN would be notified that a CE was
   disconnected from the VPN at the PE or that initial's PE's next hop address.

   A summary of the PE PE-Address attribute format 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

   When a PE recovers shown below.  The
   fields are transmitted from a failure, it re-authenticates all CEs
   connected left to it in all VPNs and thus re-discovers all other PEs in
   all those VPNs.

6. Scaling Limits

   Since Radius protocol operates over UDP, the maximum UDP payload size
   available 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

         (TBA) for Radius attributes is limited to about 1500 - 40 = 1460
   octets assuming that UDP fragmentation is not supported. PE-Address.

      Length

         6

      Address

   The most
   space consuming message is Access-Accept response, which contains a
   list of IP addresses of value indicates the PEs IPv4 address of a particular PE member of a
   VPN.

5.7  PE-Record

   This limits the number attribute represents a single element within a particular PE's
   description.  A group of
   PEs in PE-Records combine to form a complete PE
   description when returned during VPN to about 350.

   Besides the packet size, another factor limiting scalability authorization.

   A summary of this
   protocol might be the periodic re-authentication of CEs as required PE-Record attribute format is shown below.  The
   fields are transmitted from left to right.

       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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Type

         (TBA) for PE-Record.

      Length

         >= 8

      Text

   The Text field contains an AII prefixed by a PE-Router-ID and
   separated by the Session-Timeout reply attribute.  For example, if a provider
   has 3600 VPN sites colon, e.g.  "1.1.1.1:14" where the PE-Router-ID is
   1.1.1.1 and uses the AII is 14.  This represents a Session-Timeout particular pseudowire.
   The value is optionally suffixed by a colon separated list of 1 hour, then
   Radius will get on the average of 1 Access-Requests per second.

7. Compliance with PPVPN L2 Requirements
   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 covers a PE discovery and CE authentication solution defines one new value for provider based VPNs.  Thus only a small subset of the complete
   PPVPN L2 requirements listed in [5] are applicable to this document. an existing RADIUS attribute.
   The solution described Service-Type attribute is defined in this document fulfills all the requirements
   of section 6.3 of [5] on "Discovering L2VPN Related Information".  In
   particular:

     (1) Radius based discovery allows PEs to dynamically discover
         information about other PEs Section 5.6 of a VPN with minimal or even with
         no configuration in the PEs.

     (2) Unauthorized access to RFC 2865
   [RFC2865], as follows:

   This Attribute indicates the VPN can be prevented by
         authentication that is an integral part type of Radius.

     (3) VPN membership information is only distributed to service the PEs that
         have sites that are members of user has requested,
   or the VPN.

   Other aspects mentioned on section 6.3 of [5], such as propagation type of
   membership changes service to be provided.  It MAY be used in a "timely manner" both
   Access-Request and no manual reconfiguration
   of the other PEs, are Access-Accept packets.

   A NAS is not directly covered in this document.  They
   belong required 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
   with implement all applicable generic requirements listed in [5].  In
   particular:

     (1) The PEs of a VPN can be associated with topology and tunneling
         protocol information.

     (2) VPN sites can be associated with QoS these service types, and access control
         information.

     (3) Radius has
   MUST treat unknown or unsupported Service-Types as though an Access-
   Reject had been widely implemented by existing PEs and has
         very good interoperability record.

     (4) Multi-provider/multi-AS VPNs received instead.

   A summary of the Service-Type Attribute format is shown below.

   The fields are readily supported without any
         extra complications.

     (5) CEs 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 require either no configuration or minimal
         configuration (user name/password).

     (6) There authorization is no practical limit on occurring.

   o  For CE/AC authorization, the number of VPNs and, User-Name value contains either a
      Network Access Identifier (NAI) associated with
         hierarchical implementation, each the CE [RFC2486],
      or an implementation dependent AC name.
   o  For VPN can have authorization, the User-Name value contains the VPN-ID or
      a very large
         number Router-Distinguisher.
   o  For pseudowire authorization, the User-Name value contains a
      PE-Router-ID.

7.  Table of PEs and CEs.

     (7) Radius based provisioning systems are readily available and are
         easily adaptable to PE discovery.

   In summary, Radius provides Attributes

   The following tables provide a good directory based alternative guide to
   PPVPN PE discovery which attributes may be found
   in which kinds of packets, and a natural means to authenticate 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 CEs.

8. Security Considerations

   Security of Radius based 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 discovery depends on 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 security meaning of
   Radius that is covered the above table entries.

   0    This attribute MUST NOT be present in [3] and [4].  In multi-provider operation,
   secure tunnels SHOULD a packet.
   0+   Zero or more instances of this attribute MAY be used to carry Radius traffic between
   providers. 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
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2

11.1  Normative References

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

   3  C.

   [RFC2865]  Rigney, et al., C., Willens, S., Rubens, A. and W. Simpson,
              "Remote Authentication Dial In User Service
      (RADIUS)". (RADIUS)",
              RFC 2865, June 2000.

   4  C. Rigney,

   [RFC2868]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
              M. and I. Goyret, "RADIUS Accounting". 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 2866, June 2000.

   5  W. Augustun, Y. Serbest, "Service Requirements 2279, January 1998.

   [I-D.ietf-l2vpn-l2-framework]
              Andersson, L. and E. Rosen, "Framework for Layer 2
      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-
      radius-vpls-00.txt, January Networks (L2VPNs)",
              Internet-Draft draft-ietf-l2vpn-l2-framework-05, June
              2004.

10. Acknowledgments

   The authors would like to thank Mark Duffy, Joel Halpern,

   [RFC2486]  Aboba, B. and Mark
   Townsley for their constructive comments on earlier versions of this
   memo.

11. Author's 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
   TutPro Inc.
   Utsjoki,
   Utsjoki
   Finland

   Email: jh@tutpro.com

   Greg Weber (editor)
   Cisco Systems
   10850 Murdock Road
   Knoxville, TN  37932
   US

   Email: gdweber@cisco.com

   W. Mark Townsley
   Cisco Systems
   7025 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: mark@townsley.net

   Skip Booth
   Cisco Systems
   7025 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: ebooth@cisco.com

   Wei Luo
   Cisco Systems
   170 West Tasman Drive
   San Jose, California CA  95134
   US

   Email: gdweber@cisco.com

12. Full Copyright

   Copyright (C) luo@cisco.com

Intellectual Property Statement

   The Internet Society (2004). All Rights Reserved.

   This document and translations IETF takes no position regarding the validity or scope of it may any
   Intellectual Property Rights or other rights that might be copied and furnished claimed to
   others, and derivative works that comment on or otherwise explain it
   or assist in its
   pertain to the implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction use of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, technology described in
   this document itself may or the extent to which any license under such rights
   might or might not be modified in available; nor does it represent that it has
   made any independent effort to identify any way, such as by removing rights.  Information
   on the copyright notice or references procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the Internet Society IETF Secretariat and any
   assurances of licenses to be made available, or other
   Internet organizations, except as needed for the purpose result of
   developing Internet standards in which case the procedures an
   attempt made to obtain a general license or permission for
   copyrights defined in the Internet Standards process must be
   followed, use of
   such proprietary rights by implementers or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not users of this
   specification can be
   revoked by obtained from the Internet Society or IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its successors attention any
   copyrights, patents or patent applications, or assigns. 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 is 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 DISCLAIMS 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.