Network Working Group | B.S. Sarikaya |
Internet-Draft | M.S. Spini |
Intended status: Informational | Huawei |
Expires: April 24, 2014 | D.H. von Hugo |
Telekom Innovation Laboratories | |
October 21, 2013 |
IPv6 Prefix Sharing Problem Use Case
draft-sarikaya-aps-prefix-sharing-usecase-00.txt
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.
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 (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.
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.
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].
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 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.
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
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 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.
This document makes no request to IANA.
Any security considerations arising from Policy for Convergence are TBD.
TBD.
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[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. | , "
[TS23.203] | 3GPP TS23.203, Policy and Charging Control Architecture", December 2012. | , "
[TR23.896] | 3GPP TR23.896, Technical Report on Support for fixed broadband access network convergence", November 2012. | , "
[RFC2663] | Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. |
[I-D.boucadair-intarea-host-identifier-scenarios] | Boucadair, M., Binet, D., Durel, S., Reddy, T. and B. Williams, "Host Identification: Use Cases", Internet-Draft draft-boucadair-intarea-host-identifier-scenarios-02, December 2012. |
[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", Internet-Draft draft-ietf-intarea-nat-reveal-analysis-05, February 2013. |