Skip to main content

PCP Server Discovery with IPv4 traffic offload for Proxy Mobile IPv6
draft-rpcw-pcp-pmipv6-serv-discovery-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Tirumaleswar Reddy.K , Prashanth Patil , Ravikumar Chandrasekaran, Dan Wing
Last updated 2012-08-31
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-rpcw-pcp-pmipv6-serv-discovery-01
PCP Working Group                                               T. Reddy
Internet-Draft                                                  P. Patil
Intended status: Standards Track                       R. Chandrasekaran
Expires: March 4, 2013                                           D. Wing
                                                                   Cisco
                                                         August 31, 2012

  PCP Server Discovery with IPv4 traffic offload for Proxy Mobile IPv6
                draft-rpcw-pcp-pmipv6-serv-discovery-01

Abstract

   This document proposes a solution to PCP Server Discovery problems in
   Proxy Mobile IPv6 (PMIPv6) networks when both home network traffic
   and traffic off-loaded to local access network require traversing a
   gateway implementing NAT and/or Firewall.  This draft proposes
   enhancements to DHCPv4 Relay Agent by introducing a new sub-option
   under DHCPv4 Relay Option and to PMIPv6 signaling through additional
   options to Proxy Binding Update/Acknowledgement messages.

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 March 4, 2013.

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

Reddy, et al.             Expires March 4, 2013                 [Page 1]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

   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  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Mobility Options . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  DHCPv4 Relay Agent co-located with MAG . . . . . . . . . . . .  8
     5.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Relay Agent behavior . . . . . . . . . . . . . . . . . . .  9
     5.3.  DHCPv4 Server behavior . . . . . . . . . . . . . . . . . .  9
   6.  DHCPv4 Server co-located with MAG  . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Changes from draft-rpcw-pcp-pmipv6-serv-discovery-00
           to -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

Reddy, et al.             Expires March 4, 2013                 [Page 2]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

1.  Introduction

   Given the exponential growth in the mobile data traffic, Mobile
   Operators are looking for ways to offload some of the IP traffic
   flows at the nearest access edge that has an Internet peering point.
   This approach results in efficient usage of the mobile packet core
   and helps lower the transport cost.
   [I-D.ietf-netext-pmipv6-sipto-option] defines a way to signal the
   Traffic Offload capability of a Mobile Access Gateway (MAG) to the
   Local Mobility Anchor (LMA) in Proxy Mobile IP Networks.  There are
   scenarios in PMIPv6 Mobile Networks where the traffic going through
   the Mobile Packet Core as well as the traffic that is off-loaded to
   the Local Access Networks end up going through a NAT or Firewall
   gateway.  If the mobile node applications desire to find or control
   the external addresses assigned to the internal address used by the
   Mobile Node (MN), it could be achieved by having a Port Control
   Protocol (PCP) Client on the mobile node.

   [I-D.ietf-pcp-dhcp] specifies DHCP (IPv4 and IPv6) options to
   configure hosts with Port Control Protocol (PCP) Server addresses.
   However, PCP Client on the mobile node will not know whether a flow
   will traverse the Mobile Packet Core or will get offloaded at the
   local access network and hence will not know which PCP server to send
   its queries to.  Even if the mobile node tries to find its PCP server
   using DHCP, it may only find out about the PCP server in the Home
   Network since the source of information is the DHCP server in the
   Home Network.  The mobile node may never learn the presence of the
   PCP server in the Local Access Network.  This requires mobile access
   gateway to act as a smart PCP Proxy for the PCP servers in both the
   mobile node's home network as well as in the Local Access Network.
   However, this alone does not solve this problem since the mobile node
   needs to be informed of the PCP proxy on the MAG.  This draft
   proposes an extension to DHCPv4 Relay Information Option and PMIPv6
   Options to achieve these objectives.

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

   All the mobility related terms used in this document are to be
   interpreted as defined in the Proxy Mobile IPv6 specifications
   [RFC5213], [RFC5844].  This note also uses terminology defined in
   [I-D.ietf-pcp-base].

   Additionally, this document uses the following abbreviations:

