One document matched: draft-rpcw-pcp-pmipv6-serv-discovery-00.xml
<?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-00"
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="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.</t>
<t><xref target="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.</t>
<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"/>.</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="I-D.ietf-pcp-base"/>.</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
smart PCP proxy functionality <xref target="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.</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 IP Traffic Offload Selector option <xref
target="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
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 domain name from DHCPv4 server
using DHCPv4 option OPTION_PCP_SERVER <xref
target="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.</t>
<t>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<xref target="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.</t>
<t>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.</t>
<t><figure anchor="fig_solution_overview"
title="PCP-Enabled Proxy Mobile IPv6">
<artwork align="left"><![CDATA[ _----_
_( )_
( 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]
......................................................
]]></artwork>
</figure></t>
<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 Sever, smart 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:"><IANA-1></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 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.</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 PCP server domain
name of the home network to the mobile access gateway.</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 Domain Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list style="hanging">
<t hangText="Type:"><IANA-2></t>
<t hangText="Length: ">An 8-bit unsigned integer indicating the
length of the option in octets, excluding the Type and Length
fields.</t>
<t hangText="Reserved (R):">This 16-bit field is unused for now.</t>
<t hangText="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 <xref target="RFC3315"/>.</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 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.</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 domain name of PCP Server/Proxy.</t>
<t/>
<t><figure>
<artwork><![CDATA[ Code Length PCP Server Domain Name
+-----+-----+-----+-----+-----+-----+-----+--
| TBA | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+--
]]></artwork>
</figure></t>
<t><list style="hanging">
<t hangText="Code:">TBA</t>
<t hangText="Length: ">Includes the length of the "PCP Server
Domain Name" field in octets; The maximum length is 255
octets.</t>
<t hangText="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 <xref
target="RFC3315"/>.</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 Domain name is assigned and configured
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 domain name
overriding any other PCP server domain name 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 domain
name 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 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.</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 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 <xref
target="mobile_options"/>. Option OPTION_PCP_SERVER will be used as
described in <xref target="I-D.ietf-pcp-dhcp"/>.</t>
<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"/> 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"/>. 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="I-D.ietf-pcp-base"/> ,
<xref target="I-D.bpw-pcp-proxy"/> and section 5 of <xref
target="RFC3046"/> 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"/>. 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"/>.</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"/> suboption number space.</t>
</section>
<section anchor="Ack" title="Acknowledgements">
<t>The authors would like to thank Sri Gundavelli for his valuable
comments.</t>
</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.I-D.ietf-netext-pmipv6-sipto-option'?>
<?rfc include='reference.I-D.ietf-pcp-dhcp'?>
<?rfc include='reference.I-D.ietf-pcp-base'?>
<?rfc include='reference.I-D.bpw-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>
| PAFTECH AB 2003-2026 | 2026-04-24 05:44:29 |