[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-tschofenig-dime-mip6-split) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 5778

Diameter Maintenance and                              J. Bournelle (Ed.)
Extensions (DIME)                                                GET/INT
Internet-Draft                                               G. Giaretta
Intended status: Standards Track                          Telecom Italia
Expires: April 25, 2007                                    H. Tschofenig
                                           Siemens Networks GmbH & Co KG
                                                             M. Nakhjiri
                                                                  Huawei
                                                        October 22, 2006


                Diameter Mobile IPv6: HA-to-AAAH support
                     draft-ietf-dime-mip6-split-01

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 April 25, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   In a Mobile IPv6 deployment the need for an interaction between the
   Home Agent, the AAA infrastructure of the Mobile Service Provider
   (MSP) and the Mobility Service Authorizer (MSA) has been identified.



Bournelle (Ed.), et al.  Expires April 25, 2007                 [Page 1]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


   This document describes a new Diameter application, called Mobile
   IPv6 Authorization Application, used in conjunction with the Diameter
   EAP Application is used to perform the necessary AAA functions before
   executing Mobile IPv6 services.  This document also specifies the
   role of the Home Agent as part of the AAA infrastructure supporting
   the Diameter Mobile IPv6 Authorization Application.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Diameter MIP6 HA-to-AAAH Overview  . . . . . . . . . . . . . .  4
   4.  Diameter Mobile IPv6 HA-to-AAAH Support  . . . . . . . . . . .  5
     4.1.  Authentication . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.1.  HA with EAP Support  . . . . . . . . . . . . . . . . .  6
       4.1.2.  HA without EAP Support . . . . . . . . . . . . . . . .  8
     4.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Accounting . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.4.  Mobile IPv6 Session Management . . . . . . . . . . . . . .  9
       4.4.1.  Session-Termination-Request Command  . . . . . . . . .  9
       4.4.2.  Session-Termination-Answer Command . . . . . . . . . .  9
       4.4.3.  Abort-Session-Request Command  . . . . . . . . . . . .  9
       4.4.4.  Abort-Session-Answer Command . . . . . . . . . . . . . 10
   5.  Command-Code Values  . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  MIP6-Authorization-Request . . . . . . . . . . . . . . . . 10
     5.2.  MIP6-Authorization-Answer  . . . . . . . . . . . . . . . . 10
   6.  Result-Code AVPs . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Mandatory AVPs . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Accounting AVPs  . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  AVP Occurence Tables . . . . . . . . . . . . . . . . . . . . . 11
   10. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Authentication Token . . . . . . . . . . . . . . . . . . . 11
     10.2. HA as a Single Physical Device . . . . . . . . . . . . . . 11
     10.3. Triggering the MIP6 Authorization Application  . . . . . . 11
     10.4. RFC4285 Support  . . . . . . . . . . . . . . . . . . . . . 12
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     14.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 15







Bournelle (Ed.), et al.  Expires April 25, 2007                 [Page 2]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


1.  Introduction

   With the Mobile IPv6 protocol [1], a Mobile Node (MN) is assigned a
   Home Agent which is in charge of relaying IPv6 packets destined to
   MN's Home Address to the MN's current address.  Moreover, the Mobile
   Node and its Home Agent (HA) must share IPsec Security Associations
   to protect Mobile IPv6 signalling.  Note that it is possible to use
   another method than IPsec to secure signalling messages, but in this
   document, only IPsec is considered.  One of the problem is to
   dynamically set-up these Security Associations and to assign the Home
   Agent Address and the Home Address to the Mobile Node.  This problem
   is known as the Mobile IPv6 bootstrapping problem and is detailed in
   [2].  Two possible bootstrapping scenarios have been identified,
   namely the Integrated and the Split Scenario.  With the Integrated
   Scenario (see [3]), the Home Agent Address is delivered during the
   process of network access authentication, while in the Split scenario
   (see [4]), the Home Agent information is discovered using the DNS
   infrastructure.  In both cases, the Mobile Node has the Home Agent
   information and it interacts with the Home Agent using IKEv2 [5].

   From an operator perspective, it is important to verify that the user
   (MN) is authorized to utilize Mobile IPv6 service and that such
   services are accounted for.  The Home Agent, while verifying the
   user's identity, also participates in the Mobile IPv6 authorization
   process and due to its role in traffic forwarding performs accounting
   for this service.  For this reason, it is important for the Home
   Agent to act as part of the service provider's AAA infrastructure.

   The goal of this document is to specify a new Diameter application,
   called Diameter Mobile IPv6 Authorization Application specifying the
   authorization and accounting procedures associated for Mobile IPv6
   service.  Furthermore, the document specifies the role of Home Agent
   as a Diameter client to support this application.  This modular
   approach provides flexibility for the choice of authentication in
   conjunction with Mobile IPv6 services.  For instance, the HA can use
   the Diameter EAP Application [6] or other procedures for performing
   authentications through a Diameter server.  Note that this
   application can be used both in Integrated and Split scenarios.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [7].

   The MIPv6 bootstrapping terminology is taken from [2].




