Skip to main content

Diameter Support for Proxy Mobile IPv6 Localized Routing
draft-ietf-dime-pmip6-lr-10

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7156.
Authors Glen Zorn , Qin Wu , Marco Liebsch , Jouni Korhonen
Last updated 2012-03-29 (Latest revision 2012-02-21)
Replaces draft-wu-dime-pmip6-lr
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Other - see Comment Log
Document shepherd Lionel Morand
Shepherd write-up Show Last changed 2011-12-13
IESG IESG state Became RFC 7156 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Benoît Claise
IESG note
Send notices to dime-chairs@tools.ietf.org, draft-ietf-dime-pmip6-lr@tools.ietf.org
draft-ietf-dime-pmip6-lr-10
Network Working Group                                            G. Zorn
Internet-Draft                                               Network Zen
Intended status: Standards Track                                   Q. Wu
Expires: August 25, 2012                                          Huawei
                                                              M. Liebsch
                                                                     NEC
                                                             J. Korhonen
                                                                     NSN
                                                       February 22, 2012

        Diameter Support for Proxy Mobile IPv6 Localized Routing
                      draft-ietf-dime-pmip6-lr-10

Abstract

   In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the
   Mobile Access Gateway (MAG) to which it is attached are typically
   tunneled to a Local Mobility Anchor (LMA) for routing.  The term
   "localized routing" refers to a method by which packets are routed
   directly between an MN's MAG and the MAG of its Correspondent Node
   (CN) without involving any LMA.  In order to establish a localized
   routing session between two Mobile Access Gateways in a Proxy Mobile
   IPv6 domain, two tasks must be accomplished:

   1.  The usage of localized routing must be authorized for both MAGs
       and

   2.  The address of the MAG to which the Correspondent Node (CN) is
       attached must be ascertained

   This document specifies how to accomplish these tasks using the
   Diameter protocol.

Status of this Memo

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

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

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

Zorn, et al.             Expires August 25, 2012                [Page 1]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

   This Internet-Draft will expire on August 25, 2012.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Zorn, et al.             Expires August 25, 2012                [Page 2]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Attribute Value Pair Definitions . . . . . . . . . . . . . . .  6
     4.1.  MIP6-Agent-Info AVP  . . . . . . . . . . . . . . . . . . .  6
     4.2.  PMIP6-IPv4-Home-Address AVP  . . . . . . . . . . . . . . .  6
     4.3.  MIP6-Home-Link-Prefix AVP  . . . . . . . . . . . . . . . .  6
     4.4.  MIP6-Feature-Vector AVP  . . . . . . . . . . . . . . . . .  6
   5.  Example Signaling flows  . . . . . . . . . . . . . . . . . . .  7
     5.1.  Localized Routing Service Authorization  . . . . . . . . .  7
     5.2.  Diameter Server Authorizes MAG Location Query  . . . . . . 11
   6.  Localized Routing Service Authorization in Networks with
       Multiple AAA Servers . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     11.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Zorn, et al.             Expires August 25, 2012                [Page 3]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

1.  Introduction

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] allows the Mobility Access
   Gateway to optimize media delivery by locally routing packets from a
   Mobile Node to a Correspondent Node that is locally attached to an
   access link connected to itself, avoiding tunneling them to the
   Mobile Node's Local Mobility Anchor.  This is referred to as "local
   routing" in RFC 5213.  However, this mechanism is not applicable to
   the typical scenarios in which the MN and CN are connected to
   different MAGs and are registered to the same LMA or different LMAs.
   In these scenarios (as described in [RFC6279]), the relevant
   information needed to set up a localized routing path (e.g., the
   addresses of the Mobile Access Gateways to which the MN and CN are
   respectively attached) is distributed between their respective Local
   Mobility Anchors.  This may complicate the setup and maintenance of
   localized routing.

   Therefore, in order to establish a localized routing path between the
   two Mobile Access Gateways, the Mobile Node's MAG must identify the
   LMA that is managing the Correspondent Node's traffic and then obtain
   the address of the Correspondent Node's MAG from that LMA.  In Proxy
   Mobile IPv6, the LMA to be assigned to the CN may be maintained as a
   configured entry in the Correspondent Node's policy profile located
   on an Authentication, Authorization and Accounting (AAA) server.
   However, there is no relevant work discussing how AAA-based
   mechanisms can be used by the Mobile Node's LMA to discover the
   address of the Correspondent Node's LMA during the setup of localized
   routing.  The method by which the Mobile Node's MAG or LMA interacts
   with the Correspondent Node's LMA to identify the Correspondent
   Node's MAG is also unspecified.

   This document describes AAA support for the authorization and
   discovery of PMIPv6 mobility entities during localized routing.  In
   LMA discovery, Diameter [I-D.ietf-dime-rfc3588bis] is used to
   authorize the localized routing service and provide the Mobile Node's
   MAG/LMA with information regarding the Correspondent Node's LMA.  In
   MAG discovery, AAA is used to determine whether Mobile Node's MAG is
   allowed to fetch the address of the Correspondent Node's MAG from the
   Correspondent Node's LMA.  If MAG discovery is successful, the
   Correspondent Node's LMA will respond to the Mobile Node's MAG with
   the address of the Correspondent Node's MAG.

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