Reddy, et al.             Expires March 4, 2013                 [Page 3]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

   o  IP Flow - IP Flow represents a set of IP packets that match a
      traffic selector.  The selector is typically based on the source
      IP address, destination IP address, source port, destination port
      and other fields in upper layer headers.

   o  IP Traffic Offload - The approach of selecting specific IP flows
      and routing them to the local network, as supposed to tunneling
      them to the home network.

   o  NAT (Network Address Translation) - Network Address Translation
      [RFC2663] is a method by which IP addresses are mapped from one
      address realm to another, providing transparent routing to end
      hosts.

   o  Firewall (FW) - A packet filtering device that matches packets
      against a set of policy rules and applies the actions.

   o  peer-to-peer (P2P) - Applications and protocols, such as
      teleconferencing, multiplayer online gaming, BitTorrent etc

   o  Internal Address - The address of Mobile Node assigned by the home
      agent.

   o  Remote Peer IP Address - The address of a Remote Peer, as seen by
      the Mobile Node.  A Remote Address is generally a publicly
      routable address.

   o  External Address - The address of the Mobile Node as seen by other
      Remote Peers on the Internet with which the Mobile Node is
      communicating, after translation by any NAT gateways on the path.

3.  Solution overview

   The following illustrates a scenario where the Mobile Node is a PCP
   client, Mobile Access Gateway in the access network is a PCP server
   with smart PCP proxy functionality [I-D.bpw-pcp-proxy], Local
   Mobility Anchor in the home network has a PCP server and PCP proxy
   functionality.  The assumption made for this specification is Mobile
   Access Gateway is always co-located with NAT.

   Mobile access gateway has the ability to offload some of the IPv4
   traffic flows based on the traffic selectors it receives from the
   local mobility anchor.  Using IP Traffic Offload Selector option
   [I-D.ietf-netext-pmipv6-sipto-option] mobile access gateway will
   negotiate IP Flows that can be offloaded to the local access network.
   For example, consider a mobile node acting as both client and server
   for FTP, VoIP and P2P. In this case FTP flows for that mobility

Reddy, et al.             Expires March 4, 2013                 [Page 4]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

   session may be offloaded at the mobile access gateway and P2P, Voice
   over IP (VoIP) flows tunneled back to the local mobility anchor.
   Mobile node uses PCP to create mappings between external IP address/
   port and internal IP address/port.  These mappings will be used for
   successful inbound communication destined to the mobile node behind
   NAT and/or firewall.

   The mobile node learns the PCP server domain name from DHCPv4 server
   using DHCPv4 option OPTION_PCP_SERVER [I-D.ietf-pcp-dhcp].  If IP
   Flows are offloaded at the mobile access gateway then the mobile node
   needs to learn the domain name of the mobile access gateway acting as
   smart PCP proxy.  Mobile access gateway will compare the Remote Peer
   IP Address and Port fields set in PCP PEER request from the mobile
   node with the Traffic Selector fields and IP Traffic Offload Mode
   Flag in IP Traffic Offload Selector Option to determine if the
   dynamic outbound mapping is to be created in the local access network
   or home network.  In case of PCP MAP request mobile access gateway
   will compare the Remote Peer IP Address and Port fields in FILTER
   Option with the Traffic Selector fields and IP Traffic Offload Mode
   Flag in IP Traffic Offload Selector Option to determine if dynamic
   outbound mapping is to be created in the local access network or home
   network.  For PCP MAP request without FILTER option since the Remote
   Peer IP Address is not available the mobile access gateway will
   function as smart PCP proxy and forward the PCP MAP request to the
   PCP server in the home network.  Mobile Nodes which require
   communication with well known peers (For e.g. applications like SIP
   proxy, FTP server) will use PCP MAP with FILTER option.  When MNs act
   as servers (such as P2P server, Web Server) i.e., when the remote
   peer IP address is not known, PCP client will use PCP MAP request in
   which case the MAG cannot make a decision as per the traffic selector
   fields and will hence relay to either PCP server based on local
   configuration.

   If the dynamic outbound mapping is for the local access network then
   there are two cases to consider - In the first case where there is a
   nested NAT[I-D.penno-pcp-nested-nat], the mobile access gateway will
   function as both PCP server and PCP proxy forwarding the accepted PCP
   request to CGN PCP server.  In the second case, where there is no
   CGN, mobile access gateway will function as a PCP server in the local
   access network.

   If dynamic outbound mapping is for the home network then mobile
   access gateway will function as smart PCP proxy and forward the
   accepted PCP request to the PCP server in the home network.

