Diameter Maintenance and                                J. Korhonen (ed.) Korhonen, Ed.
Extensions (DIME)                                            TeliaSonera
Internet-Draft                                              J. Bournelle
Intended status: Standards Track                      France Telecom R&D
Expires: January 10, May 9, 2008                                       H. Tschofenig
                                                              C. Perkins
                                                  Nokia Siemens Networks
                                                            K. Chowdhury
                                                        Starent Networks
                                                            July 9,
                                                        November 6, 2007

  Diameter Mobile IPv6: Support for Network Access Server to Diameter
                           Server Interaction
                 draft-ietf-dime-mip6-integrated-05.txt
                 draft-ietf-dime-mip6-integrated-06.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

   This Internet-Draft will expire on January 10, May 9, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   A Mobile IPv6 node requires a Home Agent address, a home address, and
   a security association with its Home Agent before it can start
   utilizing Mobile IPv6.  RFC 3775 requires that some or all of these
   parameters are statically configured.  Mobile IPv6 bootstrapping work
   aims to make this information dynamically available to the Mobile
   Node.  An important aspect of the Mobile IPv6 bootstrapping solution
   is to support interworking with existing authentication,
   authorization and accounting infrastructure.  This document describes
   the MIPv6 bootstrapping using the Diameter Network Access Server
   (NAS) to home Authentication, Authorization and Accounting server
   (HAAA) interface.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Commands, AVPs and Advertising Application Support . . . . . .  6
     4.1.  Advertising Application Support  . . . . . . . . . . . . .  6
     4.2.  Command Codes  . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . .  7
     4.4.  Diameter-EAP-Answer (DEA)  . . . . . . . . . . . . . . . .  7
     4.5.  AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . .  8
     4.6.  AA-Answer (AAA)  . . . . . . . . . . . . . . . . . . . . .  8
     4.7.  Attribute Value Pair Definitions . . . . . . . . . . . . .  9
       4.7.1.  MIP6-Agent-Info  . . . . . . . . . . . . . . . . . . .  9
       4.7.2.  MIP-Home-Agent-Address AVP . . . . . . . . . . . . . .  9
       4.7.3.  MIP-Home-Agent-Host AVP  . . . . . . . . . . . . . . . 10
       4.7.4.  MIP6-Feature-Vector AVP  . . . . . . . . . . . . . . . 10
   5.  Example Message Flows  Examples . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  EAP-based Authentication . . . . . 11
     5.1.  Home Agent Assignment by the NAS . . . . . . . . . . . . . 11
     5.2.  Integrated Scenario and HA Allocation in MSP  Home Agent Assignment by the Diameter Server . . . . . . . 12
     5.3.  Integrated Scenario and HA Allocation in ASP . .  Home Agent Assignment by NAS or Diameter Server  . . . . . 13
   6.  AVP Occurrence Tables  . . . . . . . . . . . . . . . . . . . . 14
     6.1.  AAR, AAA, DER and DEA Commands AVP Table . . . . . . . . . 14
   7.  MIPv6 Bootstrapping NAS to HAAA Interface AVPs . . . . . . . . 15
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Registration of new AVPs . . . . . . . . . . . . . . . . . 15 16
     8.2.  New Registry: Mobility Capability  . . . . . . . . . . . . 15 16
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 20

1.  Introduction

   The Mobile IPv6 (MIPv6) specification [1] requires a Mobile Node (MN)
   to perform registration with a Home Agent (HA) with information about
   its current point of attachment (Care-of Address). (care-of address).  The HA creates
   and maintains binding between the MN's Home Address and the MN's
   Care-of Address.

   In order to register with a HA, the MN needs to know some information
   such as the Home Link prefix, the HA address, the Home Address(es),
   the Home Link prefix Length length and security association related
   information.

   The aforementioned set of information may be statically provisioned
   in the MN. statically.  However, static
   provisioning of this information becomes an administrative burden for
   an operator.  Moreover, static
   provisioning it does not address load balancing, failover,
   opportunistic home link assignment and assignment of local home
   agents in close proximity to the MN.  Also the ability to react on
   sudden environmental or topological changes is minimal.  Static
   provisioning may not be desirable, in light of the mentioned
   limitations.

   Dynamic assignment of MIPv6 home registration information is a
   desirable feature for ease of deployment and network maintenance.
   For this purpose, the AAA infrastructure, which is used for access
   authentication, can be leveraged to assign some or all of the
   necessary parameters.  The Diameter server in Access Service
   Provider's (ASP) or in Mobility Service Provider's (MSP) network may
   return these parameters to the AAA client.  Regarding the
   bootstrapping procedures, the AAA client might either be the NAS, in
   case of the integrated scenario, or the HA, in case of the split
   scenario [7].  The terms integrated and split are described in the
   terminology section and were introduced in [8] and [9].

