RADIUS Option for DHCPv6 Relay Agent
draft-ietf-dhc-dhcpv6-radius-opt-11

DHC Working Group                                                 L. Yeh
Internet-Draft                                   Freelancer Technologies
Intended status: Standards Track                            M. Boucadair
Expires: October 14, 2013                                 France Telecom
                                                          April 12, 2013

                  RADIUS Option for DHCPv6 Relay Agent
                  draft-ietf-dhc-dhcpv6-radius-opt-11

Abstract

   The DHCPv6 RADIUS option provides a mechanism to exchange
   authorization and identification information between the DHCPv6 relay
   agent and the DHCPv6 server.  This mechanism is meant for the
   centralized DHCPv6 server to select the right configuration for the
   requesting DHCPv6 client based on the authorization information
   received from the RADIUS server, which is not co-located with the
   DHCPv6 server.  The Network Access Server (NAS) acts as DHCPv6 relay
   agent and RADIUS client simultaneously in this document.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 14, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Yeh & Boucadair         Expires October 14, 2013                [Page 1]
Internet-Draft            DHCPv6 RADIUS Option                April 2013

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Language . . . . . . . . . . . . . . . . . . .  3
   3.  Network Scenarios  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  DHCPv6 RADIUS option . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  RADIUS attributes permitted in DHCPv6 RADIUS option  . . .  7
   5.  DHCPv6 Relay Agent Behavior  . . . . . . . . . . . . . . . . .  8
   6.  DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . .  8
   7.  DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . .  8
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     11.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     11.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Yeh & Boucadair         Expires October 14, 2013                [Page 2]
Internet-Draft            DHCPv6 RADIUS Option                April 2013

1.  Introduction

   DHCPv6 provides a mechanism that allows the server to assign or
   delegate both stateful and stateless configuration parameters to the
   clients.  The stateful configuration parameters include IPv6 address
   [RFC3315] and IPv6 prefix [RFC3633].  The stateless configuration
   parameters [RFC3736] include, for example, DNS [RFC3646], or a FQDN
   of AFTR [RFC6334].  In the scenarios described in this document, the
   DHCPv6 server is deployed in the central part of an ISP network.

   RADIUS [RFC2865] is widely used as the centralized authentication,
   authorization and user management mechanism for the service provision
   in Broadband access network.  [RFC3162], [RFC4818], [RFC6519] and
   [I-D.ietf-radext-ipv6-access] specified attributes that support the
   service provision for IPv6-only and IPv6-transition access.  RADIUS
   server authorizes the Network Access Server (NAS) to assign an IPv6
   address or prefix from the indicated pool, or to assign an IPv6
   address or prefix with an explicitly indicated value, and other
   configuration parameters as per the attributes for the subscribers.

   These mechanisms work well in the deployment scenarios where the NAS
   acts as the distributed DHCPv6 server.  In that case the NAS directly
   responds the DHCPv6 messages as per the indication conveyed by the
   attributes in the Access-Accept message from the RADIUS server.
   These mechanisms might also work well in the scenario where the
   centralized DHCPv6 server is co-located with the RADIUS server, where
   they can share the same database of the users.  But when the NAS acts
   as the relay agent and RADIUS client simultaneously, and the
   centralized DHCPv6 server is not located in the same place as the
   RADIUS server, a new communication mechanism is needed for the relay
   agent to transfer the authorization information indicated by the
   RADIUS attributes to the DHCPv6 server.

2.  Terminology and Language

   This document specifies a new DHCPv6 option for the DHCPv6 Relay
   Agent to transfer the authorization information of RADIUS attributes
   received in the Access-Accept message from the RADIUS server to the
   centralized DHCPv6 server.  Definitions for terms and acronyms not
   specified in this document are defined in [RFC2865] and [RFC3315].

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

Yeh & Boucadair         Expires October 14, 2013                [Page 3]
Internet-Draft            DHCPv6 RADIUS Option                April 2013

