Diameter Maintenance and                                J. Korhonen, Ed.
Extensions (DIME)                                  Nokia Siemens Network
Internet-Draft                                              J. Bournelle
Intended status: Standards Track                             Orange Labs
Expires: July 18, September 7, 2009                                        A. Muhanna
                                                                  Nortel                                  K. Chowdhury
                                                        Starent Networks
                                                              A. Muhanna
                                                                  Nortel
                                                                U. Meyer
                                                             RWTH Aachen
                                                        January 14,
                                                           March 6, 2009

  Diameter Proxy Mobile IPv6: Support For Mobile Access Gateway and Local Mobility
                Anchor to Interaction with Diameter Server Interaction
                      draft-ietf-dime-pmip6-00.txt
                      draft-ietf-dime-pmip6-01.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 July 18, September 7, 2009.

Copyright Notice

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

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

Abstract

   This specification defines the Diameter support for the Proxy Mobile
   IPv6 and the corresponding mobility service session setup.  The
   policy information needed by the Proxy Mobile IPv6 is defined in
   mobile node's policy profile, which could be downloaded from the
   Diameter server to the Mobile Access Gateway once the mobile node
   roams into
   attaches to a Proxy Mobile IPv6 Domain and performs access
   authentication.  During the binding update exchange between the
   Mobile Access Gateway and the Local Mobility Anchor, the Local
   Mobility Anchor can interact with the Diameter server in order to
   update the remote policy store with the mobility session related
   information.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  4
   3.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Attribute Value Pair Definitions . . . . . . . . . . . . . . .  7
     4.1.  MIP6-Agent-Info AVP  . . . . . . . . . . . . . . . . . . .  7
     4.2.  PMIP6-IPv4-Home-Address AVP  . . . . . . . . . . . . . . .  7
     4.3.  PMIP6-DHCP-Address  MIP6-Home-Link-Prefix AVP  . . . . . . . . . . . . . . . . . .  8
     4.4.  PMIP6-Home-Prefix  PMIP6-DHCP-Server-Address AVP  . . . . . . . . . . . . . . . . . .  8
     4.5.  MIP6-Feature-Vector AVP  . . . . . . . . . . . . . . . . .  8
     4.6.  Mobile-Node-Identifier AVP . . . . . . . . . . . . . . . .  9
     4.7.  Calling-Station-Id AVP . . . . . . . . . . . . . . . . . . 10  9
     4.8.  Service-Selection AVP  . . . . . . . . . . . . . . . . . . 10
     4.9.  Session-Timeout  Service-Configuration AVP  . . . . . . . . . . . . . . . . . . . 10
   5.  MAG to HAAA Interface Application Support  . . . . . . . . . . 10
     5.1.  Application Support and Command Codes  . . . . . . . . . . 10
     5.2.  Accounting at MAG . . 11
     5.1.  MAG-to-HAAA Interface  . . . . . . . . . . . . . . . . . . 11
   6.  LMA to HAAA
     5.2.  LMA-to-HAAA Interface Application Support  . . . . . . . . . . 11
     6.1.  Application Support and Command Codes  . . . . . . . . . . 11
     6.2.
       5.2.1.  Authorization of the Proxy Binding Update  . . . . . . 12
   6.  Proxy Mobile IPv6 Session Management . . 11
       6.2.1.  LHA-Request  . . . . . . . . . . . . 12
     6.1.  Session-Termination-Request  . . . . . . . . . 12
       6.2.2.  LHA-Answer . . . . . . 13
     6.2.  Session-Termination-Answer . . . . . . . . . . . . . . . . 13
     6.3.  Accounting at LMA  . . . . . . .  Abort-Session-Request  . . . . . . . . . . . . . 14
   7.  Proxy Mobile IPv6 Session Management . . . . . 13
     6.4.  Abort-Session-Answer . . . . . . . . 14
     7.1.  Session-Termination-Request . . . . . . . . . . . 13
   7.  Attribute Value Pair Occurrence Tables . . . . 15
     7.2.  Session-Termination-Answer . . . . . . . . 13
     7.1.  MAG-to-HAAA Interface  . . . . . . . . 15
     7.3.  Abort-Session-Request . . . . . . . . . . 14
     7.2.  LMA-to-HAAA Interface  . . . . . . . . 15
     7.4.  Abort-Session-Answer . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . 15
   8.  Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 15 14
     8.1.  MAG to HAAA Interface  . .  Attribute Value Pair Codes . . . . . . . . . . . . . . . . 15 14
     8.2.  LMA to HAAA Interface  . . . . . . . . . . . . .  Namespaces . . . . . 17
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . 15
     8.3.  Result-Code AVP Values . . 17
     9.1.  Attribute Value Pair Codes . . . . . . . . . . . . . . . . 17
     9.2.  Namespaces 15
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   10. Acknowledgements . . . . . 17
     9.3.  Application Identifiers . . . . . . . . . . . . . . . . . 18
     9.4.  Command Codes . 15
   11. References . . . . . . . . . . . . . . . . . . . . . 18
     9.5.  Result-Code AVP Values . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . 18
   10. Security Considerations . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . 18
   11. Acknowledgements . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . 19
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     12.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 17

