Network Working Group B. Sarikaya Internet-Draft M. Spini Intended status: Informational Huawei Expires: August 15, 2013 D. von Hugo Telekom Innovation Laboratories February 11, 2013 IPv6 Prefix Sharing Problem Use Case draft-sarikaya-fmc-prefix-sharing-usecase-01.txt Abstract The purpose of this document is to present a use case on problems in addressing end user equipment arising from IPv6 prefix sharing. 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 August 15, 2013. 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. Sarikaya, et al. Expires August 15, 2013 [Page 1] Internet-Draft Prefix Sharing for FMC February 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 3. Policy for Convergence Operation . . . . . . . . . . . . . . . 3 4. Issue Description . . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Sarikaya, et al. Expires August 15, 2013 [Page 2] Internet-Draft Prefix Sharing for FMC February 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]. Moreover several solutions to provide a unique identification to hosts in deployment contexts with address sharing have been analysed in [I-D.ietf-intarea-nat-reveal-analysis]. However, all these use cases involve IPv4 and Network Address Translation (NAT) [RFC2663]. 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]. 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 (RR) 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 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 mobile UE and fixed device. The edge router next initiates an IP Connectivity Access Network (IP- CAN) session with the policy server, aka Policy and Charging Rules Function (PCRF) to receive the Quality of Service (QoS) Sarikaya, et al. Expires August 15, 2013 [Page 3] Internet-Draft Prefix Sharing for FMC February 2013 parameters. Edge router via the RG provides IPv6 Prefix and assigns to 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. 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. 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. 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 communicating 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. +-------------+ +-------------+ +---------------+ |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 Sarikaya, et al. Expires August 15, 2013 [Page 4] Internet-Draft Prefix Sharing for FMC February 2013 4. Issue Description The RG does not signal to the edge router the IPv6 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 for the given UE ID, IPv6 Address. Each host in the home network creates an IPv6 address which is global and this address can be used to identify the hosts traffic and would enable PCEF to enforce the proper QoS after establishing an IP-CAN session to download the required parameters. 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 executing DHCPv6 PD for each host separately. RG gets a different /64 prefix for each host from the edge router and the edge router establishes a different IP-CAN session for each prefix. In case stateful address configuration is used, the issue we described here can be avoided by DHCP server assigning IPv6 addresses from /64 prefixes distinct for each host. Also DHCPv6 server must be located at the edge router so that for each prefix DHCPv6 server assigned, the edge router can establish an IP-CAN session with the mobile network. Note that both of the solutions described in the above two paragraphs are optional and not all networks can be configured to assign different IPv6 prefixes for each host. 5. IANA Considerations This document makes no request to IANA. 6. Security Considerations Any security considerations arising from Policy for Convergence are TBD. 7. Acknowledgements TBD. Sarikaya, et al. Expires August 15, 2013 [Page 5] Internet-Draft Prefix Sharing for FMC February 2013 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., Reddy, T., and B. Williams, "Host Identification: Use Cases", draft-boucadair-intarea-host-identifier-scenarios-02 (work in progress), 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", draft-ietf-intarea-nat-reveal-analysis-04 (work in progress), August 2012. Authors' Addresses Behcet Sarikaya Huawei 5340 Legacy Dr. Sarikaya, et al. Expires August 15, 2013 [Page 6] Internet-Draft Prefix Sharing for FMC February 2013 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 Email: Dirk.von-Hugo@telekom.de Sarikaya, et al. Expires August 15, 2013 [Page 7]