Zorn, et al.             Expires August 25, 2012                [Page 4]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

3.  Solution Overview

   MAG/LMA discovery is a prerequisite to the establishment of a direct
   routing path between MAG1 and MAG2 (associated with MN1 and MN2
   respectively).  This document addresses how to resolve the
   destination MN's MAG by means of interaction between the LMA and the
   AAA server.  Figure 1 shows the reference architecture for Localized
   Routing Service Authorization.  This reference architecture assumes

   o  MN1 and MN2 belong to different LMAs or the same LMA.  If MN1 and
      MN2 belong to the same LMA, the LMA1 and LMA2 to which MN1 and MN2
      are anchored in Figure 1 should be the same LMA.  If MN1 and MN2
      belong to different LMAs, LMA1 and LMA2 in Figure 1 are in the
      same provider domain (as described in [RFC6279]).

   o  The MAG and LMA support Diameter client functionality.

                                   +---------+
                        LMA2?      |  AAA &  |
                           +------>| Policy  |<----------+
                           |       | Profile |           |
                       Diameter    +---------+        Diameter
                       (Step a)                       (Step b)
                           |                             |
                           |                             |
                           |                             |
                  LMA2? +--V-+             +----+        |
               +------->|LMA1|             |LMA2|<-------+
               |        +----+             +----+
               |          |                  |
               |         //                  \\
              PMIP      //                    \\
               |       //                      \\
               |       |                        |
               |     +----+  MAG2?            +----+
               +---->|MAG1|<--------          |MAG2|
                     +----+                   +----+
                        :                        :
                     +---+                     +---+
                     |MN1|                     |MN2|
                     +---+                     +---+

        Figure 1: Localized Routing Service Authorization Reference
                               Architecture

   The interaction of the MAG and LMA with the AAA server according to
   the extension specified in this document considers the follows

Zorn, et al.             Expires August 25, 2012                [Page 5]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

   features:

   a.  The interaction of LMA1 with the AAA server is used to authorize
       the localized routing service and, if necessary, fetch the IP
       address of LMA2 (Step a in Figure 1)

   b.  LMA2 interaction with the AAA server is used to determine whether
       MAG1 or LMA1 is allowed to obtain the IP address of MAG2 (Step b
       in Figure 1)

   Note that if MN1 and MN2 are connected to different MAGs but share
   the same LMA, the interaction between LMA1 and the AAA server should
   be exactly the same as the case where MNs belong to MAGs under
   different LMAs.

4.  Attribute Value Pair Definitions

   This section describes Attribute Value Pairs (AVPs) defined by this
   specification or re-used from existing specifications in a PMIPv6-
   specific way.

4.1.  MIP6-Agent-Info AVP

   The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in
   [RFC5447] and extended in [RFC5779].  This AVP is used to carry LMA
   addressing in the AA-Answer (AAA) message [I-D.ietf-dime-rfc4005bis].

4.2.  PMIP6-IPv4-Home-Address AVP

   The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in
   [RFC5779].  This AVP is used to carry the IPv4-MN-HoA (Mobile Node's
   IPv4 home address)[RFC5844] in the AA-Request (AAR) message
   [I-D.ietf-dime-rfc4005bis] from the LMA to the home AAA server
   (HAAA).