3.  Network Scenarios

   Figure 1 and Figure 2 show the typical network scenarios where the
   communication mechanism introduced in this document is necessary.  In
   these scenarios, the centralized DHCPv6 server is not co-located with
   the RADIUS server, but both of them are in the same administrative
   domain.  The NAS acts as the DHCPv6 relay agent and the RADIUS client
   simultaneously.  Figure 1 shows the sequence of DHCPv6 and RADIUS
   messages for IP over Ethernet (IPoE) access model, when the access
   loop adopts the direct Ethernet encapsulation.  Figure 2 shows the
   sequence of DHCPv6 and RADIUS messages for PPP over Ethernet (PPPoE)
   access model.

   The mechanism introduced in this document is a generic mechanism, and
   might also be employed in other network scenarios where the DHCPv6
   relay agent and the RADIUS client locate in the same device.

Yeh & Boucadair         Expires October 14, 2013                [Page 4]
Internet-Draft            DHCPv6 RADIUS Option                April 2013

   +-------+                   +-------+                    +-------+
   |DHCPv6 |   Access Model:   |  NAS  |                    |RADIUS |
   |Client |       IPoE        |       |                    |Server |
   +-------+                   +-------+                    +-------+
                      RADIUS Client/DHCPv6 Relay Agent

       |                           |                            |
       |---Solicit---------------->|                            |
       |                           |---Access-Request---------->|
       |                           |                            |
       |                           |<--Access-Accept------------|
       |                           |(e.g. Delegated-IPv6-Prefix)|
       |                           |                            |

              DHCPv6 messages             RADIUS messages

                                                            +-------+
                                                            |DHCPv6 |
                                                            |Server |
                                                            +-------+
       |                           |                            |
       |                           |---Relay-forward----------->|
       |                           |  (OPTION_RADIUS)           |
       |                           |                            |
       |                           |<--Relay-reply -------------|
       |<--Advertise---------------|                            |
       |  (e.g. IA_PD)             |                            |
       |                           |                            |
       |---Request---------------->|                            |
       |  (e.g. IA_PD)             |---Relay-forward----------->|
       |                           |  (OPTION_RADIUS)           |
       |                           |                            |
       |                           |<--Relay-reply -------------|
       |" flag is used in the context of
   RPL.  A 6LN operates as a RUL for an IPv6 address iff it sets the "R"
   flag in the EARO used to register the address.  The RPL Router
   generates a DAO message for the Registered Address upon an NS(EARO)
   iff the "R" flag in the EARO is set.  Conversely, this document
   specifies the behavior of a RPL Router acting as 6LR that depends on
   the setting of the "R" flag in the EARO.

3.2.2.  TID, I Field and Opaque Fields

   The EARO also includes a sequence counter called Transaction ID
   (TID), which maps to the Path Sequence Field found in Transit Options
   in RPL DAO messages.  This is the reason why the support of [RFC8505]
   by the RUL as opposed to only [RFC6775] is a prerequisite for this
   specification (more in Section 6.1).  The EARO also transports an
   Opaque field and an "I" field that describes what the Opaque field
   transports and how to use it.  Section 9.2.1 specifies the use of the
   "I" field and of the Opaque field by a RUL.

3.2.3.  ROVR

   Section 5.3. of [RFC8505] introduces the Registration Ownership
   Verifier (ROVR) field of variable length from 64 to 256 bits.  The
   ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was
   used to identify uniquely an Address Registration with the Link-Layer
   address of the owner, but provided no protection against spoofing.

   "Address Protected Neighbor Discovery for Low-power and Lossy
   Networks" [AP-ND] leverages the ROVR field as a cryptographic proof
   of ownership to prevent a rogue third party from misusing the
   address.  [AP-ND] adds a challenge/response exchange to the [RFC8505]
   Address Registration and enables Source Address Validation by a 6LR
   that will drop packets with a spoofed address.

   This specification does not address how the protection by [AP-ND]
   could be extended to RPL.  On the other hand, it adds the ROVR to the
   DAO to build the proxied EDAR at the Root, which means that nodes
   that are aware of the Host route to the 6LN are now aware of the
   associated ROVR as well.