Bournelle (Ed.), et al.  Expires April 25, 2007                 [Page 3]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


3.  Diameter MIP6 HA-to-AAAH Overview

   The Home Agent offers the Mobile IPv6 service to the Mobile Node.  As
   a Diameter client, the delivered Home Agent performs the following
   operations:

   Authentication:  The Home Agent must verify the identity of the user
      provided in the IKEv2 exchange.

   Authorization:  The Home Agent must verify that the user is
      authorized to use the Mobile IPv6 service.

   Accounting:  For billing purposes and capacity planning, the Home
      Agent provides accounting report to the AAA infrastructure.


   Figure 1 shows the architecture of the solution described in this
   document.


                 MSP                                MSA
              +--------+                      +-------------+
    +--+  IKEv2 +--+   |    Diameter EAP      | +--------+  |
    |MN|<------>|HA|<-------------------------->|AAAH-EAP|  |
    +--+      | +--+   |(AUTHENTICATE_ONLY)   | +--------+  |
              |   ^    |                      |             |
              |   |    |                      |             |
              |   |   Diameter MIP6 Authz/Acc | +---------+ |
              |   +---------------------------->|AAAH-MIP6| |
              |        |                      | +---------+ |
              +--------+                      +-------------+

                      Figure 1: Architecture Overview

   For the authentication part, it is likely that operators will use EAP
   within IKEv2 to authenticate the user since it is the easiest way for
   operator to leverage their AAA infrastructure for IKEv2 initiator
   authentication.  The Diameter EAP Application [6] is the application
   that permits carrying EAP packets between an access device and a AAA
   server.  However, this application is primarly defined to perform AAA
   operations for network access service and not for Mobile IPv6
   service.  For this reason, it is recommended that, when EAP is used
   for authentication, the Diameter EAP application will be used only
   for Authentication purpose.  This implies that the Home Agent will
   use the Diameter EAP Application in "AUTHENTICATE_ONLY" mode.  This
   is realized by setting the Auth-Request-Type AVP to
   AUTHENTICATE_ONLY.  In this document, the AAA server contacted for
   Authentication is called AAAH-EAP.  This server belongs to the MSA.



Bournelle (Ed.), et al.  Expires April 25, 2007                 [Page 4]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


   To explicitely authorize the Mobile IPv6 service, in this document,
   we define a new Diameter application, called Mobile IPv6
   Authorization Application.  The application requires two new
   messages, namely: MIP6-Authorization-Request (MAR) and MIP6-
   Authorization-Answer (MAA).  The HA, acting as a Diameter client for
   this new application, sends a MIP6-Authorization-Request message
   containing identity of the user to the Mobility service authorizer
   (e.g., HAAA for MIP6 service) to verify that this user is authorized
   to use Mobile IPv6 service.  This message is sent towards Diameter
   server called AAAH-MIP6 in this document.  This server belongs to the
   MSA.

   This message may also contain some specific authorization AVPs
   concerning Home-Address Allocation and Home-Address DNS registration.
   The response is contained in the MIP6-Authorization-Answer.  As this
   application needs a new Application-Id [[[To Be assigned by IANA]]],
   it has to be noted that the Mobile IPv6 authorization requests may be
   routed to a different AAA server (AAAH-MIP6) than the AAA server used
   for Authentication request (AAAH-EAP).

   When the verification of user authorization to receive Mobile IPv6
   service is complete, the Home-Agent start performing Accounting
   operation by sending accounting message (ACR) with the AVP Acct-
   Application-ID set to [[[To Be Assigned by IANA]]].  These messages
   contain specific Mobile IPv6 AVPs and are sent to the AAAH-MIP6.


