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

Versions: 00 01

NETEXT WG                                                  S. Gundavelli
Internet-Draft                                                M. Grayson
Intended status: Informational                                     Cisco
Expires: August 25, 2012                                          Y. Lee
                                                                 Comcast
                                                                 H. Deng
                                                            China Mobile
                                                               H. Yokota
                                                                KDDI Lab
                                                       February 22, 2012


          Multiple APN Support for Trusted Wireless LAN Access
           draft-gundavelli-netext-multiple-apn-pmipv6-01.txt

Abstract

   This specification defines a mechanism for extending multiple APN/
   home-network support for a mobile node.

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



Gundavelli, et al.       Expires August 25, 2012                [Page 1]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


   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.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  4
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Potential Limitations and Workarounds  . . . . . . . . . .  6
   4.  Operational Details  . . . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12






























Gundavelli, et al.       Expires August 25, 2012                [Page 2]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


1.  Introduction

   Mobile Operators are expanding their network coverage by integrating
   various access technology domains.  Proxy Mobile IPv6 [RFC5213] is
   one of the key protocol interface for integrating these access
   networks and building a common IP mobility architecture.  For
   example, the Trusted non-3GPP Access interface based on Proxy Mobile
   IPv6 [TS23402] interface, 3GPP S2a PMIPv6, specified by the 3GPP
   system architecture, provides the needed protocol glue across
   different access systems.

   The 3GPP system architecture supports the concept of an Access Point
   Name (APN).  An APN can identify a particular routing domain and can
   be used by 3GPP operators to segment user traffic.  APNs are included
   in the session establishment signaling sent by 3GPP User Equipments
   (UEs), identifying which routing domain they want to be connected to.
   Furthermore, 3GPP has defined a system architecture which supports
   the ability of a single UE to have simultaneous connectivity to a
   plurality of APNs, and be allocated multiple IPv4 addresses and/or
   IPv6 prefixes from the network.

   When the S2a protocol interface based on Proxy Mobile IPv6 is used,
   the system architecture is restricted in that the mobile access
   gateway can establish bindings with a single APN/home network at any
   point of time.  There is a limitation with respect to simultaneous,
   multiple APN access.  This limitation is due to the lack of semantics
   for allowing multiple IPv4 address assignment over DHCP to a given
   interface of a mobile node.  In IEEE 802.11-based Wireless LAN
   networks, the mobile node can only be assigned a single IPv4 address
   to the Wireless LAN interface.  This essentially forces the mobile
   access gateway to establish only a single mobility session with any
   one home network/APN and assign a single IPv4 address to the mobile
   node.

   This limitation of single, simultaneous, APN/home-network access from
   WLAN network, at any point of time, is proving to be a major
   hindrance.  Mobile operators have deployed application specific APN's
   for many years and those networks are operational.  For example, APNs
   have been defined to specifically support IP Multimedia Subsystem
   (IMS) based SIP services.  It is critical for the mobile operator to
   ensure access to these APN's/home networks in a consistent way,
   irrespective of the access technology domain to which they are
   connected.  It is in the interest of the operator to enable the
   mobile user to activate multiple applications hosted in different
   APN's and allow access from the WLAN access network.  Therefore,
   there is a need to allow multiple APN access from WLAN access
   network.  The proper approach to solving this problem is to force the
   mobile operator to move away from the model of building application