Thubert & Richardson      Expires 18 June 2020                  [Page 8]
Internet-Draft             RPL Unaware Leaves              December 2019

3.3.  RFC 8505 Extended DAR/DAC

   [RFC8505] updates the periodic DAR/DAC exchange that takes place
   between the 6LR and the 6LBR using Extended DAR/DAC messages.  The
   Extended Duplicate Address messages can carry a ROVR field of
   variable size.  The periodic EDAR/EDAC exchange is triggered by a
   NS(EARO) message and is intended to create and then refresh the
   corresponding state in the 6LBR for a lifetime that is indicated by
   the 6LN.  Conversely, RPL [RFC6550] specifies a periodic DAO from the
   6LN all the way to the Root that maintains the routing state in the
   RPL network for a lifetime that is indicated by the source of the
   DAO.  This means that there are two periodic messages that traverse
   the whole network to indicate that an address is still reachable, one
   to the Root and one to the 6LBR.

   This specification saves the support of RPL in a 6LN called a RUL and
   avoids an extraneous periodic flow across the LLN.  The RUL only
   needs to perform a [RFC8505] Address Registration to the 6LR.  The
   6LR turns it into a DAO message to the Root on behalf of the RUL.
   Upon the new DAO, the Root proxies the EDAR exchange to the 6LBR on
   behalf of the 6LR.  This is illustrated in Figure 5.

4.  Updating RFC 6550

   This document specifies a new behavior whereby a 6LR injects DAO
   messages for unicast addresses (see Section 9) and multicast
   addresses (see Section 10) on behalf of leaves that are not aware of
   RPL.  The Targets are exposed as External addresses.  An IP-in-IP
   encapsulation that terminates at the border 6LR is used to remove RPL
   artifacts and compression techniques that may not be processed
   correctly outside of the RPL domain.

   This document also synchronizes the liveness monitoring at the Root
   and the 6LBR.  A same value of lifetime is used for both, and a
   single heartbeat message, the RPL DAO, traverses the RPL network.  A
   new behavior is introduced whereby the RPL Root proxies the EDAR
   message to the 6LBR on behalf of the 6LR (more in Section 5), for any
   6LN, RUL or RAN.

   RPL defines a configuration option that is registered to IANA in
   section 20.14. of [RFC6550].  This specification defines a new flag
   "Root Proxies EDAR/EDAC" (P) that is encoded in one of the reserved
   control bits in the option.  The new flag is set to indicate that the
   Root performs the proxy operation and that all nodes in the network
   must refrain from renewing the 6LBR state directly.  The bit position
   of the "P" flag is indicated in Section 12.1.

Thubert & Richardson      Expires 18 June 2020                  [Page 9]
Internet-Draft             RPL Unaware Leaves              December 2019

   Section 6.3.1.  of [RFC6550] defines a 3-bit Mode of Operation (MOP)
   in the DIO Base Object.  The new "P" flag is defined only for MOP
   value between 0 to 6.  For a MOP value of 7 or above, the flag MAY
   indicate something different and MUST NOT be interpreted as "Root
   Proxies EDAR/EDAC" unless the specification of the MOP indicates to
   do so.

   The RPL Status defined in section 6.5.1. of [RFC6550] for use in the
   DAO-Ack message is extended to be used in the DCO messages
   [EFFICIENT-NPDAO] as well.  Furthermore, this specification enables
   to use a RPL Status to transport the IPv6 ND Status defined for use
   in the EARO, more in Section 7.

   Section 6.7. of [RFC6550] introduces the RPL Control Message Options
   such as the RPL Target Option that can be included in a RPL Control
   Message such as the DAO.  Section 8 updates the RPL Target Option to
   optionally transport the ROVR used in the IPv6 Registration (see
   Section 3.2.3) so the RPL Root can generate a full EDAR Message.