4.  Diameter Mobile IPv6 HA-to-AAAH Support

   Although the main goal of this document is to specify the
   authorization and accounting for Mobile IPv6 application, the intent
   is also to provide guidance on the AAA operations expected from HA.
   Hence, this document provides guidance on the procedures required
   from the HA as part of the authentication process.  As EAP is
   considered as a strong choice in performing authentication, this
   document explains the use of Diameter EAP application in cases where
   the prior authentication between MN and HA is done through use of
   EAP.  Therefore, the HA performs AAA operations for Mobile IPv6 by
   using two Diameter Applications, namely: Diameter EAP[6] and Diameter
   Mobile IPv6 (specified by this document).

   If EAP is used within IKEv2, the HA uses the procedures of Diameter
   EAP application (DER/DEA) with the Auth-Request-Type set to
   AUTHENTICATE_ONLY.







Bournelle (Ed.), et al.  Expires April 25, 2007                 [Page 5]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


4.1.  Authentication

   As mentioned before, prior to performing authorization process, the
   HA must authenticate the user.  The use of IKEv2 between the MN and
   the HA allows the HA to authenticate the Mobile Node.  Traditional
   IKE authentication procedures require existence of pre-shared secrets
   or certificates between MN and HA.  However, given the possible lack
   of prior knowledge between MN and HA, the more desired approach is to
   use EAP and the AAA infrastructure to authenticate the user during
   IKEv2.

4.1.1.  HA with EAP Support

   Figure 2 shows the message flow involved during the authentication
   phase when EAP is used.




































Bournelle (Ed.), et al.  Expires April 25, 2007                 [Page 6]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


Mobile Node          HA/Diameter Client    Home AAA/EAP Server(AAAH-EAP)
----------            -----------------       -------------------
         IKE_SA_INIT     (1,2)
<------------------------------>

HDR, SK{IDi,[CERTREQ,] [IDr,]
        [CP(CFG_REQUEST),]
         SAi2, TSi, TSr}  (3)
------------------------------->
                                 DER (EAP-Response)(AUTHENTICATE_ONLY)
                                 ------------------------>
                                    DEA (EAP-Request)
                                 <------------------------
 HDR, SK {IDr, [CERT,] AUTH,
          EAP }
<-------------------------------
 HDR, SK {EAP}
-------------------------------->
                                 DER (EAP-Response)(AUTHENTICATE_ONLY)
                                 ------------------------>
                                    DEA (EAP-Request)
                                 <------------------------
 HDR, SK{EAP-Request}
<-------------------------------
 HDR, SK{EAP-Response}
-------------------------------->
                                    DER (EAP-Response)
                                 ------------------------>
          ...                           ...

                                    DEA (EAP-Success)
                                 <------------------------
 HDR, SK{EAP-Success}
<-------------------------------
 HDR, SK{AUTH}
