summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7220.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7220.txt')
-rw-r--r--doc/rfc/rfc7220.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc7220.txt b/doc/rfc/rfc7220.txt
new file mode 100644
index 0000000..b5db5c3
--- /dev/null
+++ b/doc/rfc/rfc7220.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Boucadair
+Request for Comments: 7220 France Telecom
+Category: Standards Track R. Penno
+ISSN: 2070-1721 D. Wing
+ Cisco
+ May 2014
+
+
+ Description Option for the Port Control Protocol (PCP)
+
+Abstract
+
+ This document extends the Port Control Protocol (PCP) with the
+ ability to associate a description with a PCP-instantiated mapping.
+ It does this by defining a new DESCRIPTION option.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7220.
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 1]
+
+RFC 7220 PCP Description Option May 2014
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 5
+ 6.2. Informative References . . . . . . . . . . . . . . . . . 6
+
+1. Introduction
+
+ This document extends the base PCP [RFC6887] with the ability to
+ associate a human-readable description with a PCP-instantiated
+ mapping. It does this by defining a new DESCRIPTION option.
+
+ This PCP option can be used in simple scenarios with a PCP client and
+ PCP server, as well as in more complex scenarios where an
+ interworking function is used to proxy between a UPnP IGD Control
+ Point and a PCP server [RFC6970].
+
+ Querying the PCP server to get the description text of an existing
+ mapping is out of scope.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 2]
+
+RFC 7220 PCP Description Option May 2014
+
+
+2. Format
+
+ The format of the DESCRIPTION option is shown in Figure 1.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |Option Code=128| Reserved | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Description |
+ : :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ This Option:
+
+ Option Name: DESCRIPTION
+ Number: 128
+ Purpose: Used to associate a text description with a mapping
+ Valid for Opcodes: MAP, PEER
+ Length: Variable, maximum 1016 octets.
+ May appear in: request. May appear in response only if it
+ appeared in the associated request.
+ Maximum occurrences: 1
+
+ Figure 1: DESCRIPTION Option
+
+ The 'Reserved' field is initialized as specified in Section 7.3 of
+ [RFC6887].
+
+ The Description field MUST carry UTF-8 encoded [RFC3629] description
+ text. The description text MUST NOT be null terminated. The length
+ of the description text is indicated by the Length field. In
+ particular, the description text is not null terminated, and when a
+ client or server receives a DESCRIPTION option, it MUST NOT rely on
+ the presence of a NUL character in the wire format data to identify
+ the end of the text.
+
+ This option can be used by a user (or an application) to indicate a
+ description associated with a given mapping, such as "FTP server",
+ "My remote access to my CP router", "Camera", "Network attached
+ storage serve", etc.
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 3]
+
+RFC 7220 PCP Description Option May 2014
+
+
+ How the content of the DESCRIPTION option is used is deployment-
+ specific. For example, the description text can be used by the
+ entity managing the PCP server for many purposes, such as the
+ following:
+
+ o The description text can be used as a hint when cleaning a mapping
+ table by an administrator.
+
+ o In some deployments making use of a portal to instruct PCP
+ mappings (e.g., Section 5.2 of [PCP-DEPLOY]), the description text
+ can be used to store a subscriber identifier.
+
+3. Behavior
+
+ Support for the DESCRIPTION option by PCP servers and PCP clients is
+ optional. This option (Code 128; see Figure 1) MAY be included in a
+ PCP MAP/PEER request to associate a description with the requested
+ mapping.
+
+ A PCP server MAY ignore the DESCRIPTION option sent to it by a PCP
+ client (e.g., if it does not support the option or if it is
+ configured to ignore it). To signal that it has not accepted the
+ option, a PCP server simply does not include the DESCRIPTION option
+ in the response. If the PCP client does not receive a DESCRIPTION
+ option in a response to a request enclosing a DESCRIPTION option,
+ this means the PCP server does not support the option or it is
+ configured to ignore it.
+
+ If the DESCRIPTION option is not included in the PCP client request,
+ the PCP server MUST NOT include the DESCRIPTION option in the
+ associated response.
+
+ A PCP server SHOULD be able to store at least 128 bytes for a
+ description. When the PCP server receives a DESCRIPTION option, it
+ first stores the value of the received Description field, truncating
+ it if it cannot store the entire value. The server MUST then send
+ the stored value back to the PCP client in the DESCRIPTION option in
+ the response.
+
+ If the PCP client request contains invalid DESCRIPTION options (e.g.,
+ the content is not a legal UTF-8 string), the PCP server MUST ignore
+ the request (i.e., MUST NOT return a DESCRIPTION option in the
+ response).
+
+ To update the description text of a mapping maintained by a PCP
+ server, the PCP client generates a PCP MAP/PEER renewal request that
+ includes a DESCRIPTION option carrying the new description text.
+ Upon receipt of the PCP request, the PCP server proceeds to the same
+
+
+
+Boucadair, et al. Standards Track [Page 4]
+
+RFC 7220 PCP Description Option May 2014
+
+
+ operations to validate a MAP/PEER request refreshing an existing
+ mapping. If validation checks are successfully passed, the PCP
+ server replaces the old description text with the new one included in
+ the DESCRIPTION option, and the PCP server returns the updated
+ description text in the response, truncated (if necessary) as
+ described above.
+
+ The PCP client uses an empty DESCRIPTION option (i.e., Length set to
+ 0) to erase the description text associated with a mapping. To
+ indicate that the PCP server has successfully cleared the description
+ text associated with a mapping, the PCP server returns the empty
+ DESCRIPTION option in the response.
+
+4. Security Considerations
+
+ PCP-related security considerations are discussed in [RFC6887]. In
+ addition, administrators of PCP servers SHOULD configure a maximum
+ description length that does not lead to exhausting storage resources
+ in the PCP server.
+
+ If the PCP client and the PCP server are not under the same
+ administrative entity, the DESCRIPTION option has the potential to
+ leak privacy-related information. PCP clients should not use the
+ DESCRIPTION option for such leakage. For example, the option should
+ not be used to include user identifiers, locations, or names. Refer
+ to Section 3.2 of [RFC6462] for a discussion on information leakage.
+
+5. IANA Considerations
+
+ IANA has allocated the following value in the "PCP Options" registry
+ (http://www.iana.org/assignments/pcp-parameters) from the optional-
+ to-process range (see Section 19.4 of [RFC6887]):
+
+ DESCRIPTION set to 128 (see Section 2)
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+ [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
+ P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
+ 2013.
+
+
+
+
+Boucadair, et al. Standards Track [Page 5]
+
+RFC 7220 PCP Description Option May 2014
+
+
+6.2. Informative References
+
+ [PCP-DEPLOY]
+ Boucadair, M., "Port Control Protocol (PCP) Deployment
+ Models", Work in Progress, April 2014.
+
+ [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop",
+ RFC 6462, January 2012.
+
+ [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and
+ Play (UPnP) Internet Gateway Device - Port Control
+ Protocol Interworking Function (IGD-PCP IWF)", RFC 6970,
+ July 2013.
+
+Authors' Addresses
+
+ Mohamed Boucadair
+ France Telecom
+ Rennes 35000
+ France
+
+ EMail: mohamed.boucadair@orange.com
+
+
+ Reinaldo Penno
+ Cisco
+ USA
+
+ EMail: repenno@cisco.com
+
+
+ Dan Wing
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, California 95134
+ USA
+
+ EMail: dwing@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 6]
+