5.  Updating RFC 8505

   This document updates [RFC8505] to introduce a keep-alive EDAR
   message and a keep-alive NS(EARO) message.  The keep-alive messages
   are used for backward compatibility, when the DAO does not transport
   a ROVR as specified in Section 8.  The keep-alive messages have a
   zero ROVR field and can only be used to refresh a pre-existing state
   associated to the Registered Address.  More specifically, a keep-
   alive message can only increase the lifetime and/or increment the TID
   of the existing state in a 6LBR.

   Upon the renewal of a 6LoWPAN ND Address Registration, this
   specification changes the behavior of a RPL Router acting as 6LR for
   the Address Registration as follows.  If the Root indicates the
   capability to proxy the EDAR/EDAC exchange to the 6LBR then the 6LR
   refrains from sending an EDAR message; if the Root is separated from
   the 6LBR, the Root regenerates the EDAR message to the 6LBR upon a
   DAO message that signals the liveliness of the Address.

6.  Requirements on the RPL-Unware Leaf

   This document provides RPL routing for a RUL, that is a 6LN acting as
   an IPv6 Host and not aware of RPL.  Still, a minimal RPL-independent
   functionality is required from the RUL in order to obtain routing
   services from the 6LR.

Thubert & Richardson      Expires 18 June 2020                 [Page 10]
Internet-Draft             RPL Unaware Leaves              December 2019

6.1.  Support of 6LoWPAN ND

   In order to obtain routing services from a RPL 6LR, a RUL MUST
   implement [RFC8505] and set the "R" flag in the EARO option.

   The RUL MUST register to all the 6LRs from which it expects to get
   routing services.  The Address Registrations SHOULD be performed in a
   rapid sequence, using the exact same EARO for a same Address.  Gaps
   between the Address Registrations will invalidate some of the routes
   till the Address Registration finally shows on those routes as well.

   [RFC8505] introduces error Status values in the NA(EARO) which can be
   received synchronously upon an NS(EARO) or asynchronously.  The RUL
   MUST support both cases and refrain from using the Registered Address
   as specified by [RFC8505] depending on the Status value.

   A RUL SHOULD support [AP-ND] to protect the ownership of its
   addresses.

6.2.  External Routes and RPL Artifacts

   Section 4.1. of [USEofRPLinfo] provides a set of rules that MUST be
   followed when forwarding packets over an external route:

   RPL data packets are often encapsulated using IP-in-IP and in Non-
   Storing Mode, packets going down will carry an SRH as well.  RPL data
   packets also typically carry a Hop-by-Hop Header to transport a RPL
   Packet Information (RPI) [RFC6550].  These additional headers are
   called RPL artifacts.

   When IP-in-IP is used and the outer headers terminate at a 6LR down
   the path (see Figure 9 for the compressed format in Storing Mode),
   then the 6LR decapsulates the IP-in-IP and the packet that is
   forwarded to the external destination is free of RPL artifacts - but
   possibly an RPI if packet was generated by a RAN in the same RPL
   domain as the destination RUL.

   Non-Storing Mode DAO messages are used to signal external routes to
   the Root, even if the DODAG is operated in Storing Mode.  This
   enables to advertise the 6LR that injects the route for use as tunnel
   endpoint in the data path.

   For all external routes, the Root should use an IP-in-IP tunnel to
   that 6LR, with the RPL artifacts in the outer header to be stripped
   by the 6LR.  The IP-in-IP encapsulation may be avoided in Storing
   Mode if the path to the external destination beyond the 6LR is known
   to handle or ignore the RPL artifacts properly [RFC8200].

