PCP Working Group T. Reddy
Internet-Draft P. Patil
Intended status: Standards Track R. Chandrasekaran
Expires: February 15, 2014 D. Wing
Cisco
August 14, 2013

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

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 February 15, 2014.

Copyright Notice

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

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


Table of Contents

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

[I-D.ietf-pcp-dhcp] 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.

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

Additionally, this document uses the following abbreviations:

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 PCP proxy functionality [I-D.ietf-pcp-proxy], the home network has a PCP server.

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

The mobile node learns the PCP server IP addresses 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 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.

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.

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.

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.

                                   _----_
                                 _(      )_
              :-----------------( Internet )---------------:
              |                  (_      _)                |
              |                    '----'                  |
              |                                            |
              :                                            |
   (IPv4 Traffic Offload Point)                            |
              :                                            |
              |                                            |
   ........................................................|....
              |                              |             |
   +--------+ |                   +---------------------+  |
   |  Local | |                   | Services requiring  |  |
   |Services| |                   | mobility, or service|  |
   +--------+ |                   | treatment           |  |
        |     |                   +---------------------+  |
        |   +---+                            |             |
        |   |NAT|                            |             |
        |   +---+                            |             |
        +-----|            _----_            |             |
           +-----+       _(      )_       +-----+          |
   [MN]----| MAG |======(    IP    )======| LMA |----------
           +-----+       (_      _)       +-----+  Internet
                           '----'
                              .
                              .
       [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 Server, PCP Proxy.

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

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.

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

Figure 3: PCP Server Option

Type:
<IANA-2>
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.
Reserved (R):
This 16-bit field is unused for now.
PCP Server IP address:
The IP address of the PCP Server to be used by the mobile access gateway.

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

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

          Code  Length   PCP IP address
         +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
         | TBA |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  a3 |  a4 |  ...
         +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

Code:
TBA
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.
PCP Server IP address:
The IP address of the PCP Server to be used by the PCP Client when issuing PCP messages.

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 IP address is determined 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 IP address overriding any other PCP server IP address 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 IP address 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 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.

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 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 [RFC6887] , [I-D.ietf-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 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 and Gang Chen for their 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-01 to -02

Updated Section 1, Section 3, Section4, Section 5, and Section 6.

10.2. Changes from draft-rpcw-pcp-pmipv6-serv-discovery-02 to -03

Updated Section 1, Section 3, Section4, Section 5, and Section 6.

11. References

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G. and R. Koodli, "IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6", RFC 6909, April 2013.
[I-D.ietf-pcp-dhcp] Boucadair, M., Penno, R. and D. Wing, "DHCP Options for the Port Control Protocol (PCP)", Internet-Draft draft-ietf-pcp-dhcp-06, February 2013.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R. and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[I-D.ietf-pcp-proxy] Boucadair, M., Penno, R. and D. Wing, "Port Control Protocol (PCP) Proxy Function", Internet-Draft draft-ietf-pcp-proxy-02, February 2013.
[I-D.penno-pcp-nested-nat] Penno, R., Wing, D. and M. Boucadair, "PCP Support for Nested NAT Environments", Internet-Draft draft-penno-pcp-nested-nat-03, January 2013.

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