1.  Introduction

   In the Proxy Mobile IPv6 (PMIPv6) protocol [RFC5213] and its IPv4 support
   for Proxy Mobile IPv6 [I-D.ietf-netlmm-pmip6-ipv4-support] a Mobile
   Access Gateway (MAG) performs a proxy registration with a Local
   Mobility Anchor (LMA) on behalf of the mobile node (MN).  In order to
   perform the proxy registration the PMIPv6 MAG needs the IP address of the
   LMA, possibly MN's home network prefix Home Network Prefix(es) (MN-HNP), possibly MN's IPv4 home
   address (IPv4-HoA), (IPv4-MN-HoA), DHCP server address and other PMIPv6 specific
   information such as the allowed address configuration modes and possible
   roaming related policies.  All this information is defined in MN's
   policy profile that gets downloaded from the Diameter server to the
   MAG once the MN roams into a attaches to the MAG's Proxy Mobile IPv6 Domain (PMIPv6-Domain)
   (PMIPv6 Domain) and performs the access authentication.

   Dynamic assignment and downloading of PMIPv6 policy profile
   information is a desirable feature to ease the deployment and network
   maintenance of larger PMIPv6 deployments.  For this purpose, the AAA
   Authentication, Authorization, and Accounting (AAA) infrastructure,
   which is used for access authentication, can be leveraged to assign
   some or all of the necessary parameters.  The Diameter server in the
   Mobility Service authorizer's (MSA) or in the
   Mobility Service Provider's (MSP) network may return these
   parameters to the Network Access Server (NAS).

   Once the MN authenticates to the network the MAG sends a Proxy
   Binding Update (PBU) towards the LMA on behalf of the MN.  Upon
   arrival of  When the PBU
   LMA receives the PBU, the LMA needs may need to interact with update the Diameter server
   and fetch remote policy
   store located in the MSA with the MN's policy mobility session related information that was already
   partially downloaded to the MAG.
   information.

   This specification defines the Diameter support for the PMIPv6 and
   the corresponding mobility service session setup. PMIPv6.  In the
   context of this specification the location of the subscriber policy
   profile equals to the home Diameter server, which is also referred as
   the home AAA server (HAAA).  The NAS functionality of the MAG may be co-
   located
   co-located or an integral part of the MAG.  The access authentication
   procedure into a PMIPv6-Domain resembles the Mobile IPv6 integrated
   scenario bootstrapping [I-D.ietf-dime-mip6-integrated].  The
   assumption is that the Access Service Authenticator (ASA) is the same
   entity as the MSA/MSP.  This specification leverages the work already
   done for the Mobile IPv6 integrated scenario bootstrapping
   [I-D.ietf-dime-mip6-integrated].

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

   General mobility

   The general terminology used in this document can be found in [RFC3753].
   [RFC5213] and [I-D.ietf-netlmm-pmip6-ipv4-support].  The following
   additional or clarified terms are also used in this document:

   Network Access Server (NAS):

      A device that provides an access service for a user to a network.
      In the context of this document the NAS may be integrated into or
      co-located to a MAG.  The NAS contains a Diameter client function.

   Home AAA (HAAA):

      An authentication, authorization Authentication, Authorization, and accounting Accounting (AAA) server
      located in user's home network.  A HAAA is essentially a Diameter
      server.

3.  Solution Overview

   This document addresses the authentication, authorization, accounting AAA interactions and AAA-based session
   management functionality needed by in the PMIPv6 protocol. Domain.  This document
   defines Diameter based interfaces AAA interactions between the PMIPv6
   two entities, MAG and HAAA, to the HAAA.  The intention of this
   document is only to extend existing Diameter Mobile IPv6
   specifications such as [I-D.ietf-dime-mip6-integrated] HAAA,
   and define between the
   needed additional AVPs LMA and functionality to fully support PMIPv6
   deployment. the HAAA.

   The policy profile download is downloaded from the HAAA to the MAG is part of during the
   network access authentication procedure when a
   MN roams into or
   within a attachment to the PMIPv6 Domain.  Figure 1 shows the participating
   network entities.  This document, however, only concentrates on the MAG,
   LMA,
   possible local Diameter proxies and the home Diameter server.  When
   aligned with [I-D.ietf-dime-mip6-integrated] the MAG acts as the NAS
   located in ASP, the HAAA acts as the Diameter server located in ASA/
   MSA/MSP and the LMA acts as the HA in ASP/MSP.

    +--------+
    | HAAA & | Diameter +-----+
    | Policy |<---(1)-->| |<---(2)-->| LMA |
    | Profile|          +-----+
    +--------+             | <--- LMA-Address
         ^                 |
         |               // \\
     +---|------------- //---\\----------------+
    (    |  IPv4/IPv6  //     \\                )
    (    |   Network  //       \\               )
     +---|-----------//---------\\-------------+
         |          //           \\
     Diameter      // <- Tunnel1  \\ <- Tunnel2
        (2)
        (1)       //               \\
         |        |- MAG-Address1 MAG1-Address   |- MAG-Address2 MAG2-Address
         |     +----+             +----+
         +---->|MAG1|             |MAG2|
               +----+             +----+
                  |                 |
                  |                 |
                [MN1]             [MN2]

     Legend:

       (1): LMA <-> HAAA MAG-to-HAAA interaction is described
            in Section 6 5.1
       (2): MAG <-> HAAA LMA-to-HAAA interaction is described
            in Section 5 5.2

     Figure 1: Diameter Proxy Mobile IPv6 Support Domain Interaction with MAG to HAAA and LMA
                            to Diameter HAAA Interfaces

   In a PMIPv6 access scenario
                                  Server

   When a MN attaches to a PMIPv6-Domain and
   starts PMIPv6 Domain, a network access
   authentication procedure. procedure is usually started.  The choice of the
   authentication mechanism is specific to the access network
   deployment, but could be based on the Extensible Authentication
   Protocol (EAP) [RFC3748].  During the network access authentication
   procedure, the MAG acting as a NAS queries the HAAA through the AAA
   infrastructure using the Diameter protocol.  If the HAAA detects that
   the subscriber is also authorized for the PMIPv6 service, the
   subscriber policy PMIPv6
   specific information is returned along with the successful network
   access authentication answer to the MAG.

   After the MN access is has been successfully authenticated, the MAG sends a PBU
   to the LMA. LMA based on the MN's policy profile information.  Upon
   receiving the PBU the LMA interacts with the HAAA and fetches the
   relevant parts of the subscriber policy, authorization policy profile and
   security authorization
   information related to the PMIPv6 mobility service session.  This
   specification assumes that  In this
   specification, the HAAA is the central node for managing
   everything related to PMIPv6 subscription and session, possibly even
   including the allocation of prefixes.

   Prior to sending the PBU there might be a need to dynamically setup
   the MAG to LMA Security Association (SA), for example using IKEv2/
   IPSec [RFC4306].  The dynamic SA setup procedure may be triggered by
   the MN attaching to the MAG that does not have an existing SA with
   the correspondent LMA.  The details of has the dynamic SA setup procedure
   is out role of scope of this specification.  However, the SA is between the MAG and the corresponding LMA, thus it can be created using any
   security mechanism that is applicable for PMIPv6 security such as
   IKEv2 IPSec with an EAP-based authentication.  It should be noted
   that the identity used by the MAG during the SA creation is the MAG's
   own identity and the credentials are for authenticating the MAG
   toward the LMA and possibly for authorizing the MAG to offer Proxy
   Mobile IPv6 service with the same LMA. remote policy
   store.

4.  Attribute Value Pair Definitions

   This section describes both new AVPs Attribute Value Pairs (AVPs) defined in by this
   specification
   and or re-used AVPs that are used from existing specifications in a PMIPv6
   specific way.  The AVPs
   described here are applicable for both MAG to HAAA and LMA to HAAA
   interfaces.

4.1.  MIP6-Agent-Info AVP

4.1.  MIP6-Agent-Info AVP

   The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in
   [I-D.ietf-dime-mip6-integrated].
   [RFC5447].  The AVP is used to carry LMA addressing related
   information and a MN-HNP.  This specification reuses extends the MIP6-Agent-
   Info with the said PMIP6-IPv4-Home-Address AVP and its sub-AVPs using the Diameter
   extensibility rules defined in [RFC3588].  The PMIP6-IPv4-Home-
   Address AVP contains the IPv4-MN-HoA.

   The extended MIP6-Agent-Info AVP results to carry the LMA IP address and/or FQDN. following grouped
   AVP:

       MIP6-Agent-Info ::= < AVP-Header: 486 >
                         *2[ MIP-Home-Agent-Address ]
                           [ MIP-Home-Agent-Host ]
                           [ MIP6-Home-Link-Prefix ]
                           [ PMIP6-IPv4-Home-Address ]
                         * [ AVP ]

4.2.  PMIP6-IPv4-Home-Address AVP

   The PMIP6-IPv4-Home-Address AVP (AVP Code TBD) TBD2) is of type Address
   and contains the IPv4-HoA of the MN.  The primary use of this an IPv4 address.  This AVP is used to carry the IPv4 Home Address, IPv4-MN-
   HoA, if available, from the HAAA to the MAG.  This AVP SHOULD only be
   present when the MN is statically provisioned with the IPv4-MN-HoA.
   Note that proactive dynamic assignment of the IPv4-MN-HoA by the HAAA
   may result in unnecessary reservation of IPv4 address resources,
   because the MN may considerably delay or completely bypass its IPv4
   address configuration.

   The PMIP6-IPv4-Home-Address AVP may is also be used on the LMA to HAAA LMA-to-HAAA
   interface.  In this scenario the  The AVP contains the IPv4 Home Address
   the LMA has IPv4-MN-HoA assigned to the MN.  If
   the LMA delegates the assignment of the Home Address IPv4-MN-HoA to the HAAA, the
   AVP MUST contain all zeroes IPv4 address (i.e., 0.0.0.0) in the
   request message.  If the LMA delegated the IPv4-MN-HoA assignment to
   the HAAA, then the AVP contains the HAAA assigned IPv4-MN-HoA in the
   response message.

4.3.  MIP6-Home-Link-Prefix AVP

   The answer message SHOULD MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5447].
   This AVP is used to carry the MN-HNP, if available, from the HAAA to
   the MAG.  The low 64 bits of the prefix MUST be all cases zeroes.

   The MIP6-Home-Link-Prefix AVP is also used on the LMA-to-HAAA
   interface.  The AVP contains the prefix assigned to the MN.  If the
   LMA delegates the assignment of the MN-HNP to the HAAA, the AVP MUST
   contain all zeroes address (i.e., 0::0) in the request message.  If
   the LMA delegated the MN-HNP assignment to the HAAA, then the AVP
   contains the HAAA assigned IPv4 Home Address value.

