<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-rpcw-pcp-pmipv6-serv-discovery-03"
     ipr="trust200902">
  <front>
    <title abbrev="PCP Server Discovery for PMIPv6">PCP Server Discovery with
    IPv4 traffic offload for Proxy Mobile IPv6</title>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Prashanth Patil" initials="P." surname="Patil">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marthalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>praspati@cisco.com</email>
      </address>
    </author>

    <author fullname="Ravikumar Chandrasekaran" initials="R."
            surname="Chandrasekaran">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marthalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>sravikum@cisco.com</email>
      </address>
    </author>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <date />

    <workgroup>PCP Working Group</workgroup>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>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. <xref target="RFC6909"></xref> defines a
      mechanism for Mobile Access Gateway (MAG) and the Local Mobility Anchor
      (LMA) to negotiate Ipv4 traffic offload policy for mobility sessions 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.</t>

      <t><xref target="I-D.ietf-pcp-dhcp"></xref> specifies DHCP (IPv4 and
      IPv6) options to communicate Port Control Protocol (PCP) Server
      addresses to hosts. 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 PCP Proxy for the PCP server in the mobile node's home
      network and as a PCP server/PCP Proxy for the NAT that the offloaded
      traffic at the Local Access Network have to traverse through. 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.</t>
    </section>

    <section anchor="terminology" title="Terminology">
      <t>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 <xref
      target="RFC2119"></xref>.</t>

      <t>All the mobility related terms used in this document are to be
      interpreted as defined in the Proxy Mobile IPv6 specifications <xref
      target="RFC5213"> </xref><xref target="RFC5844"> ,</xref>. This note
      also uses terminology defined in <xref target="RFC6887"></xref>.</t>

      <t>Additionally, this document uses the following abbreviations:</t>

      <t><list style="symbols">
          <t>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.</t>

          <t>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.</t>

          <t>NAT (Network Address Translation) - Network Address Translation
          <xref target="RFC2663"> </xref> is a method by which IP addresses
          are mapped from one address realm to another, providing transparent
          routing to end hosts.</t>

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

          <t>peer-to-peer (P2P) - Applications and protocols, such as
          teleconferencing, multiplayer online gaming, BitTorrent etc</t>

          <t>Internal Address - The address of Mobile Node assigned by the
          home agent.</t>

          <t>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.</t>

          <t>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.</t>
        </list></t>
    </section>

    <section anchor="solution" title="Solution overview">
      <t>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
      PCP proxy functionality <xref target="I-D.ietf-pcp-proxy"></xref>, the
      home network has a PCP server.</t>

      <t>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 IPv4 Traffic Offload Selector option <xref
      target="RFC6909"></xref> mobile access gateway will negotiate IP Flows
      that can be offloaded to the local access network or internet. 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 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.</t>

      <t>The mobile node learns the PCP server IP addresses from DHCPv4 server
      using DHCPv4 option OPTION_PCP_SERVER <xref
      target="I-D.ietf-pcp-dhcp"></xref>. If IP Flows are offloaded at the
      mobile access gateway then the mobile node needs to learn the IP address
      of the mobile access gateway acting as 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 a
      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 hence will relay the request to a PCP server
      based on local configuration.</t>

      <t>If the dynamic outbound mapping is for Internet Offload, then the
      mobile access gateway will function as a PCP server for the mobile node
      if the NAT is co-located on the MAG. If the NAT is not co-located, then
      MAG will act as a proxy and forward the PCP requests to the respective
      PCP server in the Local Access Network.</t>

      <t>NAT may not always be required for traffic offloaded for local
      access. If there is NAT required for traffic offloaded for Local Access,
      then, the dynamic outbound mapping is for the Local Access Network. In
      this case, the Mobile Access Gateway will function as a PCP server if
      NAT device for the Local Access Network is co-located on the MAG,
      otherwise, it will act as a PCP proxy forwarding the PCP requests to the
      respective PCP server on the Local Access Network.</t>

      <t>If dynamic outbound mapping is for the home network then mobile
      access gateway will function as PCP proxy and forward the accepted PCP
      requests to the PCP server in the home network.</t>

      <t><figure anchor="fig_solution_overview"
          title="PCP-Enabled Proxy Mobile IPv6">
          <artwork align="left"><![CDATA[                                   _----_
                                 _(      )_
              :-----------------( Internet )---------------:
              |                  (_      _)                |
              |                    '----'                  |
              |                                            |
              :                                            |
   (IPv4 Traffic Offload Point)                            |
              :                                            |
              |                                            |
   ........................................................|....
              |                              |             |
   +--------+ |                   +---------------------+  |
   |  Local | |                   | Services requiring  |  |
   |Services| |                   | mobility, or service|  |
   +--------+ |                   | treatment           |  |
        |     |                   +---------------------+  |
        |   +---+                            |             |
        |   |NAT|                            |             |
        |   +---+                            |             |
        +-----|            _----_            |             |
           +-----+       _(      )_       +-----+          |
   [MN]----| MAG |======(    IP    )======| LMA |----------
           +-----+       (_      _)       +-----+  Internet
                           '----'
                              .
                              .
       [Access Network]       .        [Home Network]
   ..........................................................   

]]></artwork>
        </figure></t>
    </section>

    <section anchor="mobile_options" title="Mobility Options">
      <t>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 Server, PCP Proxy.</t>

      <t><figure anchor="fig_cap_exch_option"
          title="Capability Exchange Option">
          <artwork align="left"><![CDATA[
       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|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure><list style="hanging">
          <t hangText="Type:">&lt;IANA-1&gt;</t>

          <t hangText="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.</t>

          <t hangText="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.</t>

          <t hangText="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.</t>

          <t hangText="PCP Proxy Mode (P): ">A 1-bit field that specifies PCP
          proxy support mode. The flag value of (1) indicates that mobile
          access gateway is capable of functioning as PCP Proxy to the Mobile
          node.</t>
        </list></t>

      <t>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 the IP address of
      PCP server in the home network to the mobile access gateway. If there
      are more than one IP address associated with a PCP server, all the IP
      addresses will be listed in the option. If there are multiple PCP
      servers, there will be multiple instances of this PCP server option each
      corresponding to a PCP server.</t>

      <t><figure anchor="fig_pcp_server_opt" title="PCP Server Option">
          <artwork align="left"><![CDATA[
       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 IP address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  PCP Server IP address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     ...

]]></artwork>
        </figure></t>

      <t><list style="hanging">
          <t hangText="Type:">&lt;IANA-2&gt;</t>

          <t hangText="Length: ">An 8-bit unsigned integer indicating the
          length of the option in octets, excluding the Type, Length and
          Reserved fields. This should be a multiple of 4.</t>

          <t hangText="Reserved (R):">This 16-bit field is unused for now.</t>

          <t hangText="PCP Server IP address: ">The IP address of the PCP
          Server to be used by the mobile access gateway.</t>
        </list></t>
    </section>

    <section title="DHCPv4 Relay Agent co-located with MAG">
      <t>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 address 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 IP
      address 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 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.</t>

      <t><figure>
          <artwork><![CDATA[    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
    |       |        |    |]]></artwork>
        </figure></t>

      <section title="Format">
        <t>To realize the mechanism described above, the document proposes a
        new PCP Server suboption for the DHCPv4 relay agent information option
        that carries the IP address of PCP Server/Proxy. If a PCP server is
        associated with more than one IP address, all those IP addresses can
        be listed as part of this option. If there is more than one PCP
        server, there will be multiple instances of this option each
        corresponding to a PCP server.</t>

        <t><figure>
            <artwork><![CDATA[          Code  Length   PCP IP address
         +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
         | TBA |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  a3 |  a4 |  ...
         +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+]]></artwork>
          </figure></t>

        <t><list style="hanging">
            <t hangText="Code:">TBA</t>

            <t hangText="Length: ">Includes the length of the "PCP Server IP
            address" field in octets; The maximum length is 255 octets. The
            length should be multiple of 4.</t>

            <t hangText="PCP Server IP address:">The IP address of the PCP
            Server to be used by the PCP Client when issuing PCP messages.</t>
          </list></t>
      </section>

      <section title="Relay Agent behavior">
        <t>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 IP address is determined through
        mechanisms that are outside the scope of this memo.</t>
      </section>

      <section title="DHCPv4 Server behavior">
        <t>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 IP address
        overriding any other PCP server IP address configuration that it may
        already have. There is no special additional processing for this
        suboption.</t>
      </section>
    </section>

    <section title="DHCPv4 Server co-located with MAG">
      <t>When the DHCPv4 Server is co-located with the mobile access gateway,
      the DHCPv4 Server will have to provide the appropriate PCP server IP
      address in the DHCP Offer/Ack based on traffic offload negotiation
      between the mobile access gateway and local mobility anchor.</t>

      <t>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 IP address of the PCP Proxy (MAG) in the
      DHCP Offer/Ack. The mobile access gateway will act as a 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 Flows.</t>

      <t>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 IP address of the home network PCP server in the
      DHCPv4 Offer/Ack. The IP address of the PCP server in the home network
      is obtained from Proxy Binding message exchange explained in <xref
      target="mobile_options"></xref>. Option OPTION_PCP_SERVER will be used
      as described in <xref target="I-D.ietf-pcp-dhcp"></xref>.</t>

      <figure>
        <artwork><![CDATA[    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
    |       |        |    ]]></artwork>
      </figure>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>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 <xref target="RFC5213"></xref> 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 <xref
      target="RFC2663"></xref>. 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.</t>

      <t>The security considerations in <xref target="RFC6887"></xref> , <xref
      target="I-D.ietf-pcp-proxy"></xref> and section 5 of <xref
      target="RFC3046"></xref> also apply to this use.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This specification defines two new Mobility Header options -
      Capability Exchange option, PCP server option. These options are
      described in <xref target="mobile_options"></xref>. The Type value for
      this option needs to be assigned from the same numbering space as
      allocated for the other mobility options <xref
      target="RFC6275"></xref>.</t>

      <t>IANA is requested to assign a suboption number for the PCP Server
      Suboption from the DHCP Relay Agent Information Option <xref
      target="RFC3046"></xref> suboption number space.</t>
    </section>

    <section anchor="Ack" title="Acknowledgements">
      <t>The authors would like to thank Sri Gundavelli and Gang Chen for
      their valuable comments.</t>
    </section>

    <section title="Change History">
      <t>[Note to RFC Editor: Please remove this section prior to
      publication.]</t>

      <section title="Changes from draft-rpcw-pcp-pmipv6-serv-discovery-01 to -02">
        <t>Updated Section 1, Section 3, Section4, Section 5, and Section
        6.</t>
      </section>

      <section title="Changes from draft-rpcw-pcp-pmipv6-serv-discovery-02 to -03">
        <t>Updated Section 1, Section 3, Section4, Section 5, and Section
        6.</t>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.3315"?>

      <!--      <?rfc include="reference.RFC.4862"?> -->

      <?rfc include="reference.RFC.5213"?>

      <?rfc include="reference.RFC.5844"?>

      <?rfc include="reference.RFC.3046"?>

      <?rfc include='reference.RFC.6909'?>

      <?rfc include='reference.I-D.ietf-pcp-dhcp'?>

      <?rfc include='reference.RFC.6887'?>

      <?rfc include='reference.I-D.ietf-pcp-proxy'?>

      <?rfc include='reference.I-D.penno-pcp-nested-nat'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.2663'?>

      <?rfc include="reference.RFC.6275"?>

      <!---->
    </references>
  </back>
</rfc>