Reddy, et al.             Expires March 4, 2013                 [Page 5]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

             _----_
           _(      )_
          ( Internet )
           (_      _)
             '----'
               |
    (IPv4 Traffic Offload Point
     Ex: FTP Traffic Offloaded)
             |
 ......................................................
   +--------+ |
   |  Local |-|                   +----------------------+
   |Services| |                   | Services requiring   |
   +--------+ |                   | mobility, or service |
              |                   | treatment            |
              |                   +----------------------+
       +------------+                   |
       | NAT/FW     |                   |
       |  with      |                   |
       | PCP server |                   |
       +------------+                   |
             |          _----_          |
          +-----+     _(      )_      +-----+   +------------+
  [MN]----| MAG |=====(   IP    )=====| LMA |---| NAT/FW     |--Internet
          +-----+      (_     _)      +-----+   |  with      |
                        (    )                  | PCP Server |
                        '----'                  +------------+
                           .
                           .
                           .
        [Access Network]   .        [Home Network]
  ......................................................

                  Figure 1: PCP-Enabled Proxy Mobile IPv6

4.  Mobility Options

   A new mobility option, Capability Exchange Option is defined for use
   with Proxy Binding Update sent by the mobile access gateway to the
   local mobility anchor.  The option is used for conveying device
   capabilities such as PCP Sever, smart PCP Proxy.

Reddy, et al.             Expires March 4, 2013                 [Page 6]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |   Length      |    Reserved (R)           |S|P|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: Capability Exchange Option

   Type:  <IANA-1>

   Length:   An 8-bit unsigned integer indicating the length of the
      option in octets, excluding the Type and Length fields.  This
      field MUST be set to 2.

   Reserved (R):  This 14-bit field is unused for now.  The value MUST
      be initialized to (0) by the sender and MUST be ignored by the
      receiver.

   PCP Server Support Mode (S):   A 1-bit field that specifies the PCP
      server support mode.  The flag value of (1) indicates that mobile
      access gateway is capable of functioning as PCP Server to the
      Mobile node.

   PCP Proxy Support Mode (P):   A 1-bit field that specifies the smart
      PCP proxy support mode.  The flag value of (1) indicates that
      mobile access gateway is capable of functioning as smart PCP Proxy
      to the Mobile node.

   A new mobility option, PCP Server Option is defined for use with
   Proxy Binding Acknowledgement sent by the local mobility anchor to
   the mobile access gateway .  The option is used to provide PCP server
   domain name of the home network to the mobile access gateway.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |   Length      |         Reserved (R)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  PCP Server Domain Name                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 3: PCP Server Option

Reddy, et al.             Expires March 4, 2013                 [Page 7]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

   Type:  <IANA-2>

   Length:   An 8-bit unsigned integer indicating the length of the
      option in octets, excluding the Type and Length fields.

   Reserved (R):  This 16-bit field is unused for now.

   PCP Server Domain Name:   The domain name of the PCP Server to be
      used by the mobile access gateway.  The domain name is encoded as
      specified in Section 8 of [RFC3315].

