idnits 2.17.00 (12 Aug 2021) /tmp/idnits57374/draft-boucadair-pcp-nat-reveal-01.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 28 instances of too long lines in the document, the longest one being 1 character in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 28, 2013) is 3273 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-boucadair-intarea-host-identifier-scenarios has been published as RFC 7620 == Outdated reference: draft-ietf-intarea-nat-reveal-analysis has been published as RFC 6967 == Outdated reference: draft-ietf-pcp-authentication has been published as RFC 7652 -- Obsolete informational reference (is this intentional?): RFC 6342 (Obsoleted by RFC 6342) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track T. Reddy 5 Expires: November 29, 2013 P. Patil 6 D. Wing 7 Cisco 8 May 28, 2013 10 Using PCP to Reveal a Host behind NAT 11 draft-boucadair-pcp-nat-reveal-01 13 Abstract 15 This document describes how to use PCP to retrieve the identity of a 16 host behind a NAT. Two use cases are discussed and the PCP 17 applicability is analyzed. This document extends PCP with a new 18 OpCode called QUERY Opcode. 20 The proposed mechanism is valid for all NAT flavors including NAT44, 21 NAT64 or NPTv6. 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 November 29, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language and Terminology . . . . . . . . . . . . 3 59 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Policy and Charging Control Architecture . . . . . . . . 3 61 3.2. NAT between the PCEF and AF . . . . . . . . . . . . . . . 4 62 3.3. NAT before PCEF . . . . . . . . . . . . . . . . . . . . . 5 63 4. PCP Applicability . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. NAT between the PCEF and AF . . . . . . . . . . . . . . . 6 65 4.2. NAT before PCEF . . . . . . . . . . . . . . . . . . . . . 7 66 5. QUERY OpCode . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. QUERY Request Format . . . . . . . . . . . . . . . . . . 9 68 5.2. QUERY Response Format . . . . . . . . . . . . . . . . . . 10 69 5.3. Generating a QUERY Request . . . . . . . . . . . . . . . 11 70 5.4. Processing a QUERY Request . . . . . . . . . . . . . . . 12 71 5.5. Processing a QUERY Response . . . . . . . . . . . . . . . 13 72 6. Applicability Scope of QUERY OpCode . . . . . . . . . . . . . 13 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 9.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 As reported in [RFC6269], several issues are encountered when an IP 83 address is shared among several subscribers. These issues are 84 encountered in various deployment contexts: e.g., Carrier Grade NAT 85 (CGN), application proxies or A+P [RFC6346]. 87 This document extends Port Control Protocol [RFC6887] to identify a 88 host among those sharing the same IP address in certain scenarios. 90 The proposed technique can be used independently or combined with the 91 host identifier, denoted as HOST_ID defined in 92 [I-D.ietf-intarea-nat-reveal-analysis]. 94 Additional scenarios requiring host identification are listed in 95 [I-D.boucadair-intarea-host-identifier-scenarios]. 97 2. Requirements Language and Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 This note uses terminology defined in [RFC6887]. 105 3. Problem Space 107 3.1. Policy and Charging Control Architecture 109 Figure 1 depicts a reference architecture of a mobile network 110 [RFC6342]. 112 +-----+ +-----+ 113 | AAA | | PCRF| 114 +-----+ +-----+ 115 \ / 116 \ / /- 117 \ / / I 118 UE BS \ / / n 119 | /\ +-----+ /-----------\ +-----+ /-----------\ +----+ / t 120 +-+ /_ \---| ANG |/ Operator's \| PCEF|/ Operator's \| BR |/ e 121 | |---/ \ +-----+\ IP Network /+-----+\ IP Network /+----+\ r 122 +-+ \-----------/ \-----------/ \ n 123 \ e 124 \ t 125 +-----+ 126 | AF | 127 +-----+ 129 Figure 1: Mobile Network Archtecture 131 The main involved functional elements are: 133 o UE (User Equipment) is a mobile node. 135 o Policy and Charging Rule Function (PCRF) which is responsible for 136 determining which policy and charging control rules are to be 137 applied [TS.23203]. 139 o Policy and Charging Enforcement Function (PCEF) which performs 140 policy enforcement (e.g., Quality of Service (QoS)) and flow-based 141 charging [TS.23203]. 143 o Application Function (AF) is an element offering applications that 144 require dynamic policy and/or charging control [TS.23203]. 146 o Access Network Gateway (ANG), Base Station (BS) and Border Router 147 (BR) are defined in [RFC6342]. 149 Section 3.2 and Section 3.3 explain the encountered problems to 150 identify individual UEs when a NAT is involved in the data path. The 151 use of PCP to solve those problems is analyzed in Section 4. 153 3.2. NAT between the PCEF and AF 155 Figure 2 shows a scenario where a NAT function is located between the 156 PCEF and AF. 158 +------------------------------------+ 159 | | 160 | +------+ | 161 | | PCRF |-----------------+ | 162 | +------+ | | 163 | | | | 164 +----+ | +------+ +-----+ +------+ | 165 |Host|-|----| PCEF |---| NAT |----| AF | | 166 +----+ | +------+ +-----+ +------+ | 167 | | 168 | | 169 +------------------------------------+ 170 Single Administrative Domain 172 Figure 2: NAT between PCEF and AF 174 The main issue in this case is that PCEF, PCRF and AF all receive 175 information bound to the same UE but cannot correlate between the 176 piece of data visible for each entity. Concretely, 178 o PCEF is aware of the IMSI (International Mobile Subscriber 179 Identity) and an internal IP address assigned to the UE. 181 o AF receives an external IP address and port as assigned by the NAT 182 function. 184 o PCRF is not able to correlate between the external IP address/port 185 assigned by the NAT and the internal IP address and IMSI of the 186 UE. For instance, the offered QoS on internal IPv4 address and 187 the (shared) external IPv4 address may need to be correlated for 188 accounting purposes. 190 o The IP address seen by the AF is shared among multiple UEs using 191 NAT, the PCRF needs to be able to inspect the NAT binding to 192 disambiguate among the individual UEs. AF will not be able to 193 treat UE traffic based on policy provided by PCRF. 195 This scenario can be generalized as follows (Figure 3): 197 o Policy Enforcement Point (PEP, [RFC2753]) 199 o Policy Decision Point (PDP, [RFC2753]) 201 +------------------------------------+ 202 | | 203 | +------+ | 204 | | PDP |-----------------+ | 205 | +------+ | | 206 | | | | 207 +----+ | +------+ +-----+ +------+ | 208 |Host|-|----| PEP |---| NAT |----|Server| | 209 +----+ | +------+ +-----+ +------+ | 210 | | 211 | | 212 +------------------------------------+ 213 Single Administrative Domain 215 Figure 3: NAT between PEP and Server 217 3.3. NAT before PCEF 219 Figure 4 shows an alternative scenario in which a NAT function is 220 located before PCEF. The main issue is that PCEF and AF are only 221 aware of the external IP address and the external port number 222 assigned by the NAT function. PCEF/AF will fail to identify each UE 223 behind NAT since multiple UEs share the same external IP address and 224 thus are unable to treat incoming connections differently. 226 +------------------------------------+ 227 | | 228 | +-------+ | 229 | | PCRF |------+ | 230 | +-------+ | | 231 | | | | 232 +----+ | +------+ +-----+ +-----+ | 233 | UE |-|----| NAT |---|PCEF |----| AF | | 234 +----+ | +------+ +-----+ +-----+ | 235 | | 236 | | 237 +------------------------------------+ 238 Single Administrative Domain 240 Figure 4: NAT before PCEF 242 This scenario can be generalized as follows (Figure 5): 244 +------------------------------------+ 245 | | 246 | +-------+ | 247 | | PDP |------+ | 248 | +-------+ | | 249 | | | | 250 +----+ | +------+ +-----+ +------+ | 251 | UE |-|----| NAT |---| PEP |----|Server| | 252 +----+ | +------+ +-----+ +------+ | 253 | | 254 | | 255 +------------------------------------+ 256 Single Administrative Domain 258 Figure 5: NAT before PEP 260 4. PCP Applicability 262 This section discusses how PCP can be used to solve the problems 263 described in Section 3.2 and Section 3.3. 265 4.1. NAT between the PCEF and AF 267 A solution to solve the problem discussed in Section 3.2 is to enable 268 a PCP Server to control the NAT and enable a PCP Client in the PCRF 269 (see Figure 6). 271 +------------------------------------+ 272 | PCP Client | 273 | +------+ | 274 | | PCRF |-----------------+ | 275 | +------+ | | 276 | | | | 277 +----+ | +------+ +-----+ +------+ | 278 |Host|-|----| PCEF |---| NAT |----| AF | | 279 +----+ | +------+ +-----+ +------+ | 280 | PCP-enabled | 281 | | 282 +------------------------------------+ 283 Single Administrative Domain 285 Figure 6: NAT between PCEF and AF 287 The updated interaction between PCRF, PCEF and AF is detailed below. 289 o The PCP server controlling the NAT is configured to accept PCP 290 requests with THIRD_PARTY Option from authorized PCP clients 291 (i.e., PCRF). 293 o PCRF is configured with the IP address of the PCP Server. 295 o The PCRF is aware of the following 5-tuple of each flow {Internal 296 IP address of UE, Internal Port, Protocol, Remote Peer IP address, 297 Remote Port number} learnt from PCEF. PCRF is also aware of the 298 following 5-tuple of each flow {External IP address, External 299 Port, Protocol, Remote Peer IP address, Remote Port number} learnt 300 from AF. 302 o The PCRF generates PCP PEER request with THIRD_PARTY option which 303 has Internal IP Address set to the UE's Internal IP address 304 provided by the PCEF. 306 * The Internal Port, Protocol, Remote Peer Port, Remote Peer IP 307 Address fields of the PEER request are set by the PCRF 308 according to the 5-tuple flow information provided by PCEF. 310 * Suggested External Port and Suggested External IP Address are 311 set to zero. 313 * Requested Lifetime field is set to a very low value (see 314 Section 12.3 of [RFC6887]). 316 o Upon the receipt of the PEER response, the PCRF compares the 317 External IP Address and Port learnt with the 5-tuple flow 318 information provided by the AF to correlate external IP address/ 319 port associated with the mapping and the internal IP address/port 320 of the flow. 322 o PCRF notifies PCEF/AF to enforce relevant policies for the UE. 324 4.2. NAT before PCEF 326 A solution to solve the problem discussed in Section 3.3 is to extend 327 PCP with a new OpCode called QUERY (see Section 5). 329 +------------------------------------+ 330 | PCP Client | 331 | +-------+ | 332 | | PCRF |------+ | 333 | +-------+ | | 334 | | | | 335 +----+ | +------+ +-----+ +-----+ | 336 | UE |-|----| NAT |---|PCEF |----| AF | | 337 +----+ | +------+ +-----+ +-----+ | 338 | PCP-enabled | 339 | | 340 +------------------------------------+ 341 Single Administrative Domain 343 Figure 7: NAT before PCEF 345 The updated interaction between PCRF, PCEF and AF is detailed below: 347 o The PCP server controlling the NAT is configured to accept QUERY 348 requests Section 5 from authorized PCP clients such as PCRF. 349 Query requests must not be received in the Internet-facing 350 interface but from an internal interface (e.g., dedicated 351 management interface). 353 o PCRF generates a PCP QUERY request with External IP Address, 354 External Port, Remote Peer IP address, Remote Peer Port and 355 Protocol fields for the flow learnt from PCEF or AF. 357 o PCRF learns the internal IP address and internal port number in 358 the QUERY response. This correlation is used by the PCRF to 359 retrieve the UE's policy to be passed to the PCEF. 361 Figure 8 shows an example of the use of QUERY OpCode. In this 362 example, an HTTP connection is initiated by the UA (192.0.2.1:33041) 363 to an HTTP server (198.51.100.2:80). The NAT assigns 198.51.100.1/ 364 23432 as external IP Address/Port. PCRF learns Internal IP Address 365 and Port associated with the NAT mapping using PCP QUERY request/ 366 response. 368 +------+ +-----+ +------+ +------+ 369 | UE | | NAT | | PCRF | | AF | 370 +------+ +-----+ +------+ +------+ 371 192.0.2.1 | 198.51.100.2 372 | | | 373 |Src IP Address:Port | | 374 | = 192.0.2.1:33041 | | 375 |Dst IP Address:Port | | 376 | = 198.51.100.2:80 | | 377 |===================>|=====================================>| 378 | |Src IP Address:Port=198.51.100.1:23432| 379 | |Dst IP Address:Port=198.51.100.2:80 | 380 | | | 381 | {PCRF learns 5-tuple | 382 | from AF or PCEF} | 383 | | | | 384 | | PCP QUERY Request | | 385 | | External IP:Port = | | 386 | | 198.51.100.1:23432 | | 387 | | Remote Peer IP:Port = | | 388 | | 198.51.100.2:80 | | 389 | | Protocol = TCP | | 390 | |<=======================| | 391 | | PCP QUERY Response | | 392 | | External IP:Port = | | 393 | | 198.51.100.1:23432 | | 394 | | Internal IP:Port = | | 395 | | 192.0.2.1:33041 | | 396 | | Protocol = TCP | | 397 | | Lifetime = 1000 sec | | 398 | |=======================>| | 399 | | | | 400 | Generate Policy Rules 402 Figure 8: Usage Example 404 5. QUERY OpCode 406 This section defines a new PCP OpCode which can be used to query PCP- 407 aware NAT to retrieve the Internal IP Address and Internal Port of a 408 given mapping. 410 The PCP Server MUST provide a configuration option to allow 411 administrators to enable/disable QUERY OpCode. 413 5.1. QUERY Request Format 415 The following diagram shows the format of the OpCode-specific 416 information in a request for the QUERY OpCode. 418 0 1 2 3 419 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | 422 | QUERY Nonce (96 bits) | 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Protocol | Reserved (24 bits) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | External Port | Remote Peer Port | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | | 430 | External IP Address (128 bits) | 431 | | 432 | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | | 435 | Remote Peer IP Address (128 bits) | 436 | | 437 | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Figure 9: Query Opcode Request 442 These fields are described below: 444 Requested Lifetime (in common header): This field is positioned to 445 0. 447 Mapping Nonce: Random value chosen by the PCP client. See 448 Section 12.2 of [RFC6887] 450 Protocol: Upper-layer protocol associated with this OpCode. Values 451 are taken from the IANA protocol registry [proto_numbers]. For 452 example, this field contains 6 (TCP) if the OpCode is describing a 453 TCP mapping. Protocol MUST NOT be zero. 455 Reserved: 24 reserved bits, MUST be set to 0 on transmission and 456 MUST be ignored on reception. 458 External Port: External port allocated by NAT for the flow. 459 External Port MUST NOT be zero 461 Remote Peer Port: Remote peer's port for the flow. Remote Peer Port 462 MUST NOT be zero 464 External IP address: External IP address allocated by NAT for the 465 flow. External IP address MUST NOT be zero 467 Remote Peer IP address: Remote peer IP address for the flow. Remote 468 Peer IP address MUST NOT be zero. 470 5.2. QUERY Response Format 472 The following diagram shows the format of OpCode-specific information 473 in a response packet for the QUERY OpCode: 475 0 1 2 3 476 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | | 479 | QUERY Nonce (96 bits) | 480 | | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Protocol | Reserved (24 bits) | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | External Port | Internal Port | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 | External IP Address (128 bits) | 488 | | 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 | Internal IP Address (128 bits) | 493 | | 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 10: Query Opcode Response 499 These fields are described below: 501 Lifetime (in common header): On a success response, this indicates 502 the lifetime for this mapping, in seconds. On an error response, 503 this indicates that mapping does not exist. 505 Mapping Nonce: Copied from the request. 507 Protocol: Copied from the request. 509 Reserved: 24 reserved bits, MUST be set to 0. 511 External Port: Copied from the request. 513 External IP address: Copied from the request. 515 Internal Port: Internal Port as assigned by the PCP-controlled 516 device. 518 Internal IP address: Internal IP address as assigned by the PCP- 519 controlled controlled device. 521 5.3. Generating a QUERY Request 523 This section describes the operation of a PCP client when sending 524 requests with the QUERY OpCode. 526 PCP QUERY request is used by an authorized third party PCP client 527 that is only aware of the 5-tuple {External IP address and Port, 528 Protocol, Remote Peer IP address and Port} and needs to learn the 529 Internal IP address and Port associated with the NAT mapping. The 530 request MUST contain non-zero values of Protocol, External Port, 531 Remote Peer Port, External IP address and Remote Peer IP address. 532 The Requested Lifetime MUST be set to zero. 534 5.4. Processing a QUERY Request 536 This section describes the operation of a PCP server when processing 537 a QUERY request. 539 For EIM/EIF port-mapping NAT, the processing of the QUERY request is 540 as follows: 542 o If any of the values Protocol, External Port and External IP 543 address are equal to zero, the request is invalid and the PCP 544 server MUST return a MALFORMED_REQUEST to the client. 546 o If Protocol, External Port and External IP address do not match 547 any existing implicit dynamic mapping, then the PCP server MUST 548 return NONEXIST_MAP error response (also needed in 549 [I-D.boucadair-pcp-failure]). 551 o If Protocol, External Port and External IP address match an 552 existing implicit dynamic mapping, then the PCP server MUST build 553 a QUERY response with the Internal IP address, Internal Port and 554 the lifetime associated with the mapping. 556 For EDM port-mapping NAT, the processing of the QUERY request is as 557 follows: 559 o If any of the values Protocol, External Port, Remote Peer Port, 560 External IP address and Remote Peer IP Address are zero, the 561 request is invalid and PCP server MUST return a MALFORMED_REQUEST 562 to the client. 564 o If Protocol, External Port, Remote Peer Port, External IP address 565 and Remote Peer IP address do not match any existing implicit 566 dynamic mapping then the PCP server MUST return NONEXIST_MAP error 567 response (also needed in [I-D.boucadair-pcp-failure]). 569 o If Protocol, External Port, Remote Peer Port, External IP address 570 and Remote Peer IP address matches an existing implicit dynamic 571 mapping then the PCP server builds a QUERY response with the 572 Internal IP address, Internal Port and the lifetime associated 573 with the mapping. 575 PCP QUERY requests received on the Internet-facing interface MUST be 576 silently drooped. 578 In DS-Lite context [RFC6333], the Internal IP address returned in the 579 QUERY response MUST be the IPv6 address of the remote tunnel endpoint 580 and not the internal private IPv4 address. 582 5.5. Processing a QUERY Response 584 After performing common PCP response processing by the PCP Client, 585 the response is further matched with a previously-sent QUERY request 586 by comparing the QUERY Nonce, External IP Address, External Port and 587 Protocol. On a SUCCESS response, the PCP Client can use the Internal 588 IP Address and Port in the QUERY response as needed. 590 6. Applicability Scope of QUERY OpCode 592 The PCP-Reveal solution is designed for needs within one single 593 administrative domain (i.e., the PCP Client and PCP Server are 594 managed by the same entity). Considerations related to the 595 activation of the PCP-Reveal solution in an inter-domain context is 596 out of scope of this document. 598 7. IANA Considerations 600 Authors of this document request IANA to assign the following OpCode: 602 o QUERY 604 The following error code is requested: 606 o NONEXIST_MAP 608 8. Security Considerations 610 Security considerations discussed in [RFC6887] are to be taken into 611 account. In particular, QUERY OpCode MUST NOT be implemented or used 612 unless the network on which the PCP QUERY messages are to be sent is 613 fully trusted. For example if Access Control Lists (ACLs) are 614 installed on the PCP server, and the network between the PCP client 615 and the PCP server, so those ACLs allow only communications from a 616 trusted PCP client to the PCP server. 618 QUERY OpCode may be generated by non legitimate PCP Clients; the PCP 619 Server MUST enforce some policies such as rate limit QUERY messages. 620 QUERY requests received from non legitimate PCP Clients are silently 621 dropped. 623 PCP authentication [I-D.ietf-pcp-authentication] MAY be used. 625 9. References 627 9.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, March 1997. 632 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 633 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 634 2013. 636 [proto_numbers] 637 IANA, , "Protocol Numbers", 2010, . 640 9.2. Informative References 642 [I-D.boucadair-intarea-host-identifier-scenarios] 643 Boucadair, M., Binet, D., Durel, S., Chatras, B., Reddy, 644 T., and B. Williams, "Host Identification: Use Cases", 645 draft-boucadair-intarea-host-identifier-scenarios-03 (work 646 in progress), March 2013. 648 [I-D.boucadair-pcp-failure] 649 Boucadair, M. and R. Penno, "Analysis of Port Control 650 Protocol (PCP) Failure Scenarios", draft-boucadair-pcp- 651 failure-06 (work in progress), May 2013. 653 [I-D.ietf-intarea-nat-reveal-analysis] 654 Boucadair, M., Touch, J., Levis, P., and R. Penno, 655 "Analysis of Solution Candidates to Reveal a Host 656 Identifier (HOST_ID) in Shared Address Deployments", 657 draft-ietf-intarea-nat-reveal-analysis-10 (work in 658 progress), April 2013. 660 [I-D.ietf-pcp-authentication] 661 Wasserman, M., Hartman, S., and D. Zhang, "Port Control 662 Protocol (PCP) Authentication Mechanism", draft-ietf-pcp- 663 authentication-01 (work in progress), October 2012. 665 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 666 for Policy-based Admission Control", RFC 2753, January 667 2000. 669 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 670 Roberts, "Issues with IP Address Sharing", RFC 6269, June 671 2011. 673 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 674 Stack Lite Broadband Deployments Following IPv4 675 Exhaustion", RFC 6333, August 2011. 677 [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 678 Deployment", RFC 6342, August 2011. 680 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 681 IPv4 Address Shortage", RFC 6346, August 2011. 683 [TS.23203] 684 3GPP, , "Policy and charging control architecture", 685 September 2012. 687 Authors' Addresses 689 Mohamed Boucadair 690 France Telecom 691 Rennes 35000 692 France 694 Email: mohamed.boucadair@orange.com 696 Tirumaleswar Reddy 697 Cisco Systems, Inc. 698 Cessna Business Park, Varthur Hobli 699 Sarjapur Marathalli Outer Ring Road 700 Bangalore, Karnataka 560103 701 India 703 Email: tireddy@cisco.com 705 Prashanth Patil 706 Cisco Systems, Inc. 707 Cessna Business Park, Varthur Hobli 708 Sarjapur Marthalli Outer Ring Road 709 Bangalore, Karnataka 560103 710 India 712 Email: praspati@cisco.com 713 Dan Wing 714 Cisco Systems, Inc. 715 170 West Tasman Drive 716 San Jose, California 95134 717 USA 719 Email: dwing@cisco.com