4.3.  MIP6-Home-Link-Prefix AVP

   The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779].
   This AVP is used to carry the MN-HNP (Mobile Node's home network
   prefix) in the AAR from the LMA to the HAAA.

4.4.  MIP6-Feature-Vector AVP

   The MIP6-Feature-Vector AVP is defined in [RFC5447].  This document
   allocates a new capability flag bit according to the IANA rules in
   RFC 5447.

Zorn, et al.             Expires August 25, 2012                [Page 6]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

   INTER_MAG_ROUTING_SUPPORTED (TBD)

      Direct routing of IP packets between MNs anchored to different
      MAGs without involving any LMA is supported.  This bit is used
      with MN-HNP or IPv4-MN-HoA.  When a LMA sets this bit in the MIP6-
      Feature-Vector and MN-HNP or IPv4-MN-HoA corresponding to the
      Correspondent Node is carried with this bit, it indicates to the
      HAAA that the Mobile Node associated with this LMA is allowed to
      use localized routing but the LMA needs to know from the HAAA if
      the Correspondent Node is allowed to use localized routing.  If
      the MN-HNPs or IPv4-MN-HoAs corresponding to both the Mobile Node
      and the Correspondent Node are carried with this bit, it indicates
      that both the MN and CN are allowed to use localized routing.
      Note that localized routing related signaling is required prior to
      localized routing.  If this bit is cleared in the returned MIP6-
      Feature-Vector AVP, the HAAA does not authorize direct routing of
      packets between MNs anchored to the different MAG.  The LMA MUST
      support this policy feature on a per-MN and per-subscription
      basis.

5.  Example Signaling flows

5.1.  Localized Routing Service Authorization

   Localized Routing Service Authorization also can happen during the
   network access authentication procedure [RFC5779], i.e., before
   localized routing is initialized.  In this case, the preauthorized
   pairs of LMA/prefix sets can be downloaded to Proxy Mobile IPv6
   entities during the RFC5779 procedure.  Localized routing can be
   initiated once the destination of a received packet matches one or
   more of the prefixes received during RFC5779 procedure.

   Figure 2 shows an example scenario where MAG1 acts as a Diameter
   client, processing the data packet from MN1 to MN2 and requesting
   authorization of localized routing.  In this example scenario, MN1
   and MN2 are anchored to LMA1 and LMA2 respectively if MN1 and MN2
   belong to different LMAs; otherwise, the LMA to which MN1 and MN2 are
   anchored should be the same LMA, i.e., either LMA1 or LMA2.  In the
   case where MNs belong to different LMAs, in order to setup a
   localized routing path with MAG2, MAG1 must first locate the entity
   that maintains the data required to setup the path (i.e., LMA2) by
   sending a Request message to LMA1.  Note that the discovery of LMA2
   is only done once; the request message is the Localized Routing
   Initialization (LRI) message in Figure 2 and belongs to the Initial
   phase of the localized routing.  Once LMA1 has obtained the address
   of LMA2 from the AAA server, LMA1 may associate the address of LMA2
   with the Mobile Node's cached data for future use (e.g., in case of a