4.3.  PMIP6-DHCP-Address MNM-HNP in the response message.

4.4.  PMIP6-DHCP-Server-Address AVP

   The PMIP6-DHCP-Address PMIP6-DHCP-Server-Address AVP (AVP Code TBD) TBD1) is of type Address
   and contains the IP address of the DHCPv4 and/or DHCPv6 server
   assigned to the MAG serving the newly attached MN.  If the AVP
   contains a DHCPv4 server address, then the Address type MUST be IPv4.
   If the AVP contains a DHCPv6 server address, then the Address type
   MUST be IPv6.  The HAAA MAY assign a DHCP server to the MAG in
   deployments where the MAG acts as a DHCP Relay and the DHCP Server is not co-
   located with the LMA
   [I-D.ietf-netlmm-pmip6-ipv4-support].

4.4.  PMIP6-Home-Prefix AVP

   The PMIP6-Home-Prefix AVP (AVP Code TBD) is of type Address and
   contains the MN-NHP.  The low 64 bits of the IPv6 address MUST be all
   zeroes.  The high 64 bits of the IPv6 address are used as the MN-HNP.
   The primary use of this AVP is to carry the IPv6 Home Network Prefix,
   if available, from the HAAA to the MAG.

   The PMIP6-Home-Prefix AVP may also be used on the LMA to HAAA
   interface.  In this scenario the AVP contains the prefix the LMA has
   assigned to the MN.  If the LMA delegates assignment of the home
   network prefix to the HAAA, the AVP MUST contain all zeroes address
   (i.e., 0::0) in the request message.  The answer message SHOULD in
   all cases contain the assigned home prefix value.