2.  Terminology and Abbreviations

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

   General mobility terminology can be found in [10].  The following
   additional terms, as defined in [8], are used in this document:

   Access Service Authorizer (ASA):

      A network operator that authenticates a MN and establishes the
      MN's authorization to receive Internet service.

   Access Service Provider (ASP):

      A network operator that provides direct IP packet forwarding to
      and from the MN.

   Mobility Service Authorizer (MSA):

      A service provider that authorizes MIPv6 service.

   Mobility Service Provider (MSP):

      A service provider that provides MIPv6 service.  In order to
      obtain such service, the MN must be authenticated and authorized
      to obtain the MIPv6 service.

   Split scenario:

      A scenario where the mobility service and the network access
      service are authorized by different entities.

   Integrated Scenario:

      A scenario where the mobility service and the network access
      service are authorized by the same entity.

   Network Access Server (NAS):

      A device that provides an access service for a user to a network.

   Home AAA (HAAA):

      An authentication, authorization and accounting server located in
      user's home network.

3.  Overview

   This document addresses the authentication, authorization and
   accounting functionality required by for the MIPv6 bootstrapping as
   outlined in the MIPv6 bootstrapping problem statement document [8].
   This document focuses on the Diameter based AAA functionality for the
   NAS to HAAA interface.

   In the integrated scenario MIPv6 bootstrapping is provided as part of
   the network access authentication procedure.  Figure 1 shows the
   participating entities.  This document, however, only concentrates on
   the NAS, possible local Diameter proxies and the home Diameter
   server.

                      +---------------------------+  +-----------------+
                      |Access Service Provider    |  |ASA/MSA/(MSP)    |
                      |(Mobility Service Provider)|  |                 |
                      |                           |  |                 |
                      | +--------+                |  |    +--------+   |
                      | |Local   |      Diameter  |  |    |Home    |   |
                      | |Diameter|<---------------------->|Diameter|   |
                      | |Proxy   |                |  |    |Server  |   |
                      | +--------+                |  |    +--------+   |
                      |     ^ ^                   |  |        ^        |
                      |     | |                   |  |        |        |
                      |     | |                   |  |        |        |
                      |   Diameter                |  |        v        |
                      |     | |         +-------+ |  |    +-------+    |
                      |     | |         |Home   | |  |    |Home   |    |
                      |     | +-------->|Agent  | |  |    |Agent  |    |
                      |     |           |in ASP | |  |    |in MSP |    |
                      |     v           +-------+ |  |    +-------+    |
   +-------+ IEEE     | +-----------+   +-------+ |  +-----------------+
   |Mobile | 802.1X   | |NAS/Relay  |   |DHCPv6 | |
   |Node   |------------|Diameter   |---|Server | |
   |       | PANA,... | |Client     |   |       | |
   +-------+ DHCP     | +-----------+   +-------+ |
                      +---------------------------+

      Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario

   In a typical MIPv6 access scenario the MN is attached to an ASP's
   network.  During the network attachment procedure, the NAS/Diameter
   client interacts with the MN.

   During the time of authentication the Diameter server in the MSA ASA/MSA
   detects that the user is also authorized for MIPv6 access.  Based on
   the MSA's policy, the Diameter server may return several MIPv6
   bootstrapping related parameters.

   Depending on the details of the bootstrapping solution interaction
   with the DHCPv6 server may be required, as described in [11].
   However, the Diameter based NAS to HAAA interface described in this
   document is not tied to DHCPv6 as the only possible way to convey
   MIPv6
   bootstrapping method. related configuration parameters from the Diameter client to
   the mobile node.

4.  Commands, AVPs and Advertising Application Support

   This section describes command codes, defines AVPs and advertised
   application identifiers for the Diameter MIPv6 bootstrapping in the
   NAS to HAAA interface.

4.1.  Advertising Application Support

   Diameter nodes conforming to this specification MUST include the
   value of 1 (NASREQ application) or 5 (EAP application) in the Auth-
   Application-Id and the Acct-Application-Id AVP of the Capabilities-
   Exchange-Request / Capabilities-Exchange-Answer commands [3].

