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

Versions: (draft-wu-dime-pmip6-lr) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 7156

Network Working Group                                            G. Zorn
Internet-Draft                                               Network Zen
Intended status: Standards Track                                   Q. Wu
Expires: October 28, 2012                                         Huawei
                                                              M. Liebsch
                                                                     NEC
                                                             J. Korhonen
                                                                     NSN
                                                          April 26, 2012


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

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, the usage of localized routing may be authorized for
   both MAGs.  This document specifies how to accomplish this 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."

   This Internet-Draft will expire on October 28, 2012.

Copyright Notice

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



Zorn, et al.            Expires October 28, 2012                [Page 1]

Internet-Draft       PMIP6 Localized Routing Support          April 2012


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Attribute Value Pair Definitions . . . . . . . . . . . . . . .  5
     4.1.  MIP6-Agent-Info AVP  . . . . . . . . . . . . . . . . . . .  5
     4.2.  PMIP6-IPv4-Home-Address AVP  . . . . . . . . . . . . . . .  5
     4.3.  MIP6-Home-Link-Prefix AVP  . . . . . . . . . . . . . . . .  5
     4.4.  MIP6-Feature-Vector AVP  . . . . . . . . . . . . . . . . .  5
   5.  Example Signaling Flows for Localized Routing Service
       Authorization  . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10




















Zorn, et al.            Expires October 28, 2012                [Page 2]

Internet-Draft       PMIP6 Localized Routing Support          April 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 the same Mobile Access Gateway, 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.  [RFC6279] defines the problem statement for PMIPv6
   localized routing.  [I-D.ietf-netext-pmip-lr] describes a solution
   for PMIPv6 localized routing based on the scenarios defined in
   [RFC6279].  In these scenarios the 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 MAG or LMA to discover
   the address of the Correspondent Node's LMA during the setup of
   localized routing; in addition, authorization from AAA for enabling
   localized routing is unspecified.

   This document describes Diameter [I-D.ietf-dime-rfc3588bis] support
   for the authorization and discovery of PMIPv6 mobility entities
   during localized routing.


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


3.  Solution Overview

   This document addresses how to resolve the destination MN's MAG by
   means of interaction between the LMA and the AAA server.  Figure 1



Zorn, et al.            Expires October 28, 2012                [Page 3]

Internet-Draft       PMIP6 Localized Routing Support          April 2012


   shows the reference architecture for Localized Routing Service
   Authorization.  This reference architecture assumes that

   o  MN1 and MN2 belong to the same LMA or different LMAs.  If MN1 and
      MN2 belong to the same LMA, 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    +---------+
                                |
                                |
                                |
                                |
                       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 following
   feature:

   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




Zorn, et al.            Expires October 28, 2012                [Page 4]

Internet-Draft       PMIP6 Localized Routing Support          April 2012


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


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.

   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



Zorn, et al.            Expires October 28, 2012                [Page 5]

Internet-Draft       PMIP6 Localized Routing Support          April 2012


      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 for Localized Routing Service Authorization

   Localized Routing Service Authorization 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 RFC 5779 procedure.  Localized routing can be initiated
   once the destination of a received packet matches one or more of the
   prefixes received during the RFC 5779 procedure.

   Figure 2 shows an example scenario in which 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 the same LMA.  In this case, 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., the
   LMA corresponding to MN2 or LMA2) by sending a Request message to
   LMA1.  The request message is the Localized Routing Initialization
   (LRI) message in Figure 2 and belongs to the Initial phase of the
   localized routing.  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.  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 LMA corresponding to MN2 (i.e., 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
   LMA corresponding to MN2 using the data returned in the MIP6-Agent-



Zorn, et al.            Expires October 28, 2012                [Page 6]

Internet-Draft       PMIP6 Localized Routing Support          April 2012


   Info AVP and responds to MAG1 with the address of LMA corresponding
   to MN2 in the Localized Routing Acknowledge message (LRA in
   Figure 2).  If MAG1 knows that MN1 and MN2 belong to the same LMA, it
   requests the address of MAG2 from the same LMA as MN1 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].  If MAG1 knows that MN2 belongs to a
   different LMA (which can be determined by looking up the binding
   cache entries corresponding to MN1 and MN2 and comparing the
   addresses of LMA1 and LMA2), MAG1 SHOULD request the address of MAG2
   from LMA2; the subsequent localized routing path setup is similar to
   the case where the MNs share LMAs.

   Note: This case is mentioned in RFC 6279 but not covered by
   [I-D.ietf-netext-pmip-lr]; it is used here as an illustration of the
   capabilities provided by the AAA infrastructure, possibly for future
   use.


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

          Figure 2: MAG-initiated Localized Routing Authorization

   Figure 3 shows another example scenario, in which LMA1 acts as a
   Diameter client, processing the data packet from MN2 to MN1 and
   requesting the authorization of localized routing.  In this scenario,
   MN1 and MN2 are anchored to the same LMA.  In contrast with the
   signaling flow shown in 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 either an instance of the



Zorn, et al.            Expires October 28, 2012                [Page 7]

Internet-Draft       PMIP6 Localized Routing Support          April 2012


   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 the
   localized routing service by checking if MN2 is allowed to use
   localized routing.  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 LMA corresponding to MN2 (i.e.,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 LMA
   corresponding to MN2 using the data returned in the MIP6-Agent-Info
   AVP and responds to MAG1 with the address of LMA corresponding to
   MN2.  If LMA1 knows that MN1 and MN2 share the same LMA, then 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 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.  If LMA1 knows that MN2 belongs to a different LMA
   (e.g., LMA2), LMA1 SHOULD initiate an exchange with LMA2 to trigger
   the corresponding LMA to setup binding entries on the corresponding
   MAG for localized routing and configure 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.

   Note: The latter case is mentioned in RFC 6279 but not addressed by
   [I-D.ietf-netext-pmip-lr] and used here as an illustration of the
   capabilities provided by the AAA infrastructure.


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

          Figure 3: LMA-initiated Localized Routing Authorization



Zorn, et al.            Expires October 28, 2012                [Page 8]

Internet-Draft       PMIP6 Localized Routing Support          April 2012


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


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


8.  Contributors

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


9.  Acknowledgements

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


10.  References

10.1.  Normative References

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



Zorn, et al.            Expires October 28, 2012                [Page 9]

Internet-Draft       PMIP6 Localized Routing Support          April 2012


   [I-D.ietf-dime-rfc4005bis]
              Zorn, G., "Diameter Network Access Server Application",
              draft-ietf-dime-rfc4005bis-08 (work in progress),
              April 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.

10.2.  Informative References

   [I-D.ietf-netext-pmip-lr]
              Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
              Dutta, "Localized Routing for Proxy Mobile IPv6",
              draft-ietf-netext-pmip-lr-08 (work in progress),
              January 2012.

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


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




Zorn, et al.            Expires October 28, 2012               [Page 10]

Internet-Draft       PMIP6 Localized Routing Support          April 2012


   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 October 28, 2012               [Page 11]


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