Thubert & Richardson      Expires 18 June 2020                 [Page 11]
Internet-Draft             RPL Unaware Leaves              December 2019

   A RUL is an example of a destination that is reachable via an
   external (Host) route for which IP-in-IP tunneling may be avoided as
   it ignores the RPI and the consumed SRH artifacts.  The use of non-
   Storing Mode signaling in Storing Mode and the associated IP-in-IP
   encapsulation are transparent to intermediate Routers that only see
   packets back and forth between the Root and the 6LR and do not need a
   special support for external routes.

   The RUL may not support IP-in-IP tunneling [RFC8504], so if IP-in-IP
   is used, and unless the Root as a better knowledge, the tunnel should
   terminate at the 6LR that injected the external route to the RUL.

   Additionally, the RUL is not expected to support the compression
   method defined in [RFC8138].  The 6LR that injected the route MUST
   uncompress the packet before forwarding over an external route, even
   when delivering to a RUL, even when it is not the destination in the
   outer header of the incoming packet, unless configured to do
   otherwise.

6.2.1.  Support of the HbH Header

   A RUL is expected to process an unknown Option Type in a Hop-by-Hop
   Header as prescribed by section 4.2 of [RFC8200].  This means in
   particular that an RPI with an Option Type of 0x23 [USEofRPLinfo] is
   ignored when not understood.

6.2.2.  Support of the Routing Header

   A RUL is expected to process an unknown Routing Header Type as
   prescribed by section 4.4 of [RFC8200].  This means in particular
   that Routing Header with a Routing Type of 3 [RFC6553] is ignored
   when the Segments Left is zero, and dropped otherwise.

6.2.3.  Support of IPv6 Encapsulation

   Section 2.1 of [USEofRPLinfo] sets the rules for forwarding IP-in-IP
   either to the final 6LN or to a parent 6LR.  In order to enable IP-
   in-IP to the 6LN in Non-Storing Mode, the 6LN must be able to
   decapsulate the tunneled packet and either drop the inner packet if
   it is not the final destination, or pass it to the upper layer for
   further processing.  Unless it is aware that the RUL can handle IP-
   in-IP properly, the Root that encapsulates a packet to a RUL
   terminates the IP-in-IP tunnel at the parent 6LR . For that reason,
   it is beneficial but not necessary for a RUL to support IP-in-IP.

Thubert & Richardson      Expires 18 June 2020                 [Page 12]
Internet-Draft             RPL Unaware Leaves              December 2019lt;--Reply-------------------|                            |
       |  (e.g. IA_PD)             |                            |
       |                           |                            |

              DHCPv6 messages             DHCPv6 messages

   Figure 1: Network scenario and message sequence when employing DHCPv6
                       RADIUS option in IPoE access

Yeh & Boucadair         Expires October 14, 2013                [Page 5]
Internet-Draft            DHCPv6 RADIUS Option                April 2013

   +-------+                   +-------+                    +-------+
   |DHCPv6 |   Access Model:   |  NAS  |                    |RADIUS |
   |Client |      PPPoE        |       |                    |Server |
   +-------+                   +-------+                    +-------+
                      RADIUS Client/DHCPv6 Relay Agent

       |                           |                            |
       |--PPP LCP Config-Request-->|                            |
       |                           |---Access-Request---------->|
       |                           |                            |
       |                           |<--Access-Accept------------|
       |<----PPP LCP Config-ACK----|(e.g. Delegated-IPv6-Prefix)|
       |                           |                            |

               PPP messages               RADIUS messages

                                                            +-------+
                                                            |DHCPv6 |
                                                            |Server |
                                                            +-------+
       |                           |                            |
       |---Solicit---------------->|                            |
       |                           |---Relay-forward----------->|
       |                           |  (OPTION_RADIUS)           |
       |                           |                            |
       |                           |<--Relay-reply -------------|
       |<--Advertise---------------|                            |
       |  (e.g. IA_PD)             |                            |
       |                           |                            |
       |---Request---------------->|                            |
       |  (e.g. IA_PD)             |---Relay-forward----------->|
       |                           |  (OPTION_RADIUS)
       |                           |                            |
       |                           |<--Relay-reply -------------|
       |<--Reply-------------------|                            |
       |  (e.g. IA_PD)             |                            |
       |                           |                            |

              DHCPv6 messages             DHCPv6 messages

   Figure 2: Network scenario and message sequence when employing DHCPv6
                       RADIUS option in PPPoE access

   If the authentication or the authorization through RADIUS fails, the
   associated message sequences will stop.  The NAS acting as the DHCPv6
   relay agent will not forward the message received from the client to
   the DHCPv6 server.  If the authentication or the authorization
   through RADIUS passes, the NAS MUST store the information indicated