Gundavelli, et al.       Expires August 25, 2012                [Page 3]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


   specific APN's/home-networks and consolidate them into a single home-
   network.  There is also the other approach of building virtualized
   connection model (PDN Connection) on the Wireless LAN interface and
   make it appear like a 3G interface and enable similar access
   semantics.  However, this has a huge impact on the mobile terminal
   and is not easy to achieve such radical change any time in the
   foreseeable future.

   This document specifies an alternative approach for addressing this
   limitation.  The mobile access gateway by supporting this approach
   can enable access to multiple APN/home networks, simultaneously.  The
   specified approach does not require any changes to the mobile node,
   or to the Proxy Mobile IPv6 protocol interface.  This approach is
   specific to IPv4 sessions.  For IPv6, the mobile access gateway has
   the ability to project multiple IPv6 prefixes obtained from different
   home networks, and carry them in the Router Advertisement messages
   that it sends to the mobile node.  The mobile node can potentially
   use Stateless Auto-configuration approaches for obtaining multiple IP
   addresses for the interface.  This capability in conjunction with
   Prefix Coloring scheme, allows the mobile node to use the source
   address based on the application type, and hence has a solution for
   multiple APN access.  There are clearly better ways to solve this
   problem for IPv6 and with the goal not to create NAT66 requirement,
   this specification therefore limits the scope of this document to
   IPv4-only sessions.


2.  Conventions and Terminology

2.1.  Conventions

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

2.2.  Terminology

   All the mobility related terms used in this document are to be
   interpreted as defined in the base Proxy Mobile IPv6 specifications
   [RFC5213] , [RFC5844], [RFC6459], [RFC5149] and [RFC6089].
   Additionally, this document uses the following abbreviations:

   Access Point Name (APN)








Gundavelli, et al.       Expires August 25, 2012                [Page 4]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


      Its the name of a packet data network.  This APN concept was first
      introduced in GPRS by 3GPP to enable legacy Intelligent Networking
      (IN) approaches to be applied to the newly deployed IP packet data
      services.  In roaming deployments, the APN construct was visible
      to the visited network and allowed legacy IN charging solutions to
      be supported.  Defining an application specific APN then allowed
      application charging to be supported.


3.  Solution Overview

   Figure 2 illustrates the scenario where the mobile access gateway in
   the access network has established PMIPv6 bindings for the attached
   mobile node on multiple local mobility anchors, simultaneously.


                                                   (DEFAULT APN)
                                                   MN-1 BCE: HoA-1
                                       .           +-----+     _----_
                                       .           |     |   _(      )_
                                       .     /-====| LMA |--(  Default )
                                       .    //     |     |   (_ APN-1_)
   Assigned IP                         .   //      +-----+     '----'
   Address: (HoA-1)                    .  //
    .                                  . //        MN-1 BCE: HoA-2
    .   /- All other flows -\ +----+-+ .//         +-----+     _----_
    .  /                     \|    |N| //          |     |   _(      )_
   MN- - - APN-2 flows     - -|MAG |A|--===========| LMA |--(   APN-2  )
       \                     /|    |T| \\          |     |   (_      _)
        \- APN-3 flows     -/ +----+-+ .\\         +-----+     '----'
                                       . \\
                                       .  \\       MN-1 BCE: HoA-3
                                       .   \\      +-----+     _----_
                                       .    \\     |     |   _(      )_
                                       .     \-====| LMA |--(   APN-3  )
                                       .           |     |   (_      _)
                                       .           +-----+     '----'
                                       .
                                       .
      [Trusted WLAN Access Network]    .      [Mobile Packet Core]
    ....................................................................



          Figure 1: Multiple APN Support for Trusted WLAN Access

   The mobile access gateway on detecting a new mobile node on its
   access link establishes bindings with the mobile node's home network



Gundavelli, et al.       Expires August 25, 2012                [Page 5]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


   (default APN).  The obtained IP address from this default APN is
   assigned to the WLAN interface of the mobile node over DHCP.  The
   mobile access gateway also obtains the mobile node's policy profile,
   which identifies all the home networks/APN's to which the mobile node
   belongs.  It also has knowledge on the applications hosted in the
   home network and the associated IP flow selectors.

   The mobile node after obtaining the IPv4 address on the WLAN
   interface, activates all the applications and starts sending IP
   packets using the obtained IPv4 address.  The IP flow selectors
   installed on the mobile access gateway identifies those application
   and initiates the Proxy Mobile IPv6 signaling with the respective
   local mobility anchor.  The mobile access gateway can also choose to
   establish connections to all the APN's allowed for that mobile node
   prior to detecting any application specific flows.  It maintains BUL
   entries for each of the sessions.  However, except for the IPv4
   address and the related configuration from the default APN/home
   network, the mobile node is not delivered any other IPv4 address from
   the other APN's.

   The mobile access gateway installs the NAT translation rules on an
   APN basis.  This essentially allows the mobile node's IP flows using
   the source address assigned by the default-APN/home network to an
   address assigned by the home network to which the application flows
   are associated to.  For example, an RTP/SIP packet from the mobile
   node with the source address from the default APN, will get
   translated to the source address assigned by the LMA in the SIP APN.

   IP packets from the mobile node and from the correspondent node, will
   be translated to use the IP address assigned by the respective APN.
   The translated packets are forwarded through the home network.