4.2.  Command Codes

   This document re-uses the Diameter NASREQ application [4] and the EAP
   application commands [5].  The following commands are used to carry
   MIPv6 related bootstrapping AVPs:

   Command-Name             Abbrev.   Code     Reference  Application

   Diameter-EAP-Request      DER       268      RFC 4072   EAP
   Diameter-EAP-Answer       DEA       268      RFC 4072   EAP

   AA-Request                AAR       265      RFC 4005   NASREQ
   AA-Answer                 AAA       265      RFC 4005   NASREQ

     Figure 2: MIPv6 Bootstrapping NAS to HAAA Interface Command Codes

   When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session-
   Termination-Request (STR), Session-Termination-Answer (STA), Abort-
   Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request
   (ACR), and Accounting-Answer (ACA) commands are used together with
   the MIPv6 bootstrapping NAS to HAAA interface, they follow the rules
   in the Diameter NASREQ [4], EAP [5] and RFC 3588 [3] applications.
   The accounting commands use the Application Identifier value of 3
   (Diameter Base Accounting); the others use 0 (Diameter Common
   Messages).

   All request messages SHOULD contain the User-Name AVP containing the
   identity of the MN in NAI format.  It is out of scope how the NAS
   finds out the MN identity However, for example, the NAS could use the
   MN identity provided by the network access authentication mechanism.

4.3.  Diameter-EAP-Request (DER)

   The Diameter-EAP-Request (DER) message [5], indicated by the Command-
   Code field set to 268 and the 'R' bit set in the Command Flags field,
   is sent by the NAS to the Diameter server to initiate a network
   access authentication and authorization procedure.  The DER message
   format is the same as defined in [5].  The message MAY include
   optional MIPv6 bootstrapping AVPs:

     <Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
                                < Session-Id >
                                { Auth-Application-Id }
                                { Origin-Host }
                                { Origin-Realm }
                                { Destination-Realm }
                                { Auth-Request-Type }

                              * [ MIP6-Agent-Info ]
                                [ MIP6-Feature-Vector ]

                                [ User-Name ]
                                [ Destination-Host ]
                                ...
                              * [ AVP ]

4.4.  Diameter-EAP-Answer (DEA)

   The Diameter-EAP-Answer (DEA) message defined in [5], indicated by
   the Command-Code field set to 268 and 'R' bit cleared in the Command
   Flags field, is sent in response to the Diameter-EAP-Request message
   (DER).  If the network access authentication procedure was successful
   then the response MAY include any set of bootstrapping AVPs.

   The DEA message format is the same as defined in [5] with an addition
   of optional MIPv6 bootstrapping AVPs:

     <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
                               < Session-Id >
                               { Auth-Application-Id }
                               { Auth-Request-Type }
                               { Result-Code }
                               { Origin-Host }
                               { Origin-Realm }

                             * [ MIP6-Agent-Info ]
                               [ MIP6-Feature-Vector ]

                               [ User-Name ]
                               ...
                             * [ AVP ]

4.5.  AA-Request (AAR)

   The AA-Request (AAR) message [4], indicated by the Command-Code field
   set to 265 and 'R' bit set in the Command Flags field, is sent by the
   NAS to the Diameter server to initiate a network access
   authentication and authorization procedure.  The AAR message format
   is the same as defined in [4].  The message MAY include optional
   MIPv6 bootstrapping AVPs:

     <AA-Request> ::= < Diameter Header: 265, REQ, PXY >
                      < Session-Id >
                      { Auth-Application-Id }
                      { Origin-Host }
                      { Origin-Realm }
                      { Destination-Realm }
                      { Auth-Request-Type }

                    * [ MIP6-Agent-Info ]
                      [ MIP6-Feature-Vector ]

                      [ User-Name ]
                      [ Destination-Host ]
                      ...
                    * [ AVP ]

4.6.  AA-Answer (AAA)

   The AA-Answer (AAA) message, indicated by the Command-Code field set
   to 265 and 'R' bit cleared in the Command Flags field is sent in
   response to the AA-Request (AAR) message for confirmation of the
   result of MIPv6 HA bootstrapping.  If the network access
   authentication procedure was successful then the response MAY include
   any set of bootstrapping AVPs.

   The AAA message format is the same as defined in [4] with an addition
   of optional MIPv6 bootstrapping AVPs:

     <AA-Answer> ::= < Diameter Header: 265, PXY >
                     < Session-Id >
                     { Auth-Application-Id }
                     { Auth-Request-Type }
                     { Result-Code }
                     { Origin-Host }
                     { Origin-Realm }

                   * [ MIP6-Agent-Info ]
                     [ MIP6-Feature-Vector ]

                     [ User-Name ]
                     ...
                   * [ AVP ]

