RFC 7220

Description Option for the Port Control Protocol (PCP)

πŸ“… published May 2014, from ietf

RFC 7220: Description Option for the Port Control Protocol (PCP) πŸ’–

  • Series: Internet Engineering Task Force (IETF), Request for Comments
  • Number: 7220
  • Title: Description Option for the Port Control Protocol (PCP)
  • Authors: M. Boucadair (France Telecom), R. Penno (Cisco), D. Wing (Cisco)
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: May 2014
  • Obsoletes / Updates: the header has no Obsoletes or Updates entry, so this RFC isn't replacing or updating any other RFC πŸŽ€

Abstract ✨

okay so this doc gives the Port Control Protocol (PCP) a glow-up πŸ’… It lets you attach a description to a PCP-instantiated mapping, and it does that by defining a brand new DESCRIPTION option. iconic, right? πŸ¦‹


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.

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc7220. bookmark it bestie πŸ”–

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) as in effect on the date of publication of this document. Please review those documents carefully, because 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 they are provided without warranty as described in the Simplified BSD License. Read the fine print, it's giving legal drama πŸ“œ

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 ✨

okay so this doc builds on the base PCP [RFC6887] and adds the ability to stick a human-readable description onto a PCP-instantiated mapping. The way it does that is a new DESCRIPTION option 🧚

This PCP option works in simple setups with one PCP client and one PCP server. It also works in fancier setups where an interworking function sits in the middle and proxies between a UPnP IGD Control Point and a PCP server [RFC6970]. main character energy πŸ‘‘

Asking the PCP server to read back the description text of an existing mapping is out of scope. that's a different story, bestie πŸ™ˆ

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]. These are the official BCP 14 words, so they carry real weight here 🫢

2. Format πŸŽ€

Here's the layout of the DESCRIPTION option, 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 gets initialized the way Section 7.3 of [RFC6887] says. no notes, just vibes 🌸

The Description field MUST carry UTF-8 encoded [RFC3629] description text. The description text MUST NOT be null terminated, and the length is whatever the Length field says. so when a client or server gets a DESCRIPTION option, it MUST NOT rely on finding a NUL character in the wire format data to figure out where the text ends. no NUL-hunting, we're doing it properly πŸ’…

This option lets a user (or an application) say what a given mapping is for. Examples from the doc include "FTP server", "My remote access to my CP router", "Camera", "Network attached storage serve", and so on πŸ“Έ

What the DESCRIPTION content actually gets used for depends on the deployment. The entity managing the PCP server can use the text for stuff like this:

  • The description text can be used as a hint when cleaning a mapping table by an administrator.
  • 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, so it's a nice-to-have, not a must-have. This option (Code 128; see Figure 1) MAY be included in a PCP MAP/PEER request to attach a description to the requested mapping. πŸ’–

A PCP server MAY ignore the DESCRIPTION option a PCP client sends it. Maybe it doesn't support the option, or maybe it's configured to ignore it. not me being ignored tho 😭 To say "I didn't accept this," the PCP server just leaves the DESCRIPTION option out of its response. So if a PCP client gets a request that had a DESCRIPTION option but the response has none, the server either doesn't support it or is set to ignore it.

If the PCP client request doesn't include a DESCRIPTION option, the PCP server MUST NOT include the DESCRIPTION option in the associated response. no uninvited guests 🚫

A PCP server SHOULD be able to store at least 128 bytes for a description. When the server gets a DESCRIPTION option, it first stores the value of the received Description field, truncating it if it can't store the whole thing. Then the server MUST send the stored value back to the PCP client in the DESCRIPTION option in the response. ✨

If the PCP client request has invalid DESCRIPTION options (for example, the content isn't a legal UTF-8 string), the PCP server MUST ignore the request. That means it MUST NOT return a DESCRIPTION option in the response. rejected, next πŸ™…β€β™€οΈ

To update the description text of a mapping that a PCP server is maintaining, the PCP client sends a PCP MAP/PEER renewal request with a DESCRIPTION option carrying the new text. When the server gets that PCP request, it runs the same operations it uses to validate a MAP/PEER request that refreshes an existing mapping. If the validation checks pass, the PCP server replaces the old description with the new one from the DESCRIPTION option, and it returns the updated description in the response, truncated if necessary as described above. glow up complete πŸ¦‹

Last one: the PCP client can send an empty DESCRIPTION option (Length set to 0) to erase the description for a mapping. To show that the PCP server has successfully cleared it, the server sends back the empty DESCRIPTION option in the response. clean slate, no drama 🧹


4. Security Considerations πŸ”

Real talk, this part is serious. PCP-related security considerations are discussed in [RFC6887]. On top of that, administrators of PCP servers SHOULD configure a maximum description length that doesn't lead to exhausting storage resources in the PCP server. nobody wants a storage meltdown πŸ’€

If the PCP client and the PCP server aren't under the same administrative entity, the DESCRIPTION option could leak privacy-related information. PCP clients should not use the DESCRIPTION option for that kind of leakage. For example, the option should not be used to include user identifiers, locations, or names. For a discussion of information leakage, see Section 3.2 of [RFC6462]. protect your privacy, periodt 🫣


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)

Code 128 is officially claimed for DESCRIPTION, so it's locked in πŸ”’


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

That's the whole RFC, bestie! πŸŒˆπŸ’– Go make your PCP mappings iconic.

πŸ“¦ where this page comes from