[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   DHC Working Group                                        Ralph Droms
                                                          Cisco Systems
   Internet Draft                                       Wing Cheong Lau
   Document: draft-droms-dhc-v6-relayopt-00.txt                Qualcomm
   Expires: March 2005                                     October 2004


                   DHCPv6 Relay Agent Information Option


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.




Abstract

   This document introduces the capabilities of the DHCPv4 Relay Agent
   Information Option in RFC 3046 and the corresponding RADIUS-
   Attributes Sub-option to DHCPv6. In particular, the document
   describes a new DHCPv6 option called the Relay Agent Information
   option which extends the set of DHCPv6 options as defined in RFC 3315
   and 3376. Following its DHCPv4 counterpart as defined in RFC 3046,
   the new option is inserted by the DHCPv6 relay agent when forwarding
   client-originated DHCPv6 packets to a DHCPv6 server. Servers
   recognizing the Relay Agent Information option may use the
   information to implement IP address or other parameter assignment
   policies.  The DHCP Server echoes the option back verbatim to the
   relay agent in server-to-client replies, and the relay agent strips


                      Expires - April 2005                    [Page 1]


                DHCPv6 Relay Agent Information Option        Oct 2004


   the option before forwarding the reply to the client. The Relay Agent
   Information option is organized as a single DHCPv6 option that
   contains one or more "sub-options" that convey information known by
   the relay agent.  A RADIUS Attributes Sub-option, following its
   DHCPv4 counterpart, is also defined.


Conventions used in this document

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

   The use of the standard keywords MUST, SHOULD, MUST NOT and SHOULD
   NOT within this specification are with respect to RADIUS clients and
   servers that implement the optional features of this specification,
   do not create any normative requirements outside of that scope and do
   not modify the base RADIUS specifications, such as RFC2865 [6] or
   RFC2866 [11].

   Throughout this document, "DHCP" refers to DHCP for IPv6 unless
   explicitly stated otherwise.

Table of Contents

   1. Motivation and Introduction....................................2
   2. Terminology....................................................4
      2.1 DHCP Terminology...........................................4
      2.2 RADIUS Terminology.........................................5
   3. Relay Agent Information Option for DHCPv6......................5
      3.1 Relay Agent Operation......................................7
      3.2 Server Operation...........................................8
      3.3 DHCP Client Behavior.......................................8
   4. Relay Agent Information Sub-options............................8
      4.1 RADIUS Attributes sub-option...............................8
   5. Security Considerations.......................................10
   6. IANA Considerations...........................................11
   7. Acknowledgments...............................................11
   8. Intellectual Property Statement...............................11
   9. Full copyright statement......................................12
   Authors' Addresses...............................................12
   References.......................................................12


1. Motivation and Introduction

   In 3GPP2 networks, the Packet Data Service Node (PDSN) provides the
   function of a Network Access Server (NAS) to enable authenticated
   network access of its clients, i.e. the mobile stations (MS). The


                         Expires - April 2005                 [Page 2]


                DHCPv6 Relay Agent Information Option        Oct 2004


   PDSN also acts as a DHCPv6 relay agent to forward requests and
   responses between an MS and a DHCPv6 server within the network. The
   DHCPv6 server may be used for assigning DNS server, Mobile IPv6 Home
   agent (HA), Mobile IPv6 Home address (HoA) [9,10] and other
   configuration parameters for the MS. The PDSN, using RADIUS as an
   authentication authority, will receive attributes from a RADIUS
   server that may be used by the DHCP server in the selection of
   configuration parameters to be delivered to the MS through its DHCP
   client. The Relay Agent Information option, together with the RADIUS
   Attributes sub-option enable a network element like the PDSN in 3GPP2,
   to pass along attributes for the user of a device received during
   RADIUS authentication to a DHCP server.

   The RADIUS Attributes sub-option for the DHCP Relay Agent Information
   option provides a way in which a NAS, such as the 3GPP2 PDSN, can
   pass attributes obtained from a RADIUS server to a DHCP server [3].
   The 3GPP2 access authentication mechanism is an example through which
   a PDSN (which doubles as the NAS) can authenticate the identity of
   the user of a device before providing network access using RADIUS as
   the Authentication Service specified in [6]. In 3GPP2 authenticated
   access, an MS must first exchange some authentication credentials
   with the PDSN. The PDSN then supplies these credentials to a RADIUS
   server, which eventually sends either an Access-Accept or an Access-
   Reject in response to an Access-Request. The PDSN, based on the reply
   of the RADIUS server, then allows or denies network access to the
   requesting device.

   Figure 1 summarizes the message exchange among the participants in
   3GPP2 network access authentication.



            +------------------+
            |Mobile Station(MS)|
            |    requesting    |
            |  network access  |
            +------------------+
                |         ^
                |         |
               (1) Request for access
                |         |
                |        (4) Success/Failure
                v         |
            +-------------------+
            |    3GPP2 PDSN     |
            |  (Acts as NAS     |
            |       and         |
            |DHCPv6 relay agent)|
            +-------------------+


                         Expires - April 2005                 [Page 3]


                DHCPv6 Relay Agent Information Option        Oct 2004


                  |     ^
                  |     |
                 (2) Request for authentication
                  |     |
                  |    (3) Access-Accept/Reject
                  v     |
            +-----------------+
            |     RADIUS      |
            |     Server      |
            +-----------------+

                                   Figure 1

   In the application described in this document, the PDSN acts as a NAS
   as well as a DHCPv6 relay agent. It adds a DHCP Relay Agent
   Information option which includes a RADIUS Attributes sub-option to
   DHCP messages. At the successful conclusion of network access
   authentication, a RADIUS Access-Accept provides attributes for
   service authorizations to the NAS. The NAS stores these attributes
   locally. When the NAS subsequently forwards DHCP messages from the
   device requesting network access, the NAS adds these attributes in a
   RADIUS Attributes Sub-option for the Relay Agent Information option.

   This document uses 3GPP2 access authentication as an example to
   motivate the use of the Relay Agent Information option and the RADIUS
   Attributes sub-option by a NAS. The Relay Agent Information option is
   not limited to use in conjunction with RADIUS sub-option when other
   sub-options are defined in the future. The RADIUS Attributes sub-
   option for the Relay Agent Information option described in this
   document is not limited to use in conjunction with 3GPP2 and can be
   used to carry RADIUS attributes obtained by the relay agent for any
   reason.  That is, the sub-option is not limited to use with 3GPP2,
   but is constrained by RADIUS semantics.

   The scope of applicability of this specification is such that the NAS
   (which acts as a DHCP relay agent), any other participating DHCP
   relay agent, the DHCP server and DHCP client should be within the
   same administrative domain while the RADIUS service involved may span
   multiple administrative domains. See the Section 5 for details of
   security considerations when this specification is deployed with
   RADIUS service operating across multiple administrative domains.
   Global interoperability of this specification, across arbitrary
   administrative domains, is not supported.

2. Terminology


2.1   DHCP Terminology



                         Expires - April 2005                 [Page 4]


                DHCPv6 Relay Agent Information Option        Oct 2004


   The following terms are used as defined in RFC3315 and RFC3736: DHCP
   relay agent, DHCP server, DHCP client, Stateless DHCP.

2.2     RADIUS Terminology

   The following terms are used in conjunction with RADIUS:

   RADIUS server: A RADIUS server is responsible for receiving user
   connection requests, authenticating the user, and then returning
   all configuration information necessary for the client to deliver
   service to the user.

   Attribute: A Type-Length-Value tuple encapsulating data elements as
   defined in RFC 2865 [6].

   NAS: A Network Access Server (NAS) provides access to the network and
   operates as a client of RADIUS. The client is responsible for passing
   user information to designated RADIUS servers, and then acting on the
   response which is returned.


3. Relay Agent Information Option for DHCPv6

   To support the capability of a PDSN as described in Section 1, we
   introduce the DHCPv6 counterpart of the DHCPv4 Relay Agent
   Information Option and the related RADIUS Attributes Sub-option as
   defined in RFC3046 [12] and [13] respectively. In particular, this
   document describes a new DHCPv6 option called the Relay Agent
   Information option which extends the set of DHCPv6 options as defined
   in RFC 3315 [3] and 3736 [4]. Following its DHCPv4 counterpart as
   defined in RFC 3046, the new option is inserted by the DHCPv6 relay
   agent when forwarding client-originated DHCPv6 packets to a DHCPv6
   server.  Servers recognizing the Relay Agent Information option may
   use the information to implement IP address or other parameter
   assignment policies.  The DHCP Server echoes the option back verbatim
   to the relay agent in server-to-client replies, and the relay agent
   strips the option before forwarding the reply to the client.


   The new DHCPv6 Option is called the Relay Agent Information Option.
   It is a "container" option for specific agent supplied sub-options.
   The format of the Relay Agent Information option follows that of the
   DHCP Options as defined in Section 22.1 of RFC 3315 [3] 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_RELAY_INFO        |           option-len          |


                         Expires - April 2005                 [Page 5]


                DHCPv6 Relay Agent Information Option        Oct 2004


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Agent Information Field                    |
   |                    (variable no. of octets)                   |
   .                                                               .
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         option-code   OPTION_RELAY_INFO (TBD). This is the DHCP option
                       code for the Relay Agent Information Option

         option-len    An unsigned integer giving the length of the
                       Agent Information Field in octets.

         Agent Information Field
                       This consists of a sequence of
                       SubOpt/Length/Value tuples for each sub-option,
                       encoded in the following manner:


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |sub-option-code|sub-option-len |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               .
   .                    sub-option-value field                     .
   .                  (variable no. of octets)                     .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        sub-option-code  An unsigned integer identifying the specific
                         sub-option type carried in this sub-option.

        sub-option-len   An unsigned integer giving the length the
                         sub-option value in octets.

        sub-option-value field
                       This consists of a sequence of octets carrying
                       the sub-option value.


   Since at least one sub-option must be defined, the minimum option-len
   for the Relay Agent Information option length is two (2).  The length
   an sub-option shall be the number of octets in that sub-option's
   value field. A sub-option length may be zero.  The sub-options need
   not appear in sub-option code order.

   The initial assignment of DHCP Relay Agent Sub-options is as follows:


                         Expires - April 2005                 [Page 6]


                DHCPv6 Relay Agent Information Option        Oct 2004



             DHCP Agent           Sub-Option Description
             Sub-option Code
             ---------------      ----------------------
             SUBOPT_RADIUS (TBD)  RADIUS-Attributes Sub-option


3.1   Relay Agent Operation

   Overall adding of the DHCP relay agent option SHOULD be configurable,
   and SHOULD be disabled by default.  Relay agents SHOULD have separate
   configurables for each sub-option to control whether it is added to
   client-to-server packets.

   The operation of relay agents for specific sub-options is specified
   with that sub-option.

   Relay agents are NOT required to monitor or modify client-originated
   DHCP packets addressed to a server unicast address.


   3.1.1 Relaying a Message from a Client

   When a relay agent receives a valid DHCP message to be relayed from a
   client, it constructs a new Relay-forward message per Section 20.1.1
   of RFC 3315 [3] and then adds to the Relay-forward message the Relay
   Agent Information Option if it is configured to do so. The relay
   agent must be aware of the recommendations on packet sizes and the
   use of fragmentation in Section 5 of RFC 2460 [8].


   3.1.2 Relaying a Message from a Relay Agent

   When a relay agent receives a valid Relay-forward message from
   another relay agent closer to the client, regardless of whether the
   message already includes a Relay Agent Information option or not, the
   relay agent shall construct a new Relay-forward message per Section
   20.1.2 of RFC 3315 [3] and then add to this newly created Relay-
   forward message the Relay Agent Information Option if it is
   configured to do so. The relay agent must be aware of the
   recommendations on packet sizes and the use of fragmentation in
   Section 5 of RFC 2460 [8].


   3.1.3 Relaying a Replay-reply Message

   The Relay Agent Information option echoed by a server MUST be removed
   by the relay agent which added it when forwarding a server-to-client
   response back to the client.


                         Expires - April 2005                 [Page 7]


                DHCPv6 Relay Agent Information Option        Oct 2004




3.2  Server Operation

   DHCP servers unaware of the Relay Agent Information option will
   ignore the option upon receive and will not echo it back on
   responses.  This is the specified server behavior for unknown
   options.

   DHCP servers claiming to support the Relay Agent Information option
   MUST discard the message and increment an error count if a Relay
   Agent Information option was added by a DHCP client but not by a
   relay agent. (This situation can be identified by the nesting of a
   Relay Agent Information option inside the content of the Relay
   Message option created by the first-hop relay agent.) We put the
   responsibility of such checking to the DHCP server instead of the
   relay agents in order to simplify the operations of the latter.
   Furthermore, it is unreasonable to require a relay agent not
   supporting/ understanding the Relay Agent Information option to
   perform such checking.

   DHCP servers claiming to support the Relay Agent Information option
   MUST echo the entire contents of the Relay Agent Information option
   in all of its relay-replies. The nesting of the echoed Relay-Agent
   Information option(s) within the possibly nested relay-reply message
   MUST be according to the nesting order of those options within the
   original the Relay-forward message. DHCP servers must be aware of the
   recommendations on packet sizes and the use of fragmentation in
   Section 5 of RFC 2460 [8].

   The operation of DHCP servers for specific sub-options is specified
   with that sub-option.



3.3   DHCP Client Behavior

   Relay agent options are exchanged only between relay agents and DHCP
   server, so DHCP clients are never aware of their use.


4. Relay Agent Information Sub-options

4.1   RADIUS Attributes sub-option

      The RADIUS Attributes Sub-option is a sub-option for the DHCP
      Relay Agent option.

      The format of the RADIUS Attributes sub-option is:


                         Expires - April 2005                 [Page 8]


                DHCPv6 Relay Agent Information Option        Oct 2004



    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SUBOPT_RADIUS |sub-option-len |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               .
   .                      RADIUS attributes                        .
   .                  (variable no. of octets)                     .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The RADIUS attributes are encoded as a sequence of octets according
   to the encoding rules in RFC 2865 [6].


   4.1.1  DHCP Relay Agent Behavior for the RADIUS Attributes Sub-option

   When the DHCP relay agent receives a DHCP message from the client, it
   MAY append a DHCP Relay Agent Information option containing the
   RADIUS Attributes sub-option, along with any other sub-options it is
   configured to supply.  The RADIUS Attributes sub-option MUST only
   contain the attributes provided in the RADIUS Access/Accept message.
   The DHCP relay agent MUST NOT add more than one RADIUS Attributes
   sub-option in a message.

   The relay agent MUST include the User-Name and IPv6 Framed-Pool
   attributes in the RADIUS Attributes sub-option if available, and MAY
   include other attributes.

   In order to avoid dependencies between the address allocation and
   other state information between the RADIUS server and the DHCP server,
   the DHCP relay agent SHOULD include only the attributes in the table
   below an instance of the RADIUS Attributes sub-option.  The table
   lists attributes that MAY be included:

               #   Attribute
             ---   ---------
               1   User-Name (RFC 2865 [6])
               6   Service-Type (RFC 2865)
              26   Vendor-Specific (RFC 2865)
              27   Session-Timeout (RFC 2865)
             100   Framed-IPv6-Pool (RFC 3162 [7])


   4.1.2   DHCP Server Behavior

   When the DHCP server receives a message from a relay agent containing
   a RADIUS Attributes sub-option, it extracts the contents of the sub-


                         Expires - April 2005                 [Page 9]


                DHCPv6 Relay Agent Information Option        Oct 2004


   option and uses that information in selecting configuration
   parameters for the client. If the relay agent forwards RADIUS
   attributes not included in the table in Section 4.1.1, the DHCP
   server SHOULD ignore them. If the DHCP server uses attributes not
   specified here, it might result in side effects not anticipated in
   the existing RADIUS specifications.



5. Security Considerations

   The DHCP Relay Agent Information option depends on a trusted
   relationship between the DHCP relay agent and the server. If a client
   message is relayed through multiple relay agents, each of the relay
   agents must have established independent, pairwise trust
   relationships. While the introduction of fraudulent relay-agent
   options can be prevented by a perimeter defense that blocks these
   options unless the relay agent is trusted, a deeper defense using,
   e.g. IPsec [5] as described in Section 21.1 of RFC 3315 [3] SHOULD be
   deployed as well.

   There are several data in a DHCP message that convey information that
   may identify an individual host on the network. Depending on the type
   of data included, the Relay Agent Information option and its sub-
   options may also convey information that identifies a specific host
   or a specific user on the network. In practice, this information
   isn't exposed outside the internal service-provider network, where
   DHCP messages are usually confined. Administrators who configure data
   that's going to be used the Relay Agent Information option and its
   sub-options should be careful to use data that are appropriate for
   the types of networks they administer. If DHCP messages travel
   outside the service-provider's own network, or if the sub-option
   values may become visible to other users, that may raise privacy
   concerns for the access provider or service provider.

   The RADIUS protocol [6] was designed for intra-domain use, where the
   NAS, proxy, and home server exist within a single administrative
   domain, and proxies may be considered a trusted component. However,
   under roaming situation, the NAS, proxies, and home server will
   typically be managed by different administrative entities. As a
   result, inter-domain RADIUS operations are inherently required for
   roaming applications, and proxies cannot necessarily be trusted.
   Refer to Section 7 of RFC 2609 for a detailed security threat
   analysis, limitations and precautions of operating RADIUS in a inter-
   domain environment. In general, robust and secure operations of
   RADIUS across multiple administrative domains require pre-established
   agreement, mutual trust, and secure communications channel amongst
   all the participating domains.



                         Expires - April 2005                [Page 10]


                DHCPv6 Relay Agent Information Option        Oct 2004



6. IANA Considerations

   IANA is requested to assign a new option code, in the registry of DHCP
   option codes, for the DHCP Relay Agent Information Option.

   IANA is also requested to maintain a new number space of "DHCPv6
   Relay Agent Information Option Sub-options".  The initial sub-options
   are described in Section 4 of this document. In particular, IANA is
   requested to assign Sub-option number for RADIUS-Attributes Sub-
   option.

   IANA assigns future DHCP Relay Agent Information Option Sub-options
   with a "IETF Consensus" policy as described in RFC 2434.  Future
   proposed sub-options are to be referenced symbolically in the
   Internet-Drafts that describe them, and shall be assigned numeric
   codes by IANA when approved for publication as an RFC.


7. Acknowledgments

   Many thanks to M. Patrick, R. Droms, J. Schnizlein, M. Stapp, R.
   Johnson and T. Palaniappan as this document is based on their work on
   the DHCPv4 relay agent information option RFC3046 [12] and the
   related sub-options [13,14]. The document follows closely the
   original structure and borrows text from [12,13,14]. The 2nd author
   would also like to thank P. Barany, T. Hardie, R. Hsu, M. Lioy, A.C.
   Mahendran, R. Rezaiifar, S. Veerepalli and J. Wang for their helpful
   discussions.


8. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary


                         Expires - April 2005                [Page 11]


                DHCPv6 Relay Agent Information Option        Oct 2004


   rights which may cover technology that may be required to practice
   this document.  Please address the information to the IETF Executive
   Director.

9. Full copyright statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.
   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.


Authors' Addresses

   Ralph Droms
   Cisco Systems
   1414 Massachusetts Avenue
   Boxborough, MA 01719
   U.S.A.
   Email: rdroms@cisco.com

   Wing Cheong Lau
   Qualcomm
   5775 Morehouse Drive
   San Diego, CA 92121
   U.S.A.
   Phone: 858-651-5032
   Email: lau@qualcomm.com


References

   Normative References

   [1]Bradner, S., "Intellectual Property Rights in IETF Technology",
      BCP 79, RFC 3668, Feb. 2004.

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

   [3]Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6
      (DHCPv6)", RFC 3315, July 2003.



                         Expires - April 2005                [Page 12]


                DHCPv6 Relay Agent Information Option        Oct 2004


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

   [5]Kent, S. and Atkinson R., "Security Architecture for the Internet
      Protocol", RFC 2401, Nov. 1998.

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

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

   [8]Deering, S and Hinden, R., "Internet Protocol Version 6 (IPv6)
      Specification", RFC 2460, Dec.  1998.

   Informative References

   [9]3GPP2 X.S0011-002-D v.0.4, "cdma2000 Wireless IP Network
      Standard:Simple IP and Mobile IP services," Work in progress.

   [10]Johnson, D, Perkins, C. and Arkko, J., "Mobility Support in
       IPv6", RFC 3775, June 2004.

   [11]Rigney, C. "RADIUS Accounting", RFC 2866, June 2000.

   [12]M.Patrick, "DHCP Relay Agent Information Option", RFC3046, Jan
       2001.

   [13]Droms, R., Schnizlein J., "RADIUS Attributes Sub-option for the
       DHCP Relay Agent Information Option", draft-ietf-dhc-agentopt-
      radius-08.txt, August 18, 2004.

   [14]Stapp, M., Johnson, R., and Palaniappan, T., "Vendor-Specific
       Information Sub-option for the DHCP Relay Agent Option", draft-
       ietf-dhc-vendor-suboption-00.txt, Work-in-progress, Aug. 2004.

   [15]Aboba B. and Vollbrecht J., "Proxy Chaining and Policy
       Implementation in Roaming", RFC 2607, June 1999.












                         Expires - April 2005                [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/