4.7.  Attribute Value Pair Definitions

4.7.1.  MIP6-Agent-Info

   The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and
   contains necessary information to assign a HA to the MN.  When the
   MIP6-Agent-Info AVP is present in a message, it MUST contain either a
   the MIP-Home-Agent-Address AVP or a the MIP-Home-Agent-Host AVP, but not
   both. or
   both AVPs.  The grouped AVP has the following grammar:

   <MIP6-Agent-Info> ::= < AVP Header: TBD >
                         [ MIP-Home-Agent-Address ]
                         [ MIP-Home-Agent-Host ]
                       * [ AVP ]

4.7.2.  MIP-Home-Agent-Address AVP

   The MIP-Home-Agent-Address AVP (AVP Code 334 [6]) is of type Address
   and contains the HA address.  The Diameter server MAY decide to
   assign a HA to the MN that is in close proximity to the point of
   attachment (e.g., determined by the NAS-Identifier AVP).  There may
   be other reasons for dynamically assigning HAs to the MN, for example
   to share the traffic load.

   This AVP MAY also be attached by the NAS or by the intermediate local
   Diameter proxy when sent to the Diameter server in a request message
   as a hint of a locally assigned HA
   address. HA.

4.7.3.  MIP-Home-Agent-Host AVP

   The MIP-Home-Agent-Host AVP (AVP Code 348 [6]) is of type Grouped and
   contains the identity of the assigned HA.  Both the FQDN Destination-Realm
   and the
   Realm Destination-Host AVP of the HA are included in the grouped
   AVP.  The usage of this AVP is equivalent to the MIP-Home-Agent-Address MIP-Home-Agent-
   Address AVP but offers an additional level of indirection via the DNS
   infrastructure.

   This AVP MAY also be attached by the NAS or by the intermediate local
   Diameter proxy when sent to the Diameter server in a request message
   as a hint of a locally assigned HA.

4.7.4.  MIP6-Feature-Vector AVP

   The MIP6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned64 and
   contains a 64 bits flags field of supported capabilities of the NAS/
   ASP.  Sending and receiving the MIP6-Feature-Vector AVP with value 0
   MUST be supported, although that does not provide much guidance about
   specific needs of bootstrapping.

   The NAS MAY include this AVP to indicate capabilities of the NAS/ASP
   to the Diameter server.  For example, the NAS may indicate that a
   local home agent can be provided.  Similarly, the Diameter server MAY
   include this AVP to inform the NAS/ASP about which of the NAS/ASP
   indicated capabilities are supported or authorized by the ASA/MSA(/
   MSP).

   The following capabilities are defined in this document:

   MOBILITY_CAPABILITY (0x0000000000000000)

      The MIP6-Feature-Vector AVP MAY contain value 0 (zero) with the
      semantics that Mobile IPv6 bootstrapping is generally supported.
      This 'zero' flag is always implicitly set value represents the default when the MIP6-Feature-
      Vector MIP6-Feature-Vector AVP
      is used. included in a message.

   MIP6_INTEGRATED (0x0000000000000001)

      This

      The entity that sets the flag has an impact on the semantic.  When
      this flag is set by the NAS/ASP when NAS then it means that the Mobile IPv6
      integrated scenario bootstrapping functionality is supported.  This supported by
      the NAS.  When this flag is set by the ASA/MSA(/MSP) when Diameter server then the
      Mobile IPv6 integrated scenario bootstrapping is supported and authorized to be used. by the
      Diameter server.

   LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002)

      This

      The entity that sets the flag has an impact on the semantic.  When
      this flag is set by the NAS/ASP when NAS then a local home agent can be
      assigned to the MN.  This  When this flag is set by the ASA/MSA(/MSP) when Diameter server
      then the use assignment of a local HA location HAs is authorized. authorized by the Diameter
      server.

5.  Example Message Flows  Examples