4.5.  MIP6-Feature-Vector AVP

   The MIP6-Feature-Vector AVP is originally defined in
   [I-D.ietf-dime-mip6-integrated]. [RFC5447].  This
   document only reserves defines new capability flag bits according to the rules in
   [I-D.ietf-dime-mip6-integrated].  The new reserved bits contain
   PMIPv6 capability announcement of the MAG and the HAAA(/LMA)).  Using
   the capability announcement it is possible to perform a simple
   capability negotiation between the MAG and the HAAA.  Those
   capabilities that are announced by both parties are also known to be
   mutually supported.  The following capability bits are defined in
   this document:
   [RFC5447].

   PMIP6_SUPPORTED (0x0000010000000000)

      When the MAG/NAS sets this bit in the MIP6-Feature-Vector AVP, it
      is an indication to the HAAA that the NAS supports PMIPv6.  When
      the HAAA sets this bit in the response MIP6-Feature-Vector AVP, it
      indicates that the HAAA also has PMIPv6 support.  This capability
      bit can also be used to allow PMIPv6 mobility support in a
      subscription granularity.

   IP4_HOA_SUPPORTED (0x0000020000000000)

      Assignment of the IPv4-HoA IPv4-MN-HoA is supported.  When the MAG sets
      this bit in the MIP6-Feature-Vector AVP, it indicates that the MAG
      implements a minimal functionality of a DHCP server (and a relay)
      and is able to deliver IPv4-HoA IPv4-MN-HoA to the MN.  When the HAAA sets
      this bit in the response MIP6-Feature-Vector AVP, it indicates
      that the HAAA has authorized the use of IPv4-HoA IPv4-MN-HoA for the MN.
      If this bit is unset in the returned MIP6-Feature-Vector AVP, the
      HAAA does not authorize the configuration of IPv4 address.

   LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000)

      Direct routing of IP packets between MNs anchored to the same MAG
      is supported.  When a MAG sets this bit in the MIP6-Feature-
      Vector, it indicates that routing IP packets between MNs anchored
      to the same MAG is supported, without reverse tunneling packets
      via the LMA or requiring any Route Optimization related signaling
      (e.g. the Return Routability Procedure in [RFC3775]) prior direct
      routing.  If this bit is unset in the returned MIP6-Feature-Vector
      AVP, the HAAA does not authorize direct routing of packets between
      MNs anchored to the same MAG.  This policy feature MUST SHOULD be
      supported per MN and subscription basis.

   The MIP6-Feature-Vector AVP is also used on the LMA to HAAA
   interface.  Using the capability announcement AVP it is possible to
   perform a simple capability negotiation between the LMA and the HAAA.
   Those capabilities that are announced by both parties are also known
   to be mutually supported.  The capabilities listed in earlier are
   also supported in the LMA to HAAA interface.  The LMA to HAAA
   interface does not define any new capability values.

4.6.  Mobile-Node-Identifier AVP

   The Mobile-Node-Identifier AVP (AVP Code TBD) TBD3) is of type UTF8String
   and contains the mobile node identifier (MN-Identifier, see
   [RFC5213]) in a the NAI [RFC4282] format.  This AVP is used on the MAG-
   to-HAAA interface.  The Mobile-Node-Identifier AV is designed for
   deployments where the MAG does not have a way to find out such MN
   identity that could be used in subsequent PBU/PBA exchanges (e.g.,
   due to identity hiding during the network access authentication) or
   the HAAA interface. wants to assign periodically changing identities to the MN.

   The Mobile-Node-Identifier AVP is returned in the answer message that
   ends a successful authentication (and possibly an authorization)
   exchange between the MAG and the HAAA, assuming the HAAA is also able
   to provide the MAG with the MN-Identifier in the first place.  The
   MAG MUST use the received MN-Identifier, if it has not been able to
   get the mobile node identifier through other means.  If the MAG
   already has a valid mobile node identifier, then the MAG MAY MUST
   silently discard the received MN-identifier.

4.7.  Calling-Station-Id AVP

   The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and
   contains a Link-Layer Identifier of the MN.  This identifier may
   correspond
   corresponds to a real physical interface or something that the MAG has
   generated. Link-Layer Identifier as defined in RFC 5213
   Section 2.2. and 8.6.

4.8.  Service-Selection AVP

   The Service-Selection AVP (AVP Code TBD) is of type UTF8String and
   contains a LMA provided service identifier on the LMA to HAAA LMA-to-HAAA
   interface.  The service identifier may be  This AVP is re-used from [I-D.ietf-dime-mip6-split].  The
   service identifier may be used to assist the PBU
   authorization. authorization and
   the assignment of the MN-HNP and the IPv4-MN-HoA as described in RFC
   5149 [RFC5149].  The identifier MUST be unique within the PMIPv6
   domain.  This AVP is re-used from [I-D.ietf-dime-mip6-split].

4.9.  Session-Timeout AVP

   The Session-Timeout AVP (AVP Code 27) is of type Unsigned32 and
   contains lifetime
   Domain.  In the absence of the Binding Cache Entry Service-Selection AVP in a unit of seconds.

5.  MAG to HAAA Interface Application Support

5.1.  Application Support and Command Codes

   This specification does not define a new Application-ID for the MAG
   to request
   message, the HAAA interface.  Rather, this specification re-uses any Diameter
   application and its commands that are used may want to authenticate and
   authorize inform the MN for LMA of the network access and mobility service.
   Example applications include NASREQ [RFC4005] and EAP [RFC4072].  The
   MAG acts as a Diameter client.

   The MAG to HAAA interface is primarily used for bootstrapping PMIPv6
   mobility default service session when a MN attaches and authenticates
   provisioned to a
   PMIPv6 domain.  This includes the bootstrapping of PMIPv6 session
   related information MN and possibly PMIPv6 security related information
   retrieval.  The same interface may include the Service-Selection AVP in the
   response message.

   It is also be used for accounting.

   Whenever possible that the MAG sends a Diameter request message to receives the HAAA service selection
   information from the
   User-Name AVP MUST contain MN, for example, via some lower layer mechanism.
   In this case the MN identity.  At minimum MAG SHOULD include the home
   realm Service-Selection AVP also in
   the MAG-to-HAAA request messages.  In absence of the MN MUST be available at Service-
   Selection AVP in the MAG when MAG-to-HAAA request messages, the network access
   authentication takes place.  Otherwise HAAA may want
   to inform the MAG is not able to route of the Diameter request messages towards default service provisioned to the correct HAAA.  The MN
   identity MUST be in Network Access Identifier (NAI) [RFC4282] format.

   The Diameter and
   include the Service-Selection AVP in the response messages MAY contain Framed-IPv6-Prefix and/or
   Framed-IPv4-Address AVPs.  For example message.

   Whenever the Service-Selection AVP is included either in a local Diameter proxy MAY add
   those request
   message or in order to advertise locally available prefixes a response message, and addresses
   as well [I-D.damic-netlmm-pmip6-ind-discover].  It the AAA interaction with HAAA
   completes successfully, it is also possible an indication that PMIPv6 mobility support is not allowed for a subscription.  In
   this case, a MAG may still provide normal IP connectivity to the MN
   using, for example, local address pools.