5.  DHCPv4 Relay Agent co-located with MAG

   When DHCPv4 Relay Agent is co-located with the mobile access gateway,
   the proposal is for the relay agent to influence the DHCPv4 Server to
   opt for the PCP server domain name proposed by the Relay Agent over
   the one configured on the DHCPv4 Server.  The DHCPv4 Relay Agent will
   insert a a new suboption under relay agent information option
   indicating the domain name of the appropriate PCP server/proxy only
   after successful Tunnel/Route setup.  For this to happen, the MN MUST
   ensure that it includes OPTION_PCP_SERVER in the Parameter Request
   List Option in the DHCPv4 Discover/Request message.  The mobile
   access gateway will also have to act as a smart PCP-Proxy in this
   case so that it can handle PCP Servers of both the local access
   network and the home network.  This will ensure that the right PCP
   Server is picked by the proxy based on IP Flow.

    MN  MAG(DHCP-R) LMA DHCP-S
    |------>|        |    |     1. Mobile Node Attach
    |       |------->|    |     2. Proxy Binding Update
    |       |<-------|    |     3. Proxy Binding Acknowledgement
    |       |        |    |        (IPTS Option)
    |       |========|    |     4. Tunnel/Route Setup
    |       +        |    |     5. Installing the traffic offload rules
    |<----->|<----------->|     6. DHCP OFFER/REQUEST/ACK exchange
    |       |        |    |        OPTION_PCP_SERVER inserted by DHCP-R
    |------>|        |    |     7. IPv4 packet from mobile node
    |       +        |    |     8. Forwarding rule - Tunnel home/offload
    |       |        |    |

5.1.  Format

   To realize the mechanism described above, the document proposes a new
   PCP Server suboption for the DHCPv4 relay agent information option
   that carries the domain name of PCP Server/Proxy.

Reddy, et al.             Expires March 4, 2013                 [Page 8]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

             Code  Length   PCP Server Domain Name
            +-----+-----+-----+-----+-----+-----+-----+--
            | TBA |  n  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
            +-----+-----+-----+-----+-----+-----+-----+--

   Code:  TBA

   Length:   Includes the length of the "PCP Server Domain Name" field
      in octets; The maximum length is 255 octets.

   PCP Server Domain Name:  The domain name of the PCP Server to be used
      by the PCP Client when issuing PCP messages.  The domain name is
      encoded as specified in Section 8 of [RFC3315].

5.2.  Relay Agent behavior

   DHCPv4 relay agents MAY be configured to include a PCP Server
   suboption if they include a relay agent information option in relayed
   DHCPv4 messages.  The PCP Server Domain name is assigned and
   configured through mechanisms that are outside the scope of this
   memo.

5.3.  DHCPv4 Server behavior

   This suboption provides additional information to the DHCP server.
   Upon receiving a DHCPv4 Discover/Request containing the suboption,
   the DHCPv4 server, if configured to support this suboption, MUST
   populate the DHCPv4 Offer/Ack with the suggested PCP server domain
   name overriding any other PCP server domain name configuration that
   it may already have.  There is no special additional processing for
   this suboption.

6.  DHCPv4 Server co-located with MAG

   When the DHCPv4 Server is co-located with the mobile access gateway,
   the DHCPv4 Server will have to provide the appropriate PCP server
   domain name in the DHCP Offer/Ack based on traffic offload
   negotiation between the mobile access gateway and local mobility
   anchor.

   If traffic offload is successfully negotiated between the mobile
   access gateway and the local mobility anchor, the proposal is for the
   DHCPv4 Server to include the domain name of the PCP Proxy in the DHCP
   Offer/Ack. The mobile access gateway will act as a smart PCP-Proxy in
   this case to ensure that it can handle PCP Servers of both the local
   access network and the home network.  This will ensure that the right
   PCP Server is picked by the proxy based on IP Flow.