Yeh & Boucadair         Expires October 14, 2013                [Page 6]
Internet-Draft            DHCPv6 RADIUS Option                April 2013

   in the RADIUS attributes received in the Access-Accept message from
   the RADIUS server during the whole session.  How the NAS manages
   these information during the RADIUS session is out of the scope of
   this document.

   After receiving RENEW (5) message from the DHCPv6 client, the NAS
   SHOULD NOT initiate a new Access-Request/Access-Accept message
   exchange with the RADIUS server; but after receiving REBIND (6)
   message from the DHCPv6 client, the NAS SHOULD initiate a new Access-
   Request/Access-Accept message exchange with the RADIUS server.

4.  DHCPv6 RADIUS option

   The OPTION_RADIUS is a DHCPv6 option used by the DHCPv6 relay agent
   to carry the authorization information of RADIUS attributes received
   in the Access-Accept message from the RADIUS server.

   The format of the OPTION_RADIUS option is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         OPTION_RADIUS         |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            option-data (List of RADIUS Attributes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code      TBD
   option-len       Length of the option-data in octets
   option-data      List of one or more RADIUS attributes

   The option-data of OPTION_RADIUS is a list of one or more RADIUS
   attributes received in the Access-Accept message from the RADIUS
   server.  The OPTION_RADIUS can only contain the RADIUS attributes
   listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6
   RADIUS option'.

   According to the network scenarios described in section 3, the
   OPTION_RADIUS SHOULD appear in the RELAY-FORW (12) message relaying
   SOLICIT (1), REQUEST (3) and REBIND (6) from the DHCPv6 client, and
   MAY appear in the RELAY-FORW (12) relaying any other message from the
   DHCPv6 client.

4.1.  RADIUS attributes permitted in DHCPv6 RADIUS option

   The RADIUS attributes listed in the below table are recommended as
   the first batch of attributes in the IANA Registry of 'RADIUS

Yeh & Boucadair         Expires October 14, 2013                [Page 7]
Internet-Draft            DHCPv6 RADIUS Option                April 2013

   attributes permitted in DHCPv6 RADIUS option'.  New RADIUS attributes
   MAY be added to this list after the IETF Expert Review [RFC5226].

   Type Code  Attribute                   Reference
   26         Vendor-Specific             [RFC2865]
   123        Delegated-IPv6-Prefix       [RFC4818]
   144        DS-Lite-Tunnel-Name         [RFC6519]
   168        Framed-IPv6-Address         [I-D.ietf-radext-ipv6-access]
   169        DNS-Server-IPv6-Address     [I-D.ietf-radext-ipv6-access]
   171        Delegated-IPv6-Prefix-Pool  [I-D.ietf-radext-ipv6-access]
   172        Stateful-IPv6-Address-Pool  [I-D.ietf-radext-ipv6-access]

   Note: The RADIUS attribute's 'Length' defined in section 5 of
   [RFC2865] includes the length of 'Type' and 'Length' fields.

5.  DHCPv6 Relay Agent Behavior

   The DHCPv6 relay agent MAY include OPTION_RADIUS in the RELAY-FORW
   (12) message.  When the value in the attributes, for example,
   Delegated-IPv6-Prefix-Pool (171), Stateful-IPv6-Address-Pool (172),
   Delegated-IPv6-Prefix (123) or Framed-IPv6-Address (168) in the
   Access-Accept message replied from RADIUS server are valid, the relay
   agent that supports OPTION_RADIUS SHOULD include these RADIUS
   attributes into the OPTION_RADIUS one by one.

6.  DHCPv6 Server Behavior

   Upon receipt of the RELAY-FORW (12) message with OPTION_RADIUS from a
   relay agent, the DHCPv6 server that supports OPTION_RADIUS SHOULD
   extract and interpret the RADIUS attributes in the OPTION_RADIUS, and
   use that information in selecting configuration parameters for the
   requesting client.  If the DHCPv6 server does not support
   OPTION_RADIUS, the DHCPv6 server MUST silently discard this option.

7.  DHCPv6 Client Behavior

   OPTION_RADIUS is only exchanged between the relay agents and the
   servers.  DHCPv6 clients are not aware of the usage of OPTION_RADIUS.
   DHCPv6 client MUST NOT send OPTION_RADIUS, and MUST ignore
   OPTION_RADIUS if received.

8.  Security Considerations

   Known security vulnerabilities of the DHCPv6 and RADIUS protocol may

Yeh & Boucadair         Expires October 14, 2013                [Page 8]
Internet-Draft            DHCPv6 RADIUS Option                April 2013

   apply to its options.  Security issues related with DHCPv6 are
   described in section 23 of [RFC3315].  Security issues related with
   RADIUS are described in section 8 of [RFC2865], section 5 of
   [RFC3162].

   The mechanism described in this document may introduce new attack
   vector against the DHCPv6 server in case the DHCPv6 relay agent is
   compromised.  By forging the RADIUS attributes contained in the
   OPTION_RADIUS of the RELAY-FORW (12) messages, the attacker may
   influence the parameter assignment on the DHCPv6 server for the
   DHCPv6 clients.  However, in the network scenarios described in the
   section 3, NAS could always be regarded as a trusted network
   component in the real deployment.

9.  IANA Considerations

   This document requests to assign a new DHCPv6 option code for
   OPTION_RADIUS defined in section 4, and to create a new registry on
   the same assignment page, which is entitled as 'RADIUS attributes
   permitted in DHCPv6 RADIUS option' defined in section 4.1.  The new
   registry will enumerate the RADIUS Attributes Types
   (http://www.iana.org/assignments/radius-types/radius-types.xml) that
   are permitted to be included in the DHCPv6 RADIUS option.  New RADIUS
   attributes MAY be added to this list after the IETF Expert Review
   [RFC5226].  The IETF expert review SHOULD include careful
   consideration of the security implications of allowing the relay
   agent to include the RADIUS attribute being considered for addition
   to this registry.

10.  Acknowledgements

   Thanks to Tomek Mrugalski, Bernie Volz, Gaurav Halwasia and Roberta
   Maglione for their thorough review comments in the mailing list of
   DHC working group, to Ted Lemon for his continuous encouragement and
   technical guidance.

11.  References

11.1.  Normative References

   [I-D.ietf-radext-ipv6-access]
              Dec, W., Sarikaya, B., Zorn, G., Miles, D., and B.
              Lourdelet, "RADIUS attributes for IPv6 Access Networks",
              draft-ietf-radext-ipv6-access-16 (work in progress),
              February 2013.

Yeh & Boucadair         Expires October 14, 2013                [Page 9]
Internet-Draft            DHCPv6 RADIUS Option                April 2013

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

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4818]  Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
              Attribute", RFC 4818, April 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6519]  Maglione, R. and A. Durand, "RADIUS Extensions for Dual-
              Stack Lite", RFC 6519, February 2012.

11.2.  Informative References

   [RFC3162]  Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
              RFC 3162, August 2001.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              December 2003.

   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, April 2004.

   [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
              RFC 6334, August 2011.

Yeh & Boucadair         Expires October 14, 2013               [Page 10]
Internet-Draft            DHCPv6 RADIUS Option                April 2013

Authors' Addresses

   Leaf Y. Yeh
   Freelancer Technologies
   P. R. China

   Email: leaf.yeh.sdo@gmail.com

   Mohamed Boucadair
   France Telecom
   France

   Email: mohamed.boucadair@orange.com

Yeh & Boucadair         Expires October 14, 2013               [Page 11]