Zorn, et al.             Expires August 25, 2012                [Page 7]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

   handover).  The Diameter client in LMA1 sends an AAR message to the
   Diameter server.  The message contains an instance of the MIP6-
   Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the
   INTER_MAG_ROUTING_SUPPORTED bit (Section 4.4) set and an instance of
   the MIP6-Home-Link-Prefix AVP ([RFC5779], Section 5.3) or an instance
   of the PMIP6-IPv4-Home-Address AVP ([RFC5779], Section 5.2)
   containing the IP address/HNP of MN2.

   The Diameter server authorizes localized routing service by checking
   if MN2 is allowed to use localized routing and if LMA2 and LMA1 are
   in the same provider domain.  If so, the Diameter server responds
   with an AAA message encapsulating an instance of the MIP6-Agent-Info
   AVP [RFC5779] containing the IP address and/or Fully Qualified Domain
   Name (FQDN) of LMA2 and an instance of the MIP6-Feature-Vector (MFV)
   AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED
   bit (Section 4.4) set indicating Direct routing of IP packets between
   MNs anchored to different MAGs is supported.  LMA1 then determines
   the IP address of LMA2 using the data returned in the MIP6-Agent-Info
   AVP and responds to MAG1 with the address of LMA2 in the Localized
   Routing Acknowledge message (LRA in the Figure 2).  If MAG1 knows
   that MN1 and MN2 belong to the same LMA, it requests the address of
   MAG2 from LMA2 and uses that address to setup the localized routing
   path between itself and MAG2 via a Proxy Binding Update (PBU)/Proxy
   Binding Acknowledgement (PBA) message exchange [RFC5213].  Note that
   whether MN1 and MN2 belong to the same LMA can be verified by looking
   up the binding cache entries corresponding to MN1 and MN2 and
   comparing the addresses of LMA1 and LMA2.

   In the case where MNs share the same LMA, the MAG1 should send a
   request message (LRI in the Figure 2) to the LMA for localized
   routing which includes the IP address of MN2.  The subsequent
   interaction between LMA1 and the AAA should be exactly the same as
   the case where the MNs belong to different LMAs.  If authorization is
   successful, the LMA may look up the address of MAG2 directly based on
   IP address of MN2 and send a message to MAG1 with IP address of MAG2
   included.

Zorn, et al.             Expires August 25, 2012                [Page 8]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

   +---+    +----+    +----+     +---+    +----+  +----+   +---+
   |MN1|    |MAG1|    |LMA1|     |AAA|    |LMA2|  |MAG2|   |MN2|
   +-+-+    +-+--+    +-+--+     +-+-+    +-+--+  +-+--+   +-+-+
     |        |         |          |        |       |        |
     |     Anchored     |          |        |    Anchored    |
     o------------------o          |        o-------+--------o
   Data[MN1->MN2]       |          |        |       |        |
     |------->| LRI(MN2)|          |        |       |        |
     |        |-------->|          |        |       |        |
     |        |         |AAR(MFV, MN2)      |       |        |
     |        |         |--------->|        |       |        |
     |        |         |AAA(MFV, LMA2)     |       |        |
     |      LRA([LMA2]) |<---------|        |       |        |
     |        |<--------|          |        |       |        |
     |                  |          |        |       |        |

          Figure 2: MAG-initiated Localized Routing Authorization

   Figure 3 shows another example scenario, in which the LMA1 acts as a
   Diameter client, processing the data packet from MN2 to MN1 and
   requesting the authorization of localized routing.  In this example
   scenario, MN1 and MN2 are anchored to LMA1 and LMA2 respectively.  In
   contrast with the signaling flow of Figure 2, it is LMA1 instead of
   MAG1 which initiates the setup of the localized routing path.

   The Diameter client in LMA1 sends an AA-Request message to the
   Diameter server.  The message contains an instance of the MIP6-
   Feature-Vector AVP ([RFC5447], Section 4.2.5) with the
   INTER_MAG_ROUTING_SUPPORTED bit set and an instance of the MIP6-Home-
   Link-Prefix AVP ([RFC5779], Section 5.3) or an instance of the PMIP6-
   IPv4-Home-Address AVP ([RFC5779], Section 5.2) containing the IP
   address/HNP of MN2.  The Diameter server authorizes localized routing
   service by checking if MN2 is allowed to use localized routing and if
   LMA2 and LMA1 are in the same domain.  If so, the Diameter server
   responds with an AA-Answer message encapsulating an instance of the
   MIP6-Agent-Info AVP [RFC5779] containing the IP address and/or Fully
   Qualified Domain Name (FQDN) of LMA2 and an instance of the MIP6-
   Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the
   INTER_MAG_ROUTING_SUPPORTED bit (Section 4.4) set indicating direct
   routing of IP packets between MNs anchored to different MAGs is
   supported. .  LMA1 then determines the IP address of LMA2 using the
   data returned in the MIP6-Agent-Info AVP and responds to MAG1 with
   the address of LMA2.

   In the case where MNs share the same LMA, the Diameter client in LMA1
   sends an AA-Request message to the Diameter server.  The interaction
   between LMA1 and the Diameter server should be exactly the same as
   the case where MNs belong to different LMAs.  If authorization is