3.1.  Potential Limitations and Workarounds

   The approach specified in this document have some known limitations
   and can only be enabled when some assumptions are met.  These
   limitations and the related considerations are specified in this
   section.

   1.  The mobile node is assigned a DNS server from the default-APN and
       all the DNS traffic will be routed to the DNS server in the
       default home-network.  DNS is a global name space and generally
       there should not be any issues with DNS name resolutions for
       services in the other home networks.  However, if a given APN/
       home-network (other than the default home-network) is hosting
       private DNS name space, the DNS resolution requests initiated by
       the mobile node will always end up in the default home-network
       and those resolutions will be incorrect.  There are clearly



Gundavelli, et al.       Expires August 25, 2012                [Page 6]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


       approaches to deal with this problem.

       *  There are two potential approaches to deal with this problem.
          These approaches are outside the scope of this document, but
          few points related to those approaches are presented for
          further study.  In both the cases, the mobile access gateway
          has the assumed capability to recover DNS information
          provisioned for that home network (or obtained using Protocol
          Configuration options related to primary and secondary DNS
          server addresses, when using 3GPP S2a interface).

       *  In one approach, the mobile access gateway can maintain the
          different DNS server configurations for the different home-
          networks, and create a single ordered list of DNS servers and
          provide it to the mobile node as part of the DHCP
          configuration message.  Such an approach assumes that the
          mobile access gateway has chosen to establish connections to
          all the APN's allowed for that mobile node prior to detecting
          any application specific flows.

       *  Alternatively, the mobile access gateway can store the
          recovered DNS server information and only provide its own IP
          address as DNS server to the client.  The MAG is then operable
          to receive DNS requests from clients and to determine to which
          DNS server to proxy the request.  The mobile access gateway
          may use preference information or requested realm to select a
          DNS server.  If the selected DNS server returns an error with
          unknown realm, the mobile access gateway may subsequently
          select an alternative DNS server.

   2.  If the configured APN's/home-networks are hosting a set of
       applications and if those applications have no unique traffic
       selectors that the mobile access gateway can apply and identify
       the IP packets in an unambiguous way, this approach will not
       work.

       *  There is no workaround for this limitation.  In such
          deployments, those APN's/home-networks hosting applications
          with no unique traffic selectors have to be excluded from
          multiple home network support.


4.  Operational Details

   Figure 2 explains the operational sequence of the Proxy Mobile IPv6
   signaling message exchange between the mobile access gateway and the
   local mobility anchor when supporting multiple IPv4 home address
   support.