5.2.  Accounting at MAG

   The accounting at HAAA also
   authorized the MAG MN to HAAA interface is based on some service.  This should be taken into account
   when considering what to include in the
   [RFC4005]. Auth-Request-Type AVP.

   The application identifier service selection concept supports signaling one service at time.
   However, the MN policy profile MAY support multiple services being
   used for accounting is simultaneously.  For this purpose, the
   Diameter Base Accounting (3) [RFC3588].

   TBD.

6.  LMA to HAAA Interface Application Support

6.1.  Application Support and Command Codes

   The MAY return multiple
   LMA and service pairs (see Section 4.9) to HAAA interface may be used for multiple purposes.  These
   include the authorization of MAG in a response
   message that ends a successful authentication (and possibly an
   authorization) exchange between the incoming PBU, possible PMIPv6
   security related information retrieval, accounting MAG and PMIPv6 the HAAA.  Whenever the
   MN initiates additional mobility session
   management.

   This specification defines to another service (using a new Application-ID for
   link layer or deployment specific method), the LMA to HAAA
   interface and specifically provisioned service
   information is already contained in the MAG.  Therefore, there is no
   need for additional AAA signaling between the authorization of MAG and the Proxy Binding
   Updates. HAAA.

4.9.  Service-Configuration AVP

   The new application identifier Service-Configuration AVP (AVP Code TBD4) is TBD BY IANA.  The new
   application also defines two new commands and respective Command
   Codes: LHA-Request (value of TBD) type Grouped and LHA-Answer (value of TBD).  The
   LMA
   contains a service and a LMA pair.  The HAAA can use this AVP to
   inform the MAG of MN's subscribed services and LMAs where those
   services are hosted in.

       Service-Configuration ::= < AVP-Header: TBD4 >
                                 [ MIP6-Agent-Info ]
                                 [ Service-Selection ]
                               * [ AVP ]

5.  Application Support and Command Codes

5.1.  MAG-to-HAAA Interface

   This specification does not define a new Application-ID for the MAG-
   to-HAAA Diameter connection.  Rather, this specification re-uses any
   Diameter application and their commands that are used to authenticate
   and authorize the MN for the network access.  Example applications
   include NASREQ [RFC4005] and EAP [RFC4072].  The MAG acts as a
   Diameter client.

6.2.  Authorization of

   The MAG-to-HAAA interactions are primarily used for bootstrapping
   PMIPv6 mobility service session when a MN attaches and authenticates
   to a PMIPv6 Domain.  This includes the Proxy Binding Update bootstrapping of PMIPv6
   session related information.  The same interface may also be used for
   accounting.

   Whenever the LMA MAG sends a Diameter request message to the HAAA, HAAA the
   User-Name AVP MUST SHOULD contain the MN MN's identity.  The identity MN identity, if
   available, MUST be in
   a NAI Network Access Identifier (NAI) [RFC4282]
   format.  The LMA MAY retrieve  At minimum the MN identity information from home realm of the PBU MN-ID [RFC4283][RFC5213] mobility option.  The identity
   SHOULD MN MUST be available at the same as used on
   MAG when the network access authentication takes place.  Otherwise
   the MAG is not able to HAAA interface, but in a
   case those identities differ route the HAAA MUST have a mechanism of
   mapping Diameter request messages towards
   the correct HAAA.  The MN identity used on the MAG to HAAA MAG-to-HAAA interface to
   and in the
   identity used on User-Name AVP MAY entirely be related to the LMA network
   access authentication, and therefore not suitable to HAAA interface.

   If be used as the PBU contains
   MN-ID mobility option value in the MN Link-Layer Identifier option, subsequent PBU/PBA messages.  See
   the Calling-
   Station-Id AVP SHOULD be included related discussion on MN's identities in Section 4.6 and in
   Section 5.2.1

   For the session management and service authorization purposes,
   session state SHOULD be maintained on the MAG-to-HAAA interface.  See
   the discussion in Section 4.8.

5.2.  LMA-to-HAAA Interface

   The-LMA-to HAAA interface may be used for multiple purposes.  These
   include the authorization of the incoming PBU, updating the LMA
   address to the HAAA, accounting and PMIPv6 session management.

   This specification does not define a new Application-ID for the LMA-
   to-HAAA Diameter connection.  Rather, this specification re-uses any
   Diameter application and their commands.  An example application
   could be NASREQ [RFC4005].  The LMA acts as a Diameter client.

5.2.1.  Authorization of the Proxy Binding Update

   Whenever the LMA sends a Diameter request message to the HAAA, the
   User-Name AVP SHOULD contain the MN's identity.  The LMA MAY retrieve
   the MN's identity information from the PBU MN-ID [RFC4283][RFC5213]
   mobility option.  The identity SHOULD be the same as used on the MAG-
   to-HAAA interface, but in the case those identities differ the HAAA
   MUST have a mechanism of mapping the MN identity used on the MAG-to-
   HAAA interface to the identity used on the LMA-to-HAAA interface.

   If the PBU contains the MN Link-Layer Identifier option, the Calling-
   Station-Id AVP SHOULD be included in the request message containing
   the received Link-Layer Identifier.  Furthermore, if the PBU contains
   the Service Selection mobility option [RFC5149], the Service-
   Selection AVP SHOULD be included in the request message containing
   the received service identifier.

   The LMA and the HAAA use the PMIP6-Home-Prefix MIP6-Home-Link-Prefix AVP to exchange
   the MN-HNP when appropriate.  The low 64 bits of the prefix must be all
   zeroes.  Similarly, the LMA and the HAAA use the PMIP6-IPv4-Home-
   Address
   PMIP6-IPv4-Home-Address AVP to exchange the MN IPv4-HoA IPv4-MN-HoA when
   appropriate.  If  Note that these AVPs are encapsulated inside the
   PMIP6-Home-Prefix MIP6-
   Agent-Info AVP.  Which entity is set to an all zeroes address (i.e., 0::0) in actually responsible for the
   request message, it address
   management is an indication that the HAAA needs to assign a deployment specific within the MN-HNP PMIPv6 Domain and return it to the LMA in the response message.  If the
   PMIP6-IPv4-Home-Address is set to all zeroes (i.e., 0.0.0.0) in the
   request message, it is an indication that the HAAA needs to assign
   the MN IPv4-HoA and return it to the LMA in the response message.

   The Auth-Request-Type AVP MUST be set MUST
   be pre-agreed on per deployment basis.

   The Auth-Request-Type AVP MUST be set to the value AUTHORIZE_ONLY.
   If the HAAA is not able to authorize the subscriber's mobility
   service session, then the reply message to the LMA MUST have the
   Result-Code AVP set to value DIAMETER_PMIP6_AUTHORIZATION_FAILED (TBD
   BY IANA)
   (TBD5) indicating a permanent failure.

   The LMA to HAAA LMA-to-HAAA interface can also be used to update the selected LMA
   address to the HAAA. HAAA and the remote policy store during the
   authorization step.  This applies to the case where the MAG, for
   example, discovers discovered the LMA address using the DNS.