Zorn, et al.             Expires August 25, 2012                [Page 9]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

   successful, the LMA may look up the address of MAG2 directly based on
   the IP address of MN2 and send a request message (LRI in Figure 3) to
   the MAG1 for localized routing with the IP address of MAG2 included.
   The MAG1 confirms the success of localized routing if a localized
   routing path can be setup.

          +---+    +----+  +----+     +---+      +----+  +----+   +---+
          |MN1|    |MAG1|  |LMA1|     |AAA|      |LMA2|  |MAG2|   |MN2|
          +-+-+    +-+--+  +-+--+     +-+-+      +-+--+  +-+--+   +-+-+
            |        |       |          |          |       |        |
            |     Anchored   |          |          |    Anchored    |
            o--------+-------o Data[MN2->MN1]      o-------+--------o
            |        |       |<-----    |          |       |        |
            |        |       |AAR(MFV,MN2)         |       |        |
            |        |       |--------->|          |       |        |
            |          LRI   |AAA(MFV,LMA2)        |       |        |
            |    (MN2,[LMA2])|<---------|          |       |        |
            |        |<------|          |          |       |        |
            |     LRA(Succ)  |          |          |       |        |
            |        |------>|          |          |       |        |

          Figure 3: LMA-initiated Localized Routing Authorization

   Figure 4 shows another example scenario, similar to the example
   scenario illustrated in Figure 3.  In this case, however, LMA1 does
   not respond to MAG1 with the address of LMA2, instead initiating an
   exchange between LMA1 and LMA2 to trigger the corresponding LMA to
   setup binding entries on the corresponding MAG for localized routing
   and configuring MAG1 and MAG2 to use the same encapsulation mechanism
   as that being used for the PMIP tunnel between the MAG and LMA
   without special configuration or dynamic tunneling negotiation
   between MAGs.  Alternatively, special configuration for other
   encapsulation mechanisms or dynamic tunneling negotiation may be used
   to override the default tunneling.

Zorn, et al.             Expires August 25, 2012               [Page 10]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

          +---+    +----+  +----+     +---+      +----+  +----+   +---+
          |MN1|    |MAG1|  |LMA1|     |AAA|      |LMA2|  |MAG2|   |MN2|
          +-+-+    +-+--+  +-+--+     +-+-+      +-+--+  +-+--+   +-+-+
            |        |       |          |          |       |        |
            |     Anchored   |          |          |    Anchored    |
            o--------+-------o Data[MN2->MN1]      o-------+--------o
            |        |       |<-----    |          |       |        |
            |        |       |AAR(MFV,MN2)         |       |        |
            |        |       |--------->|          |       |        |
            |        |       |AAA(MFV,LMA2)        |       |        |
            |        |       |<---------|          |       |        |
            |        |       Localized routing setup       |        |
            |        |       |<------------------->|       |        |

          Figure 4: LMA-initiated Localized Routing Authorization

5.2.  Diameter Server Authorizes MAG Location Query

   Figure 5 shows an example scenario in which LMA2 acts as a Diameter
   client, receiving a MAG location request and requesting authorization
   for a MAG location query from the AAA server.  In this example
   scenario, MN1 and MN2 may be anchored to LMA1 and LMA2 respectively
   or belong to the same LMA.  In the case where MNs belong to different
   LMAs, MAG1 or LMA1 should already know that the recipient of
   localized routing is LMA2.  If MAG1 initiates LR, MAG1 may take
   Option a in Figure 5 and solicit LMA2 to look up the IP address of
   the MAG to which MN2 is currently attached (in this case, MAG2)
   according to the IP addresses/HNPs of MN2.  If LMA1 initiates LR,
   LMA1 may take Option b in Figure 5 and solicit LMA2 to look up the IP
   address of the MAG to which MN2 is currently attached.  LMA2
   validates the request (LRI in Figure 5) from MAG1 by sending an AAR
   to the Diameter server containing the IP address/HNP of MN1
   (encapsulated in an instance of the MIP6-Home-Link-Prefix AVP or an
   instance of PMIP6-IPv4-Home-Address AVP) and an instance of the MIP6-
   Feature- Vector AVP ([RFC5779], Section 5.5) with the
   INTER_MAG_ROUTING_SUPPORTED bit set.  If the authorization is
   successful, the Diameter server responds with an AA-Answer (AAA)
   message encapsulating an instance of the MIP6- Feature-Vector (MFV)
   AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED
   bit (Section 4.4) set indicating Direct routing of IP packets between
   MNs anchored to the different MAG is supported.  LMA2 then looks up
   the IP address of MAG2 based on the IP address/HNP of MN2 and
   responds to MAG1 or LMA1 with the IP address of MAG2.