Gundavelli, et al.       Expires August 25, 2012                [Page 7]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


   MN        MAG        AAA         LMA-1       LMA-2        LMA-3
                              (Default-APN)    (SIP-APN) (Internet-APN)
   |          |          |           |                         |
   | (1) MN Attachment + Access Authentication                 |
   |--------->|          |                                     |
   |          |                      |                         |
   |          | (2) Access Request/Access Accept               |
   |          |<-------->|                                     |
   |          |                                                |
   |          + (3) APN Flow Selector Insertion                |


   |          |                      |                         |
   |          | (4) PBU/PBA (MN-1, Internet-APN, HoA-1)        |
   |          |<-------------------->|                         |
   |          |                      |                         |
   |          | (5) PMIP Tunnel      |                         |
   |          |<====================>|                         |
   |          |                      |                         |
   | (6) DHCPDISCOVER/OFFER/REQUEST/ACK (HoA-1)                |
   |<-------->|                      |                         |
   |                                 |                         |
   | (7) Default IP flow (Source=HoA-1)                        |
   |----------*--=================-->|                         |


   | (8) SIP/RTP flow (Source=HoA-1)                           |
   |--------->|                                                |
   |          | (9) PBU/PBA (MN-1, SIP-APN, HoA-2)             |
   |          |<--------------------------------->|            |
   |          |                                   |            |
   |          |(10) PMIP Tunnel                   |            |
   |          |<=================================>|            |
   |                                                           |
   | (11) SIP/RTP flow (Source=HoA-2 after translation at MAG  |
   |----------*-===============================-->|            |
   |                                                           |
   |                                                           |


   | (12) HTTP Flow (Source=HoA-1)                             |
   |--------->|                                                |
   |          | (13) PBU/PBA (MN-1, Internet-APN, HoA-3)       |
   |          |<---------------------------------------------->|
   |          |                                                |
   |          | (14) PMIP Tunnel                               |
   |          |<==============================================>|
   |                                                           |



Gundavelli, et al.       Expires August 25, 2012                [Page 8]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


   | (15) HTTP Flow (Source=HoA-3 after translation at MAG)    |
   |----------*-=============================================->|


            Figure 2: Exchange of IP Traffic Offload Selectors

   o  Step-1: The mobile node (MN1) attaches to the access link and
      completes the access authentication.  Based on the interworking
      between the access authentication function (such as EAP
      Authenticator, or by virtue of being in the AAA path), the mobile
      access gateway learns the authenticated identity and the link-
      layer address of the mobile node.

   o  Step-2: The mobile access gateway obtains the mobile node's policy
      profile, which includes the list of home networks (APN's/Local
      mobility anchors that that the mobile node is allowed to access).
      It also includes the IP flow selectors for identifying the
      application traffic associated with each of those home networks.

   o  Step-3: The mobile access gateway installs the Policy Based
      Routing rules for detecting the application traffic associated
      with different home networks.  For example, HTTP packets will be
      associated with the home network serving the Internet APN (LMA-3),
      SIP/RTP packets will be associated with the home network serving
      SIP APN (LMA-2), and all other IP flows will be associated with
      the default home APN (LMA-1).  The mobile access gateway can
      complete the Proxy Mobile IPv6 signaling with different home
      networks based on the traffic detect function, or it may complete
      the signaling with all the home networks right after the mobile
      node's attachment to the access link.

   o  Step-4 to Step-7: The mobile access gateway completes the Proxy
      Mobile IPv6 signaling with the local mobility anchor (LMA-1)
      serving the default home APN.  This is as specified in [RFC5213]
      and [RFC5844].  The obtained IPv4 address (HoA-1) is delivered to
      the mobile node over DHCPv4.  This is the only IPv4 address from
      the home network that is assigned to the mobile node.  The mobile
      node uses this IPv4 address as the source address with all of its
      applications when using the attached access technology.  The
      mobile access gateway tunnels all the application traffic, except
      the application traffic associated with the other home networks,
      through the established Proxy Mobile IPv6 tunnel.  These IP flows
      will not be subjected to any NAT translation treatment.

   o  Step-8 to Step-11: The mobile node launches a SIP application and
      initiates the SIP signaling.  The traffic detect function on the
      mobile access gateway identifies this application traffic and
      determines that this application traffic needs to be routed to the



Gundavelli, et al.       Expires August 25, 2012                [Page 9]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


      home network serving the SIP APN.  The mobile access gateway
      completes the needed Proxy Mobile IPv6 signaling with the local
      mobility anchor (LMA-2) and obtains an IPv4 address (HoA-2) for
      the mobile node.  It also inserts a NAT translation rule, which
      essentially identifies the application traffic associated with SIP
      and translates it to use the IP address assigned by that home
      network.  "Application Traffic: SIP/RTP, NAT Internal IPv4
      Address: HoA-1, NAT External IPv4 Address: HoA-2.

   o  Step-12 to Step-15: The mobile node launches a Web browser
      application and opens a URL link.  The traffic detect function on
      the mobile access gateway identifies this HTTP application traffic
      and determines that this application traffic needs to be routed to
      the home network serving the Internet APN.  The mobile access
      gateway completes the needed Proxy Mobile IPv6 signaling with the
      local mobility anchor (LMA-2) and obtains an IPv4 address for the
      mobile node.  It also inserts a NAT translation rule, which
      essentially identifies the application traffic associated with
      HTTP and translates it to use the IP address assigned by that home
      network.  "Application Traffic: Internet, NAT Internal IPv4
      Address: HoA-1, NAT External IPv4 Address: HoA-3.

   o  The IP traffic from the mobile node belonging to different
      applications will now get NAT translated to use the IPv4 address
      assigned by the respective home network and will be routed through
      that network correctly.  However, the application traffic
      belonging to the default home network (APN) does not require any
      NAT translation.  The home network can correctly apply application
      specific charging, or other policy functions on the mobile node's
      IP traffic.


5.  IANA Considerations

   This document does not require any IANA actions.


6.  Security Considerations

   This specification does not define any new protocol extensions and
   therefore does not identify any specific issues on the protocol
   security.

   When multiple APN (home network) support is enabled, per this
   specification, the mobile node's IP flows belonging to different
   applications selectively get NAT translated and it essentially
   introduces certain vulnerabilities which are common to any NAT
   deployment.  These vulnerabilities and the related considerations



Gundavelli, et al.       Expires August 25, 2012               [Page 10]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


   have been well documented in the NAT specification [RFC2663].  There
   are no additional considerations above and beyond what is already
   documented by the NAT specifications and which are unique to the
   approach specified in this document.


7.  Acknowledgements

   The authors would like to first thank 3GPP body for creating the APN
   concept and the associated issues for WLAN access, thus making this
   technical work relevant, without which the document would not have
   existed.

   The authors would also like to thank Ivan Centeno on the importance
   of this use-case and the need to address this issue.  Finally, the
   authors would like to thank Kent Leung, Rajesh Pazhyannur, Eric
   Hamel, Sanjay Kumar and Radhakrishna C, on the reviews related to
   this approach and specifically the discussions related to Split DNS,
   importance of requiring home-networks with non-overlapping
   applications.


8.  References

8.1.  Normative References

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

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

   [RFC6089]  Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
              Network Mobility (NEMO) Basic Support", RFC 6089,
              January 2011.

8.2.  Informative References

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

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



Gundavelli, et al.       Expires August 25, 2012               [Page 11]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


   [RFC6459]  Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
              Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
              Partnership Project (3GPP) Evolved Packet System (EPS)",
              RFC 6459, January 2012.

   [TS23402]  3GPP, "Architecture enhancements for non-3GPP accesses",
              2010.


Authors' Addresses

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com


   Mark Grayson
   Cisco
   11 New Square Park
   Bedfont Lakes, FELTHAM  TW14 8HA
   ENGLAND

   Email: mgrayson@cisco.com


   Yiu L. Lee
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   U.S.A.

   Email: yiu_lee@cable.comcast.com
   URI:   http://www.comcast.com


   Hui Deng
   China Mobile
   53A,Xibianmennei Ave.
   Xuanwu District, Beijing  100053
   China

   Email: denghui02@gmail.com





Gundavelli, et al.       Expires August 25, 2012               [Page 12]

Internet-Draft       Multiple APN Support for PMIPv6       February 2012


   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara
   Saitama, Fujimino  356-8502
   Japan

   Email: yokota@kddilabs.jp












































Gundavelli, et al.       Expires August 25, 2012               [Page 13]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/