6.2.1.  LHA-Request

   The LHA-Request (LHAR, value of TBD) message is sent by

6.  Proxy Mobile IPv6 Session Management

   Concerning a PMIPv6 mobility session, the LMA to HAAA, the MAG and the LMA
   Diameter server to initiate entities SHOULD be stateful and maintain the corresponding
   Authorization Session State Machine defined in [RFC3588].  If a state
   is maintained, then a PMIPv6 mobility service session
   authorization procedure.  The LHAR message format is defined below:

   <LHA-Request> ::= < Diameter Header: TBD, REQ, PXY >
                     < Session-ID >
                     { Auth-Application-Id }
                     { User-Name }
                     { Destination-Realm }
                     { Origin-Host }
                     { Origin-Realm }
                     { Auth-Request-Type }
                     [ Destination-Host ]
                     [ Origin-State-Id ]
                     [ NAS-Identifier ]
                     [ NAS-IP-Address ]
                     [ NAS-IPv6-Address ]
                     [ NAS-Port-Type ]
                     [ Called-Station-Id ]
                     [ Calling-Station-Id ]
                     { MIP6-Feature-Vector }
                     { MIP6-Agent-Info }
                   * [ PMIP6-Home-Prefix ]
                     [ PMIP6-IPv4-Home-Address ]
                     [ Service-Selection ]
                     [ Authorization-Lifetime ]
                     [ Auth-Session-State ]
                   * [ Proxy-Info ]
                   * [ Route-Record ]
                   * [ AVP ]

6.2.2.  LHA-Answer

   The LHA-Answer (LHAA, value that can be identified
   by any of TBD) message is sent the Binding Cache (BCE) Lookup Keys described in response RFC 5213
   (see Sections 5.4.1.1., 5.4.1.2. and 5.4.1.3.)  MUST map to
   the LHA-Request (LHAR) message. a single
   Diameter Session-Id.  If the mobility service session
   authorization procedure was successful then the response MAY include PMIPv6 LMA to HAAA interface AVPs.  The PMIP6-Home-Prefix AVP
   contains MN-HNP Domain allows further separation
   of sessions, for example, identified by the RFC 5213 BCE Lookup Keys
   and the PMIP6-IPv4-Home-Address AVP contains IPv4-
   HoA, if such information are needed.  The LHAA message format is
   defined below:

   <LHA-Answer> ::= < service selection combination (see Section 4.8 and
   [RFC5149]), then a single Diameter Header: TBD, PXY >
                    < Session-Id >
                    { Auth-Application-Id }
                    { Result-Code }
                    { Origin-Host }
                    { Origin-Realm }
                    { Auth-Request-Type }
                    [ User-Name ]
                    [ Authorization-Lifetime ]
                    [ Auth-Session-State ]
                    [ Error-Message ]
                    [ Error-Reporting-Host ]
                    [ Re-Auth-Request-Type ]
                    [ MIP6-Feature-Vector ]
                  * [ PMIP6-Home-Prefix ]
                    [ PMIP6-IPv4-Home-Address ]
                    [ Session-Timeout ]
                    [ Chargeable-User-Identity ]
                    [ Origin-State-Id ]
                  * [ Proxy-Info ]
                  * [ Redirect-Host ]
                    [ Redirect-Host-Usage ]
                    [ Redirect-Max-Cache-Time ]
                  * [ Failed-AVP ]
                  * [ AVP ]

6.3.  Accounting at LMA

   The accounting at the LMA MUST map to HAAA interface is based on a PMIPv6
   mobility session identified by the
   [RFC4005].  The application identifier used for accounting is RFC 5213 BCE Lookup Keys and the
   Diameter Base Accounting (3) [RFC3588].

   TBD.

7.  Proxy Mobile IPv6 Session Management

   Concerning
   selected service.

   If both the MAG-to-HAAA and the LMA-to-HAAA interfaces are deployed
   in a PMIPv6 session, Domain, and a state is maintained on both interfaces,
   then one PMIPv6 mobility session would have two distinct Diameter
   sessions on the HAAA MAY maintain a state. HAAA.  The LMA HAAA needs to be aware of this deployment
   possibility and SHOULD allow multiple Diameter sessions for the MAG MUST support the Authorization Session State Machine
   defined in [RFC3588]. same
   PMIPv6 mobility session.

   Diameter session termination related commands described in the
   following sections may be exchanged between the LMA and the HAAA, or
   between the MAG and the HAAA.  The actual PMIPv6 session termination
   procedures take place at PMIPv6 protocol level and are out of scope of this document.

7.1. described in
   more detail in RFC 5213 and [I-D.ietf-mext-binding-revocation].

6.1.  Session-Termination-Request

   The LMA or the MAG MAY send the Session-Termination-Request (STR)
   command [RFC3588] to the HAAA and inform the termination of an
   ongoing PMIPv6 session is in progress.

7.2.

6.2.  Session-Termination-Answer

   The Session-Termination-Answer (STA) [RFC3588] is sent by the HAAA to
   acknowledge the termination of a PMIPv6 session.

7.3.  Abort-Session-Request

   The HAAA MAY send the Abort-Session-Request (ACR) command [RFC3588]
   to the LMA or to the MAG and request termination of a PMIPv6 session.