5.1.  EAP-based Authentication

   This section shows basic message flows of MIPv6 integrated scenario
   bootstrapping and dynamic HA assignment.  In Figure 3 network access
   authentication is based on EAP (e.g., 802.11i/802.1X).  The  Home Agent Assignment by the NAS
   informs

   In this scenario we consider the home Diameter server that it case where the NAS wishes to provide
   allocate a locally
   assigned local HA to the visiting MN.  The NAS will also inform the Diameter
   server assigns the MN a
   HA in the home MSP but also authorizes about the assignment of local HA for address it has assigned to the ASP. visiting MN (e.g.,
   2001:db8:1:c020::1).  The Diameter server then replies to Diameter-EAP-Request message therefore has
   the NAS MIP6-Feature-Vector with HA related
   bootstrapping information.  Whether the NAS/ASP then offers a locally
   assigned HA or LOCAL_HOME_AGENT_ASSIGNMENT and the MSP assigned HA to
   MIP6_INTEGRATED set.  The MIP6-Agent-Info AVP contains the MN is based on MIP-Home-
   Agent-Address AVP with the local
   ASP policy. address of the proposed HA.

                                                                Diameter
   NAS                                                       Home server                                                            Server
    |                                                                 |
    |  Diameter-EAP-Request                                           |
    |  MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT               |
    |                       | MIP6_INTEGRATED)                        |
    |  MIP6-Agent-Info{                                               |
    |       MIP-Home-Agent-Address(2001:db8:1:c020::1)}               |
    |  }                                                              |
    |  Auth-Request-Type=AUTHORIZE_AUTHENTICATE                       |
    |  EAP-Payload(EAP Start)                                         |
    |---------------------------------------------------------------->|
    |                                                                 |
    |                                                                 |
    :              ...more EAP Request/Response pairs...              :
    |                                                                 |
    |                                                                 |
    |                                            Diameter-EAP-Answer  |
    |                                               MIP6-Agent-Info{  |
    |                          MIP-Home-Agent-Address(IPv6 address)}  |
    |               MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT  |
    |                                    | MIP6_INTEGRATED)           |
    |                                   Result-Code=DIAMETER_SUCCESS  |
    |                                       EAP-Payload(EAP Success)  |
    |                                         EAP-Master-Session-Key  |
    |                                           (authorization AVPs)  |
    |                                                           ...   |
    |<----------------------------------------------------------------|
    |                                                                 |

                  Figure 3: Home Agent Assignment by NAS

   Depending on the Diameter EAP Application with MIPv6 bootstrapping

5.2.  Integrated Scenario server configuration and user's
   subscription profile, the Diameter server either accepts or rejects
   the proposal of locally HA Allocation in MSP allocated by the NAS will be used.  In our
   example, the Diameter is used to authenticate server accepts the proposal and authorize the MN for the
   mobility service, and to send information about MIP6-
   Feature-Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT flag (together
   with the allocated HA MIP6_INTEGRATED flag) is set and returned to the NAS.

5.2.  Home Agent Assignment by the Diameter Server

   In this example scenario we consider the case where the NAS supports the
   Diameter MIPv6 integrated scenario as defined in this document but
   does not offer local home agent assignment.  Hence, the MIP6-Feature-
   Vector AVP only has the MIP6_INTEGRATED flag set.  The Diameter
   server allocates a home agent to the mobile node and conveys the MN uses DHCP for its IP
   address configuration.

                                         |
                 --------------ASP------>|<--ASA/MSA/(MSP)--
                                         |
   +----+       +--------+     +-------+   +--------+
   |    |       |Diameter|     |       |   |        |
   |    |       | Client |     |       |   |        |
   | MN |       | NAS/   |     | DHCP  |   |  Home  |
   |    |       | DHCP   |     | Server|   |Diameter|
   |    |       | Relay  |     |       |   | in the MIP-Home-Agent-Address AVP that is encapsulated in the
   MIP6-Agent-Info AVP.  Additionally, the MIP6-Feature-Vector AVP has
   the MIP6_INTEGRATED flag set.

                                                                Diameter
   NAS                                                            Server
    |
   +-+--+       +----+---+     +---+---+   +--------+
     |               |             |           |
     |     1         |      2      |           |
     |<------------->|<----------------------->|
     |               |             |           |
     |               |             |           |
     |     3                                                                 |
    |  Diameter-EAP-Request                                           |
     |-------------->|
    |  MIP6-Feature-Vector=(MIP6_INTEGRATED)                          |
    |  Auth-Request-Type=AUTHORIZE_AUTHENTICATE                       |
    |  EAP-Payload(EAP Start)                                         |
    |---------------------------------------------------------------->|
    |                                                                 |      4
    |                                                                 |
    :              ...more EAP Request/Response pairs...              :
    |               |------------>|                                                                 |
    |                                                                 |
    |                                            Diameter-EAP-Answer  |
    |                                               MIP6-Agent-Info{  |      5
    |         MIP-Home-Agent-Address(2001:db8:6000:302::1/64)         |
    |               |<------------|                                                              }  |
    |                          MIP6-Feature-Vector=(MIP6_INTEGRATED)  |
    |                                   Result-Code=DIAMETER_SUCCESS  |
    |     6                                       EAP-Payload(EAP Success)  |
    |                                         EAP-Master-Session-Key  |
     |<--------------|
    |                                           (authorization AVPs)  |
    |                                                           ...   |
    |<----------------------------------------------------------------|
    |                                                                 |

            Figure 4: Mobile IPv6 Integrated Scenario Bootstrapping and the
             allocation of HAs either in the ASP or in the MSP

   1) The MN executes the normal network access authentication procedure
      (IEEE 802.11i/802.1X, PANA, ...) with the NAS.  The Home Agent Assignment by Diameter Server