------------------------------->
 HDR, SK {AUTH, [CP(CFG_REPLY,] SAr2, TSi, TSr }
<-------------------------------


                 Figure 2: IKEv2 Diameter EAP Message Flow

   The MN and the HA start the interaction with an IKE_SA_INIT exchange.
   In this phase cryptographic algorithms are negotiated, nonces and a
   Diffie-Hellman parameters are exchanged.  Message (3) starts the
   IKE_AUTH phase.  This second phase authenticates the previous
   messages, exchanges identities and certificates and establishes the
   first CHILD_SA.  It is used to mutually authenticate the Mobile Node



Bournelle (Ed.), et al.  Expires April 25, 2007                 [Page 7]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


   (acting as an IKEv2 Initiator) and the Home Agent (acting as an IKEv2
   Responder).  The identity of the User/Mobile Node is provided in the
   field IDi.  The Mobile Node indicates its willingness to be
   authenticated by EAP by omitting the field AUTH in message 3 (cf.
   [5]).  The Mobile Node authenticates the Home Agent by requesting a
   certificate.  This is done by including the field [CERTREQ] in
   message 3.

   As part of the authentication process, the Mobile Node MAY request a
   Home-Address, a Home Prefix or suggests one [4].  This is done by
   using a CFG_REQUEST payload in the message 3.

   The Home Agent extracts the IDi field from the message 3 and sends a
   Diameter-EAP-Request message towards the authenticating Diameter
   server AAAH-EAP.  The User-Name AVP of the DER message MUST be set to
   the IDi field and the Auth-Request-Type MUST be set to
   AUTHENTICATE_ONLY.  This message is routed through the AAA
   infrastructure to the home AAA server (AAAH-EAP) of this Mobile Node.
   The AAAH-EAP chooses an authentication method and replies with the
   DEA Message.

   At the end of the EAP authentication phase, the AAAH-EAP indicates
   the result of the authentication in the Result-Code AVP and provides
   the corresponding EAP packet (EAP Success or EAP Failure).  The last
   IKEv2 message sent by the Home Agent contains the Home Address or the
   Home Prefix.  In the latter case, a CREATE_CHILD_SA exchange is
   necessary to setup IPsec SAs for Mobile IPv6 signalling.

4.1.2.  HA without EAP Support

   To be completed.

4.2.  Authorization

   Following the successful authentication, the Home Agent must ensure
   that the Mobile Node is authorized to use the Mobile IPv6 service.
   For this purpose, the Home Agent sends a MIP6-Authorization-Request
   (MAR) message containing identity of the user towards the AAAH-MIP6.
   The Application-ID of this message is set to [TO BE ASSIGNED].  The
   identity is extracted from the IDi field provided in the message 3 of
   the IKEv2 exchange.  The home AAA server (AAAH-MIP6) replies with a
   MIP6-Authorization-Answer which contains the result of the
   authorization process.  This latter message MAY contain configuration
   policies to be applied at the Home Agent.

   As part of the authorization request for the Mobile IPv6 service.
   The Home Agent may require specific authorization for this MN.  As an
   example, it may request if this user is allowed to auto-assign its



Bournelle (Ed.), et al.  Expires April 25, 2007                 [Page 8]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


   Home-Address.

4.3.  Accounting

   Concerning accounting, the Diameter Mobile IPv4 Application [8]
   defines the following AVPs:

   o  Accounting-Input-Octets: Number of octets in IP packets received
      from the user
   o  Accounting-Output-Octets: Number of octets in IP packets sent by
      the user
   o  Accounting-Input-Packets: Number of IP packets received from the
      user
   o  Accounting-Output-Packets: Number of IP packets sent by the user.

   These AVPs may be re-used for the Mobile IPv6 service.  However, due
   to routing optimization techniques introduced with Mobile IPv6 the HA
   does not see the entire traffic exchanged between the MN and the CN.

   [Editor's Note: As the document describing goals for this interface
   is not finalized, other parameters may be needed in the future.]

4.4.  Mobile IPv6 Session Management

   Concerning Mobile IPv6 session, the AAAH (AAAH-MIP6) server may
   maintain state or may be stateless.  This is indicated in the Auth-
   Session-State AVP (or its abscence) in the MAA message.  The Home
   Agent MUST support the Authorization Session State Machine defined in
   [9].  Moreover the following 4 commands may be exchanged between the
   Home Agent and the home AAA server.

4.4.1.  Session-Termination-Request Command

   The Session-Termination-Request (STR) message [9] is sent by the Home
   Agent to inform the Diameter server that an authorized session is
   being terminated.

4.4.2.  Session-Termination-Answer Command

   The Session-Termination-Answer (STA) message [9] is sent by the
   Diameter server to acknowledge the notification that the session has
   been terminated.

4.4.3.  Abort-Session-Request Command

   The Abort-Session-Request (ASR) message [9] is sent by the Diameter
   server to terminates the session.  This fulfills one of the
   requirement described in [11].



Bournelle (Ed.), et al.  Expires April 25, 2007                 [Page 9]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


4.4.4.  Abort-Session-Answer Command

   The Abort-Session-Answer (ASA) message [9] is sent by the Home Agent
   in response to an ASR message.


5.  Command-Code Values

   This section defines Command-Code [9] value that MUST be supported by
   all Diameter implementations conforming to this specification.  The
   following Command Codes are defined in this specification:


           Command-Name               Abbreviation  Code   Section
           ---------------------------------------------------------
           MIP6-Authorization-Request      MAR      TBD
           MIP6-Authorization-Answer       MAA      TBD

                                 Figure 3

5.1.  MIP6-Authorization-Request

   The MIP6-Authorization-Request (MAR), indicated by the Command-Code
   field set to TBD and the 'R' bit set in the Command Flags field is
   sent by the Home Agent acting as a Diameter Client.  This message is
   used by the Home-Agent to authorize the Mobile IPv6 service.

5.2.  MIP6-Authorization-Answer

   The MIP6-Authorization-Answer (MAA), indicated by the Command-Code
   field set to TBD and the 'R' bit cleared in the Command Flags field
   is sent by the AAAH (AAAH-MIP6) in response to MIP6-Authorization-
   Request.


6.  Result-Code AVPs

   This section defines new Result-Code [9] values that MUST be
   supported by all Diameter implementations that conform to this
   specification.

   To be completed.


7.  Mandatory AVPs

   To be completed.




Bournelle (Ed.), et al.  Expires April 25, 2007                [Page 10]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


8.  Accounting AVPs

   To be completed.


9.  AVP Occurence Tables

   To be completed.


10.  Open Issues

10.1.  Authentication Token

   Authentication and Authorization/Accounting process may be handled by
   two different AAA servers, namely AAAH-EAP and AAAH-MIP6.  As such,
   the AAAH-MIP6 does not know if the MN has been correctly
   authenticated before authorizing the service.

   The issue is to know wether we need to provide a proof to the AAAH-
   MIP6 that the MN is correctly authenticated by AAAH-EAP

10.2.  HA as a Single Physical Device

   The HA acts as a IKEv2 responder with the MN.  As such, it can be
   colocated with a VPN concentrator.

   The issue is how the HA know that the MN want MIP6 service.

10.3.  Triggering the MIP6 Authorization Application

   If EAP is used to authenticate the MN, the HA uses two applications
   to perform AAA operations: Diameter EAP and the MIP6 Authorization
   Application.

   The issue is to know when the MIP6 Authorization Application must be
   used by the HA.

   This issue is tied with the "HA as a single box" one.  If the only
   way for the HA to know that it was for mip6 is to wait for a BU from
   the MN, then the Application can be used only after the reception of
   the BU.  However, if we want to do HoA-Allocation authorization by
   the AAAH-MIP6, this implies that the application must be used before
   the end of the IKEv2 exchange and thus before the BU reception







Bournelle (Ed.), et al.  Expires April 25, 2007                [Page 11]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


10.4.  RFC4285 Support

   This document deals with the HA-to-AAAH support in case IKEv2 is used
   to setup IPsec SAs between MN and HA to secure Mobile IPv6
   signalling.

   The issue is wether support for RFC 4285 mechanism should also be
   handled by this document.


11.  IANA Considerations

   To be completed.


12.  Security Considerations

   To be completed.


13.  Acknowledgements

   The authors would like to thanks Jari Arkko, Tolga Asversen, Pasi
   Eronen, Santiago Zapata Hernandez, Jouni Korhonen, Anders Kristensen,
   Avi Lior, John Loughney, Lionel Morand.  The authors would
   particularly like to thank Yoshihiro Ohba for suggesting the idea of
   creating a specific authorization application for Mobile IPv6 and to
   use Diameter EAP for the authentication part.

   The authors would like to thank the European Commission support in
   the co-funding of the ENABLE project, where this work is partly being
   developed.

   Julien Bournelle would like to thank Orange-FT which partly funded
   this work.


14.  References

14.1.  Normative References

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

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

   [3]   Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for



Bournelle (Ed.), et al.  Expires April 25, 2007                [Page 12]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


         the Integrated Scenario",
         draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
         progress), June 2006.

   [4]   Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
         draft-ietf-mip6-bootstrapping-split-02 (work in progress),
         March 2006.

   [5]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
         RFC 4306, December 2005.

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

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

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

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

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

