idnits 2.17.1 draft-boucadair-intarea-host-identifier-scenarios-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2014) is 3668 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-08 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-10 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft D. Binet 4 Intended status: Informational S. Durel 5 Expires: October 13, 2014 B. Chatras 6 France Telecom 7 T. Reddy 8 Cisco 9 B. Williams 10 Akamai, Inc. 11 B. Sarikaya 12 L. Xue 13 Huawei 14 April 11, 2014 16 Host Identification: Use Cases 17 draft-boucadair-intarea-host-identifier-scenarios-05 19 Abstract 21 This document describes a set of scenarios in which host 22 identification is problematic. The document does not include any 23 solution-specific discussion. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 13, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Use Case 1: CGN . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Use Case 2: A+P . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Use Case 3: Application Proxies . . . . . . . . . . . . . . . 5 64 6. Use Case 4: Open Wi-Fi or Provider Wi-Fi . . . . . . . . . . 6 65 7. Use Case 5: Policy and Charging Control Architecture . . . . 7 66 8. Use Case 6: Cellular Networks . . . . . . . . . . . . . . . . 8 67 9. Use Case 7: Femtocells . . . . . . . . . . . . . . . . . . . 9 68 10. Use Case 8: Overlay Network . . . . . . . . . . . . . . . . . 10 69 11. Use Case 9: Emergency Calls . . . . . . . . . . . . . . . . . 12 70 12. Use Case 10: Traffic Detection Function . . . . . . . . . . . 13 71 13. Use Case 11: Fixed and Mobile Network Convergence . . . . . . 14 72 14. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 74 16. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 76 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 77 19. Informative References . . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 The goal of this document is to enumerate use cases which encounter 83 the issue of uniquely identifying a host among those sharing the same 84 IP address. Examples of encountered issues in those use cases are: 86 o Blacklist a misbehaving host without impacting all hosts sharing 87 the same IP address. 88 o Enforce a per-subscriber/per-UE policy (e.g., limit access to the 89 service based on some counters such as volume-based service 90 offering); enforcing the policy will have impact on all hosts 91 sharing the same IP address. 92 o If invoking a service has failed (e.g., wrong login/password), all 93 hosts sharing the same IP address may not be able to access that 94 service. 95 o Need to correlate between the internal address:port and external 96 address:port to generate and therefore to enforce policies. 98 o Query a location server for the location of an emergency caller 99 based on the source IP address. 101 It is out of scope of this document to list all the encountered 102 issues as this is already covered in [RFC6269]. 104 The following use cases are identified: 106 (1) Carrier Grade NAT (CGN) (Section 3) 107 (2) A+P (e.g., MAP ) (Section 4) 108 (3) Application Proxies (Section 5) 109 (4) Provider Wi-Fi (Section 6) 110 (5) Policy and Charging Architectures (Section 7) 111 (6) Cellular Networks (Section 8) 112 (7) Femtocells (Section 9) 113 (8) Overlay Networks (e.g., CDNs) (Section 10) 114 (9) Emergency Calls (Section 11) 115 (10) Traffic Detection Function (Section 12) 116 (11) Fixed and Mobile Network Convergence (Section 13) 118 The analysis of the use cases listed in this document indicates 119 several root causes for the host identification issue: 121 1. Presence of address sharing (NAT, A+P, application proxies, 122 etc.). 123 2. Use of tunnels between two administrative domains. 124 3. Combination of address sharing and presence of tunnels in the 125 path. 127 2. Scope 129 It is out of scope of this document to argue in favor or against the 130 use cases listed in the following sections. The goal is to identify 131 scenarios the authors are aware of and which share the same issue of 132 host identification. 134 This document does not include any solution-specific discussion. 135 This document can be used as a tool to design solution(s) mitigating 136 the encountered issues. Describing the use case allows to identify 137 what is common between the use cases and then would help during the 138 solution design phase. 140 The document does not elaborate whether explicit authentication is 141 enabled or not. 143 3. Use Case 1: CGN 145 Several flavors of stateful CGN have been defined. A non-exhaustive 146 list is provided below: 148 1. NAT44 ([RFC6888], [I-D.tsou-stateless-nat44]) 150 2. DS-Lite NAT44 [RFC6333] 152 3. NAT64 [RFC6146] 154 4. NPTv6 [RFC6296] 156 As discussed in [RFC6967], remote servers are not able to distinguish 157 between hosts sharing the same IP address (Figure 1). 159 +-----------+ 160 | HOST_1 |----+ 161 +-----------+ | +--------------------+ +------------+ 162 | | |------| server 1 | 163 +-----------+ +-----+ | | +------------+ 164 | HOST_2 |--| CGN |----| INTERNET | :: 165 +-----------+ +-----+ | | +------------+ 166 | | |------| server n | 167 +-----------+ | +--------------------+ +------------+ 168 | HOST_3 |-----+ 169 +-----------+ 171 Figure 1: CGN Reference Architecture 173 Some of the above referenced CGN use cases will be satisfied by 174 eventual completion of the transition to IPv6 across the Internet 175 (e.g., NAT64), but this is not true of all CGN use cases (e.g. NPTv6 176 [RFC6296]) for which some of the issues discussed in [RFC6269] will 177 be encountered (e.g., impact on geolocation [RFC6269]). Note, it is 178 not the intent of this document to advocate in favor or against 179 NPTv6, but to highlight the complications that may raise when 180 enabling such function. 182 4. Use Case 2: A+P 184 A+P [RFC6346][I-D.ietf-softwire-map][I-D.ietf-softwire-lw4over6] 185 denotes a flavor of address sharing solutions which does not require 186 any additional NAT function be enabled in the service provider's 187 network. A+P assumes subscribers are assigned with the same IPv4 188 address together with a port set. Subscribers assigned with the same 189 IPv4 address should be assigned non overlapping port sets. Devices 190 connected to an A+P-enabled network should be able to restrict the 191 IPv4 source port to be within a configured range of ports. To 192 forward incoming packets to the appropriate host, a dedicated entity 193 called PRR (Port Range Router, [RFC6346]) is needed (Figure 2). 195 Similar to the CGN case, the same issue to identify hosts sharing the 196 same IP address is encountered by remote servers. 198 +-----------+ 199 | HOST_1 |----+ 200 +-----------+ | +--------------------+ +------------+ 201 | | |------| server 1 | 202 +-----------+ +-----+ | | +------------+ 203 | HOST_2 |--| PRR |----| INTERNET | :: 204 +-----------+ +-----+ | | +------------+ 205 | | |------| server n | 206 +-----------+ | +--------------------+ +------------+ 207 | HOST_3 |-----+ 208 +-----------+ 210 Figure 2: A+P Reference Architecture 212 5. Use Case 3: Application Proxies 214 This scenario is similar to the CGN scenario. Remote servers are not 215 able to distinguish hosts located behind the PROXY. Applying 216 policies on the perceived external IP address as received from the 217 PROXY will impact all hosts connected to that PROXY. 219 Figure 3 illustrates a simple configuration involving a proxy. Note 220 several (per-application) proxies may be deployed. 222 +-----------+ 223 | HOST_1 |----+ 224 +-----------+ | +--------------------+ +------------+ 225 | | |------| server 1 | 226 +-----------+ +-----+ | | +------------+ 227 | HOST_2 |--|PROXY|----| INTERNET | :: 228 +-----------+ +-----+ | | +------------+ 229 | | |------| server n | 230 +-----------+ | +--------------------+ +------------+ 231 | HOST_3 |-----+ 232 +-----------+ 234 Figure 3: Proxy Reference Architecture 236 In the application proxy scenario, packets/connections must be 237 received by the proxy regardless of the IP address family in use. 238 The requirements of this use case are not satisfied by eventual 239 completion of the transition to IPv6 across the Internet. 241 6. Use Case 4: Open Wi-Fi or Provider Wi-Fi 243 In the context of Provider Wi-Fi (WLAN), a dedicated SSID can be 244 configured and advertised by the RG (Residential Gateway) for 245 visiting terminals. These visiting terminals can be mobile 246 terminals, PCs, etc. 248 Several deployment scenarios are envisaged: 250 1. Deploy a dedicated node in the service provider's network which 251 will be responsible to intercept all the traffic issued from 252 visiting terminals (see Figure 4). This node may be co-located 253 with a CGN function if private IPv4 addresses are assigned to 254 visiting terminals. Similar to the CGN case discussed in 255 Section 3, remote servers may not be able to distinguish visiting 256 hosts sharing the same IP address (see [RFC6269]). 258 2. Unlike the previous deployment scenario, IPv4 addresses are 259 managed by the RG without requiring any additional NAT to be 260 deployed in the service provider's network for handling traffic 261 issued from visiting terminals. Concretely, a visiting terminal 262 is assigned with a private IPv4 address from the IPv4 address 263 pool managed by the RG. Packets issued form a visiting terminal 264 are translated using the public IP address assigned to the RG 265 (see Figure 5). This deployment scenario induces the following 266 identification concerns: 268 * The provider is not able to distinguish the traffic belonging 269 to the visiting terminal from the traffic of the subscriber 270 owning the RG. This is needed to apply some policies such as: 271 accounting, DSCP remarking, black list, etc. 273 * Similar to the CGN case Section 3, a misbehaving visiting 274 terminal is likely to have some impact on the experienced 275 service by the subscriber owning the RG (e.g., some of the 276 issues are discussed in [RFC6269]). 278 +-------------+ 279 |Local_HOST_1 |----+ 280 +-------------+ | 281 | | 282 +-------------+ +-----+ | +-----------+ 283 |Local_HOST_2 |--| RG |-|--|Border Node| 284 +-------------+ +-----+ | +----NAT----+ 285 | | 286 +-------------+ | | Service Provider 287 |Visiting Host|-----+ 288 +-------------+ 290 Figure 4: NAT enforced in a Service Provider's Node 292 +-------------+ 293 |Local_HOST_1 |----+ 294 +-------------+ | 295 | | 296 +-------------+ +-----+ | +-----------+ 297 |Local_HOST_2 |--| RG |-|--|Border Node| 298 +-------------+ +-NAT-+ | +-----------+ 299 | | 300 +-------------+ | | Service Provider 301 |Visiting Host|-----+ 302 +-------------+ 304 Figure 5: NAT located in the RG 306 7. Use Case 5: Policy and Charging Control Architecture 308 This issue is related to the framework defined in [TS23.203] when a 309 NAT is located between the PCEF (Policy and Charging Enforcement 310 Function) and the AF (Application Function) as shown in Figure 6. 312 The main issue is: PCEF, PCRF and AF all receive information bound to 313 the same UE( User Equipment) but without being able to correlate 314 between the piece of data visible for each entity. Concretely, 316 o PCEF is aware of the IMSI (International Mobile Subscriber 317 Identity) and an internal IP address assigned to the UE. 319 o AF receives an external IP address and port as assigned by the NAT 320 function. 322 o PCRF is not able to correlate between the external IP address/port 323 assigned by the NAT (received from the AF) and the internal IP 324 address and IMSI of the UE (received from the PCEF). 326 +------+ 327 | PCRF |-----------------+ 328 +------+ | 329 | | 330 +----+ +------+ +-----+ +-----+ 331 | UE |------| PCEF |---| NAT |----| AF | 332 +----+ +------+ +-----+ +-----+ 334 Figure 6: NAT located between AF and PCEF 336 This scenario can be generalized as follows (Figure 7): 338 o Policy Enforcement Point (PEP, [RFC2753]) 340 o Policy Decision Point (PDP, [RFC2753]) 342 +------+ 343 | PDP |-----------------+ 344 +------+ | 345 | | 346 +----+ +------+ +-----+ +------+ 347 | UE |------| PEP |---| NAT |----|Server| 348 +----+ +------+ +-----+ +------+ 350 Figure 7: NAT located between PEP and Server 352 Note that an issue is encountered to enforce per-UE policies when the 353 NAT is located before the PEP function (see Figure 8): 355 +------+ 356 | PDP |------+ 357 +------+ | 358 | | 359 +----+ +------+ +-----+ +------+ 360 | UE |------| NAT |---| PEP |----|Server| 361 +----+ +------+ +-----+ +------+ 363 Figure 8: NAT located before PEP 365 8. Use Case 6: Cellular Networks 367 Cellular operators allocate private IPv4 addresses to mobile 368 terminals and deploy NAT44 function, generally co-located with 369 firewalls, to access to public IP services. The NAT function is 370 located at the boundaries of the PLMN (Public Land Mobile Network). 371 IPv6-only strategy, consisting in allocating IPv6 prefixes only to 372 mobile terminals, is considered by various operators. A NAT64 373 function is also considered in order to preserve IPv4 service 374 continuity for these customers. 376 These NAT44 and NAT64 functions bring some issues very similar to 377 those mentioned in Figure 1 and Section 7. This issue is 378 particularly encountered if policies are to be applied on the Gi 379 interface: a private IP address is assigned to the mobile terminals, 380 there is no correlation between the internal IP address and the 381 external address:port assigned by the NAT function, etc. 383 9. Use Case 7: Femtocells 385 This use case can be seen as a combination of the use cases described 386 in Section 6 and Section 7. 388 The reference architecture is shown in Figure 8. 390 +---------------------------+ 391 | +----+ +--------+ +----+ | +-----------+ +-------------------+ 392 | | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ | 393 | +----+ | alone | | RG | | | | | | | | | Mobile | 394 | | FAP | +----+ | | | | |S | |F | Network| 395 | +--------+ (NAPT) | | Broadband | | |e | |A | | 396 +---------------------------+ | Fixed | | |G |-|P | +-----+| 397 | Network | | |W | |G |-| Core|| 398 +---------------------------+ | (BBF) | | | | |W | | Ntwk|| 399 | +----+ +------------+ | | | | | | | | +-----+| 400 | | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ | 401 | +----+ | FAP (NAPT) | | +-----------+ +-------------------+ 402 | +------------+ | 403 +---------------------------+ 405 <=====> IPsec tunnel 406 CoreNtwk Core Network 407 FAPGW FAP Gateway 408 SeGW Security Gateway 410 Figure 9: Femtocell Reference Architecture 412 UE is connected to the FAP at the residential gateway (RG), routed 413 back to 3GPP Evolved Packet Core (EPC). UE is assigned IPv4 address 414 by the Mobile Network. Mobile operator's FAP leverages the IPsec 415 IKEv2 to interconnect FAP with the SeGW over the BBF network. Both 416 the FAP and the SeGW are managed by the mobile operator which may be 417 a different operator for the BBF network. 419 An investigated scenario is the mobile operator to pass on its mobile 420 subscriber's policies to the BBF to support traffic policy control . 421 But most of today's broadband fixed networks are relying on the 422 private IPv4 addressing plan (+NAPT) to support its attached devices 423 including the mobile operator's FAP. In this scenario, the mobile 424 network needs to: 426 o determine the FAP's public IPv4 address to identify the location 427 of the FAP to ensure its legitimacy to operate on the license 428 spectrum for a given mobile operator prior to the FAP be ready to 429 serve its mobile devices. 431 o determine the FAP's pubic IPv4 address together with the 432 translated port number of the UDP header of the encapsulated IPsec 433 tunnel for identifying the UE's traffic at the fixed broadband 434 network. 436 o determine the corresponding FAP's public IPv4 address associated 437 with the UE's inner-IPv4 address which is assigned by the mobile 438 network to identify the mobile UE to allow the PCRF to retrieve 439 the special UE's policy (e.g., QoS) to be passed onto the 440 Broadband Policy Control Function (BPCF) at the BBF network. 442 SeGW would have the complete knowledge of such mapping, but the 443 reasons for unable to use SeGW for this purpose is explained in 444 "Problem Statements" (section 2 of [I-D.so-ipsecme-ikev2-cpext]). 446 This use case involves PCRF/BPCF but it is valid in other deployment 447 scenarios making use of AAA servers. 449 The issue of correlating the internal IP address and the public IP 450 address is valid even if there is no NAT in the path. 452 10. Use Case 8: Overlay Network 454 An overlay network is a network of machines distributed throughout 455 multiple autonomous systems within the public Internet that can be 456 used to improve the performance of data transport (see Figure 10). 457 IP packets from the sender are delivered first to one of the machines 458 that make up the overlay network. That machine then relays the IP 459 packets to the receiver via one or more machines in the overlay 460 network, applying various performance enhancement methods. 462 +------------------------------------+ 463 | | 464 | INTERNET | 465 | | 466 +-----------+ | +------------+ | 467 | HOST_1 |-----| OVRLY_IN_1 |-----------+ | 468 +-----------+ | +------------+ | | 469 | | | 470 +-----------+ | +------------+ +-----------+ | +--------+ 471 | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | 472 +-----------+ | +------------+ +-----------+ | +--------+ 473 | | | 474 +-----------+ | +------------+ | | 475 | HOST_3 |-----| OVRLY_IN_3 |-----------+ | 476 +-----------+ | +------------+ | 477 | | 478 +------------------------------------+ 480 Figure 10: Overlay Network Reference Architecture 482 Such overlay networks are used to improve the performance of content 483 delivery [IEEE1344002]. Overlay networks are also used for peer-to- 484 peer data transport [RFC5694], and they have been suggested for use 485 in both improved scalability for the Internet routing infrastructure 486 [RFC6179] and provisioning of security services (intrusion detection, 487 anti-virus software, etc.) over the public Internet [IEEE101109]. 489 In order for an overlay network to intercept packets and/or 490 connections transparently via base Internet connectivity 491 infrastructure, the overlay ingress and egress hosts (OVERLAY_IN and 492 OVERLAY_OUT) must be reliably in-path in both directions between the 493 connection-initiating HOST and the SERVER. When this is not the 494 case, packets may be routed around the overlay and sent directly to 495 the receiving host. 497 For public overlay networks, where the ingress and/or egress hosts 498 are on the public Internet, packet interception commonly uses network 499 address translation for the source (SNAT) or destination (DNAT) 500 addresses in such a way that the public IP addresses of the true 501 endpoint hosts involved in the data transport are invisible to each 502 other (see Figure 11). For example, the actual sender and receiver 503 may use two completely different pairs of source and destination 504 addresses to identify the connection on the sending and receiving 505 networks in cases where both the ingress and egress hosts are on the 506 public Internet. 508 ip hdr contains: ip hdr contains: 509 SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER 510 dst = overlay1 dst = receiver 512 Figure 11: NAT operations in an Overlay Network 514 In this scenario, the remote server is not able to distinguish among 515 hosts using the overlay for transport. In addition, the remote 516 server is not able to determine the overlay ingress point being used 517 by the host, which can be useful for diagnosing host connectivity 518 issues. 520 In some of the above referenced use cases, IP packets traverse the 521 overlay network fundamentally unchanged, with the overlay network 522 functioning much like a CGN (Section 3). In other cases, connection- 523 oriented data flows (e.g. TCP) are terminated by the overlay in order 524 to perform object caching and other such transport and application 525 layer optimizations, similar to the proxy scenario (Section 5). In 526 both cases, address sharing is a requirement for packet/connection 527 interception, which means that the requirements for this use case are 528 not satisfied by the eventual completion of the transition to IPv6 529 across the Internet. 531 More details about this use case are provided in 532 [I-D.williams-overlaypath-ip-tcp-rfc]. 534 11. Use Case 9: Emergency Calls 536 Voice service providers (VSPs) operating under certain jurisdictions 537 are required to route emergency calls from their subscribers and have 538 to include information about the caller's location in signaling 539 messages they send towards PSAPs (Public Safety Answering Points, 540 [RFC6443]), via an Emergency Service Routing Proxy (ESRP, [RFC6443]). 541 This information is used both for the determination of the correct 542 PSAP and to reveal the caller's location to the selected PSAP. 544 In many countries, regulation bodies require that this information be 545 provided by the network rather than the user equipment, in which case 546 the VSP needs to retrieve this information (by reference or by value) 547 from the access network where the caller is attached. 549 This requires the VSP call server receiving an emergency call request 550 to identify the relevant access network and to query a Location 551 Information Server (LIS) in this network using a suitable look-up 552 key. In the simplest case, the source IP address of the IP packet 553 carrying the call request is used both for identifying the access 554 network (thanks to a reverse DNS query) and as a look-up key to query 555 the LIS. Obviously the user-id as known by the VSP (e.g., telephone 556 number, or email-formatted URI) can't be used as it is not known by 557 the access network. 559 The above mechanism is broken when there is a NAT between the user 560 and the VSP and/or if the emergency call is established over a VPN 561 tunnel (e.g., an employee remotely connected to a company VoIP server 562 through a tunnel wishes to make an emergency call). In such cases, 563 the source IP address received by the VSP call server will identity 564 the NAT or the address assigned to the caller equipment by the VSP 565 (i.e., the address inside the tunnel). This is similar to the CGN 566 case (Section 3) and overlay network case (Section 10) and applies 567 irrespective of the IP versions used on both sides of the NAT and/or 568 inside and outside the tunnel. 570 Therefore, the VSP needs to receive an additional piece of 571 information that can be used to both identify the access network 572 where the caller is attached and query the LIS for his/her location. 573 This would require the NAT or the Tunnel Endpoint to insert this 574 extra information in the call requests delivered to the VSP call 575 servers. For example, this extra information could be a combination 576 of the local IP address assigned by the access network to the 577 caller's equipment with some form of identification of this access 578 network. 580 However, because it shall be possible to setup an emergency call 581 regardless of the actual call control protocol used between the user 582 and the VSP (e.g., SIP [RFC3261], IAX [RFC5456], tunneled over HTTP, 583 or proprietary protocol, possibly encrypted), this extra information 584 has to be conveyed outside the call request, in the header of lower 585 layers protocols. 587 12. Use Case 10: Traffic Detection Function 589 Operators expect that the traffic subject to the packet inspection is 590 routed via the Traffic Detection Function (TDF) function as 591 requirement specified in [TS29.212], otherwise, the traffic may 592 bypass the TDF. This assumption only holds if it is possible to 593 identify individual UEs behind NA(P)T which may be deployed into the 594 RG in fixed broadband network, shown in Figure 12. As a result, 595 additional mechanisms are needed to enable this requirement. 597 +--------+ 598 | | 599 +-------+ PCRF | 600 | | | 601 | +--------+ 602 +--------+ +--------+ +--------+ +----+----+ 603 | | | | | +-----+ | 604 | ------------------------------------------------------------------ 605 | | | | | | | TDF | / \ 606 | ****************************************************************** 607 | | | +-------+ | | | Service 608 | | | | | | | \ / 609 | | | | | | | +--------+ 610 | | | | | | +--------+ PDN | 611 | ********---------**********--------************------------******* | 612 | UE | | RG | | BNG +------------------+ Gateway| 613 +--------+ +--------+ +--------+ +--------+ 615 Legends: 616 --------- 3GPP UE User Plane Traffic Offloaded subject to packet 617 inspection 618 ********* 3GPP UE User Plane Traffic Offloaded not subject to packet 619 inspection 620 *****---- 3GPP UE User Plane Traffic Home Routed 622 Figure 12: UE's Traffic Routed with TDF 624 13. Use Case 11: Fixed and Mobile Network Convergence 626 In the Policy for Convergence of Fixed Mobile Convergence (FMC) 627 scenario, the fixed broadband network must partner with the mobile 628 network to acquire the policies for the terminals or hosts attaching 629 to the fixed broadband network, shown in Figure 13 so that host- 630 specific QoS and accounting policies can be applied. 632 A UE is connected to the RG, routed back to the mobile network. The 633 mobile operator's PCRF needs to maintain the interconnect with the 634 Broadband Policy Control Function (BPCF) in the BBF network for PCC 635 (Section 7). The hosts (i.e., UEs) attaching to fixed broadband 636 network with a NA(P)T deployed should be identified. Based on the UE 637 identification, the BPCF to deploy policy rules in the fixed 638 broadband network can acquire the associated policy rules of the 639 identified UE from the PCRF in the mobile network. But in the fixed 640 broadband network, private IPv4 address is supported. The similar 641 requirements are raised in this use case as Section 9. 643 +------------------------------+ +-------------+ 644 | | | | 645 | +------+ | | +------+ | 646 | | BPCF +---+---+-+ PCRF | | 647 | +--+---+ | | +---+--+ | 648 +-------+ | | | | | | 649 |HOST_1 |Private IP1 +--+---+ | | +---+--+ | 650 +-------+ | +----+ | | | | | | | 651 | | RG | | | | | | | | 652 | |with+-------------+ BNG +--------+ PGW | | 653 +-------+ | | NAT| | | | | | | | 654 |HOST_2 | | +----+ | | | | | | | 655 +-------+Private IP2 +------+ | | +------+ | 656 | | | | 657 | | | | 658 | Fixed | | Mobile | 659 | Broadband | | Network | 660 | Network | | | 661 | | | | 662 +------------------------------+ +-------------+ 664 Figure 13: Reference Architecture for Policy for Convergence in Fixed 665 and Mobile Network Convergence (1) 667 In IPv6 network, the similar issues exists when the IPv6 prefix is 668 sharing between multiple UEs attaching to the RG (see Figure 14). 669 The case applies when RG is assigned a single prefix, the home 670 network prefix, e.g. using DHCPv6 Prefix Delegation [RFC3633] with 671 the edge router, BNG acting as the Delegating Router (DR). RG uses 672 the home network prefix in the address configuration using stateful 673 (DHCPv6) or stateless address assignment (SLAAC) techniques. 675 +------------------------------+ +-------------+ 676 | | | | 677 | | | +------+ | 678 | +-------------+ PCRF | | 679 | | | | +---+--+ | 680 +-------+ | | | | | | 681 |HOST_1 |--+ +--+---+ | | +---+--+ | 682 +-------+ | +----+ | | | | | | | 683 | | RG | | | | | | | | 684 | | +------------+ BNG +---------+ PGW | | 685 +-------+ | | | | | | | | | | 686 |HOST_2 |--+ +----+ | | | | | | | 687 +-------+ | +------+ | | +------+ | 688 | | | | 689 | | | | 690 | Fixed | | Mobile | 691 | Broadband | | Network | 692 | Network | | | 693 | | | | 694 +------------------------------+ +-------------+ 696 Figure 14: Reference Architecture for Policy for Convergence in Fixed 697 and Mobile Network Convergence (2) 699 BNG acting as PCEF initiates an IP Connectivity Access Network (IP- 700 CAN) session with the policy server, a.k.a. Policy and Charging Rules 701 Function (PCRF), to receive the Quality of Service (QoS) parameters 702 and Charging rules. BNG provides to the PCRF the IPv6 Prefix 703 assigned to the host, in this case the home network prefix and an ID 704 which in this case has to be equal to the RG specific home network 705 line ID. 707 HOST_1 in Figure 14 creates an 128-bit IPv6 address using this prefix 708 and adding its interface id. Having completed the address 709 configuration, the host can start communication with a remote hosts 710 over Internet. However, no specific IP-CAN session can be assigned 711 to HOST_1, and consequently the QoS and accounting performed will be 712 based on RG subscription. 714 Another host, e.g. HOST_2, attaches to RG and also establishes an 715 IPv6 address using the home network prefix. Edge router, the BNG, is 716 not involved with this and all other such address assignments. 718 This leads to the case where no specific IP-CAN session/sub-session 719 can be assigned to the hosts, HOST_1, HOST_2, etc., and consequently 720 the QoS and accounting performed can only be based on RG subscription 721 and not host specific. Therefore IPv6 prefix sharing in Policy for 722 Convergence scenario leads to similar issues as the address sharing 723 as it has been explained in the previous use cases in this document. 725 14. Synthesis 727 The following table shows whether each use case is valid for IPv4/ 728 IPv6 and if it is within one single administrative domain or span 729 multiple domains. 731 +-------------------+------+-------------+-----------------------+ 732 | Use Case | IPv4 | IPv6 | Single Administrative | 733 | | |------+------| Domain | 734 | | |Client|Server| | 735 +-------------------+------+------+------+-----------------------+ 736 | CGN | Yes |Yes(1)| No | No | 737 | A+P | Yes | No | No | No | 738 | Application Proxy | Yes |Yes(2)|Yes(2)| No | 739 | Provider Wi-Fi | Yes | No | No | Yes | 740 | PCC | Yes |Yes(1)| No | Yes | 741 | Femtocells | Yes | No | No | No | 742 | Cellular Networks | Yes |Yes(1)| No | Yes | 743 | Overlay Networks | Yes |Yes(3)|Yes(3)| No | 744 | Emergency Calls | Yes | Yes |Yes | No | 745 | TDF | Yes | Yes | No | Yes | 746 | FMC | Yes |Yes(1)| No | No | 747 +-------------------+------+------+------------------------------+ 749 Notes: 750 (1) e.g., NAT64 751 (2) A proxy can use IPv6 for the communication leg with the server 752 or the application client. 753 (3) This use case is a combination of CGN and Application Proxies. 755 15. Privacy Considerations 757 Privacy-related considerations that apply to means to reveal a host 758 identified are discussed in [RFC6967]. This document does not 759 introduce additional privacy issues than those discussed in 760 [RFC6967]. 762 16. Security Considerations 764 This document does not define an architecture nor a protocol; as such 765 it does not raise any security concern. Host identifier related 766 security considerations are discussed in [RFC6967]. 768 17. IANA Considerations 770 This document does not require any action from IANA. 772 18. Acknowledgments 774 Many thanks to F. Klamm, D. Wing, and D. von Hugo for their review. 776 Figure 8 and part of the text in Section 9 are inspired from 777 [I-D.so-ipsecme-ikev2-cpext]. 779 19. Informative References 781 [I-D.ietf-softwire-lw4over6] 782 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 783 I. Farrer, "Lightweight 4over6: An Extension to the DS- 784 Lite Architecture", draft-ietf-softwire-lw4over6-08 (work 785 in progress), March 2014. 787 [I-D.ietf-softwire-map] 788 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 789 Murakami, T., and T. Taylor, "Mapping of Address and Port 790 with Encapsulation (MAP)", draft-ietf-softwire-map-10 791 (work in progress), January 2014. 793 [I-D.so-ipsecme-ikev2-cpext] 794 So, T., "IKEv2 Configuration Payload Extension for Private 795 IPv4 Support for Fixed Mobile Convergence", draft-so- 796 ipsecme-ikev2-cpext-02 (work in progress), June 2012. 798 [I-D.tsou-stateless-nat44] 799 Tsou, T., Liu, W., Perreault, S., Penno, R., and M. Chen, 800 "Stateless IPv4 Network Address Translation", draft-tsou- 801 stateless-nat44-02 (work in progress), October 2012. 803 [I-D.williams-overlaypath-ip-tcp-rfc] 804 Williams, B., "Overlay Path Option for IP and TCP", draft- 805 williams-overlaypath-ip-tcp-rfc-04 (work in progress), 806 June 2013. 808 [IEEE101109] 809 Salah, K., Calero, J., Zeadally, S., Almulla, S., and M. 810 ZAaabi, "Using Cloud Computing to Implement a Security 811 Overlay Network, IEEE Security & Privacy, 21 June 2012. 812 IEEE Computer Society Digital Library.", June 2012. 814 [IEEE1344002] 815 Byers, J., Considine, J., Mitzenmacher, M., and S. Rost, 816 "Informed content delivery across adaptive overlay 817 networks: IEEE/ACM Transactions on Networking, Vol 12, 818 Issue 5, ppg 767-780", October 2004. 820 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 821 for Policy-based Admission Control", RFC 2753, January 822 2000. 824 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 825 A., Peterson, J., Sparks, R., Handley, M., and E. 826 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 827 June 2002. 829 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 830 Host Configuration Protocol (DHCP) version 6", RFC 3633, 831 December 2003. 833 [RFC5456] Spencer, M., Capouch, B., Guy, E., Miller, F., and K. 834 Shumard, "IAX: Inter-Asterisk eXchange Version 2", RFC 835 5456, February 2010. 837 [RFC5694] Camarillo, G. and IAB, "Peer-to-Peer (P2P) Architecture: 838 Definition, Taxonomies, Examples, and Applicability", RFC 839 5694, November 2009. 841 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 842 NAT64: Network Address and Protocol Translation from IPv6 843 Clients to IPv4 Servers", RFC 6146, April 2011. 845 [RFC6179] Templin, F., "The Internet Routing Overlay Network 846 (IRON)", RFC 6179, March 2011. 848 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 849 Roberts, "Issues with IP Address Sharing", RFC 6269, June 850 2011. 852 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 853 Translation", RFC 6296, June 2011. 855 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 856 Stack Lite Broadband Deployments Following IPv4 857 Exhaustion", RFC 6333, August 2011. 859 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 860 IPv4 Address Shortage", RFC 6346, August 2011. 862 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 863 "Framework for Emergency Calling Using Internet 864 Multimedia", RFC 6443, December 2011. 866 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 867 and H. Ashida, "Common Requirements for Carrier-Grade NATs 868 (CGNs)", BCP 127, RFC 6888, April 2013. 870 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 871 "Analysis of Potential Solutions for Revealing a Host 872 Identifier (HOST_ID) in Shared Address Deployments", RFC 873 6967, June 2013. 875 [TS23.203] 876 3GPP, , "Policy and charging control architecture", 877 September 2012. 879 [TS29.212] 880 3GPP, , "Policy and Charging Control (PCC); Reference 881 Points", December 2013. 883 Authors' Addresses 885 Mohamed Boucadair (editor) 886 France Telecom 887 Rennes 35000 888 France 890 Email: mohamed.boucadair@orange.com 892 David Binet 893 France Telecom 894 Rennes 895 France 897 Email: david.binet@orange.com 899 Sophie Durel 900 France Telecom 901 Rennes 902 France 904 Email: sophie.durel@orange.com 905 Bruno Chatras 906 France Telecom 907 Paris 908 France 910 Email: bruno.chatras@orange.com 912 Tirumaleswar Reddy 913 Cisco Systems, Inc. 914 Cessna Business Park, Varthur Hobli 915 Sarjapur Marathalli Outer Ring Road 916 Bangalore, Karnataka 560103 917 India 919 Email: tireddy@cisco.com 921 Brandon Williams 922 Akamai, Inc. 923 Cambridge MA 924 USA 926 Email: brandon.williams@akamai.com 928 Behcet Sarikaya 929 Huawei 930 5340 Legacy Dr. Building 3, 931 Plano, TX 75024 932 USA 934 Email: behcet.sarikaya@huawei.com 936 Li Xue 937 Huawei 938 Beijing 939 China 941 Email: xueli@huawei.com