7.4.  Abort-Session-Answer

   The Abort-Session-Answer (ASA) command [RFC3588]is sent by the LMA or
   the MAG to acknowledge that the termination of a PMIPv6 session.

8.  Attribute Value Pair Occurrence Tables

   The following tables list the PMIPv6 MAG to HAAA interface and LMA to
   HAAA interface AVPs including those that are defined in
   [I-D.ietf-dime-mip6-integrated].

   The Figure 2 contains the AVPs and their occurrences on the MAG to
   HAAA interface.  The AVPs that are part of grouped AVP are not listed
   in the table, rather only the grouped AVP is listed.

8.1.  MAG to HAAA Interface
                                     +---------------+
                                     |  Command-Code |
                                     |-------+-------+
      Attribute Name                 |  REQ  |  ANS  |
      -------------------------------+-------+-------+
      PMIP6-DHCP-Address             |   0   |  0+   |
      MIP6-Agent-Info                |   0   |  0+   |
      MIP6-Feature-Vector            |  0-1  |  0-1  |
      PMIP6-IPv4-Home-Address        |   0   |  0-1  |
      PMIP6-Home-Prefix              |   0   |   0+  |
      Mobile-Node-Identifier         |  0-1  |  0-1  |
      Calling-Station-Id             |  0-1  |   0   |
                                     +-------+-------+

    Figure 2: MAG to HAAA Interface Generic Diameter Request and Answer
                               Commands AVPs

   The following table describes the Diameter AVPs code values, types,
   possible flag values, and whether the AVP MAY be encrypted. a PMIPv6 session.

6.3.  Abort-Session-Request

   The
   Diameter base protocol specification [RFC3588] specifies HAAA MAY send the AVP
   Flags rules for AVPs in section 4.5.  Due Abort-Session-Request (ASR) command [RFC3588]
   to space constraints, the
   short form DiamIdent is used LMA or to represent DiameterIdentity the MAG and
   OctetStr is used to represent OctetString.

                                             +--------------------+
                                             |   AVP Flag rules   |
                                             +----+----+----+-----+----+
                      AVP  Section           |    |    |SHLD|MUST |    |
   Attribute Name     Code Defined Data Type |MUST| MAY|NOT |NOT  |Encr|
   ------------------------------------------+----+----+----+-----+----+
   MIP6-Agent-Info    TBD  4.1     Grouped   |    |  P |    | M,V | Y  |
   PMIP6-IPv4-Home-                          |    |    |    |     |    |
       Address        TBD  4.2     Address   |    |  P |    | M,V | Y  |
   PMIP6-DHCP-Address TBD  4.3     Address   |    |  P |    | M,V | Y  |
   PMIP6-Home-Prefix  TBD  4.4     Address   |    |  P |    | M,V | Y  |
   MIP6-Feature-                             |    |    |    |     |    |
       Vector         TBD  4.5     Unsigned64|    |  P |    | M,V | Y  |
   Calling-Station-Id  31  4.7     UTF8String|    |  P |    | M,V | Y  |
   Mobile-Node-                              |    |    |    |     |    |
       Identifier     TBD  4.6     UTF8String|    |  P |    | M,V | Y  |
   ------------------------------------------+----+----+----+-----+----+

                      Figure 3: AVP Flag Rules Table

8.2. request termination of a PMIPv6 session.

6.4.  Abort-Session-Answer

   The Abort-Session-Answer (ASA) command [RFC3588]is sent by the LMA or
   the MAG to HAAA Interface acknowledge that the termination of a PMIPv6 session.

7.  Attribute Value Pair Occurrence Tables

   The AVP occurrences following tables list the PMIPv6 MAG-to-HAAA interface and LMA-
   to-HAAA interface AVPs including those that are defined in the ABNFs for the LHA-Request (see
   Section 6.2.1) and LHA-Answer (see Section 6.2.2) commands. [RFC5447].

   The following table describes Figure 2 contains the Diameter AVPs code values, types,
   possible flag values, and whether their occurrences on the AVP MAY be encrypted. MAG-to-
   HAAA interface.  The
   Diameter base protocol specification [RFC3588] specifies the AVP
   Flags rules for AVPs that are part of grouped AVP are not listed
   in section 4.5.  Due to space constraints, the
   short form DiamIdent is used to represent DiameterIdentity and
   OctetStr is used to represent OctetString.

                                             +--------------------+
                                             |   AVP Flag rules   |
                                             +----+----+----+-----+----+ table, rather only the grouped AVP  Section           |    |    |SHLD|MUST is listed.

7.1.  MAG-to-HAAA Interface

                                     +---------------+
                                     |  Command-Code |
                                     |-------+-------+
      Attribute Name     Code Defined Data Type |MUST| MAY|NOT |NOT  |Encr|
   ------------------------------------------+----+----+----+-----+----+
   MIP6-Agent-Info    TBD  4.1     Grouped   |  M |  P |    |  V  | Y  |
   PMIP6-IPv4-Home-                 |  REQ  |  ANS  |
      -------------------------------+-------+-------+
      PMIP6-DHCP-Server-Address      |   0   |  0+   |
       Address        TBD  4.2     Address
      MIP6-Agent-Info                |  M  0+   |  P  0+   |
      MIP6-Feature-Vector            |  V  0-1  | Y  0-1  |
   PMIP6-Home-Prefix  TBD  4.4     Address
      Mobile-Node-Identifier         |  M  0-1  |  P  0-1  |
      Calling-Station-Id             |  V  0-1  | Y   0   |
   MIP6-Feature-
      Service-Selection              |  0-1  |   0   |
      Service-Configuration          |   0   |  0+   |
       Vector         TBD  4.5     Unsigned64|  M
                                     +-------+-------+

    Figure 2: MAG-to-HAAA Interface Generic Diameter Request and Answer
                               Commands AVPs