14.2.  Informative References

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

   [12]  Alfano, F., "Diameter Quality of Service Application",
         draft-tschofenig-dime-diameter-qos-01 (work in progress),
         October 2006.

   [13]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
         Loughney, "Diameter Credit-Control Application", RFC 4006,
         August 2005.










Bournelle (Ed.), et al.  Expires April 25, 2007                [Page 13]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


Authors' Addresses

   Julien Bournelle
   GET/INT
   9 rue Charles Fourier
   Evry  91011
   France

   Email: julien.bournelle@int-evry.fr


   Gerardo Giaretta
   Telecom Italia Lab
   via G. Reiss Romoli, 274
   TORINO,   10148
   Italy

   Email: gerardo.giaretta@telecomitalia.it


   Hannes Tschofenig
   Siemens Networks GmbH & Co KG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

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


   Madjid Nakhjiri
   Huawei USA
   12040, 98th AVE NE, suite 200B
   Kirkland, WA  98033
   USA

   Email: mnakhjiri@huawei.com
   URI:













Bournelle (Ed.), et al.  Expires April 25, 2007                [Page 14]

Internet-Draft      Diameter MIP6: HA-to-AAAH support       October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.


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





Bournelle (Ed.), et al.  Expires April 25, 2007                [Page 15]


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