Zorn, et al.             Expires August 25, 2012               [Page 11]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

        +---+    +----+  +----+     +---+      +----+  +----+   +---+
        |MN1|    |MAG1|  |LMA1|     |AAA|      |LMA2|  |MAG2|   |MN2|
        +-+-+    +-+--+  +-+--+     +-+-+      +-+--+  +-+--+   +-+-+
          |        |       |          |          |       |        |
          |     Anchored   |          |          |    Anchored    |
          o----------------o          |          o-------+--------o
        Data[MN1->MN2]     |          |          |       |        |
          |------->|       |          |          |       |        |
          |        |    Location Query(MN1,MN2 ) |       |        |
          |        |-------+----------+--------->|\      |        |
          |        |       |          |          | |     |        |
          |        |       |         AAR(MFV,MN1)|Option a        |
          |        |       |          |<-------- | |     |        |
          |        |       |        AAA(MFV,LMA1)| |     |        |
          |        |       |          |--------->| |     |        |
          |        |   Location Query Ack(MAG2 ) | |     |        |
          |        |<--------------------------- |/      |        |
          |        |                             |       |        |
          |        |   Location Query(MN1,MN2)   |\      |        |
          |        |       +----------+--------->| |     |        |
          |        |       |         AAR(MFV,MN1)|Option b        |
          |        |       |          |<-------- | |     |        |
          |        |       |        AAA(MFV,LMA1)| |     |        |
          |        |       |          |--------->| |     |        |
          |        |   Location Query Ack(MAG2)  | |     |        |
          |        |       |<------------------- |/      |        |
          |        |       |                             |        |
          |        |      Localized routing setup        |        |
          |        |<------+---------------------------->|        |
          |        |===================================->|        |
          |        |       |          |          |       |------->|
          |        |       |          |          |    Data[MN2->MN1]
          |<------ |<-===================================|<-------|
          |        |       |          |          |       |        |

          Figure 5: Diameter Server Authorizes MAG Location Query

   In the case where MNs share the same LMA, LR should be initiated by
   LMA1 (i.e., LMA2) since only LMA1 knows that both MN1 and MN2 belong
   to itself by looking up the binding cache entries corresponding to
   MN1 and MN2.  Unlike the case where MNs belong to different LMAs, the
   interaction between LMAs in Option b is omitted since LMA1 and LMA2
   are the same entity.  The interaction between LMA1 and the AAA should
   be exactly the same as the case where MNs belong to different LMAs.

Zorn, et al.             Expires August 25, 2012               [Page 12]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

6.  Localized Routing Service Authorization in Networks with Multiple
    AAA Servers

                      +------------------------------------+
                      (                      AAA           )
                      (     +--------+     Backend         )
                      (     |Redirect|                     )
                      (     | Agent  |                     )
                      (     +--------+                     )
                      (         ^                          )
                      (         |                          )
                      (         |                          )
                      (         v                          )
                      (  +---------+          +---------+  )
                   +---->| AAA1 &  |          | AAA2 &  |<---+
                   |  (  | Policy  |<-------->| Policy  |  ) |
                   |  (  | Profile |          | Profile |  ) |
                   |  (  +---------+          +---------+  ) |
                   |  (      ^                     ^       ) |
                   |  +----- | ------------------- |-------+ |
                   |         A1                    A2        |
                   |         |                     |         |
                   |         |                     |         |
                Diameter     v                     v      Diameter
                   B1       +----+  LMA2 ?     +----+        B2
                   |        |LMA1| ------>     |LMA2|        |
                   |        +----+             +----+        |
                   |          |                  |           |
                   |         //                  \\          |
                   |        //                    \\         |
                   |       //                      \\        |
                   |       |                        |        |
                   |     +----+                   +----+     |
                   +---->|MAG1|                   |MAG2|<----+
                         +----+                   +----+
                            :                        :
                         +---+                     +---+
                         |MN1|                     |MN2|
                         +---+                     +---+

      Figure 6: Use of a Diameter Redirect Agent to Support Localized
    Routing Service Authorization in Networks with Multiple AAA servers

   Referring to an architecture with multiple AAA servers (as
   illustrated in Figure 6), AAA1 may not maintain the LMA to be
   assigned to MN2 as a configured entry in the Correspondent Node's
   Policy profile, as AAA2 holds this information in its policy store.
   In such a case, AAA1 contacts a Diameter redirect agent

