idnits 2.17.1 draft-sarikaya-aps-prefix-sharing-usecase-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-intarea-nat-reveal-analysis' is defined on line 294, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-11) exists of draft-boucadair-intarea-host-identifier-scenarios-03 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft M. Spini 4 Intended status: Informational Huawei 5 Expires: April 24, 2014 D. von Hugo 6 Telekom Innovation Laboratories 7 October 21, 2013 9 IPv6 Prefix Sharing Problem Use Case 10 draft-sarikaya-aps-prefix-sharing-usecase-00.txt 12 Abstract 14 In case a given fixed network is policy converged with the mobile 15 network, i.e if Policy for Convergence is deployed, host specific 16 quality of service and charging can be applied to the hosts 17 connecting using the wireless local area network access or some other 18 means. When local or visiting hosts are assigned their addresses 19 using IPv6 prefix sharing, the edge router is unable to provide host 20 specific quality of service and charging. We explain both stateless 21 and stateful address assignment cases. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 24, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 59 3. Policy for Convergence Operation . . . . . . . . . . . . . . . 3 60 4. Issue Description . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 A number of use cases have been documented that exhibit the issue of 72 uniquely identifying a host among many hosts sharing the same IP 73 address [I-D.boucadair-intarea-host-identifier-scenarios]. However, 74 all these use cases involve IPv4 and Network Address Translation 75 (NAT) [RFC2663] or tunneling. 77 The use case described in this document belongs to Policy for 78 Convergence (P4C) area in Fixed Mobile Convergence (FMC). P4C deals 79 with applying 3GPP Policy and Charging Control (PCC) to the hosts in 80 a fixed IP network, including the User Equipment (UE) accessing the 81 fixed IP network from home or from a hot spot [TS23.203], [TR23.896] 82 using wireless local area network. 84 IPv6 addressing of hosts in a fixed IP network is described in 85 [TR177]. For Routed Residential Gateways (RG) it is the RG that 86 makes the assignments. Stateful (DHCPv6) or stateless address 87 assignment (SLAAC) techniques are supported. For the stateless 88 address assignment, RG uses DHCPv6 Prefix Delegation (PD) [RFC3633]. 89 RG is the Requesting Router and the edge router, aka Broadband 90 Network Gateway (BNG) is the Delegating Router. A different prefix 91 is requested for each access loop, e.g. home or for each host. For 92 stateful address assignment, DHCP server assigns a different 64-bit 93 prefix per access loop or per host. 95 2. Conventions and Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 3. Policy for Convergence Operation 103 3GPP Policy and Charging Control (PCC) is based on interaction 104 between the policy server, aka Policy and Charging Rules Function 105 (PCRF), which sends to the Policy Enforcement Point Function (PCEF) 106 the Quality of Service (QoS) and Charging rules for supporting Online 107 accounting (i.e. pre-paid). The IP Connectivity Access Network (IP- 108 CAN) session, defined in [TS23.203], represents the control session 109 identified by the association between an host, identified by its 110 identity, an IP network, identified by one IPv4 address and/or an 111 IPv6 prefix together. In addition, if available, it can be 112 identified also by the 3GPP Packet Data Network connection. The IP 113 CAN session exists as long as host IP addresses/prefix are 114 established and announced to the PCEF and the PCRF. The IP-CAN 115 session is initiated by PCEF when PCEF becomes aware of the IP 116 address/prefix assigned to the UE, possibly as soon as it is assigned 117 to the host. In fixed network, the edge router acts as a Policy 118 Enforcement Point Function (PCEF). 120 When a Residential Gateway, RG, is attached to the network, e.g. when 121 it is switched on, in IPv6 prefix delegation scenario, it receives an 122 IPv6 prefix. The Edge router, acting as PCEF is aware of both the 123 IPv6 prefix assigned and the identity of the line connecting the home 124 to its operator network, which is the line ID. Hence an IP-CAN 125 session identified by RG ID and IPv6 prefix is established. 127 When a host, e.g. Local_Host_1 in Figure 1 attaches to a routed 128 Residential Gateway, RG uses DHCPv6 Prefix Delegation as Requesting 129 Router (RR) to request a prefix, possibly of size /60 for home 130 network. The edge router acts as the Delegating Router (DR). So the 131 edge router assigns the IPv6 prefix to the RG. Note that the host 132 can be both UE and fixed device. 134 In this scenario, the edge router, acting as PCEF initiates an IP 135 Connectivity Access Network (IP-CAN) session with the policy server, 136 a.k.a. Policy and Charging Rules Function (PCRF) to receive the 137 Quality of Service (QoS) parameters and Charging rules. The edge 138 router provides to the PCRF the IPv6 Prefix assigned to the host and 139 User Equipment (UE) an ID which in this case has to be equal to the 140 RG specific home network line ID. 142 In case of stateless address auto configuration, the host sends a 143 Router Solicitation message to RG and RG sends a Router Advertisement 144 with an IPv6 prefix, the home network prefix. It is assumed that the 145 IPv6 prefix is different from those assigned to the RG. Since it is 146 assigned by router/PCEF there is no problem. In addition the prefix 147 can be different for each host, it is not a problem. 149 The host creates an 128-bit IPv6 address using this prefix and adding 150 its interface id. Having completed the address configuration, the 151 host can start communication with the Internet to use the Internet 152 services. 154 As we explain in Section 4, no specific IP-CAN session can be 155 assigned to Local_Host_1, and consequently the QoS and accounting 156 performed will be based on RG subscription. 158 Another host, e.g. Visiting Host 1 attaches to RG and also 159 establishes an IPv6 address using the home network prefix. Edge 160 router is not involved with this and all other such address 161 assignments. 163 As in previous scenario no specific IP-CAN session/sub-session can be 164 assigned to that given host, and consequently the QoS and accounting 165 performed will be based on RG subscription. 167 The above operation steps assumed that stateless address auto 168 configuration (SLAAC) is used. DHCPv6 based stateful address 169 assignment can also be used. In case of routed RG, RG can be DHCPv6 170 relay agent communication with a DHCPv6 server in the operator's IP 171 network. DHCPv6 server in assigning IPv6 addresses to the hosts uses 172 a method where /64 prefixes are never shared between hosts in 173 different home networks. 175 In DHCPv6 stateful address assignment scenario as in the previous two 176 scenarios, no specific IP-CAN session/sub-session can be assigned to 177 the hosts and likewise the QoS and accounting performed will be based 178 on RG subscription. 180 +-------------+ +-------------+ 181 +---------------+ |Policy Server| | AAA Server | 182 |Visiting Host 1|--+ Mobile Network+-------------+ +-------------+ 183 +---------------+ | ---------------------|-------------------------- 184 +----+ | 185 +-------------+ |Rout| +-------------+ | +-------------+ 186 |Local_Host_1 |--| ed |----| Edge Router |-------+ | AAA Server/| 187 +-------------+ | RG | +-------------+ | Proxy | 188 +----+ \ +-------------+ 189 +---------------+ | \ 190 |Visiting Host 2|--+ Fixed IP Network \ --+- 191 +---------------+ \ / \ 192 \ |Internet| 193 ------------- | Service| 194 \ / 195 ---- 197 Figure 1: Use Case Architecture 199 4. Issue Description 201 In case of Local_Host_1 in Section 3, the edge router, acting as 202 PCEF, becomes aware of the presence of the new IPv6 Address when the 203 host initiates the communication with Internet, but it is not able to 204 associate this IPv6 address with the host's ID. The edge router may 205 associate the traffic to the IPv6 home prefix previously assigned to 206 RG and in such way, the traffic is associated to the IP-CAN session 207 established for the RG. So no specific IP-CAN session can be 208 assigned to that given host, and consequently the QoS and accounting 209 performed will be based on RG subscription. 211 In case of Visiting Host 1 in Section 3, the edge router acting as 212 PCEF is not aware of the IPv6 address assigned to the host and PCEF 213 is not able to start a new IP-CAN session/sub-session for such host 214 different from those initiatiated for the RG. As in previous 215 scenario, no specific IP-CAN session/sub-session can be assigned to 216 that given host, and consequently the QoS and accounting performed 217 will be based on RG subscription. 219 Also, in the case of DHCPv6 based address assignment and if DHCP 220 server uses the same prefix for all hosts in Figure 1, the edge 221 router will associate the traffic to the IP-CAN session established 222 for the RG and this will result in the hosts not getting host 223 specific quality of service or charging. 225 The RG does not signal to the edge router the IP6 address assigned to 226 a host, e.g. visiting host 1 or 2, so the edge router acting as 227 Policy and Charging Enforcement Function (PCEF) is not able to start 228 an 3GPP IP-CAN session/sub-session for the given UE ID, IPv6 Address. 230 UE id given to the mobile network in Section 3 is the home network 231 line id which is the same for all the hosts in the home network. 233 In case stateless address auto configuration is used, the issue we 234 described here can be avoided by a new protocol between RG and edge 235 router. RG needs to signal host address (Local_Host_1 or Visiting 236 Host 1) to the edge router. Edge router needs to take this as a 237 trigger to establish a new IP-CAN session/subsession specific to the 238 attaching host. 240 In case stateful address configuration is used, a similar protocol 241 solution is needed. Due to the stateful operation RG can easily 242 detect the termination of the address assignment and thus decide more 243 precisely when to start communicating with the edge router to trigger 244 the edge router to establish a new IP-CAN session/subsession specific 245 to the attaching host. 247 5. IANA Considerations 249 This document makes no request to IANA. 251 6. Security Considerations 253 Any security considerations arising from Policy for Convergence are 254 TBD. 256 7. Acknowledgements 258 TBD. 260 8. References 262 8.1. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 268 Translator (NAT) Terminology and Considerations", 269 RFC 2663, August 1999. 271 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 272 Host Configuration Protocol (DHCP) version 6", RFC 3633, 273 December 2003. 275 [TR177] "Broadband Forum Technical report TR-177, IPv6 in the 276 context of TR-101 Issue 1", November 2010. 278 [TR23.896] 279 "3GPP TR23.896, Technical Report on Support for fixed 280 broadband access network convergence", November 2012. 282 [TS23.203] 283 "3GPP TS23.203, Policy and Charging Control Architecture", 284 December 2012. 286 8.2. Informative References 288 [I-D.boucadair-intarea-host-identifier-scenarios] 289 Boucadair, M., Binet, D., Durel, S., Chatras, B., Reddy, 290 T., and B. Williams, "Host Identification: Use Cases", 291 draft-boucadair-intarea-host-identifier-scenarios-03 (work 292 in progress), March 2013. 294 [I-D.ietf-intarea-nat-reveal-analysis] 295 Boucadair, M., Touch, J., Levis, P., and R. Penno, 296 "Analysis of Solution Candidates to Reveal a Host 297 Identifier (HOST_ID) in Shared Address Deployments", 298 draft-ietf-intarea-nat-reveal-analysis-10 (work in 299 progress), April 2013. 301 Authors' Addresses 303 Behcet Sarikaya 304 Huawei 305 5340 Legacy Dr. 306 Plano, TX 75074 308 Email: sarikaya@ieee.org 310 Marco Spini 311 Huawei 312 Paris, 313 France 315 Email: M.Spini@huawei.com 317 Dirk von Hugo 318 Telekom Innovation Laboratories 319 Deutsche-Telekom-Allee 7 320 D-64295 Darmstadt 321 Germany 323 Phone: 324 Email: Dirk.von-Hugo@telekom.de