5.3.  Home Agent Assignment by NAS acts as an
      authenticator in "pass-through" mode.  The other endpoint of the
      authentication dialogue is the MN's home or Diameter server. Server

   This is section shows a typical scenario message flows for network access authentication using EAP
      methods.  The NAS includes at least one of the NAS to HAAA
      interface AVPs in the DER or in the AAR messages to indicate MIPv6 integrated scenario
   bootstrapping capability.  For example, where the NAS should include the
      MIP6-Feature-Vector AVP with a value 0x0000000000000001.

   2) Depending on the Diameter server configuration and the user's
      subscription profile, the MIP6-Agent-Info AVP and/or the MIP6-
      Feature-Vector AVP may be carried in the DEA, assuming informs the home Diameter server has allocated a HA to the MN.  In case the MIP-
      Home-Agent-Host AVP was returned within the MIP6-Agent-Info
      grouped AVP the MN ultimately needs that it is
   able to perform locally assign a DNS query in
      order HA to discover the HA's IP address.  For example, the home
      Diameter server could return the following AVPs:

      o  MIP6-Feature-Vector = 0x0000000000000001
      o  MIP6-Agent-Info grouped AVP containing:
         *  MIP-Home-Agent-Address = 2001:db8:6000:302::1/64

   3) the MN sends a DHCPv6 Information Request message to
      all_DHCP_Relay_Agents_and_Servers address.  In the OPTION_ORO,
      Option Code for the Home Network Identifier Option shall be
      included in that message [11].  The Home Network Identifier Option
      should have id-type of 1, the message is a request to discover
      home network information that pertains to the given realm, i.e.,
      the user's home domain (identified by the NAI of the MN).  The
      OPTION_CLIENTID is set by the MN to identify itself to the DHCP
      server.

   Steps 4 to 6 are not relevant from the NAS to HAAA Diameter interface
   point of view and are not described in this document.  The reader
   should consult [11] for a detailed description about the rest of the
   integrated scenario bootstrapping procedure.

