idnits 2.17.1 draft-boucadair-intarea-host-identifier-scenarios-03.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 17 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 549: '...REQ#1: HOST_ID MUST be set by a trus...' RFC 2119 keyword, line 550: '... HOST_ID MUST be able to valid...' RFC 2119 keyword, line 551: '...evice. Receiver MUST detect HOST_ID s...' RFC 2119 keyword, line 555: '...t generates HOST_ID MUST strip HOST_ID...' RFC 2119 keyword, line 559: '...ces policy based on HOST_ID MUST strip...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2013) is 4054 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.cui-softwire-b4-translated-ds-lite' is defined on line 653, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-intarea-nat-reveal-analysis-06 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-04 == Outdated reference: A later version (-04) exists of draft-williams-overlaypath-ip-tcp-rfc-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA Working Group M. Boucadair, Ed. 3 Internet-Draft D. Binet 4 Intended status: Informational S. Durel 5 Expires: September 15, 2013 B. Chatras 6 France Telecom 7 T. Reddy 8 Cisco 9 B. Williams 10 Akamai, Inc. 11 March 14, 2013 13 Host Identification: Use Cases 14 draft-boucadair-intarea-host-identifier-scenarios-03 16 Abstract 18 This document describes a set of scenarios in which host 19 identification is required. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 15, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Use Case 1: CGN . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Use Case 2: A+P . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. Use Case 3: Application Proxies . . . . . . . . . . . . . 5 61 3.4. Use Case 4: Open Wi-Fi or Provider Wi-Fi . . . . . . . . 6 62 3.5. Use Case 5: Policy and Charging Control Architecture . . 7 63 3.6. Use Case 6: Cellular Networks . . . . . . . . . . . . . . 8 64 3.7. Use Case 7: Femtocells . . . . . . . . . . . . . . . . . 8 65 3.8. Use Case 8: Overlay Network . . . . . . . . . . . . . . . 10 66 3.9. Use Case 9: Emergency Calls . . . . . . . . . . . . . . . 11 67 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.1. HOST_ID Requirements . . . . . . . . . . . . . . . . . . 12 69 4.2. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . 14 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 73 8. Informative References . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 The ultimate goal of this document is to enumerate scenarios which 79 encounter the issue of uniquely identifying a host among those 80 sharing the same IP address. Examples of encountered issues are: 82 o Blacklist a misbehaving host without impacting all hosts sharing 83 the same IP address. 84 o Enforce a per-subscriber/per-UE policy (e.g., limit access to the 85 service based on some counters such as volume-based service 86 offering); enforcing the policy will have impact on all hosts 87 sharing the same IP address. 88 o If invoking a service has failed (e.g., wrong login/passwd), all 89 hosts sharing the same IP address may not be able to access that 90 service. 91 o Need to correlate between the internal address:port and external 92 address:port to generate and therefore to enforce policies. 94 It is out of scope of this document to list all the encountered 95 issues as this is already covered in [RFC6269]. 97 The generic concept of host identifier, denoted as HOST_ID, is 98 defined in [I-D.ietf-intarea-nat-reveal-analysis]. 100 The analysis of the use cases listed in this document indicates two 101 root causes for the host identification issue: 103 1. Presence of address sharing (NAT, A+P, application proxies, 104 etc.). 105 2. Use of tunnels between two administrative domains. 106 3. Combination of NAT and presence of tunnels in the path. 108 The following use cases are identified so far: 110 (1) Section 3.1: Carrier Grade NAT (CGN) 111 (2) Section 3.2: A+P (e.g., MAP ) 112 (3) Section 3.3: Application Proxies 113 (4) Section 3.4: Provider Wi-Fi 114 (5) Section 3.5: Policy and Charging Architectures 115 (6) Section 3.6: Cellular Networks 116 (7) Section 3.7: Femtocells 117 (8) Section 3.8: Overlay Networks (e.g., CDNs) 118 (9) Section 3.9: Emergency Calls 120 2. Scope 122 It is out of scope of this document to argue in favor or against the 123 use cases listed in the following sub-sections. The goal is to 124 identify scenarios the authors are aware of and which share the same 125 issue of host identification. 127 This document does not include any solution-specific discussion. 128 This document can be used as a tool to design solution(s) mitigating 129 the encountered issues. Having a generic solution which would solve 130 the issues encountered in these use cases is preferred over designing 131 a solution for each use case. Describing the use case allows to 132 identify what is common between the use cases and then would help 133 during the solution design phase. 135 The first version of the document does not elaborate whether explicit 136 authentication is enabled or not. 138 3. Use Cases 139 3.1. Use Case 1: CGN 141 Several flavors of stateful CGN have been defined. A non-exhaustive 142 list is provided below: 144 1. NAT44 ( [I-D.ietf-behave-lsn-requirements], 145 [I-D.tsou-stateless-nat44]) 147 2. DS-Lite NAT44 [RFC6333] 149 3. NAT64 [RFC6146] 151 4. NPTv6 [RFC6296] 153 As discussed in [I-D.ietf-intarea-nat-reveal-analysis], remote 154 servers are not able to distinguish between hosts sharing the same IP 155 address (Figure 1). 157 +-----------+ 158 | HOST_1 |----+ 159 +-----------+ | +--------------------+ +------------+ 160 | | |------| server 1 | 161 +-----------+ +-----+ | | +------------+ 162 | HOST_2 |--| CGN |----| INTERNET | :: 163 +-----------+ +-----+ | | +------------+ 164 | | |------| server n | 165 +-----------+ | +--------------------+ +------------+ 166 | HOST_3 |-----+ 167 +-----------+ 169 Figure 1: CGN: Architecture Example 171 3.2. Use Case 2: A+P 173 A+P [RFC6346][I-D.ietf-softwire-map][I-D.cui-softwire-b4-translated- 174 ds-lite] denotes a flavor of address sharing solutions which does not 175 require any additional NAT function be enabled in the service 176 provider's network. A+P assumes subscribers are assigned with the 177 same IPv4 address together with a port set. Subscribers assigned 178 with the same IPv4 address should be assigned non overlapping port 179 sets. Devices connected to an A+P-enabled network should be able to 180 restrict the IPv4 source port to be within a configure range of 181 ports. To forward incoming packets to the appropriate host, a 182 dedicated entity called PRR (Port Range Router, [RFC6346]) is needed 183 (Figure 2). 185 Similar to the CGN case, the same issue to identify hosts sharing the 186 same IP address is encountered by remote servers. 188 +-----------+ 189 | HOST_1 |----+ 190 +-----------+ | +--------------------+ +------------+ 191 | | |------| server 1 | 192 +-----------+ +-----+ | | +------------+ 193 | HOST_2 |--| PRR |----| INTERNET | :: 194 +-----------+ +-----+ | | +------------+ 195 | | |------| server n | 196 +-----------+ | +--------------------+ +------------+ 197 | HOST_3 |-----+ 198 +-----------+ 200 Figure 2: A+P: Architecture Example 202 3.3. Use Case 3: Application Proxies 204 This scenario is similar to the CGN scenario. Remote servers are not 205 able to distinguish hosts located behind the PROXY. Applying 206 policies on the perceived external IP address as received from the 207 PROXY will impact all hosts connected to that PROXY. 209 Figure 3 illustrates a simple configuration involving a proxy. Note 210 several (per-application) proxies may be deployed. 212 +-----------+ 213 | HOST_1 |----+ 214 +-----------+ | +--------------------+ +------------+ 215 | | |------| server 1 | 216 +-----------+ +-----+ | | +------------+ 217 | HOST_2 |--|PROXY|----| INTERNET | :: 218 +-----------+ +-----+ | | +------------+ 219 | | |------| server n | 220 +-----------+ | +--------------------+ +------------+ 221 | HOST_3 |-----+ 222 +-----------+ 224 Figure 3: Proxy: Overview 226 3.4. Use Case 4: Open Wi-Fi or Provider Wi-Fi 228 In the context of Provider Wi-Fi, a dedicated SSID can be configured 229 and advertised by the RG (Residential Gateway) for visiting 230 terminals. These visiting terminals can be mobile terminals, PCs, 231 etc. 233 Several deployment scenarios are envisaged: 235 1. Deploy a dedicated node in the service provider's network which 236 will be responsible to intercept all the traffic issued from 237 visiting terminals (see Figure 4). This node may be co-located 238 with a CGN function if private IPv4 addresses are assigned to 239 visiting terminals. Similar to the CGN case discussed in 240 Section 3.1, remote servers may not be able to distinguish 241 visiting hosts sharing the same IP address (see [RFC6269]). 243 2. Unlike the previous deployment scenario, IPv4 addresses are 244 managed by the RG without requiring any additional NAT to be 245 deployed in the service provider's network for handling traffic 246 issued from visiting terminals. Concretely, a visiting terminal 247 is assigned with a private IPv4 address from the pool managed by 248 the RG. Packets issued form a visiting terminal are translated 249 using the public IP address assigned to the RG (see Figure 5). 250 This deployment scenario induces the following identification 251 concerns: 253 * The provider is not able to distinguish the traffic belonging 254 to the visiting terminal from the traffic of the subscriber 255 owning the RG. This is needed to apply some policies such as: 256 accounting, DSCP remarking, black list, etc. 258 * Similar to the CGN case Section 3.1, a misbehaving visiting 259 terminal is likely to have some impact on the experienced 260 service by the customer owning the RG (e.g., some of the 261 issues are discussed in [RFC6269]). 263 +-------------+ 264 |Local_HOST_1 |----+ 265 +-------------+ | 266 | | 267 +-------------+ +-----+ | +-----------+ 268 |Local_HOST_2 |--| RG |-|--|Border Node| 269 +-------------+ +-----+ | +----NAT----+ 270 | | 271 +-------------+ | | Service Provider 272 |Visiting Host|-----+ 273 +-------------+ 275 Figure 4: NAT enforced in a Service Provider's Node 277 +-------------+ 278 |Local_HOST_1 |----+ 279 +-------------+ | 280 | | 281 +-------------+ +-----+ | +-----------+ 282 |Local_HOST_2 |--| RG |-|--|Border Node| 283 +-------------+ +-NAT-+ | +-----------+ 284 | | 285 +-------------+ | | Service Provider 286 |Visiting Host|-----+ 287 +-------------+ 289 Figure 5: NAT located in the RG 291 3.5. Use Case 5: Policy and Charging Control Architecture 293 This issue is related to the framework defined in [TS.23203] when a 294 NAT is located between the PCEF (Policy and Charging Enforcement 295 Function) and the AF (Application Function) as shown in Figure 6. 297 The main issue is: PCEF, PCRF and AF all receive information bound to 298 the same UE but without being able to correlate between the piece of 299 data visible for each entity. Concretely, 301 o PCEF is aware of the IMSI (International Mobile Subscriber 302 Identity) and an internal IP address assigned to the UE. 304 o AF receives an external IP address and port as assigned by the NAT 305 function. 307 o PCRF is not able to correlate between the external IP address/port 308 assigned by the NAT and the internal IP address and IMSI of the 309 UE. 311 +------+ 312 | PCRF |-----------------+ 313 +------+ | 314 | | 315 +----+ +------+ +-----+ +-----+ 316 | UE |------| PCEF |---| NAT |----| AF | 317 +----+ +------+ +-----+ +-----+ 319 Figure 6 321 This scenario can be generalized as follows (Figure 7): 323 o Policy Enforcement Point (PEP, [RFC2753]) 325 o Policy Decision Point (PDP, [RFC2753]) 327 +------+ 328 | PDP |-----------------+ 329 +------+ | 330 | | 331 +----+ +------+ +-----+ +------+ 332 |Host|------| PEP |---| NAT |----|Server| 333 +----+ +------+ +-----+ +------+ 335 Figure 7 337 A similar issue is encountered when the NAT is located before the PEP 338 function (see Figure 8): 340 +------+ 341 | PDP |------+ 342 +------+ | 343 | | 344 +----+ +------+ +-----+ +------+ 345 |Host|------| NAT |---| PEP |----|Server| 346 +----+ +------+ +-----+ +------+ 348 Figure 8 350 3.6. Use Case 6: Cellular Networks 352 Cellular operators allocate private IPv4 addresses to mobile 353 customers and deploy NAT44 function, generally co-located with 354 firewalls, to access to public IP services. The NAT function is 355 located at the boundaries of the PLMN. IPv6-only strategy, 356 consisting in allocating IPv6 prefixes only to customers, is 357 considered by various operators. A NAT64 function is also considered 358 in order to preserve IPv4 service continuity for these customers. 360 These NAT44 and NAT64 functions bring some issues very similar to 361 those mentioned in Figure 1 and Section 3.5. This issue is 362 particularly encountered if policies are to be applied on the Gi 363 interface: a private IP address may be assigned to several UEs, no 364 correlation between the internal IP address and the address:port 365 assigned by the NAT function, etc. 367 3.7. Use Case 7: Femtocells 368 This issue is discussed in [I-D.so-ipsecme-ikev2-cpext]. This use 369 case can be seen as a combination of the use cases described in 370 Section 3.4 and Section 3.5. 372 The reference architecture, originally provided in 373 [I-D.so-ipsecme-ikev2-cpext], is shown in Figure 8. 375 +---------------------------+ 376 | +----+ +--------+ +----+ | +-----------+ +-------------------+ 377 | | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ | 378 | +----+ | alone | | RG | | | | | | | | | Mobile | 379 | | FAP | +----+ | | | | |S | |F | Network| 380 | +--------+ (NAPT) | | Broadband | | |e | |A | | 381 +---------------------------+ | Fixed | | |G |-|P | +-----+| 382 | Network | | |W | |G |-| Core|| 383 +---------------------------+ | (BBF) | | | | |W | | Ntwk|| 384 | +----+ +------------+ | | | | | | | | +-----+| 385 | | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ | 386 | +----+ | FAP (NAPT) | | +-----------+ +-------------------+ 387 | +------------+ | 388 +---------------------------+ 390 <=====> IPsec tunnel 391 CoreNtwk Core Network 392 FAPGW FAP Gateway 393 SeGW Security Gateway 395 Figure 9: Femtocell: Overall Architecture 397 UE is connected to the FAP at the residential gateway (RG), routed 398 back to 3GPP Evolved Packet Core (EPC). UE is assigned IPv4 address 399 by the Mobile Network. Mobile operator's FAP leverages the IPSec 400 IKEv2 to interconnect FAP with the SeGW over the BBF network. Both 401 the FAP and the SeGW are managed by the mobile operator which may be 402 a different operator for the BBF network. 404 An investigated scenario is the mobile network to pass on its mobile 405 subscriber's policies to the BBF to support remote network 406 management. But most of today's broadband fixed networks are relying 407 on the private IPv4 addressing plan (+NAPT) to support its attached 408 devices including the mobile operator's FAP. In this scenario, the 409 mobile network needs to: 411 o determine the FAP's public IPv4 address to identify the location 412 of the FAP to ensure its legitimacy to operate on the license 413 spectrum for a given mobile operator prior to the FAP be ready to 414 serve its mobile devices. 416 o determine the FAP's pubic IPv4 address together with the 417 translated port number of the UDP header of the encapsulated IPsec 418 tunnel for identifying the UE's traffic at the fixed broadband 419 network. 421 o determine the corresponding FAP's public IPv4 address associated 422 with the UE's inner-IPv4 address which is assigned by the mobile 423 network to identify the mobile UE to allow the PCRF to retrieve 424 the UE's policy (e.g., QoS) to be passed onto the Broadband Policy 425 Control Function (BPCF) at the BBF network. 427 SecGW would have the complete knowledge of such mapping, but the 428 reasons for unable to use SecGW for this purpose is explained in 429 "Problem Statements" (section 2 of [I-D.so-ipsecme-ikev2-cpext]). 431 This use case makes use of PCRF/BPCF but it is valid in other 432 deployment scenarios making use of AAA servers. 434 The issue of correlating the internal IP address and the public IP 435 address is valid even if there is no NAT in the path. 437 3.8. Use Case 8: Overlay Network 439 An overlay network is a network of machines distributed throughout 440 multiple autonomous systems within the public Internet that can be 441 used to improve the performance of data transport (see Figure 10). 442 IP packets from the sender are delivered first to one of the machines 443 that make up the overlay network. That machine then relays the IP 444 packets to the receiver via one or more machines in the overlay 445 network, applying various performance enhancement methods. 447 +------------------------------------+ 448 | | 449 | INTERNET | 450 | | 451 +-----------+ | +------------+ | 452 | HOST_1 |-----| OVRLY_IN_1 |-----------+ | 453 +-----------+ | +------------+ | | 454 | | | 455 +-----------+ | +------------+ +-----------+ | +--------+ 456 | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | 457 +-----------+ | +------------+ +-----------+ | +--------+ 458 | | | 459 +-----------+ | +------------+ | | 460 | HOST_3 |-----| OVRLY_IN_3 |-----------+ | 461 +-----------+ | +------------+ | 462 | | 463 +------------------------------------+ 464 Figure 10: Overlay Network 466 Data transport using an overlay network requires network address 467 translation for both the source and destination addresses in such a 468 way that the public IP addresses of the true endpoint machines 469 involved in data transport are invisible to each other (see Figure 470 11). In other words, the true sender and receiver use two completely 471 different pairs of source and destination addresses to identify the 472 connection on the sending and receiving networks. 474 ip hdr contains: ip hdr contains: 475 SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER 476 dst = overlay1 dst = receiver 478 Figure 11: NAT operations in an Overlay Network 480 This scenario is similar to the CGN (Section 3.1) and proxy 481 (Section 3.3) scenarios. The remote server is not able to 482 distinguish among hosts using the overlay for transport. In 483 addition, the remote server is not able to determine the overlay 484 ingress point being used by the host, which can be useful for 485 diagnosing host connectivity issues. 487 More details about this use case are provided in 488 [I-D.williams-overlaypath-ip-tcp-rfc]. 490 3.9. Use Case 9: Emergency Calls 492 Voice service providers (VSPs) operating under certain jurisdictions 493 are required to route emergency calls from their subscribers and have 494 to include information about the caller's location in signaling 495 messages they send towards PSAPs (Public Safety Answering Points, 496 [RFC6443]), via an Emergency Service Routing Proxy (ESRP, [RFC6443]). 497 This information is used both for the determination of the correct 498 PSAP and to reveal the caller's location to the selected PSAP. 500 In many countries, regulation bodies require that this information be 501 provided by the network rather than the user equipment, in which case 502 the VSP needs to retrieve this information (by reference or by value) 503 from the access network where the caller is attached. 505 This requires the VSP call server receiving an emergency call request 506 to identify the relevant access network and to query a Location 507 Information Server (LIS) in this network using a suitable look-up 508 key. In the simplest case, the source IP address of the IP packet 509 carrying the call request is used both for identifying the access 510 network (thanks to a reverse DNS query) and as a look-up key to query 511 the LIS. Obviously the user-id as known by the VSP (e.g., telephone 512 number, or email-formatted URI) can't be used as it is not known by 513 the access network. 515 The above mechanism is broken when there is a NAT between the user 516 and the VSP or if the emergency call is established over a VPN tunnel 517 (e.g., an employee remotely connected to a company VoIP server 518 through a tunnel wishes to make an emergency call). In such cases, 519 the source IP address received by the VSP call server will identity 520 the NAT or the address assigned to the caller equipment by the VSP 521 (i.e., the address inside the tunnel). 523 Therefore, the VSP needs to receive an additional piece of 524 information that can be used to both identify the access network 525 where the caller is attached and query the LIS for his/her location. 526 This would require the NAT or the Tunnel Endpoint to insert this 527 extra information in the call requests delivered to the VSP call 528 servers. For example, this extra information could be a combination 529 of the local IP address assigned by the access network to the 530 caller's equipment with some form of identification of this access 531 network. 533 However, because it shall be possible to setup an emergency call 534 regardless of the actual call control protocol used between the user 535 and the VSP (e.g., SIP [RFC3261], IAX [RFC5456], tunneled over HTTP, 536 or proprietary protocol, possibly encrypted), this extra information 537 has to be conveyed outside the call request, in the header of lower 538 layers protocols. 540 4. Discussion 542 This section is to be completed. 544 4.1. HOST_ID Requirements 546 Below is listed as set of requirements to be used to characterize 547 each use case (discussed in Section 3): 549 REQ#1: HOST_ID MUST be set by a trusted device. Receiver using 550 HOST_ID MUST be able to validate that HOST_ID is set by a 551 trusted device. Receiver MUST detect HOST_ID set by rogue 552 devices and discard HOST_ID (i.e. not use HOST_ID for 553 policy enforcement). 555 REQ#2: Trusted Device that generates HOST_ID MUST strip HOST_ID 556 received from the host or HOST_ID set by any other 557 downstream devices. 559 REQ#3: Receiver that enforces policy based on HOST_ID MUST strip 560 HOST_ID before sending it upstream 562 REQ#4: Host SHOULD be permitted to set HOST_ID 564 REQ#5: HOST_ID MUST be provided in all the IP packets 566 REQ#6: HOST_ID MUST be provided in-line (i.e. Multiplexed) with 567 the transport protocol 569 REQ#7: HOST_ID MUST be provided using out-of-band mechanism 571 REQ#8: HOST_ID MUST be provided either using in-line or out-of-band 572 mechanism 574 REQ#9: HOST_ID MUST be encrypted so that other devices cannot glean 575 the HOST_ID information, that could result in identity 576 leakage. 578 REQ#10: HOST_ID MUST be conveyed for consumption within a single 579 administrative domain. 581 REQ#11: HOST_ID MUST be conveyed across multiple administrative 582 domain. In other words, the producer and consumer of 583 HOST_ID are in different administrative domains. 585 REQ#12: Connection-oriented protocols (e.g., TCP or SCTP) MUST 586 convey HOST_ID. 588 REQ#13: Connection-less protocols (e.g., UDP) MUST convey HOST_ID. 590 REQ#14: The entire IPv6/IPv4 address MUST be conveyed in the HOST_ID 592 REQ#15: 16-bit value representing a host hint is sufficient to be 593 conveyed in the HOST_ID 595 REQ#16: HOST_ID propagation MUST be supported for IPv4-only. 597 REQ#17: HOST_ID propagation MUST be supported for IPv4 and IPv6. 599 REQ#18: Receiver MUST use HOST_ID to enforce policies like QoS. 601 REQ#19: Receiver uses HOST_ID only for Accounting and debugging 602 purposes. 604 Once this list is stabilized, each use case will be checked against 605 these requirements. 607 4.2. Synthesis 609 The following table shows whether each use case is valid for IPv4/ 610 IPv6 and if it is to be applied within one single administrative 611 domain or not. This table will be completed. 613 +-------------------+------+-------------+-----------------------+ 614 | Use Case | IPv4 | IPv6 | Single Administrative | 615 | | |------+------| Domain | 616 | | |Client|Server| | 617 +-------------------+------+------+------+-----------------------+ 618 | CGN | Yes |Yes(1)| No | No | 619 | A+P | Yes | No | No | No | 620 | Application Proxy | Yes |Yes(2)|Yes(2)| No | 621 | Provider Wi-Fi | Yes | No | No | Yes | 622 | PCC | Yes |Yes(1)| No | Yes | 623 | Femtocells | Yes | No | No | No | 624 | Cellular Networks | Yes |Yes(1)| No | Yes | 625 | Overlay Networks | Yes |Yes(3)|Yes(3)| No | 626 | Emergency Calls | Yes | Yes | Yes | No | 627 +-------------------+------+------+------------------------------+ 629 Notes: 630 (1) e.g., NAT64 631 (2) A proxy can use IPv6 for the communication leg with the server 632 or the application client. 633 (3) This use case is a combination of CGN and Application Proxies. 635 5. Security Considerations 637 This document does not define an architecture nor a protocol; as such 638 it does not raise any security concern. 640 6. IANA Considerations 642 This document does not require any action from IANA. 644 7. Acknowledgments 646 Many thanks to F. Klamm for the review. 648 Figure 8 and part of the text in Section 3.7 are inspired from 649 [I-D.so-ipsecme-ikev2-cpext]. 651 8. Informative References 653 [I-D.cui-softwire-b4-translated-ds-lite] 654 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 655 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 656 Architecture", draft-cui-softwire-b4-translated-ds-lite-11 657 (work in progress), February 2013. 659 [I-D.ietf-behave-lsn-requirements] 660 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 661 and H. Ashida, "Common requirements for Carrier Grade NATs 662 (CGNs)", draft-ietf-behave-lsn-requirements-10 (work in 663 progress), December 2012. 665 [I-D.ietf-intarea-nat-reveal-analysis] 666 Boucadair, M., Touch, J., Levis, P., and R. Penno, 667 "Analysis of Solution Candidates to Reveal a Host 668 Identifier (HOST_ID) in Shared Address Deployments", 669 draft-ietf-intarea-nat-reveal-analysis-06 (work in 670 progress), March 2013. 672 [I-D.ietf-softwire-map] 673 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., and 674 T. Murakami, "Mapping of Address and Port with 675 Encapsulation (MAP)", draft-ietf-softwire-map-04 (work in 676 progress), February 2013. 678 [I-D.so-ipsecme-ikev2-cpext] 679 So, T., "IKEv2 Configuration Payload Extension for Private 680 IPv4 Support for Fixed Mobile Convergence", draft-so- 681 ipsecme-ikev2-cpext-02 (work in progress), June 2012. 683 [I-D.tsou-stateless-nat44] 684 Tsou, T., Liu, W., Perreault, S., Penno, R., and M. Chen, 685 "Stateless IPv4 Network Address Translation", draft-tsou- 686 stateless-nat44-02 (work in progress), October 2012. 688 [I-D.williams-overlaypath-ip-tcp-rfc] 689 Williams, B., "Overlay Path Option for IP and TCP", draft- 690 williams-overlaypath-ip-tcp-rfc-03 (work in progress), 691 December 2012. 693 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 694 for Policy-based Admission Control", RFC 2753, January 695 2000. 697 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 698 A., Peterson, J., Sparks, R., Handley, M., and E. 699 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 700 June 2002. 702 [RFC5456] Spencer, M., Capouch, B., Guy, E., Miller, F., and K. 703 Shumard, "IAX: Inter-Asterisk eXchange Version 2", RFC 704 5456, February 2010. 706 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 707 NAT64: Network Address and Protocol Translation from IPv6 708 Clients to IPv4 Servers", RFC 6146, April 2011. 710 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 711 Roberts, "Issues with IP Address Sharing", RFC 6269, June 712 2011. 714 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 715 Translation", RFC 6296, June 2011. 717 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 718 Stack Lite Broadband Deployments Following IPv4 719 Exhaustion", RFC 6333, August 2011. 721 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 722 IPv4 Address Shortage", RFC 6346, August 2011. 724 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 725 "Framework for Emergency Calling Using Internet 726 Multimedia", RFC 6443, December 2011. 728 [TS.23203] 729 3GPP, , "Policy and charging control architecture", 730 September 2012. 732 Authors' Addresses 734 Mohamed Boucadair (editor) 735 France Telecom 736 Rennes 35000 737 France 739 Email: mohamed.boucadair@orange.com 741 David Binet 742 France Telecom 743 Rennes 744 France 746 Email: david.binet@orange.com 747 Sophie Durel 748 France Telecom 749 Rennes 750 France 752 Email: sophie.durel@orange.com 754 Bruno Chatras 755 France Telecom 756 Paris 757 France 759 Email: bruno.chatras@orange.com 761 Tirumaleswar Reddy 762 Cisco Systems, Inc. 763 Cessna Business Park, Varthur Hobli 764 Sarjapur Marathalli Outer Ring Road 765 Bangalore, Karnataka 560103 766 India 768 Email: tireddy@cisco.com 770 Brandon Williams 771 Akamai, Inc. 772 Cambridge MA 773 USA 775 Email: brandon.williams@akamai.com