idnits 2.17.1 draft-boucadair-pcp-capability-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 : ---------------------------------------------------------------------------- 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 (November 25, 2013) is 3804 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) == Unused Reference: 'I-D.ietf-opsawg-firewalls' is defined on line 261, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-09 == Outdated reference: A later version (-06) exists of draft-ietf-pcp-nat64-prefix64-04 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: May 29, 2014 Cisco 6 November 25, 2013 8 Retrieving the Capabilities of a PCP-controlled Device 9 draft-boucadair-pcp-capability-03 11 Abstract 13 This document extends Port Control Protocol (PCP) with the ability to 14 retrieve the capabilities of PCP-controlled device: CAPABILITY 15 Option. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 May 29, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. CAPABILITY . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. PCP Client/Server Behavior . . . . . . . . . . . . . . . . . 3 60 4. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 7.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 This document extends the base PCP [RFC6887] with a new feature to 71 discover the capabilities of a PCP-controlled device. Retrieving the 72 capabilities of a PCP-controlled device would allow to avoid error, 73 provide a hint why some applications fails, help select the OpCode to 74 issue, etc. 76 This option can be elected to be defined as a new OpCode. 78 2. CAPABILITY 80 The CAPABILITY option (Code: TBA, Figure 1) is used by a PCP Server 81 to indicate to a requesting PCP Client the capabilities it supports 82 with regards to port forwarding operations. 84 One single Capability option is conveyed in the same PCP response 85 message even if several functions are co-located in the same PCP- 86 controlled device (e.g., NAT44 and NAT64, NAT44 and ports set 87 assignment capability, etc.). 89 This option, when received from a PCP Server, is used by a PCP Client 90 to constraint the content of its requests and therefore avoid errors. 92 0 1 2 3 93 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 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | CAPABILITY | Reserved | Length=16 | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 |A| Capability | 98 +-+ | 99 : : 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 This Option: 104 Option Name: PCP Capabilities Option (CAPABILITY) 105 Number: TBA (IANA) 106 Purpose: Retrieve the capabilities of a PCP-controlled device 107 Valid for Opcodes: ANNOUNCE, MAP, PEER 108 Length: 16 109 May appear in: both request and response 110 Maximum occurrences: None 112 Figure 1: Capability option 114 A-bit when set (i.e., 1) indicates the PCP Server supports 115 authentication. If this bit is set to 0, is indicates plain PCP is 116 supported. 118 The Capability Field is encoded in 127 bits. Each bit in the 119 Capability bit mask is used to represent the PCP-controlled device 120 capability. Several bits can be set if several functions are co- 121 located in the same device. The following values for the Capability 122 field are: 124 Bit #: Description 125 1: NAT44 126 2: Stateless NAT64 [RFC6145]. 127 4: Stateful NAT64 [RFC6146]. 128 8: A+P Port Range Router [RFC6346] 129 9: Supports PORT_SET option [I-D.ietf-pcp-port-set]. 130 16: IPv4 firewall. 131 32: IPv6 Firewall [RFC6092]. 132 64: NPTv6 [RFC6296]. 133 125: DSCP re-marking function. 134 126: FLOWDATA-aware function ([I-D.wing-pcp-flowdata]). 135 127: ILNP Translator [RFC6740]. 137 3. PCP Client/Server Behavior 139 This section specifies the behavior of the PCP Client and the PCP 140 Server to handle the CAPABILITY Option. 142 The PCP Server MAY be configured to return the CAPABILITY Option even 143 if it is not included in the request. 145 Once the PCP Client is configured with its PCP Server(s), it MAY 146 issue an ANNOUNCE OpCode which enclose a CAPABILITY Option. Sending 147 the ANNOUNCE OpCode and the CAPABILITY Option allows the PCP Client 148 to determine whether the PCP Server is alive and also to retrieve its 149 capabilities. Based on the received capabilities, the PCP Client may 150 decide to tune its requests (e.g., Section 4) and decide whether all 151 PCP Servers need to be contacted in parallel or only a subset of them 152 should be contacted. 154 Upon receipt of a PCP request from a PCP Client requiring the PCP 155 Server to enforce an operation beyond its capabilities, the PCP 156 Server MAY return an error code together with the CAPABILITY option. 158 When a new PCP Server joins the network then it MAY send an ANNOUNCE 159 OpCode with its capabilities (i.e., CAPABILITY Option). 161 4. Option Usage 163 Below are provided examples of the CAPABILITY Option usage: 165 o In an IPv6 network with NPTv6 [RFC6296], Firewalls implementing 166 the PCP Server are on different devices: the PCP Client learns of 167 the available PCP Servers by using DHCP [I-D.ietf-pcp-dhcp] or any 168 other PCP Server discovery technique defined in future 169 specifications. PCP Client learns the PCP Server capabilities 170 using CAPABILITY Option. The PCP Client sends MAP PCP request to 171 PCP-controlled NPTv6 device with Internal Port=0 and Protocol=0 172 (which means 'all ports for all protocols') to find the external 173 IP address. This PCP request has to be sent only once since NPTv6 174 is stateless and provides a 1:1 relationship between addresses in 175 the "inside" and "outside" prefixes. The PCP Client will send PCP 176 re-request to NTPv6 only before the Assigned Lifetime of the MAP 177 response expires or when the host embedding the PCP Client 178 acquires a new IPv6 address using "inside" prefix. However PCP 179 Client will send MAP/PEER requests to Firewall to create/delete 180 dynamic outbound mapping or use PCP instead of its default 181 application keep-alives to maintain the Firewall state alive. 183 PCP 184 Client __________ 185 +-----------+ +------+ +------+ / \ +-----------+ 186 |Application|___| NPTv6|___| FW |____| Internet |___|Application| 187 | Client | | | | | | | | Server | 188 +-----------+ +------+ +------+ \__________/ +-----------+ 190 Figure 2: NPTv6 and FW not collocated with PCP server Capability 191 o In a network with NAT64 [RFC6146], Firewall implementing PCP 192 servers are on different devices: IPv6-only PCP Client can send 193 PREFIX64 PCP Option [I-D.ietf-pcp-nat64-prefix64] only to the PCP- 194 controlled NAT64 device to learn the Prefix64(s) used to build 195 IPv4-embedded IPv6 addresses. 196 o Multiple PCP-controlled devices: See Figure 3 the example of a 197 network deploying several techniques to ensure interconnection 198 with IPv4, provide IPv6-only connectivity, etc. Of course, one 199 can argue this configuration is no realistic. 201 +-----+ 202 ______|NPTv6|___________ 203 / +-----+ \ 204 | | 205 | +-----+ 206 +-----------+ +------+ | | PRR | 207 |Application|___| IPv6 |______| SP Network +-----+ 208 |PCP Client| | FW | | | 209 +-----------+ +------+ | +------+ 210 | | NAT64| 211 +-----------+ +-------+ | | + | 212 |PCP Client |___|A+P NAT|_____| | FW | 213 +-----------+ +-------+ | +-----+ +------+ 214 \______|NPTv6|___________/ 215 +-----+ 217 Figure 3: Multiple PCP-controlled devoce 218 o In a IPv6 network with ILNP translator [RFC6740], Firewall 219 implementing PCP servers are on different devices. PCP client 220 needs to send PCP request only to the PCP-controlled ILNP 221 translator to find Global Locators associated with Internal 222 Locators. 223 o When the PCP-controlled device is a PRR, the PCP Client should use 224 PORT_SET [I-D.ietf-pcp-port-set] option. 226 5. Security Considerations 228 Security considerations discussed in [RFC6887] must be considered. 230 6. IANA Considerations 232 The following PCP Option Code is to be allocated in the optional-to- 233 process range (the registry is maintained in http://www.iana.org/ 234 assignments/pcp-parameters/pcp-parameters.xml#options): 236 CAPABILITY 238 A sub-registry is required to track the set of capabilities of PCP- 239 controlled devices. 241 7. References 243 7.1. Normative References 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 249 Algorithm", RFC 6145, April 2011. 251 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 252 NAT64: Network Address and Protocol Translation from IPv6 253 Clients to IPv4 Servers", RFC 6146, April 2011. 255 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 256 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 257 2013. 259 7.2. Informative References 261 [I-D.ietf-opsawg-firewalls] 262 Baker, F. and P. Hoffman, "On Firewalls in Internet 263 Security", draft-ietf-opsawg-firewalls-01 (work in 264 progress), October 2012. 266 [I-D.ietf-pcp-dhcp] 267 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 268 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-09 269 (work in progress), November 2013. 271 [I-D.ietf-pcp-nat64-prefix64] 272 Boucadair, M., "Learning NAT64 PREFIX64s using PCP", 273 draft-ietf-pcp-nat64-prefix64-04 (work in progress), July 274 2013. 276 [I-D.ietf-pcp-port-set] 277 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 278 T., and S. Perreault, "Port Control Protocol (PCP) 279 Extension for Port Set Allocation", draft-ietf-pcp-port- 280 set-04 (work in progress), November 2013. 282 [I-D.wing-pcp-flowdata] 283 Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", 284 draft-wing-pcp-flowdata-00 (work in progress), July 2013. 286 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 287 Customer Premises Equipment (CPE) for Providing 288 Residential IPv6 Internet Service", RFC 6092, January 289 2011. 291 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 292 Translation", RFC 6296, June 2011. 294 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 295 IPv4 Address Shortage", RFC 6346, August 2011. 297 [RFC6740] Atkinson,, RJ., "Identifier-Locator Network Protocol 298 (ILNP) Architectural Description", RFC 6740, November 299 2012. 301 Authors' Addresses 303 Mohamed Boucadair 304 France Telecom 305 Rennes 35000 306 France 308 Email: mohamed.boucadair@orange.com 310 Tirumaleswar Reddy 311 Cisco Systems, Inc. 312 Cessna Business Park, Varthur Hobli 313 Sarjapur Marathalli Outer Ring Road 314 Bangalore, Karnataka 560103 315 India 317 Email: tireddy@cisco.com