One document matched: draft-boucadair-intarea-host-identifier-scenarios-05.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="yes"?>
<rfc category="info"
docName="draft-boucadair-intarea-host-identifier-scenarios-05"
ipr="trust200902">
<front>
<title abbrev="Host ID Use Cases">Host Identification: Use Cases</title>
<author fullname="Mohamed Boucadair" initials="M." role="editor"
surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="David Binet" initials="D." surname="Binet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>david.binet@orange.com</email>
</address>
</author>
<author fullname="Sophie Durel" initials="S." surname="Durel">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<country>France</country>
</postal>
<email>sophie.durel@orange.com</email>
</address>
</author>
<author fullname="Bruno Chatras" initials="B." surname="Chatras">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Paris</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<phone></phone>
<email>bruno.chatras@orange.com</email>
</address>
</author>
<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="Brandon Williams" initials="B." surname="Williams">
<organization>Akamai, Inc.</organization>
<address>
<postal>
<street></street>
<city>Cambridge</city>
<region></region>
<code>MA</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>brandon.williams@akamai.com</email>
<uri></uri>
</address>
</author>
<author fullname="Behcet Sarikaya" initials="B.S." surname="Sarikaya">
<organization>Huawei</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 3,</street>
<city>Plano</city>
<region>TX</region>
<code>75024</code>
<country>USA</country>
</postal>
<email>behcet.sarikaya@huawei.com</email>
</address>
</author>
<author fullname="Li Xue" initials="L." surname="Xue">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<email>xueli@huawei.com</email>
</address>
</author>
<date year="2014" />
<abstract>
<t>This document describes a set of scenarios in which host
identification is problematic. The document does not include any
solution-specific discussion. </t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The goal of this document is to enumerate use cases which encounter
the issue of uniquely identifying a host among those sharing the same IP
address. Examples of encountered issues in those use cases are:<?rfc subcompact="yes" ?><list
style="symbols">
<t>Blacklist a misbehaving host without impacting all hosts sharing
the same IP address.</t>
<t>Enforce a per-subscriber/per-UE policy (e.g., limit access to the
service based on some counters such as volume-based service
offering); enforcing the policy will have impact on all hosts
sharing the same IP address.</t>
<t>If invoking a service has failed (e.g., wrong login/password),
all hosts sharing the same IP address may not be able to access that
service.</t>
<t>Need to correlate between the internal address:port and external
address:port to generate and therefore to enforce policies.</t>
<t>Query a location server for the location of an emergency caller
based on the source IP address.<?rfc subcompact="no" ?></t>
</list></t>
<t>It is out of scope of this document to list all the encountered
issues as this is already covered in <xref target="RFC6269"></xref>.</t>
<t>The following use cases are identified:<?rfc subcompact="yes" ?><list
style="format (%d)">
<t>Carrier Grade NAT (CGN) (<xref target="CGN"></xref>)</t>
<t>A+P (e.g., MAP ) (<xref target="aplusp"></xref>)</t>
<t>Application Proxies (<xref target="aproxy"></xref>)</t>
<t>Provider Wi-Fi (<xref target="providerwifi"></xref>)</t>
<t>Policy and Charging Architectures (<xref
target="pcc"></xref>)</t>
<t>Cellular Networks (<xref target="mobile"></xref>)</t>
<t>Femtocells (<xref target="FMC"></xref>)</t>
<t>Overlay Networks (e.g., CDNs) (<xref target="cdn"></xref>)</t>
<t>Emergency Calls (<xref target="psap"></xref>)</t>
<t>Traffic Detection Function (<xref target="tdf"></xref>)</t>
<t>Fixed and Mobile Network Convergence (<xref target="fmc"></xref>)
<?rfc subcompact="no" ?></t>
</list>The analysis of the use cases listed in this document indicates
several root causes for the host identification issue:<?rfc subcompact="yes" ?><list
style="numbers">
<t>Presence of address sharing (NAT, A+P, application proxies,
etc.).</t>
<t>Use of tunnels between two administrative domains.</t>
<t>Combination of address sharing and presence of tunnels in the
path.<?rfc subcompact="no" ?></t>
</list></t>
</section>
<section title="Scope">
<t>It is out of scope of this document to argue in favor or against the
use cases listed in the following sections. The goal is to identify
scenarios the authors are aware of and which share the same issue of
host identification.</t>
<t>This document does not include any solution-specific discussion. This
document can be used as a tool to design solution(s) mitigating the
encountered issues. Describing the use case allows to identify what is
common between the use cases and then would help during the solution
design phase.</t>
<t>The document does not elaborate whether explicit authentication is
enabled or not.</t>
</section>
<section anchor="CGN" title="Use Case 1: CGN">
<t>Several flavors of stateful CGN have been defined. A non-exhaustive
list is provided below:<list style="numbers">
<t>NAT44 (<xref target="RFC6888"></xref>, <xref
target="I-D.tsou-stateless-nat44"></xref>)</t>
<t>DS-Lite NAT44 <xref target="RFC6333"></xref></t>
<t>NAT64 <xref target="RFC6146"></xref></t>
<t>NPTv6 <xref target="RFC6296"></xref></t>
</list></t>
<t>As discussed in <xref target="RFC6967"></xref>, remote servers are
not able to distinguish between hosts sharing the same IP address (<xref
target="cgn"></xref>). <figure align="center" anchor="cgn"
title="CGN Reference Architecture">
<artwork><![CDATA[+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--| CGN |----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
]]></artwork>
</figure></t>
<t>Some of the above referenced CGN use cases will be satisfied by
eventual completion of the transition to IPv6 across the Internet (e.g.,
NAT64), but this is not true of all CGN use cases (e.g. NPTv6 <xref
target="RFC6296"></xref>) for which some of the issues discussed in
<xref target="RFC6269"></xref> will be encountered (e.g., impact on
geolocation <xref target="RFC6269"></xref>). Note, it is not the intent
of this document to advocate in favor or against NPTv6, but to highlight
the complications that may raise when enabling such function.</t>
</section>
<section anchor="aplusp" title="Use Case 2: A+P">
<t>A+P <xref target="RFC6346"></xref><xref
target="I-D.ietf-softwire-map"></xref><xref
target="I-D.ietf-softwire-lw4over6"></xref> denotes a flavor of address
sharing solutions which does not require any additional NAT function be
enabled in the service provider's network. A+P assumes subscribers are
assigned with the same IPv4 address together with a port set.
Subscribers assigned with the same IPv4 address should be assigned non
overlapping port sets. Devices connected to an A+P-enabled network
should be able to restrict the IPv4 source port to be within a
configured range of ports. To forward incoming packets to the
appropriate host, a dedicated entity called PRR (Port Range Router,
<xref target="RFC6346"></xref>) is needed (<xref
target="ap"></xref>).</t>
<t>Similar to the CGN case, the same issue to identify hosts sharing the
same IP address is encountered by remote servers.</t>
<t><figure align="center" anchor="ap" title="A+P Reference Architecture">
<artwork><![CDATA[+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--| PRR |----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="aproxy" title="Use Case 3: Application Proxies">
<t>This scenario is similar to the CGN scenario. Remote servers are not
able to distinguish hosts located behind the PROXY. Applying policies on
the perceived external IP address as received from the PROXY will impact
all hosts connected to that PROXY.</t>
<t><xref target="proxy"></xref> illustrates a simple configuration
involving a proxy. Note several (per-application) proxies may be
deployed.</t>
<t><figure align="left" anchor="proxy"
title="Proxy Reference Architecture">
<artwork><![CDATA[+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--|PROXY|----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
]]></artwork>
</figure></t>
<t>In the application proxy scenario, packets/connections must be
received by the proxy regardless of the IP address family in use. The
requirements of this use case are not satisfied by eventual completion
of the transition to IPv6 across the Internet.</t>
</section>
<section anchor="providerwifi"
title="Use Case 4: Open Wi-Fi or Provider Wi-Fi">
<t>In the context of Provider Wi-Fi (WLAN), a dedicated SSID can be
configured and advertised by the RG (Residential Gateway) for visiting
terminals. These visiting terminals can be mobile terminals, PCs,
etc.</t>
<t>Several deployment scenarios are envisaged:<list style="numbers">
<t>Deploy a dedicated node in the service provider's network which
will be responsible to intercept all the traffic issued from
visiting terminals (see <xref target="ueid"></xref>). This node may
be co-located with a CGN function if private IPv4 addresses are
assigned to visiting terminals. Similar to the CGN case discussed in
<xref target="CGN"></xref>, remote servers may not be able to
distinguish visiting hosts sharing the same IP address (see <xref
target="RFC6269"></xref>).</t>
<t>Unlike the previous deployment scenario, IPv4 addresses are
managed by the RG without requiring any additional NAT to be
deployed in the service provider's network for handling traffic
issued from visiting terminals. Concretely, a visiting terminal is
assigned with a private IPv4 address from the IPv4 address pool
managed by the RG. Packets issued form a visiting terminal are
translated using the public IP address assigned to the RG (see <xref
target="ueid2"></xref>). This deployment scenario induces the
following identification concerns:<list style="symbols">
<t>The provider is not able to distinguish the traffic belonging
to the visiting terminal from the traffic of the subscriber
owning the RG. This is needed to apply some policies such as:
accounting, DSCP remarking, black list, etc.</t>
<t>Similar to the CGN case <xref target="CGN"></xref>, a
misbehaving visiting terminal is likely to have some impact on
the experienced service by the subscriber owning the RG (e.g.,
some of the issues are discussed in <xref
target="RFC6269"></xref>).</t>
</list></t>
</list></t>
<t><figure align="center" anchor="ueid"
title="NAT enforced in a Service Provider's Node">
<artwork><![CDATA[+-------------+
|Local_HOST_1 |----+
+-------------+ |
| |
+-------------+ +-----+ | +-----------+
|Local_HOST_2 |--| RG |-|--|Border Node|
+-------------+ +-----+ | +----NAT----+
| |
+-------------+ | | Service Provider
|Visiting Host|-----+
+-------------+
]]></artwork>
</figure></t>
<t><figure align="center" anchor="ueid2" title="NAT located in the RG">
<artwork><![CDATA[+-------------+
|Local_HOST_1 |----+
+-------------+ |
| |
+-------------+ +-----+ | +-----------+
|Local_HOST_2 |--| RG |-|--|Border Node|
+-------------+ +-NAT-+ | +-----------+
| |
+-------------+ | | Service Provider
|Visiting Host|-----+
+-------------+
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="pcc"
title="Use Case 5: Policy and Charging Control Architecture">
<t>This issue is related to the framework defined in <xref
target="TS23.203"></xref> when a NAT is located between the PCEF (Policy
and Charging Enforcement Function) and the AF (Application Function) as
shown in <xref target="policy"></xref>.</t>
<t>The main issue is: PCEF, PCRF and AF all receive information bound to
the same UE( User Equipment) but without being able to correlate between
the piece of data visible for each entity. Concretely,<list
style="symbols">
<t>PCEF is aware of the IMSI (International Mobile Subscriber
Identity) and an internal IP address assigned to the UE.</t>
<t>AF receives an external IP address and port as assigned by the
NAT function.</t>
<t>PCRF is not able to correlate between the external IP
address/port assigned by the NAT (received from the AF) and the
internal IP address and IMSI of the UE (received from the PCEF).</t>
</list><figure align="center" anchor="policy"
title="NAT located between AF and PCEF">
<artwork><![CDATA[ +------+
| PCRF |-----------------+
+------+ |
| |
+----+ +------+ +-----+ +-----+
| UE |------| PCEF |---| NAT |----| AF |
+----+ +------+ +-----+ +-----+
]]></artwork>
</figure></t>
<t>This scenario can be generalized as follows (<xref
target="PEP"></xref>):</t>
<t><list style="symbols">
<t>Policy Enforcement Point (PEP, <xref
target="RFC2753"></xref>)</t>
<t>Policy Decision Point (PDP, <xref target="RFC2753"></xref>)</t>
</list></t>
<t><figure align="center" anchor="PEP"
title="NAT located between PEP and Server">
<artwork><![CDATA[ +------+
| PDP |-----------------+
+------+ |
| |
+----+ +------+ +-----+ +------+
| UE |------| PEP |---| NAT |----|Server|
+----+ +------+ +-----+ +------+
]]></artwork>
</figure></t>
<t>Note that an issue is encountered to enforce per-UE policies when the
NAT is located before the PEP function (see <xref
target="natpep"></xref>):</t>
<t><figure align="center" anchor="natpep" title="NAT located before PEP">
<artwork><![CDATA[ +------+
| PDP |------+
+------+ |
| |
+----+ +------+ +-----+ +------+
| UE |------| NAT |---| PEP |----|Server|
+----+ +------+ +-----+ +------+
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="mobile" title="Use Case 6: Cellular Networks">
<t>Cellular operators allocate private IPv4 addresses to mobile
terminals and deploy NAT44 function, generally co-located with
firewalls, to access to public IP services. The NAT function is located
at the boundaries of the PLMN (Public Land Mobile Network). IPv6-only
strategy, consisting in allocating IPv6 prefixes only to mobile
terminals, is considered by various operators. A NAT64 function is also
considered in order to preserve IPv4 service continuity for these
customers.</t>
<t>These NAT44 and NAT64 functions bring some issues very similar to
those mentioned in <xref target="cgn"></xref> and <xref
target="pcc"></xref>. This issue is particularly encountered if policies
are to be applied on the Gi interface: a private IP address is assigned
to the mobile terminals, there is no correlation between the internal IP
address and the external address:port assigned by the NAT function,
etc.</t>
</section>
<section anchor="FMC" title="Use Case 7: Femtocells">
<t>This use case can be seen as a combination of the use cases described
in <xref target="providerwifi"></xref> and <xref
target="pcc"></xref>.</t>
<t>The reference architecture is shown in Figure 8.</t>
<t><figure align="center" anchor="Femtocell"
title="Femtocell Reference Architecture">
<artwork><![CDATA[+---------------------------+
| +----+ +--------+ +----+ | +-----------+ +-------------------+
| | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ |
| +----+ | alone | | RG | | | | | | | | | Mobile |
| | FAP | +----+ | | | | |S | |F | Network|
| +--------+ (NAPT) | | Broadband | | |e | |A | |
+---------------------------+ | Fixed | | |G |-|P | +-----+|
| Network | | |W | |G |-| Core||
+---------------------------+ | (BBF) | | | | |W | | Ntwk||
| +----+ +------------+ | | | | | | | | +-----+|
| | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ |
| +----+ | FAP (NAPT) | | +-----------+ +-------------------+
| +------------+ |
+---------------------------+
<=====> IPsec tunnel
CoreNtwk Core Network
FAPGW FAP Gateway
SeGW Security Gateway
]]></artwork>
</figure></t>
<t>UE is connected to the FAP at the residential gateway (RG), routed
back to 3GPP Evolved Packet Core (EPC). UE is assigned IPv4 address by
the Mobile Network. Mobile operator's FAP leverages the IPsec IKEv2 to
interconnect FAP with the SeGW over the BBF network. Both the FAP and
the SeGW are managed by the mobile operator which may be a different
operator for the BBF network.</t>
<t>An investigated scenario is the mobile operator to pass on its mobile
subscriber's policies to the BBF to support traffic policy control . But
most of today's broadband fixed networks are relying on the private IPv4
addressing plan (+NAPT) to support its attached devices including the
mobile operator's FAP. In this scenario, the mobile network needs
to:</t>
<t><list style="symbols">
<t>determine the FAP's public IPv4 address to identify the location
of the FAP to ensure its legitimacy to operate on the license
spectrum for a given mobile operator prior to the FAP be ready to
serve its mobile devices.</t>
<t>determine the FAP's pubic IPv4 address together with the
translated port number of the UDP header of the encapsulated IPsec
tunnel for identifying the UE's traffic at the fixed broadband
network.</t>
<t>determine the corresponding FAP's public IPv4 address associated
with the UE's inner-IPv4 address which is assigned by the mobile
network to identify the mobile UE to allow the PCRF to retrieve the
special UE's policy (e.g., QoS) to be passed onto the Broadband
Policy Control Function (BPCF) at the BBF network.</t>
</list></t>
<t>SeGW would have the complete knowledge of such mapping, but the
reasons for unable to use SeGW for this purpose is explained in "Problem
Statements" (section 2 of <xref
target="I-D.so-ipsecme-ikev2-cpext"></xref>).</t>
<t>This use case involves PCRF/BPCF but it is valid in other deployment
scenarios making use of AAA servers.</t>
<t>The issue of correlating the internal IP address and the public IP
address is valid even if there is no NAT in the path.</t>
</section>
<section anchor="cdn" title="Use Case 8: Overlay Network">
<t>An overlay network is a network of machines distributed throughout
multiple autonomous systems within the public Internet that can be used
to improve the performance of data transport (see <xref
target="overlay_fig"></xref>). IP packets from the sender are delivered
first to one of the machines that make up the overlay network. That
machine then relays the IP packets to the receiver via one or more
machines in the overlay network, applying various performance
enhancement methods.</t>
<t><figure align="center" anchor="overlay_fig"
title="Overlay Network Reference Architecture">
<artwork><![CDATA[
+------------------------------------+
| |
| INTERNET |
| |
+-----------+ | +------------+ |
| HOST_1 |-----| OVRLY_IN_1 |-----------+ |
+-----------+ | +------------+ | |
| | |
+-----------+ | +------------+ +-----------+ | +--------+
| HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER |
+-----------+ | +------------+ +-----------+ | +--------+
| | |
+-----------+ | +------------+ | |
| HOST_3 |-----| OVRLY_IN_3 |-----------+ |
+-----------+ | +------------+ |
| |
+------------------------------------+]]></artwork>
</figure></t>
<t>Such overlay networks are used to improve the performance of content
delivery <xref target="IEEE1344002"></xref>. Overlay networks are also
used for peer-to-peer data transport <xref target="RFC5694"></xref>, and
they have been suggested for use in both improved scalability for the
Internet routing infrastructure <xref target="RFC6179"></xref> and
provisioning of security services (intrusion detection, anti-virus
software, etc.) over the public Internet <xref
target="IEEE101109"></xref>.</t>
<t>In order for an overlay network to intercept packets and/or
connections transparently via base Internet connectivity infrastructure,
the overlay ingress and egress hosts (OVERLAY_IN and OVERLAY_OUT) must
be reliably in-path in both directions between the connection-initiating
HOST and the SERVER. When this is not the case, packets may be routed
around the overlay and sent directly to the receiving host.</t>
<t>For public overlay networks, where the ingress and/or egress hosts
are on the public Internet, packet interception commonly uses network
address translation for the source (SNAT) or destination (DNAT)
addresses in such a way that the public IP addresses of the true
endpoint hosts involved in the data transport are invisible to each
other (see <xref target="overlay_ex"></xref>). For example, the actual
sender and receiver may use two completely different pairs of source and
destination addresses to identify the connection on the sending and
receiving networks in cases where both the ingress and egress hosts are
on the public Internet.</t>
<t><figure align="center" anchor="overlay_ex"
title="NAT operations in an Overlay Network">
<artwork><![CDATA[
ip hdr contains: ip hdr contains:
SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER
dst = overlay1 dst = receiver
]]></artwork>
</figure></t>
<t>In this scenario, the remote server is not able to distinguish among
hosts using the overlay for transport. In addition, the remote server is
not able to determine the overlay ingress point being used by the host,
which can be useful for diagnosing host connectivity issues.</t>
<t>In some of the above referenced use cases, IP packets traverse the
overlay network fundamentally unchanged, with the overlay network
functioning much like a CGN (<xref target="CGN"></xref>). In other
cases, connection-oriented data flows (e.g. TCP) are terminated by the
overlay in order to perform object caching and other such transport and
application layer optimizations, similar to the proxy scenario (<xref
target="aproxy"></xref>). In both cases, address sharing is a
requirement for packet/connection interception, which means that the
requirements for this use case are not satisfied by the eventual
completion of the transition to IPv6 across the Internet.</t>
<t>More details about this use case are provided in <xref
target="I-D.williams-overlaypath-ip-tcp-rfc"></xref>.</t>
</section>
<section anchor="psap" title="Use Case 9: Emergency Calls">
<t>Voice service providers (VSPs) operating under certain jurisdictions
are required to route emergency calls from their subscribers and have to
include information about the caller's location in signaling messages
they send towards PSAPs (Public Safety Answering Points, <xref
target="RFC6443"></xref>), via an Emergency Service Routing Proxy (ESRP,
<xref target="RFC6443"></xref>). This information is used both for the
determination of the correct PSAP and to reveal the caller's location to
the selected PSAP.</t>
<t>In many countries, regulation bodies require that this information be
provided by the network rather than the user equipment, in which case
the VSP needs to retrieve this information (by reference or by value)
from the access network where the caller is attached.</t>
<t>This requires the VSP call server receiving an emergency call request
to identify the relevant access network and to query a Location
Information Server (LIS) in this network using a suitable look-up key.
In the simplest case, the source IP address of the IP packet carrying
the call request is used both for identifying the access network (thanks
to a reverse DNS query) and as a look-up key to query the LIS. Obviously
the user-id as known by the VSP (e.g., telephone number, or
email-formatted URI) can't be used as it is not known by the access
network.</t>
<t>The above mechanism is broken when there is a NAT between the user
and the VSP and/or if the emergency call is established over a VPN
tunnel (e.g., an employee remotely connected to a company VoIP server
through a tunnel wishes to make an emergency call). In such cases, the
source IP address received by the VSP call server will identity the NAT
or the address assigned to the caller equipment by the VSP (i.e., the
address inside the tunnel). This is similar to the CGN case (<xref
target="CGN"></xref>) and overlay network case (<xref
target="cdn"></xref>) and applies irrespective of the IP versions used
on both sides of the NAT and/or inside and outside the tunnel.</t>
<t>Therefore, the VSP needs to receive an additional piece of
information that can be used to both identify the access network where
the caller is attached and query the LIS for his/her location. This
would require the NAT or the Tunnel Endpoint to insert this extra
information in the call requests delivered to the VSP call servers. For
example, this extra information could be a combination of the local IP
address assigned by the access network to the caller's equipment with
some form of identification of this access network.</t>
<t>However, because it shall be possible to setup an emergency call
regardless of the actual call control protocol used between the user and
the VSP (e.g., SIP <xref target="RFC3261"></xref>, IAX <xref
target="RFC5456"></xref>, tunneled over HTTP, or proprietary protocol,
possibly encrypted), this extra information has to be conveyed outside
the call request, in the header of lower layers protocols.</t>
</section>
<section anchor="tdf" title="Use Case 10: Traffic Detection Function">
<t>Operators expect that the traffic subject to the packet inspection is
routed via the Traffic Detection Function (TDF) function as requirement
specified in <xref target="TS29.212"></xref>, otherwise, the traffic may
bypass the TDF. This assumption only holds if it is possible to identify
individual UEs behind NA(P)T which may be deployed into the RG in fixed
broadband network, shown in <xref target="tdf-pic"></xref>. As a result,
additional mechanisms are needed to enable this requirement.</t>
<t><figure align="center" anchor="tdf-pic"
title="UE's Traffic Routed with TDF">
<artwork><![CDATA[
+--------+
| |
+-------+ PCRF |
| | |
| +--------+
+--------+ +--------+ +--------+ +----+----+
| | | | | +-----+ |
| ------------------------------------------------------------------
| | | | | | | TDF | / \
| ******************************************************************
| | | +-------+ | | | Service
| | | | | | | \ /
| | | | | | | +--------+
| | | | | | +--------+ PDN |
| ********---------**********--------************------------******* |
| UE | | RG | | BNG +------------------+ Gateway|
+--------+ +--------+ +--------+ +--------+
Legends:
--------- 3GPP UE User Plane Traffic Offloaded subject to packet
inspection
********* 3GPP UE User Plane Traffic Offloaded not subject to packet
inspection
*****---- 3GPP UE User Plane Traffic Home Routed
]]></artwork>
</figure></t>
</section>
<section anchor="fmc"
title="Use Case 11: Fixed and Mobile Network Convergence">
<t>In the Policy for Convergence of Fixed Mobile Convergence (FMC)
scenario, the fixed broadband network must partner with the mobile
network to acquire the policies for the terminals or hosts attaching to
the fixed broadband network, shown in <xref target="fmc-pic"></xref> so
that host-specific QoS and accounting policies can be applied.</t>
<t>A UE is connected to the RG, routed back to the mobile network. The
mobile operator's PCRF needs to maintain the interconnect with the
Broadband Policy Control Function (BPCF) in the BBF network for PCC
(<xref target="pcc"></xref>). The hosts (i.e., UEs) attaching to fixed
broadband network with a NA(P)T deployed should be identified. Based on
the UE identification, the BPCF to deploy policy rules in the fixed
broadband network can acquire the associated policy rules of the
identified UE from the PCRF in the mobile network. But in the fixed
broadband network, private IPv4 address is supported. The similar
requirements are raised in this use case as <xref target="FMC"></xref>.
</t>
<t><figure align="center" anchor="fmc-pic"
title="Reference Architecture for Policy for Convergence in Fixed and Mobile Network Convergence (1)">
<artwork><![CDATA[ +------------------------------+ +-------------+
| | | |
| +------+ | | +------+ |
| | BPCF +---+---+-+ PCRF | |
| +--+---+ | | +---+--+ |
+-------+ | | | | | |
|HOST_1 |Private IP1 +--+---+ | | +---+--+ |
+-------+ | +----+ | | | | | | |
| | RG | | | | | | | |
| |with+-------------+ BNG +--------+ PGW | |
+-------+ | | NAT| | | | | | | |
|HOST_2 | | +----+ | | | | | | |
+-------+Private IP2 +------+ | | +------+ |
| | | |
| | | |
| Fixed | | Mobile |
| Broadband | | Network |
| Network | | |
| | | |
+------------------------------+ +-------------+
]]></artwork>
</figure></t>
<t>In IPv6 network, the similar issues exists when the IPv6 prefix is
sharing between multiple UEs attaching to the RG (see <xref
target="fmc-pic2"></xref>). The case applies when RG is assigned a
single prefix, the home network prefix, e.g. using DHCPv6 Prefix
Delegation <xref target="RFC3633"></xref> with the edge router, BNG
acting as the Delegating Router (DR). RG uses the home network prefix in
the address configuration using stateful (DHCPv6) or stateless address
assignment (SLAAC) techniques.</t>
<t><figure align="center" anchor="fmc-pic2"
title="Reference Architecture for Policy for Convergence in Fixed and Mobile Network Convergence (2)">
<artwork><![CDATA[
+------------------------------+ +-------------+
| | | |
| | | +------+ |
| +-------------+ PCRF | |
| | | | +---+--+ |
+-------+ | | | | | |
|HOST_1 |--+ +--+---+ | | +---+--+ |
+-------+ | +----+ | | | | | | |
| | RG | | | | | | | |
| | +------------+ BNG +---------+ PGW | |
+-------+ | | | | | | | | | |
|HOST_2 |--+ +----+ | | | | | | |
+-------+ | +------+ | | +------+ |
| | | |
| | | |
| Fixed | | Mobile |
| Broadband | | Network |
| Network | | |
| | | |
+------------------------------+ +-------------+
]]></artwork>
</figure></t>
<t>BNG acting as PCEF initiates an IP Connectivity Access Network
(IP-CAN) session with the policy server, a.k.a. Policy and Charging
Rules Function (PCRF), to receive the Quality of Service (QoS)
parameters and Charging rules. BNG provides to the PCRF the IPv6 Prefix
assigned to the host, in this case the home network prefix and an ID
which in this case has to be equal to the RG specific home network line
ID.</t>
<t>HOST_1 in <xref target="fmc-pic2"></xref> creates an 128-bit IPv6
address using this prefix and adding its interface id. Having completed
the address configuration, the host can start communication with a
remote hosts over Internet. However, no specific IP-CAN session can be
assigned to HOST_1, and consequently the QoS and accounting performed
will be based on RG subscription.</t>
<t>Another host, e.g. HOST_2, attaches to RG and also establishes an
IPv6 address using the home network prefix. Edge router, the BNG, is not
involved with this and all other such address assignments.</t>
<t>This leads to the case where no specific IP-CAN session/sub-session
can be assigned to the hosts, HOST_1, HOST_2, etc., and consequently the
QoS and accounting performed can only be based on RG subscription and
not host specific. Therefore IPv6 prefix sharing in Policy for
Convergence scenario leads to similar issues as the address sharing as
it has been explained in the previous use cases in this document.</t>
</section>
<section title="Synthesis">
<t>The following table shows whether each use case is valid for
IPv4/IPv6 and if it is within one single administrative domain or span
multiple domains.</t>
<t><figure>
<artwork><![CDATA[
+-------------------+------+-------------+-----------------------+
| Use Case | IPv4 | IPv6 | Single Administrative |
| | |------+------| Domain |
| | |Client|Server| |
+-------------------+------+------+------+-----------------------+
| CGN | Yes |Yes(1)| No | No |
| A+P | Yes | No | No | No |
| Application Proxy | Yes |Yes(2)|Yes(2)| No |
| Provider Wi-Fi | Yes | No | No | Yes |
| PCC | Yes |Yes(1)| No | Yes |
| Femtocells | Yes | No | No | No |
| Cellular Networks | Yes |Yes(1)| No | Yes |
| Overlay Networks | Yes |Yes(3)|Yes(3)| No |
| Emergency Calls | Yes | Yes |Yes | No |
| TDF | Yes | Yes | No | Yes |
| FMC | Yes |Yes(1)| No | No |
+-------------------+------+------+------------------------------+
Notes:
(1) e.g., NAT64
(2) A proxy can use IPv6 for the communication leg with the server
or the application client.
(3) This use case is a combination of CGN and Application Proxies.]]></artwork>
</figure></t>
<t></t>
</section>
<section title="Privacy Considerations">
<t>Privacy-related considerations that apply to means to reveal a host
identified are discussed in <xref target="RFC6967"></xref>. This
document does not introduce additional privacy issues than those
discussed in <xref target="RFC6967"></xref>.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>This document does not define an architecture nor a protocol; as such
it does not raise any security concern. Host identifier related security
considerations are discussed in <xref target="RFC6967"></xref>.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section title="Acknowledgments">
<t>Many thanks to F. Klamm, D. Wing, and D. von Hugo for their
review.</t>
<t>Figure 8 and part of the text in <xref target="FMC"></xref> are
inspired from <xref target="I-D.so-ipsecme-ikev2-cpext"></xref>.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.6346'?>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.RFC.2753'?>
<?rfc include='reference.RFC.6296'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.3633'?>
<?rfc include='reference.RFC.5456'?>
<?rfc include='reference.RFC.6443'?>
<?rfc include='reference.RFC.6179'?>
<?rfc include='reference.RFC.5694'?>
<?rfc include='reference.RFC.6888'?>
<?rfc include='reference.I-D.ietf-softwire-map'?>
<?rfc include='reference.I-D.ietf-softwire-lw4over6'?>
<?rfc include='reference.RFC.6967'?>
<?rfc include='reference.I-D.so-ipsecme-ikev2-cpext'?>
<?rfc include='reference.I-D.williams-overlaypath-ip-tcp-rfc'?>
<?rfc include='reference.I-D.tsou-stateless-nat44'?>
<?rfc include='reference.RFC.6333'?>
<reference anchor="TS23.203" target="">
<front>
<title>Policy and charging control architecture</title>
<author fullname="3GPP" surname="3GPP">
<organization>UPnP Forum</organization>
</author>
<date day="0" month="September" year="2012" />
</front>
</reference>
<reference anchor="TS29.212">
<front>
<title>Policy and Charging Control (PCC); Reference Points</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date month="December" year="2013" />
</front>
</reference>
<reference anchor="IEEE1344002">
<front>
<title abbrev="Informed content delivery">Informed content delivery
across adaptive overlay networks: IEEE/ACM Transactions on
Networking, Vol 12, Issue 5, ppg 767-780</title>
<author fullname="John Byers" initials="J.W." surname="Byers">
<organization abbrev="Boston University">Boston University, Dept.
of Computer Science</organization>
</author>
<author fullname="Jeffrey Considine" initials="J."
surname="Considine">
<organization abbrev="Boston University">Boston University, Dept.
of Computer Science</organization>
</author>
<author fullname="Michael Mitzenmacher" initials="M."
surname="Mitzenmacher">
<organization abbrev="Harvard University">Harvard University,
EECS</organization>
</author>
<author fullname="Stanislav Rost" initials="S." surname="Rost">
<organization abbrev="MIT">MIT Laboratory for Computer
Science</organization>
</author>
<date month="October" year="2004" />
</front>
</reference>
<reference anchor="IEEE101109">
<front>
<title abbrev="Security Overlay Network">Using Cloud Computing to
Implement a Security Overlay Network, IEEE Security & Privacy,
21 June 2012. IEEE Computer Society Digital Library.</title>
<author fullname="Khaled Salah" initials="K." surname="Salah">
<organization abbrev="Khalifa University">Khalifa University of
Science Technology and Research</organization>
</author>
<author fullname="Jose Maria Alcaraz Calero" initials="J.M.A."
surname="Calero">
<organization abbrev="Universidad de Murcia">Universidad de
Murcia</organization>
</author>
<author fullname="Sherali Zeadally" initials="S." surname="Zeadally">
<organization
abbrev="University of the District of Columbia">University of the
District of Columbia</organization>
</author>
<author fullname="Sameera Almulla" initials="S." surname="Almulla">
<organization abbrev="Khalifa University">Khalifa University of
Science Technology and Research</organization>
</author>
<author fullname="Mohammed ZAaabi" initials="M." surname="ZAaabi">
<organization abbrev="Khalifa University">Khalifa University of
Science Technology and Research</organization>
</author>
<date month="June" year="2012" />
</front>
</reference>
</references>
<!--
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:15:26 |