Reddy, et al.             Expires March 4, 2013                 [Page 9]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

   If traffic offload is not negotiated between the mobile access
   gateway and the local mobility anchor, the proposal is for the DHCPv4
   Server to include the domain name of the home network PCP server in
   the DHCPv4 Offer/Ack. The domain name of the PCP server in the home
   network is obtained from Proxy Binding message exchange explained in
   Section 4.  Option OPTION_PCP_SERVER will be used as described in
   [I-D.ietf-pcp-dhcp].
       MN  MAG(DHCP-S) LMA
       |------>|        |   1. Mobile Node Attach
       |       |------->|   2. Proxy Binding Update
       |       |<-------|   3. Proxy Binding Acknowledgement
       |       |        |      (IPTS Option)
       |       |========|   4. Tunnel/Route Setup
       |       +        |   5. Installing the traffic offload rules
       |<----->|        |   6. DHCP OFFER/REQUEST/ACK exchange
       |       |        |      OPTION_PCP_SERVER inserted by DHCP-S
       |------>|        |   7. IPv4 packet from mobile node
       |       +        |   8. Forwarding rule - Tunnel home/offload
       |       |        |

7.  Security Considerations

   The Capability Exchange option defined in this specification is for
   use in Proxy Binding Update messages.  The PCP server option defined
   in this specification is for the Proxy Binding Acknowledgement
   messages.  These options are carried like any other mobility header
   option as specified in [RFC5213] and does not require any special
   security considerations.  When IPv4 traffic offload support is
   enabled for a mobile node, the mobile access gateway selectively
   offloads some of the mobile node's traffic flows to the local access
   network.  Typically, these offloaded flows go through a NAT gateway
   and that essentially introduces certain vulnerabilities which are
   common to any NAT deployment.  These vulnerabilities and the related
   considerations 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.

   The security considerations in [I-D.ietf-pcp-base] ,
   [I-D.bpw-pcp-proxy] and section 5 of [RFC3046] also apply to this
   use.

8.  IANA Considerations

   This specification defines two new Mobility Header options -
   Capability Exchange option, PCP server option.  These options are

Reddy, et al.             Expires March 4, 2013                [Page 10]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

   described in Section 4.  The Type value for this option needs to be
   assigned from the same numbering space as allocated for the other
   mobility options [RFC6275].

   IANA is requested to assign a suboption number for the PCP Server
   Suboption from the DHCP Relay Agent Information Option [RFC3046]
   suboption number space.

9.  Acknowledgements

   The authors would like to thank Sri Gundavelli for his valuable
   comments.

10.  Change History

   [Note to RFC Editor: Please remove this section prior to
   publication.]

10.1.  Changes from draft-rpcw-pcp-pmipv6-serv-discovery-00 to -01

   Updated Section 3

11.  References

11.1.  Normative References

   [I-D.bpw-pcp-proxy]
              Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Port
              Control Protocol (PCP) Proxy Function",
              draft-bpw-pcp-proxy-02 (work in progress), September 2011.

   [I-D.ietf-netext-pmipv6-sipto-option]
              Gundavelli, S., Zhou, X., Korhonen, J., and R. Koodli,
              "IPv4 Traffic Offload Selector Option for Proxy Mobile
              IPv6", draft-ietf-netext-pmipv6-sipto-option-05 (work in
              progress), August 2012.

   [I-D.ietf-pcp-base]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-26 (work in progress), June 2012.

   [I-D.ietf-pcp-dhcp]
              Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
              the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-04

Reddy, et al.             Expires March 4, 2013                [Page 11]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

              (work in progress), August 2012.

   [I-D.penno-pcp-nested-nat]
              Penno, R., Wing, D., Selkirk, P., and M. Boucadair, "PCP
              Support for Nested NAT Environments",
              draft-penno-pcp-nested-nat-02 (work in progress),
              July 2012.

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

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

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

11.2.  Informative References

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

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

Authors' Addresses

   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com

Reddy, et al.             Expires March 4, 2013                [Page 12]
Internet-Draft       PCP Server Discovery for PMIPv6         August 2012

   Prashanth Patil
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marthalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: praspati@cisco.com

   Ravikumar Chandrasekaran
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marthalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: sravikum@cisco.com

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: dwing@cisco.com

Reddy, et al.             Expires March 4, 2013                [Page 13]