Network Working Group B. Sarikaya
Internet-Draft M. Spini
Intended status: Informational Huawei
Expires: April 24, 2014 D. von Hugo
Telekom Innovation Laboratories
October 21, 2013
IPv6 Prefix Sharing Problem Use Case
draft-sarikaya-aps-prefix-sharing-usecase-00.txt
Abstract
In case a given fixed network is policy converged with the mobile
network, i.e if Policy for Convergence is deployed, host specific
quality of service and charging can be applied to the hosts
connecting using the wireless local area network access or some other
means. When local or visiting hosts are assigned their addresses
using IPv6 prefix sharing, the edge router is unable to provide host
specific quality of service and charging. We explain both stateless
and stateful address assignment cases.
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 April 24, 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
Sarikaya, et al. Expires April 24, 2014 [Page 1]
Internet-Draft Prefix Sharing for FMC October 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
3. Policy for Convergence Operation . . . . . . . . . . . . . . . 3
4. Issue Description . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Sarikaya, et al. Expires April 24, 2014 [Page 2]
Internet-Draft Prefix Sharing for FMC October 2013
1. Introduction
A number of use cases have been documented that exhibit the issue of
uniquely identifying a host among many hosts sharing the same IP
address [I-D.boucadair-intarea-host-identifier-scenarios]. However,
all these use cases involve IPv4 and Network Address Translation
(NAT) [RFC2663] or tunneling.
The use case described in this document belongs to Policy for
Convergence (P4C) area in Fixed Mobile Convergence (FMC). P4C deals
with applying 3GPP Policy and Charging Control (PCC) to the hosts in
a fixed IP network, including the User Equipment (UE) accessing the
fixed IP network from home or from a hot spot [TS23.203], [TR23.896]
using wireless local area network.
IPv6 addressing of hosts in a fixed IP network is described in
[TR177]. For Routed Residential Gateways (RG) it is the RG that
makes the assignments. Stateful (DHCPv6) or stateless address
assignment (SLAAC) techniques are supported. For the stateless
address assignment, RG uses DHCPv6 Prefix Delegation (PD) [RFC3633].
RG is the Requesting Router and the edge router, aka Broadband
Network Gateway (BNG) is the Delegating Router. A different prefix
is requested for each access loop, e.g. home or for each host. For
stateful address assignment, DHCP server assigns a different 64-bit
prefix per access loop or per host.
2. Conventions and 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 RFC 2119 [RFC2119].
3. Policy for Convergence Operation
3GPP Policy and Charging Control (PCC) is based on interaction
between the policy server, aka Policy and Charging Rules Function
(PCRF), which sends to the Policy Enforcement Point Function (PCEF)
the Quality of Service (QoS) and Charging rules for supporting Online
accounting (i.e. pre-paid). The IP Connectivity Access Network (IP-
CAN) session, defined in [TS23.203], represents the control session
identified by the association between an host, identified by its
identity, an IP network, identified by one IPv4 address and/or an
IPv6 prefix together. In addition, if available, it can be
identified also by the 3GPP Packet Data Network connection. The IP
CAN session exists as long as host IP addresses/prefix are
established and announced to the PCEF and the PCRF. The IP-CAN
Sarikaya, et al. Expires April 24, 2014 [Page 3]
Internet-Draft Prefix Sharing for FMC October 2013
session is initiated by PCEF when PCEF becomes aware of the IP
address/prefix assigned to the UE, possibly as soon as it is assigned
to the host. In fixed network, the edge router acts as a Policy
Enforcement Point Function (PCEF).
When a Residential Gateway, RG, is attached to the network, e.g. when
it is switched on, in IPv6 prefix delegation scenario, it receives an
IPv6 prefix. The Edge router, acting as PCEF is aware of both the
IPv6 prefix assigned and the identity of the line connecting the home
to its operator network, which is the line ID. Hence an IP-CAN
session identified by RG ID and IPv6 prefix is established.
When a host, e.g. Local_Host_1 in Figure 1 attaches to a routed
Residential Gateway, RG uses DHCPv6 Prefix Delegation as Requesting
Router (RR) to request a prefix, possibly of size /60 for home
network. The edge router acts as the Delegating Router (DR). So the
edge router assigns the IPv6 prefix to the RG. Note that the host
can be both UE and fixed device.
In this scenario, the edge router, 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. The edge
router provides to the PCRF the IPv6 Prefix assigned to the host and
User Equipment (UE) an ID which in this case has to be equal to the
RG specific home network line ID.
In case of stateless address auto configuration, the host sends a
Router Solicitation message to RG and RG sends a Router Advertisement
with an IPv6 prefix, the home network prefix. It is assumed that the
IPv6 prefix is different from those assigned to the RG. Since it is
assigned by router/PCEF there is no problem. In addition the prefix
can be different for each host, it is not a problem.
The host 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 the Internet to use the Internet
services.
As we explain in Section 4, no specific IP-CAN session can be
assigned to Local_Host_1, and consequently the QoS and accounting
performed will be based on RG subscription.
Another host, e.g. Visiting Host 1 attaches to RG and also
establishes an IPv6 address using the home network prefix. Edge
router is not involved with this and all other such address
assignments.
Sarikaya, et al. Expires April 24, 2014 [Page 4]
Internet-Draft Prefix Sharing for FMC October 2013
As in previous scenario no specific IP-CAN session/sub-session can be
assigned to that given host, and consequently the QoS and accounting
performed will be based on RG subscription.
The above operation steps assumed that stateless address auto
configuration (SLAAC) is used. DHCPv6 based stateful address
assignment can also be used. In case of routed RG, RG can be DHCPv6
relay agent communication with a DHCPv6 server in the operator's IP
network. DHCPv6 server in assigning IPv6 addresses to the hosts uses
a method where /64 prefixes are never shared between hosts in
different home networks.
In DHCPv6 stateful address assignment scenario as in the previous two
scenarios, no specific IP-CAN session/sub-session can be assigned to
the hosts and likewise the QoS and accounting performed will be based
on RG subscription.
+-------------+ +-------------+
+---------------+ |Policy Server| | AAA Server |
|Visiting Host 1|--+ Mobile Network+-------------+ +-------------+
+---------------+ | ---------------------|--------------------------
+----+ |
+-------------+ |Rout| +-------------+ | +-------------+
|Local_Host_1 |--| ed |----| Edge Router |-------+ | AAA Server/|
+-------------+ | RG | +-------------+ | Proxy |
+----+ \ +-------------+
+---------------+ | \
|Visiting Host 2|--+ Fixed IP Network \ --+-
+---------------+ \ / \
\ |Internet|
------------- | Service|
\ /
----
Figure 1: Use Case Architecture
4. Issue Description
In case of Local_Host_1 in Section 3, the edge router, acting as
PCEF, becomes aware of the presence of the new IPv6 Address when the
host initiates the communication with Internet, but it is not able to
associate this IPv6 address with the host's ID. The edge router may
associate the traffic to the IPv6 home prefix previously assigned to
RG and in such way, the traffic is associated to the IP-CAN session
established for the RG. So no specific IP-CAN session can be
assigned to that given host, and consequently the QoS and accounting
Sarikaya, et al. Expires April 24, 2014 [Page 5]
Internet-Draft Prefix Sharing for FMC October 2013
performed will be based on RG subscription.
In case of Visiting Host 1 in Section 3, the edge router acting as
PCEF is not aware of the IPv6 address assigned to the host and PCEF
is not able to start a new IP-CAN session/sub-session for such host
different from those initiatiated for the RG. As in previous
scenario, no specific IP-CAN session/sub-session can be assigned to
that given host, and consequently the QoS and accounting performed
will be based on RG subscription.
Also, in the case of DHCPv6 based address assignment and if DHCP
server uses the same prefix for all hosts in Figure 1, the edge
router will associate the traffic to the IP-CAN session established
for the RG and this will result in the hosts not getting host
specific quality of service or charging.
The RG does not signal to the edge router the IP6 address assigned to
a host, e.g. visiting host 1 or 2, so the edge router acting as
Policy and Charging Enforcement Function (PCEF) is not able to start
an 3GPP IP-CAN session/sub-session for the given UE ID, IPv6 Address.
UE id given to the mobile network in Section 3 is the home network
line id which is the same for all the hosts in the home network.
In case stateless address auto configuration is used, the issue we
described here can be avoided by a new protocol between RG and edge
router. RG needs to signal host address (Local_Host_1 or Visiting
Host 1) to the edge router. Edge router needs to take this as a
trigger to establish a new IP-CAN session/subsession specific to the
attaching host.
In case stateful address configuration is used, a similar protocol
solution is needed. Due to the stateful operation RG can easily
detect the termination of the address assignment and thus decide more
precisely when to start communicating with the edge router to trigger
the edge router to establish a new IP-CAN session/subsession specific
to the attaching host.
5. IANA Considerations
This document makes no request to IANA.
6. Security Considerations
Any security considerations arising from Policy for Convergence are
TBD.
Sarikaya, et al. Expires April 24, 2014 [Page 6]
Internet-Draft Prefix Sharing for FMC October 2013
7. Acknowledgements
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[TR177] "Broadband Forum Technical report TR-177, IPv6 in the
context of TR-101 Issue 1", November 2010.
[TR23.896]
"3GPP TR23.896, Technical Report on Support for fixed
broadband access network convergence", November 2012.
[TS23.203]
"3GPP TS23.203, Policy and Charging Control Architecture",
December 2012.
8.2. Informative References
[I-D.boucadair-intarea-host-identifier-scenarios]
Boucadair, M., Binet, D., Durel, S., Chatras, B., Reddy,
T., and B. Williams, "Host Identification: Use Cases",
draft-boucadair-intarea-host-identifier-scenarios-03 (work
in progress), March 2013.
[I-D.ietf-intarea-nat-reveal-analysis]
Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Solution Candidates to Reveal a Host
Identifier (HOST_ID) in Shared Address Deployments",
draft-ietf-intarea-nat-reveal-analysis-10 (work in
progress), April 2013.
Sarikaya, et al. Expires April 24, 2014 [Page 7]
Internet-Draft Prefix Sharing for FMC October 2013
Authors' Addresses
Behcet Sarikaya
Huawei
5340 Legacy Dr.
Plano, TX 75074
Email: sarikaya@ieee.org
Marco Spini
Huawei
Paris,
France
Email: M.Spini@huawei.com
Dirk von Hugo
Telekom Innovation Laboratories
Deutsche-Telekom-Allee 7
D-64295 Darmstadt
Germany
Phone:
Email: Dirk.von-Hugo@telekom.de
Sarikaya, et al. Expires April 24, 2014 [Page 8]