5.3.  Integrated Scenario and HA Allocation in ASP

   This scenario is similar to the one described in Section 5.2 and
   illustrated in Figure 4.  There are slight differences in steps 2)
   and 3).

   2) The NAS/ASP wishes to allocate a local HA to the visiting MN.  The
      NAS/ASP will also inform the Diameter server about the HA address
      it has assigned to the visiting MN (e.g., 2001:db8:1:c020::1).  In
      this case the NAS includes the following AVPs in the DER or in the
      AAR messages:

      o  MIP6-Feature-Vector = 0x0000000000000003
      o  MIP6-Agent-Info grouped AVP containing:
         *  MIP-Home-Agent-Address = 2001:db8:1:c020::1

      Depending on the Diameter server configuration and user's
      subscription profile, the Diameter server either accepts or
      rejects the proposal of locally allocated HA in the NAS/ASP.  If
      the Diameter server accepts the proposal then the MIP6-Feature-
      Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT bit set is returned
      back to the NAS.  On the other hand if the Diameter server does
      not accept locally assigned HA, the Diameter returns the MIP6-
      Feature-Vector AVP with LOCAL_HOME_AGENT_ASSIGNMENT bit unset.
      The Diameter server assigns a HA to the MN (e.g.,
      2001:db8:6000::1) in the ASA/MSA/(MSP) and returns the IP address
      back to the NAS/ASP.  In a case the home Diameter server accepted
      the NAS/ASP proposal of local HA the home MN.  The Diameter server would
      return, for example, the following AVPs:

      o  MIP6-Feature-Vector = 0x0000000000000003
      o  MIP6-Agent-Info grouped AVP containing:
         *  MIP-Home-Agent-Address = 2001:db8:6000::1

   3) The type-id field in the Home Network Identifier Option is set also
   able to
      zero, indicating that provide a HA is requested in the ASP instead of in to the MSP.  Depending on MN but also authorizes the result assignment of
   local HA.  The Diameter server then replies to the phase 2) the DHCP relay
      agent places in the OPTION_MIP6-RELAY-Option either NAS with HA
   related bootstrapping information.

   Whether the NAS/ASP then offers a locally
      allocated assigned HA information or the HA information that was returned
      (proposed) by home Diameter server.  The selection of local or
      home allocated HAs
   server assigned HA to the MN is, in this example, based on the local policy in
   ASP policy.

                                                                Diameter
   NAS                                                            Server
    |                                                                 |
    |  Diameter-EAP-Request                                           |
    |  MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT               |
    |                       | MIP6_INTEGRATED)                        |
    |  MIP6-Agent-Info{                                               |
    |       MIP-Home-Agent-Address(2001:db8:1:c020::1)}               |
    |  }                                                              |
    |  Auth-Request-Type=AUTHORIZE_AUTHENTICATE                       |
    |  EAP-Payload(EAP Start)                                         |
    |---------------------------------------------------------------->|
    |                                                                 |
    |                                                                 |
    :              ...more EAP Request/Response pairs...              :
    |                                                                 |
    |                                                                 |
    |                                            Diameter-EAP-Answer  |
    |                                               MIP6-Agent-Info{  |
    |               MIP-Home-Agent-Address(2001:db8:6000:302::1/64)}  |
    |               MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT  |
    |                                    | MIP6_INTEGRATED)           |
    |                                   Result-Code=DIAMETER_SUCCESS  |
    |                                       EAP-Payload(EAP Success)  |
    |                                         EAP-Master-Session-Key  |
    |                                           (authorization AVPs)  |
    |                                                           ...   |
    |<----------------------------------------------------------------|
    |                                                                 |

         Figure 5: Home Agent Assignment by NAS or Diameter Server

   If the ASP.  It is
      also possible that both local and home allocated HAs are available
      for Diameter server does not accept locally assigned HA, the MN.  The policy and heuristics when to select
   Diameter returns the local HA MIP6-Feature-Vector AVP with
   LOCAL_HOME_AGENT_ASSIGNMENT bit unset and when the home HA are outside of this specification. address it plans to
   allocate for the MN.

6.  AVP Occurrence Tables

6.1.  AAR, AAA, DER and DEA Commands AVP Table

   The following table lists the additional MIPv6 bootstrapping NAS to
   HAAA interface AVPs that may optionally be present in the AAR and AAA
   Commands [4] or in the DER and DEA Commands [5].

                                     +-----------------------+
                                     |     Command-Code      |
                                     |-----+-----+-----+-----+
      Attribute Name                 | AAR | AAA | DER | DEA |
      -------------------------------|-----+-----|-----+-----+
      MIP6-Agent-Info                | 0+  | 0+  | 0+  | 0+  |
      MIP6-Feature-Vector            | 0-1 | 0-1 | 0-1 | 0-1 |
                                     +-----+-----+-----+-----+

            Figure 5: 6: AAR, AAA, DER and DEA Commands AVP Table

7.  MIPv6 Bootstrapping NAS to HAAA Interface AVPs

   This section defines AVPs that are specific to Diameter MIPv6
   bootstrapping NAS to HAAA interface and MAY be included in the
   Diameter EAP [5] and the NASREQ [4] application messages.  The
   Diameter AVP rules are defined in the Diameter Base [3], Section 4.
   These AVP rules are observed in AVPs defined in this section.

   The following table describes the Diameter AVPs, their AVP Code
   values, types, possible flag values, and whether the AVP MAY be
   encrypted.  The Diameter base [3] specifies the AVP Flag rules for
   AVPs in Section 4.5.

                                            +---------------------+
                                            |    AVP Flag rules   |
                                            +----+-----+----+-----+----+
                     AVP  Section           |    |     |SHLD|MUST |    |
  Attribute Name     Code Defined Data Type |MUST| MAY |NOT |NOT  |Encr|
  ------------------------------------------+----+-----+----+-----+----+
  MIP6-Agent-Info    TBD  4.7.1  Grouped    |    |  P M,P |    | M,V  V  | Y  |
  MIP-Home-Agent-                           |    |     |    |     |    |
   Address           334  4.7.2  Address    |    |  P M,P |    | M,V  V  | Y  |
  MIP-Home-Agent-                           |    |     |    |     |    |
   Host              348  4.7.3  Grouped    |    |  P M,P |    | M,V  V  | Y  |
  MIP6-Feature-                             |    |     |    |     |    |
   Vector            TBD  4.7.4  Unsigned64 |    |  P M,P |    | M,V  V  | Y  |
  ------------------------------------------+----+-----+----+-----+----+

                      Figure 6: 7: AVP Flag Rules Table