7.2.  LMA-to-HAAA Interface

                                     +---------------+
                                     |  P  Command-Code |
                                     |-------+-------+
      Attribute Name                 |  V  REQ  | Y  ANS  |
   Calling-Station-Id  31  4.7     UTF8String|  M
      -------------------------------+-------+-------+
      MIP6-Agent-Info                |  P  0-1  |  0-1  |  V
      MIP6-Feature-Vector            | Y  0-1  |
   Service-Selection  TBD  4.8     UTF8String|  M  0-1  |  P
      Calling-Station-Id             |  0-1  |  V   0   | Y
      Service-Selection              |
   Session-Timeout     27  4.9     Unsigned32|  M  0-1  |  P  0-1  |
      User-Name                      |  V  0-1  | Y  0-1  |
   ------------------------------------------+----+----+----+-----+----+
                                     +-------+-------+

    Figure 4: AVP Flag Rules Table

9. 3: LMA-to-HAAA Interface Generic Diameter Request and Answer
                               Commands AVPs

8.  IANA Considerations

9.1.

8.1.  Attribute Value Pair Codes

   This specification defines the following new AVPs:

     PMIP6-DHCP-Address

     PMIP6-DHCP-Server-Address   is set to TBD
     PMIP6-Home-Prefix TBD1
     PMIP6-IPv4-Home-Address     is set to TBD
     PMIP6-IPv4-Home-Address TBD2
     Mobile-Node-Identifier      is set to TBD
     Mobile-Node-Identifier TBD3
     Service-Configuration       is set to TBD

9.2. TBD4

8.2.  Namespaces

   This specification defines new values to the Mobility Capability
   registry (see [I-D.ietf-dime-mip6-integrated]) [RFC5447]) for use with the MIP6-
   Feature-Vector MIP6-Feature-Vector AVP:

   Token                            | Value                | Description
   ---------------------------------+----------------------+------------
   PMIP6_SUPPORTED                  | 0x0000010000000000   | [RFC TBD]
   IP4_HOA_SUPPORTED                | 0x0000020000000000   | [RFC TBD]
   LOCAL_MAG_ROUTING_SUPPORTED      | 0x0000040000000000   | [RFC TBD]

9.3.  Application Identifiers

   This specification requires IANA to allocate a new value for
   "Diameter Proxy Mobile IPv6" (PMIP6) from the Application Identifier
   namespace defined in [RFC3588].

9.4.  Command Codes

   IANA is requested to allocate new command code values for the
   following new commands from the Command Code namespace defined in
   [RFC3588].

   Command Code                       | Value
   -----------------------------------+------
   LHA-Request                 (LHAR) | TBD
   LHA-Answer                  (LHAA) | TBD

9.5.

8.3.  Result-Code AVP Values

   This specification requests IANA to allocate a new value to the
   Result-Code AVP (AVP Code 268) address space within the Permanent
   Failures category (5xxx) defined in [RFC3588]:

     DIAMETER_PMIP6_AUTHORIZATION_FAILED  is set to TBD

10. TBD5

9.  Security Considerations

   The security considerations of the Diameter Base protocol [RFC3588],
   Diameter EAP application [RFC4072], Diameter NASREQ application
   [RFC4005] and Diameter Mobile IPv6 integrated scenario bootstrapping
   [I-D.ietf-dime-mip6-integrated]
   [RFC5447] are applicable to this document.

   In general, the Diameter messages may be transported between the HA
   and the Diameter server via one or more AAA brokers or Diameter
   agents.  In this case the HA to the Diameter server AAA communication
   rely on the security properties of the intermediate AAA brokers and
   Diameter agents (such as proxies).

11.

10.  Acknowledgements

   Jouni Korhonen would like to thank the TEKES MERCoNe GIGA program MERCoNe-
   project for providing funding to work on this document while he was
   with TeliaSonera.

12.

11.  References

12.1.

11.1.  Normative References

   [I-D.ietf-dime-mip6-integrated]
              Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
              and K. Chowdhury, "Diameter Mobile IPv6: Support for
              Network Access Server to Diameter Server  Interaction",
              draft-ietf-dime-mip6-integrated-12 (work in progress),
              January 2009.

   [I-D.ietf-netlmm-pmip6-ipv4-support]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-07 draft-ietf-netlmm-pmip6-ipv4-support-09
              (work in progress), December 2008. January 2009.

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

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

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

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

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

12.2.  Informative References

   [I-D.damic-netlmm-pmip6-ind-discover]
              Damic, D., Premec, D., Patil, B., Sahasrabudhe, M.,

   [RFC5447]  Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
              and S.
              Krishnan, "Proxy K. Chowdhury, "Diameter Mobile IPv6 indication and discovery",
              draft-damic-netlmm-pmip6-ind-discover-03 (work in
              progress), IPv6: Support for
              Network Access Server to Diameter Server Interaction",
              RFC 5447, February 2008. 2009.

11.2.  Informative References

   [I-D.ietf-dime-mip6-split]
              Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G.,
              and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home
              Agent to Diameter Server  Interaction",
              draft-ietf-dime-mip6-split-16 (work in progress),
              December 2008.

   [I-D.ietf-mext-binding-revocation]
              Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
              and P. Yegani, "Binding Revocation for IPv6 Mobility",
              draft-ietf-mext-binding-revocation-03 (work in progress),
              January 2009.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.

              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

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

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

   [RFC4283]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
              (MIPv6)", RFC 4283, November 2005.

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

   [RFC5149]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
              Selection for Mobile IPv6", RFC 5149, February 2008.

Authors' Addresses

   Jouni Korhonen (editor)
   Nokia Siemens Network
   Linnoitustie 6
   Espoo  FIN-02600  FI-02600
   Finland

   Email: jouni.nospam@gmail.com

   Julien Bournelle
   Orange Labs
   38-4O rue du general Leclerc
   Issy-Les-Moulineaux  92794
   France

   Email: julien.bournelle@orange-ftgroup.com

   Ahmad Muhanna
   Nortel
   2221 Lakeside Blvd.
   Richardson, TX  75082
   USA

   Email: amuhanna@nortel.com

   Kuntal Chowdhury
   Starent Networks
   30 International Place
   Tewksbury  MA  01876
   USA

   Email: kchowdhury@starentnetworks.com
   Ahmad Muhanna
   Nortel
   2221 Lakeside Blvd.
   Richardson, TX  75082
   USA

   Email: amuhanna@nortel.com

   Ulrike Meyer
   RWTH Aachen

   Email: meyer@umic.rwth-aachen.de