Zorn, et al.             Expires August 25, 2012               [Page 13]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

   [I-D.ietf-dime-rfc3588bis] to request the AAA server being
   responsible for maintaining MN2's policy profile.  AAA2 checks if MN2
   is allowed to use localized routing and if so, responds with the IP
   address of LMA2 corresponding to MN2 and sends the results back to
   LMA1 via AAA1.  Details about the use of redirect agents in this
   context are beyond scope of this document.

7.  Security Considerations

   The security considerations for the Diameter NASREQ
   [I-D.ietf-dime-rfc4005bis] and Diameter Proxy Mobile IPv6 [RFC5779]
   applications are also applicable to this document.

   The service authorization solicited by the MAG or the LMA relies upon
   the existing trust relationship between the MAG/LMA and the AAA
   server.

   An authorised MAG could in principle track the movement of any
   participating CNs at the level of the MAG to which they are anchored.
   If such a MAG were compromised, or under the control of a bad-actor,
   then such tracking could represent a privacy breach for the set of
   tracked CNs.  In such a case, the traffic pattern from the
   compromised MAG might be notable so monitoring for e.g. excessive
   queries from MAGs might be worthwhile.

8.  IANA Considerations

   This specification defines a new value in the Mobility Capability
   registry [RFC5447] for use with the MIP6-Feature-Vector AVP:
   INTER_MAG_ROUTING_SUPPORTED (see Section 4.4).

9.  Contributors

   Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early
   versions of this document.

10.  Acknowledgements

   The authors would like to thank Carlos Jesus Bernardos Cano, Dan
   Romascanu, Elwyn Davies and Abhay Roy for their valuable comments and
   suggestions on this document.

11.  References

Zorn, et al.             Expires August 25, 2012               [Page 14]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

11.1.  Normative References

   [I-D.ietf-dime-rfc3588bis]
              Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-29
              (work in progress), August 2011.

   [I-D.ietf-dime-rfc4005bis]
              Zorn, G., "Diameter Network Access Server Application",
              draft-ietf-dime-rfc4005bis-07 (work in progress),
              February 2012.

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

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

   [RFC5447]  Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
              and K. Chowdhury, "Diameter Mobile IPv6: Support for
              Network Access Server to Diameter Server Interaction",
              RFC 5447, February 2009.

   [RFC5779]  Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
              and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
              Gateway and Local Mobility Anchor Interaction with
              Diameter Server", RFC 5779, February 2010.

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

11.2.  Informative References

   [RFC6279]  Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6
              (PMIPv6) Localized Routing Problem Statement", RFC 6279,
              June 2011.

Zorn, et al.             Expires August 25, 2012               [Page 15]
Internet-Draft       PMIP6 Localized Routing Support       February 2012

Authors' Addresses

   Glen Zorn
   Network Zen
   227/358 Thanon Sanphawut
   Bang Na, Bangkok  10260
   Thailand

   Phone: +66 (0) 87-040-4617
   Email: glenzorn@gmail.com

   Qin Wu
   Huawei Technologies Co., Ltd.
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  21001
   China

   Phone: +86-25-84565892
   Email: sunseawq@huawei.com

   Marco Liebsch
   NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg,   69115
   Germany

   Email: liebsch@nw.neclab.eu

   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo FI-02600,
   Finland

   Email: jouni.nospam@gmail.com

Zorn, et al.             Expires August 25, 2012               [Page 16]