idnits 2.17.1 draft-ietf-pcp-description-option-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2014) is 3710 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: A later version (-03) exists of draft-boucadair-pcp-deployment-cases-01 Summary: 0 errors (**), 0 flaws (~~), 2 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 R. Penno 5 Expires: August 25, 2014 D. Wing 6 Cisco 7 February 21, 2014 9 PCP Description Option 10 draft-ietf-pcp-description-option-05 12 Abstract 14 This document extends Port Control Protocol (PCP) with the ability to 15 associate a description with a PCP-instantiated mapping. It does so 16 by defining a new DESCRIPTION option. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 25, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 6.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 This document extends the base PCP [RFC6887] with the ability to 71 associate a human-readable description with a PCP-instantiated 72 mapping. It does so by defining a new DESCRIPTION option. 74 This PCP option can be used in both simple scenarios with a PCP 75 client and PCP server, as well as in more complex scenarios where an 76 interworking function is used to proxy between a UPnP IGD Control 77 Point and a PCP server [RFC6970]. 79 Querying the PCP server to get the description text of an existing 80 mapping is out of scope. 82 2. Format 84 The format of the DESCRIPTION option is shown in Figure 1. 86 0 1 2 3 87 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 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 |Option Code=TBA| Reserved | Length | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | Description | 92 : : 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 This Option: 97 Option Name: DESCRIPTION 98 Number: 99 Purpose: Used to associate a text description with a mapping 100 Valid for Opcodes: MAP, PEER 101 Length: Variable, maximum 1016 octets. 102 May appear in: request. May appear in response only if it 103 appeared in the associated request. 104 Maximum occurrences: 1 106 Figure 1: Description Option 108 The 'Reserved' field is initialized as specified in section 7.3 of 109 [RFC6887]. 111 The Description field MUST carry UTF-8 encoded [RFC3629] description 112 text. The description text MUST NOT be null terminated. The length 113 of the description text is indicated by the Length field. In 114 particular, the description text is not null terminated and when a 115 client or server receives a DESCRIPTION option, it MUST NOT rely on 116 the presence of a NUL character in the wire format data to identify 117 the end of the text. 119 This option can be used by a user (or an application) to indicate a 120 description associated with a given mapping such as "FTP server", "My 121 remote access to my CP router", "Camera", "Network attached storage 122 serve", etc. 124 How the content of the DESCRIPTION option is used is deployment- 125 specific. For example, the description text can be used by the 126 entity managing the PCP server for many purposes such as the 127 following: 129 o The description text can be used as a hint when cleaning a mapping 130 table by an administrator. 132 o In some deployments making use of a portal to instruct PCP 133 mappings (e.g., Section 5.2 of 134 [I-D.boucadair-pcp-deployment-cases]), the description text can be 135 used to store a subscriber identifier . 137 3. Behavior 139 The DESCRIPTION option is optional to be supported by PCP servers and 140 PCP clients. This option (Code TBA, Figure 1) MAY be included in a 141 PCP MAP/PEER request to associate a description with the requested 142 mapping. 144 A PCP server MAY ignore the DESCRIPTION option sent to it by a PCP 145 client (e.g., if it does not support the option, or it is configured 146 to ignore it). To signal that it has not accepted the option, a PCP 147 server simply does not include the DESCRIPTION option in the 148 response. If the PCP client does not receive a DESCRIPTION option in 149 a response to a request enclosing a DESCRIPTION option, this means 150 the PCP server does not support that option or it is configured to 151 ignore it. 153 If the DESCRIPTION option is not included in the PCP client request, 154 the PCP server MUST NOT include the DESCRIPTION option in the 155 associated response. 157 Because of the UDP payload limit of 1100 octets [RFC6887], the 158 configured maximum length MUST NOT exceed 1016 octets. The suggested 159 maximum length is 128 octets. If a PCP client includes a DESCRIPTION 160 option with a length exceeding the maximum length supported by the 161 PCP server, only the portion of the Description field fitting that 162 maximum length is stored by the PCP server and returned to the PCP 163 client in the response. 165 If the PCP server receives a DESCRIPTION option having a length which 166 does not exceed the maximum value configured, the PCP server MUST 167 record the complete sequence of the description text and MUST send 168 back to the PCP client the same DESCRIPTION option as the one 169 included in the request. 171 If the PCP client request contains invalid DESCRIPTION options (e.g., 172 the content is not a legal UTF-8 string), the PCP server MUST ignore 173 the request (i.e., MUST NOT return a DESCRIPTION option in the 174 response). 176 To update the description text of a mapping maintained by a PCP 177 server, the PCP client generates a PCP MAP/PEER renewal request which 178 includes a DESCRIPTION option carrying the new description text. 179 Upon receipt of the PCP request, the PCP server proceeds to the same 180 operations to validate a MAP/PEER request refreshing an existing 181 mapping. If validation checks are successfully passed, the PCP 182 server replaces the old description text with the new one included in 183 the DESCRIPTION option, and the PCP server returns the updated 184 description text in the response, truncated (if necessary) as 185 described above. 187 The PCP client uses empty DESCRIPTION option (i.e., Length set to 0) 188 to erase the description text associated with a mapping. To indicate 189 that the PCP server has successfully cleared the description text 190 associated with a mapping, the PCP server returns back the empty 191 DESCRIPTION option in the response. 193 4. Security Considerations 195 PCP-related security considerations are discussed in [RFC6887]. In 196 addition, administrators of PCP servers SHOULD configure a maximum 197 description length which does not lead to exhausting storage 198 resources in the PCP server. 200 If the PCP client and the PCP server are not under the same 201 administrative entity, the DESCRIPTION option has the potential to 202 leak privacy-related information. PCP clients should not use 203 DESCRIPTION option for such leakage. For example, the option should 204 not be used to include user identifiers, locations, or names. Refer 205 to Section 3.2 of [RFC6462] for a discussion on information leakage. 207 5. IANA Considerations 209 The following PCP Option Codes are to be allocated in the optional- 210 to-process range (the registry is maintained in http://www.iana.org/ 211 assignments/pcp-parameters): 213 DESCRIPTION set to TBA (see Section 2) 215 6. References 217 6.1. Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 223 10646", STD 63, RFC 3629, November 2003. 225 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 226 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 227 2013. 229 6.2. Informative References 231 [I-D.boucadair-pcp-deployment-cases] 232 Boucadair, M., "PCP Deployment Models", draft-boucadair- 233 pcp-deployment-cases-01 (work in progress), December 2013. 235 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 236 RFC 6462, January 2012. 238 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 239 Play (UPnP) Internet Gateway Device - Port Control 240 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 241 July 2013. 243 Authors' Addresses 245 Mohamed Boucadair 246 France Telecom 247 Rennes 35000 248 France 250 Email: mohamed.boucadair@orange.com 252 Reinaldo Penno 253 Cisco 254 USA 256 Email: repenno@cisco.com 258 Dan Wing 259 Cisco Systems, Inc. 260 170 West Tasman Drive 261 San Jose, California 95134 262 USA 264 Email: dwing@cisco.com