idnits 2.17.1 draft-penno-pcp-nested-nat-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 6 instances of too long lines in the document, the longest one being 29 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 291 has weird spacing: '...| Outer sIP:1...' == Line 301 has weird spacing: '...| Outer sIP:1...' == Line 315 has weird spacing: '...| Outer sIP:1...' -- The document date (January 21, 2013) is 4110 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Port Control Protocol R. Penno 3 Internet-Draft D. Wing 4 Intended status: Standards Track Cisco 5 Expires: July 25, 2013 M. Boucadair 6 France Telecom 7 January 21, 2013 9 PCP Support for Nested NAT Environments 10 draft-penno-pcp-nested-nat-03 12 Abstract 14 Nested NATs or multi-layer NATs are already widely deployed. They 15 are characterized by two or more NAT devices in the path of packets 16 from the subscriber to the Internet. Moreover, NAT devices current 17 deployed are PCP unaware and It is assumed that NAT aware PCP devices 18 will take a long time to be rolled out. Therefore in order to lower 19 the adoption barrier of PCP and make it work for current deployed 20 networks, this document proposes a few mechanisms for PCP-enabled 21 applications to work through NATs with varying levels of PCP protocol 22 support. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 25, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. PCP MAP Nested NAT Methods . . . . . . . . . . . . . . . . . . 4 68 2.1. PCP and UPnP unaware Intermediate NATs . . . . . . . . . . 5 69 2.2. PCP Server intermediate NAT . . . . . . . . . . . . . . . 7 70 2.3. UPnP enabled intermediate NAT . . . . . . . . . . . . . . 8 71 2.4. PCP Proxy Intermediate NAT . . . . . . . . . . . . . . . . 8 72 2.4.1. PCP Proxy Discovery . . . . . . . . . . . . . . . . . 9 73 3. PCP PEER Nested NAT Methods . . . . . . . . . . . . . . . . . 9 74 3.1. Send-then-connect . . . . . . . . . . . . . . . . . . . . 9 75 3.2. Connect-then-send . . . . . . . . . . . . . . . . . . . . 10 76 4. RECEIVED_SOURCE_IP_PORT Option . . . . . . . . . . . . . . . . 10 77 5. SCOPE Option . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 Nested NATs are widely deployed and come in different topology 89 flavors. It could be a home subscriber which has an ISP provided NAT 90 CPE chained with another personal NAT router. It could be an ISP 91 provided CPE chained with a CGN. 93 An example of the use of the proposed options is illustrated in the 94 following figure where there is a NAT in the path between the PCP 95 Client and the PCP Server. 97 webcam-------+ 98 | 99 +----------+ | +----+ +----------+ 100 |PCP Client|====+====|NAT1|=========|PCP Server| 101 +----------+ +----+ | NAT2 | 102 +----------+ 104 An example of instructing mappings in the PCP Server is as follows: 106 o NAT1 is detected in the path between the PCP Client and the PCP 107 Server owing to the use of the RECEIVED_SOURCE_IP_PORT Option and the returned 108 IP address (IP Header) of PCP request in PCP response; 110 o After learning about that NAT, the PCP Client uses UPnP IGD, 111 NAT-PMP or manual configuration to interact with NAT1 and 112 open the necessary port on NAT1 (e.g., IP address= IPx, port=X); 114 o The PCP Client then sends PCP message to the PCP Server, 115 indicating IPx and X as the internal IP address and port. The PCP 116 Server opens pinhole towards IPx and X. 118 1.1. Terminology 120 This document uses PCP terminology defined in [I-D.ietf-pcp-base]]. 122 1.2. Problem Statement 124 The current NAT deployed devices will take years to be replaced or 125 upgraded to become PCP aware. Moreover, nested NATs are common and 126 come in a variety of flavors (examples below). Therefore, as 127 applications become PCP enabled, it is important that they can work 128 through nested NAT networks as is, without requiring infrastructure 129 changes. From the point of view of a PCP-enabled application running 130 on an end host, the core problem is common across different nested 131 NAT topologies: how to install PCP mappings in a nested NAT scenario 132 where the different NATs in the path have varying level of PCP 133 protocol support. 135 ,-----------. 136 PCP Server ,' `--. 137 +-------+ +------+ +----------+ / : 138 |PCP |____|Home |______|ISP CPE |________; Public | 139 |Client | |Router| |NAT Router| : Internet | 140 +-------+ +------+ +----------+ \ | 141 \ ; 142 `------. ,-' 143 `-----' 144 ,-----------. 145 PCP Server ,' `--. 146 +-------+ +------+ +-------+ / : 147 |PCP |____|CPE |______|CGN/FW |___________; Public | 148 |Client | | | | | : Internet | 149 +-------+ +------+ +-------+ \ | 150 \ ; 151 `------. ,-' 152 `-----' 153 ,-----------. 154 PCP Proxy PCP Server ,' `--. 155 +-------+ +------+ +-------+ / : 156 |PCP |____|CPE |_______________|CGN/FW |__; Public | 157 |Client | | | | | : Internet | 158 +-------+ +------+ +-------+ \ | 159 \ ; 160 `------. ,-' 161 `-----' 162 ,-----------. 163 PCP Server PCP Server ,' `--. 164 +-------+ +------+ +-------+ / : 165 |PCP |____|CPE |_______________|CGN/FW |__; Public | 166 |Client | | | | | : Internet | 167 +-------+ +------+ +-------+ \ | 168 \ ; 169 `------. ,-' 170 `-----' 172 1.3. Scope 174 This proposal considers the discovery of the PCP Server out of scope. 175 Nonetheless, it s a critical piece of PCP deployment in service 176 provider networks. 178 2. PCP MAP Nested NAT Methods 180 There are a few methods to make PCP work through nested NATs. They 181 differ mainly based on the level of support that can be expected from 182 intermediate NATs, which can be: 184 o PCP and UPnP unaware or disabled 186 o PCP Server 188 o UPnP Server 190 o PCP Proxy 192 The next sections discuss each scenario on the basis of protocol 193 support on intermediate NATs. 195 2.1. PCP and UPnP unaware Intermediate NATs 197 This method will most likely be used by PCP clients in nested NAT 198 environments while PCP Proxy support in not ubiquitous. It assumes 199 no UPnP or PCP Proxy support on intermediate NATs. This proposal 200 leverages the current behavior of PCP [I-D.ietf-pcp-base] which 201 allows a PCP Client and Server to detect intervening nested NATs. 202 The PCP Server uses the information on the outer IP and PCP headers 203 to detect and install a proper NAT mapping and return the source IP: 204 port from the IP header on the PCP response. It does not assume any 205 change to current deployed NATs. 207 1. The PCP Client sends the MAP request as it normally would without 208 any changes. 210 2. As the message goes through one (or more) PCP-unaware NAT, the 211 source IP:port of the IP header will change accordingly 213 3. The PCP Server compares the PCP Client IP:port in the PCP header 214 with the source IP:port of the IP header 216 4. If these are different, the server knows that the PCP message 217 went through a PCP-unaware NAT. Therefore it installs a mapping 218 directed to the source IP address found on the IP header and 219 internal port of the PCP header. 221 s/dport: source/destination port 222 s/dIP : source/destination IP 223 PCP-C : PCP client 224 iport : Internal port 225 PCP-U : PCP Unaware NAT 226 E-port : External port 227 E-IP : External IP 229 PCP Client PCP-U NAT PCP Server 231 | | | 232 | Map request | | 233 | Outer sIP:192.168.0.2 | | 234 | Outer sPort:19216 | Map request | 235 | PCP-C Addr:192.168.0.2 | Outer sIP:10.0.0.2 | 236 | PCP-C port:19216 | Outer sPort:10002 | 237 | iPort:40000 | PCP-C Addr:192.168.0.2 | 238 | -------------------> | PCP-C port:19216 | 239 | | iPort:40000 | 240 | | ----------------------> | 241 | | | 242 | | PCP client IP != Outer IP 243 | | Allocate public IP and port 244 | | Mapping: 245 | | (10.0.0.2, 40000) <- (20.0.0.1, 20001) 246 | | | 247 | | Map response | 248 | | Outer dIP:10.0.0.2 | 249 | | Outer dport:10002 | 250 | | Assigned E-port:20001 | 251 | Map response | Assigned E-IP:20.0.0.1 | 252 | Outer dIP:192.168.0.2 | PCP-C Addr:10.0.0.2 | 253 | Outer dport:19216 | PCP-C port:10002 | 254 | Assigned E-port:20001 | <---------------------- | 255 | Assigned E-IP:20.0.0.1 | | 256 | PCP-C Addr:10.0.0.2 | | 257 | PCP-C port:10002 | | 258 |<---------------------- | 260 - Subscriber installs a port forwarding or DMZ entry on its home CPE 261 (PCP U-NAT) through manual configuration. The entry would be (*, 262 40000) -> (10.0.0.1, 40000). Alternatively the application could use 263 UPnP for the same purpose. 265 2.2. PCP Server intermediate NAT 267 If the intermediate NAT implements a PCP Server (but not a Proxy), a 268 two-step iterative process is needed in order to install PCP PEER 269 mappings for the PCP control message itself followed by another PCP 270 mapping for the data path. If the PCP Client Address does not match 271 the IP address of IP header, PCP Server (CGN) will reject request 272 with ADDRESS_MISMATCH error. Therefore PCP Client first needs to 273 know the IP address and port the CPE NAT will use for the actual PCP 274 request to CGN. 276 If the PCP client relies on nested NAT detection the first step is 277 not needed. It is assumed that before sending the PCP MAP request to 278 the CGN the client would install the following map on the NAT Home 279 Gateway: (192.168.0.2, 40000) <- (10.0.0.2, 40000). The internal 280 port that the server listens on does not necessarily needs to be 281 40000, it could be different than the internal port used between the 282 CGN and CPE. 284 The drawback of this technique is that there is no obvious way for 285 the PCP Client to know the PCP Servers downstream. One possibility 286 is for each PCP Server in the path to return the address of the 287 upstream PCP Server to the PCP Client. 288 PCP Client PCP Server (CPE) PCP Server (CGN) 290 | PEER request | | 291 | Outer sIP:192.168.0.2 | | 292 | Outer sPort:19216 | | 293 | PCP-C Addr:192.168.0.2 | | 294 | PCP-C port:19216 | | 295 | iPort:19216 | | 296 | Remote Port:44323 | | 297 | Remote IP: 10.0.0.1 | | 298 | -------------------> | | 299 | | | 300 | PEER response | | 301 | Outer sIP:192.168.0.1 | | 302 | Outer sPort: 19216 | | 303 | Assigned E-port: 10002 | | 304 | Assigned E-IP: 10.0.0.2| | 305 | PCP-C Addr:192.168.0.2 | | 306 | PCP-C port:19216 | | 307 | iPort:19216 | | 308 | Remote Port:44323 | | 309 | Remote IP: 10.0.0.1 | | 310 | <--------------------- | | 311 | (192.68.0.2,19216) -> (10.0.0.2,10002) | 312 | Dest: 10.0.0.1, 44323 | 313 | | | 314 | Map request | | 315 | Outer sIP:192.168.0.2 | | 316 | Outer sPort:19216 | | 317 | PCP-C Addr:10.0.0.2 | | 318 | PCP-C port:10002 | | 319 | iPort:40000 | | 320 | --------------------> | | 321 | | Map request | 322 | | Outer sIP:10.0.0.2 | 323 | | Outer sPort:10002 | 324 | | PCP-C Addr:10.0.0.2 | 325 | | PCP-C port: 10002 | 326 | | iPort:40000 | 327 | | ----------------------> | 328 | | | 329 | | (10.0.0.2, 40000) <- (20.0.0.1, 20001) 330 | | | 331 | | Map response | 332 | | Outer dIP:10.0.0.2 | 333 | | Outer dport: 10002 | 334 | | Assigned E-port: 20001 | 335 | Map response | Assigned E-IP: 20.0.0.1 | 336 | Outer dIP:192.168.0.2 | PCP-C Addr: 10.0.0.2 | 337 | Outer dport:19216 | PCP-C port: 10002 | 338 | Assigned E-port: 20001 | <---------------------- | 339 | Assigned E-IP: 20.0.0.1| | 340 | PCP-C Addr: 10.0.0.2 | | 341 | PCP-C port: 10002 | | 342 |<---------------------- | 344 2.3. UPnP enabled intermediate NAT 346 This scenario is very similar to the PCP Server intermediate NAT, but 347 the CPE implements a UPnP Server instead of PCP Server. The 348 mechanics are the same with the difference that first PEER message to 349 setup the PCP Control messages mapping is substituted by its UPnP 350 equivalent. 352 2.4. PCP Proxy Intermediate NAT 354 This method assumed that the intermediate NATs implement a PCP Proxy 355 function. There are two non-exclusive types of proxy functions: 356 interception (ALG) and server-client based. In the interception case 357 the PCP Proxy intercepts PCP messages destined to a PCP Server 358 downstream, modifies IP, UDP and PCP headers, allocates a mapping and 359 send them to the downstream PCP Server. Ideally if the interception 360 PCP Proxy also implements a PCP server it would let the PCP Client 361 know of its existence in a PCP response through an option (TBD) and 362 henceforth the PCP Client would start directing messages to it. 364 In the server-client scenario the PCP Client sends PCP messages to 365 the proxy which acts as both PCP Server and Client. This proxy in 366 turn will terminate the PCP request and generate a new one acting as 367 a PCP Client to its own PCP Server. Therefore mappings are installed 368 in all NAT devices in a recursive manner. This is the recommended 369 method since its does not need a special discovery procedure and 370 works with any number of NATs. More information about this method 371 can be found in [I-D.bpw-pcp-proxy]. 373 2.4.1. PCP Proxy Discovery 375 TBD 377 3. PCP PEER Nested NAT Methods 379 All techniques discussed for PCP MAP methods do not work for PCP PEER 380 messages. PCP PEER is a different beast and another set of 381 techniques need to be used to overcome intervening NATs. The 382 critical issue related to PEER is that the client needs to know the 383 external source port NAT1 will use to translate packets for the 384 actual data session. There are two scenarios to consider: send-then- 385 connect and connect-then-send. 387 3.1. Send-then-connect 389 In this scenario the client sends a PEER message to install a mapping 390 which later will be used by a regular UDP or TCP data session. In 391 order for this to work reliably, the following procedure needs to the 392 followed: 394 1. PCP Client needs to allocate a binding on the intervening NAT 395 thorugh STUN, UPnP or other method. Let's suppose this binding 396 is (192.168.0.2, 19216 <-> 10.0.0.2, 10002). 398 2. PCP Client constructs a PCP PEER request like the following 400 * Internal port: 10002 402 * Remote Peer Port: 20002 (upcoming data connection destination 403 port) 405 * Remote Peer address: 20.0.0.2 (upcoming data connection 406 destination IP address) 408 * PCP Client Address: 10.0.0.2 410 * Protocol: TCP 412 3. Application will connect to remote peer using the same source IP 413 address and port of the existing mapping on the intervening NAT. 414 If the intervening NAT supports Protocol Independent Endpoint 415 Independent Mapping (PI-EIM) 416 [I-D.penno-behave-rfc4787-5382-5508-bis] , it will allocate the 417 same external IP:port of step 1 to the new connection. Therefore 418 5-tuple of the new connection will match those of the previously 419 installed PEER map. 421 3.2. Connect-then-send 423 If the data connection to the remote peer is established before the 424 PEER message, the challenge for the PCP client is to find out which 425 source IP:port the intervening NAT is using to translate the data 426 packets. If the PCP Client has the necessary permissions to reuse 427 the socket used by the data connection and the intervening NAT 428 support EIM, two solutions are possible: 430 1. PCP Client sends a request from the same source IP:port as the 431 data connection. Since the intervening NAT supports PI-EIM, it 432 should allocate the same external IP:port of the data connection, 433 which would be returned in the RECEIVED_PORT_OPTION. The PCP 434 Client then can send an appropriate PEER message to take over the 435 data connection. The advantage of this solution is that is built 436 around a single protocol, PCP, and the disadvatange is that it 437 requires a PCP extension. 439 2. If the PCP Client is also a STUN client it can send a binding 440 request from the same source IP:port as the data connection and 441 since the intervening NAT supports EIM the client will find out 442 the external IP:port that is used to translate data packets. The 443 PCP Client then can send an appropriate PEER message to take over 444 the data connection. The advantage of this solution is that no 445 extensions to PCP are needed. The disadvantage is that STUN 446 client and server are needed, specially the fact that in case of 447 nested NATs the STUN server needs to be located between NAT1 and 448 NAT2. 450 4. RECEIVED_SOURCE_IP_PORT Option 452 This option (Code TBA, Figure 1) is used by a PCP Server to indicate 453 in a PCP response the source IP and port of PCP messages received 454 from a PCP Client. Together with the IP Address of the PCP Client 455 conveyed in the common PCP header, a PCP Client uses this information 456 to detect whether a NAT is present in the path to reach its PCP 457 Server. 459 A PCP Client MAY include this option to learn the port number as 460 perceived by the PCP Server. When this option is received by the PCP 461 Server, it uses the source IP:port of the received PCP request to set 462 the Received Port. 464 This Option: 465 Option Name: PCP Received Port Option (RECEIVED_SOURCE_IP_PORT) 466 Number: TBA (IANA) 467 Purpose: Detect the presence of a NAT in the path and discover externally allocate IP:port 468 Valid for Opcodes: MAP and PEER 469 Length: 0x12 470 May appear in: both request and response 471 Maximum occurrences: 1 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | RECEIVED_PORT | Reserved | 0x12 | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | | 479 | | 480 | Received Source IP Address | 481 | | 482 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 483 | Received Source Port | 0x00 | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Received Source Port and IP: The source IP:port number of the received PCP request 487 as seen by the PCP Server. 489 Figure 1: Received IP address/port PCP option 491 5. SCOPE Option 493 The Scope Option (Code TBA, Figure 2) is used by a PCP Client to 494 indicate to the PCP Server the scope of the flows that will use a 495 given mapping. This object is meant to be used in the context of 496 cascaded PCP Servers/NAT levels. Two values are defined: 498 Value Meaning 499 ----- -------- 500 0x00 Internet 501 0x01 Internal 503 When 0x00 value is used, the PCP Proxy MUST propagate the mapping 504 request to its upstream PCP Server. When 0x01 value is used, the 505 mapping is to be instantiated only in the first PCP-controlled 506 device; no mapping is instantiated in the upstream PCP-controlled 507 device. 509 When no Scope Option is included in a PCP message, this is equivalent 510 to including a Scope Option with a scope value of "Internet". 512 This Option: 513 Option Name: PCP Scope Policy Option (SCOPE) 514 Number: TBA (IANA) 515 Purpose: Restrict the scope of PCP requests 516 Valid for Opcodes: MAP 517 Length: 0x04 518 May appear in: both request and response 519 Maximum occurrences: 1 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | SCOPE | Reserved | 0x04 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Scope | 00...00 | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 Figure 2: Scope Option 531 6. IANA Considerations 533 The following PCP Option Codes are to be allocated: 535 RECEIVED_PORT 537 SCOPE 539 7. Security Considerations 541 Security considerations discussed in [I-D.ietf-pcp-base] must be 542 considered. 544 8. Acknowledgements 546 Thanks to Linda (wang.cui1@zte.com.cn) for her review. 548 9. References 550 9.1. Normative References 552 [I-D.ietf-pcp-base] 553 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 554 Selkirk, "Port Control Protocol (PCP)", 555 draft-ietf-pcp-base-29 (work in progress), November 2012. 557 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 558 Requirement Levels", BCP 14, RFC 2119, March 1997. 560 9.2. Informative References 562 [I-D.bpw-pcp-proxy] 563 Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Port 564 Control Protocol (PCP) Proxy Function", 565 draft-bpw-pcp-proxy-02 (work in progress), September 2011. 567 [I-D.penno-behave-rfc4787-5382-5508-bis] 568 Penno, R., Perreault, S., Kamiset, S., Boucadair, M., and 569 K. Naito, "Network Address Translation (NAT) Behavioral 570 Requirements Updates", 571 draft-penno-behave-rfc4787-5382-5508-bis-04 (work in 572 progress), January 2013. 574 Authors' Addresses 576 Reinaldo Penno 577 Cisco Systems, Inc. 578 170 West Tasman Drive 579 San Jose, California 95134 580 USA 582 Email: repenno@cisco.com 583 Dan Wing 584 Cisco Systems, Inc. 585 170 West Tasman Drive 586 San Jose, California 95134 587 USA 589 Email: dwing@cisco.com 591 Mohamed Boucadair 592 France Telecom 593 Rennes, 35000 594 France 596 Email: mohamed.boucadair@orange.com