PCP Description Option: Description Option for the Port Control Protocol (PCP)
A PCP option that lets a client attach a short human-readable label to a port mapping.
Boucadair, M., Penno, R., and D. Wing, "Description Option for the Port Control Protocol (PCP)", RFC 7220, DOI 10.17487/RFC7220, May 2014, <https://www.rfc-editor.org/info/rfc7220>.
@misc{rfc7220,
series = {Request for Comments},
number = 7220,
howpublished = {RFC 7220},
publisher = {RFC Editor},
doi = {10.17487/RFC7220},
url = {https://www.rfc-editor.org/info/rfc7220},
author = {M. Boucadair and R. Penno and D. Wing},
title = {{Description Option for the Port Control Protocol (PCP)}},
pagetotal = 6,
year = 2014,
month = may,
} RFC text
Contents
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.
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].
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.
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
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.
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
AI ELI5
On this page
§1Why a Description Option
RFC 7220 extends the base Port Control Protocol (PCP, RFC 6887) so a client can associate a human-readable description with a mapping that PCP creates. It does so by defining a new DESCRIPTION option.
The option works in simple client and server setups and in more complex ones where an interworking function proxies between a UPnP IGD control point and a PCP server (RFC 6970). Querying a server to read back the description of an existing mapping is out of scope.
It adds a label to a request so the door knows what it is for.
§2The DESCRIPTION Option Format
The option has the option code 128, a Reserved field, a Length field and the description text. Its name is DESCRIPTION, its purpose is to associate a text description with a mapping, and it is valid for the MAP and PEER opcodes. The maximum length is 1016 octets. It may appear in a request, and in a response only if it appeared in the associated request. At most one may appear per message.
The Description field MUST carry UTF-8 text (RFC 3629). The text MUST NOT be null terminated, and a receiver MUST NOT rely on a NUL character to find the end, because the Length field gives the length. The Reserved field is initialized as in Section 7.3 of RFC 6887.
Example descriptions are "FTP server", "Camera" and "Network attached storage serve". How the text is used is deployment-specific. It might help an administrator when cleaning a mapping table, or in a portal-based deployment it could store a subscriber identifier.
The label is just words, and a length number says where the words end, so nobody has to look for a special stop mark.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
OPTION-CODE | Option Code | 1 byte | 128 | Fixed at 128 for DESCRIPTION. |
RESERVED | Reserved | 1 byte | Initialized as in Section 7.3 of RFC 6887. | |
LENGTH | Length | 2 bytes | Length of the description text in octets, up to 1016; 0 erases the description. |
§3Client and Server Behavior
Support is optional for both PCP clients and servers. A client MAY include the option in a MAP or PEER request. A server MAY ignore it, for example if it does not support the option or is configured to ignore it. It signals that by leaving the option out of the response, so a client that gets no DESCRIPTION back knows it was not accepted. If the request had no DESCRIPTION, the server MUST NOT include one in the response.
A server SHOULD be able to store at least 128 bytes of description. It stores what it receives, truncating if it cannot hold the whole value, and MUST send the stored value back in the response. If the request contains an invalid DESCRIPTION, such as text that is not legal UTF-8, the server MUST ignore the request and MUST NOT return a DESCRIPTION option.
If the clerk cannot write on the note, they just hand your request back without it. If your note is too long, they copy as much as fits and show you what they wrote.
§4Updating and Erasing a Description
To change a description, the client sends a MAP or PEER renewal request carrying a DESCRIPTION option with the new text. The server runs the same validation it uses when refreshing an existing mapping. If the checks pass, it replaces the old text with the new text, truncating if needed, and returns the updated description in the response.
To erase a description, the client sends an empty DESCRIPTION option, that is, Length set to 0. The server confirms by returning the empty option in the response.
To change the note, send a new one with your next renewal. To remove it, send a blank note.
§5Security and Privacy
General PCP security considerations are in RFC 6887. In addition, administrators of PCP servers SHOULD configure a maximum description length that does not exhaust server storage.
If the client and server are not under the same administrative entity, the option can leak privacy-related information. Clients should not use it that way. For example, it should not include user identifiers, locations or names. The RFC points to Section 3.2 of RFC 6462 for a discussion of information leakage.
Do not write secrets on the note, because other people may read it. The clerk should also limit how long a note can be.
§6IANA Considerations
IANA allocated the value 128 for DESCRIPTION in the "PCP Options" registry, from the optional-to-process range defined in Section 19.4 of RFC 6887.
The number 128 was officially reserved for this label so nobody else uses it for something different.