8.  IANA Considerations

8.1.  Registration of new AVPs

   This specification defines the following new AVPs:

     MIP6-Agent-Info                is set to TBD
     MIP6-Feature-Vector            is set to TBD

8.2.  New Registry: Mobility Capability

   IANA is requested to create a new registry for the Mobility
   Capability as described in Section 4.7.4.

  Token                             | Value                | Description
  ----------------------------------+----------------------+------------
  MOBILITTY_CAPABILITY              | 0x0000000000000000   | [RFC TBD]
  MIP6_INTEGRATED                   | 0x0000000000000001   | [RFC TBD]
  LOCAL_HOME_AGENT_ASSIGNMENT       | 0x0000000000000002   | [RFC TBD]
  Available for Assignment via IANA | 2^x                  |

   Allocation rule: Only numeric values that are 2^x (power of two) are
   allowed based on the allocation policy described below.

   Following the policies outlined in [1] new values with a description
   of their semantic for usage with the MIP6-Feature-Vector AVP together
   with a Token will be assigned after Expert Review initiated by the
   O&M Area Directors in consultation with the DIME working group chairs
   or the working group chairs of a designated successor working group.
   Updates can be provided based on expert approval only.  A designated
   expert will be appointed by the O&M Area Directors.  No mechanism to
   mark entries as "deprecated" is envisioned.  Based on expert approval
   it is possible to delete entries from the registry.

9.  Security Considerations

   The security considerations for the Diameter interaction required to
   accomplish the integrated scenario are described in [11].
   Additionally, the security considerations of the Diameter base
   protocol [3], Diameter NASREQ application [4] / Diameter EAP [5]
   application (with respect to network access authentication and the
   transport of keying material) are applicable to this document.  This
   document does not introduce new security vulnerabilities.

10.  Acknowledgements

   This document is heavily based on the ongoing work for RADIUS MIPv6
   interaction.  Hence, credits go to respective authors for their work
   with draft-ietf-mip6-radius.  Furthermore, the author would like to
   thank the authors of draft-le-aaa-diameter-mobileipv6 (Franck Le,
   Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for their work
   in context of MIPv6 Diameter interworking.  Their work influenced
   this document.  Jouni Korhonen would like to thank Academy of Finland
   and TEKES MERCoNe Project for providing funding to work on this
   document.  Julien Bournelle would like to thank GET/INT since he
   began to work on this document while he was in their employ.  Authors
   would also like to acknowledge Raymond Hsu for his valuable feedback
   on local HA assignment and Wolfgang Fritsche for his thorough review.

11.  References

11.1.  Normative References

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

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

   [3]   Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
         "Diameter Base Protocol", RFC 3588, September 2003.

   [4]   Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
         Network Access Server Application", RFC 4005, August 2005.

   [5]   Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
         Authentication Protocol (EAP) Application", RFC 4072,
         August 2005.

   [6]   Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P.
         McCann, "Diameter Mobile IPv4 Application", RFC 4004,
         August 2005.

11.2.  Informative References

   [7]   Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 bootstrapping in split scenario",
         draft-ietf-mip6-bootstrapping-split-05 (work
         Bootstrapping in progress),
         May Split Scenario", RFC 5026, October 2007.

   [8]   Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
         Mobile IPv6 (MIPv6)", RFC 4640, September 2006.

   [9]   Giaretta, G., "AAA Goals for Mobile IPv6",
         draft-ietf-mip6-aaa-ha-goals-03 (work in progress),
         September 2006.

   [10]  Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

   [11]  Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
         Integrated Scenario",
         draft-ietf-mip6-bootstrapping-integrated-dhc-04
         draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in
         progress), June July 2007.

Authors' Addresses

   Jouni Korhonen (editor)
   TeliaSonera
   Teollisuuskatu 13
   Sonera  FIN-00051
   Finland

   Email: jouni.korhonen@teliasonera.com

   Julien Bournelle
   France Telecom R&D
   38-4O rue du general Leclerc
   Issy-Les-Moulineaux  92794
   France

   Email: julien.bournelle@orange-ftgroup.com

   Hannes Tschofenig
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.com

   Charles E. Perkins
   Nokia Siemens Networks
   313 Fairchild Drive
   Mountain View  CA 94043
   US

   Phone: +1 650 625-2986
   Email: charliep@nsn.com
   Kuntal Chowdhury
   Starent Networks
   30 International Place
   Tewksbury  MA  01876
   US

   Phone: +1 214 550 1416
   Email: kchowdhury@starentnetworks.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).