RFC 7843
Port Control Protocol (PCP) Third-Party ID Option
Port Control Protocol (PCP) Third-Party ID Option (RFC 7843) ✨
okay so this one is RFC 7843 🎀 It's a Standards Track doc from May 2016, published as ISSN 2070-1721. A. Ripke, R. Winter, T. Dietz, and J. Quittek from NEC, plus R. da Silva from Telefonica I+D, wrote it together. It updates RFC 6887 🦋, and nothing in the header says it obsoletes anything. The whole point is the new THIRD_PARTY_ID option for PCP. 💜
Abstract
okay so this doc describes a brand new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option 🦋 It's built to work together with the THIRD_PARTY option from RFC 6887.
The THIRD_PARTY_ID option is there to identify a third party when the IP address inside the THIRD_PARTY option isn't enough info to create the mappings a PCP-controlled device has been asked for. 🫶
Status of This Memo
This is an Internet Standards Track document. ✨
It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. You can read more about Internet Standards in Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7843 🌸
Copyright Notice
Copyright (c) 2016 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 they're in effect on the date this document was published. Please read these carefully, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes. 💅
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Target Scenarios . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Carrier-Hosted UPnP IGD-PCP IWF . . . . . . . . . . . . . 6
3.2. Carrier Web Portal . . . . . . . . . . . . . . . . . . . 7
4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Result Codes . . . . . . . . . . . . . . . . . . . . . . 10
5. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Generating a Request . . . . . . . . . . . . . . . . . . 10
5.2. Processing a Request . . . . . . . . . . . . . . . . . . 11
5.3. Processing a Response . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141. Introduction 🎀
okay so the IETF specced the Port Control Protocol (PCP) [RFC6887] to control how packets get translated and/or forwarded by a PCP-controlled device, like a Network Address Translator (NAT) or a firewall. 🧚
This doc is all about the scenarios where the PCP client sends requests about internal addresses other than its own. 👑
RFC 6887 already has an option for exactly this, called the THIRD_PARTY option 💜 It carries the IP address of a host that a PCP client wants the PCP server to do something for. Like, the THIRD_PARTY option can be used when port mapping requests for a Carrier-Grade NAT (CGN) don't come from PCP clients at subscriber terminals, but come from a PCP Interworking Function (IWF) that asks for port mappings instead. 🦋
Sometimes the THIRD_PARTY option alone isn't enough, and you need more ways to identify the third party. Those cases are handled by the THIRD_PARTY_ID option, which this document specifies. ✨
The main problem the THIRD_PARTY_ID option solves is that some CGN deployments can't tell internal hosts apart by IP address alone. They use extra identifiers (IDs) for unique subscriber identification instead. This happens, for example, when a CGN supports overlapping private or shared IP address spaces [RFC1918] [RFC6598] for the internal hosts of different subscribers 🙈 In those setups, the CGN identifies and maps internal hosts by their IP address and/or another ID, like the ID of a tunnel between the CGN and the subscriber. In these scenarios (and similar ones), the internal IP address in the THIRD_PARTY option isn't enough to demultiplex connections from internal hosts. The PCP message needs an additional identifier to uniquely identify an internal host, and the THIRD_PARTY_ID option carries that ID. 🫶
This applies to some of the PCP deployment scenarios listed in Section 2.1 of [RFC6887], especially an L2-aware NAT, which Section 3 covers in more detail. It also applies to other scenarios where address spaces overlap, like the ones in [RFC6674] or [RFC6619]. 🌈
The THIRD_PARTY_ID option is defined for the PCP opcodes MAP and PEER, and it's meant to be used together with the THIRD_PARTY option specified in [RFC6887]. 💖
2. Terminology 📚
The terminology defined in the PCP specification [RFC6887] applies here. 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🔥
3. Target Scenarios 🌸
okay this section walks through two scenarios that show how the THIRD_PARTY_ID option gets used:
- A UPnP IGD-PCP IWF (Universal Plug and Play Internet Gateway Device - Port Control Protocol Interworking Function [RFC6970]).
- A carrier web portal for port mapping.
These are just two examples to show how the option gets used and where it applies. There might be other use cases out there too 👀 But the THIRD_PARTY_ID option, as this document specifies it, is restricted to scenarios where it's needed to uniquely identify an internal host on top of what the THIRD_PARTY option already gives. That's the rule, bestie. 🍓
Both scenarios in this document are refinements of one basic scenario, shown in Figure 1. That basic scenario is one of the PCP deployment scenarios that uses L2-aware NATs, listed in Section 2.1 of [RFC6887]. Here a carrier runs a CGN and a Port Control Protocol Interworking Function (PCP IWF) [RFC6970] so subscribers can request port mappings at the CGN. The PCP IWF talks to the CGN using PCP. To do that, the PCP IWF has a PCP client that serves multiple subscribers, and the CGN is co-located with a PCP server. The basic scenario doesn't specify how subscribers interact with the PCP IWF to request port mappings for their internal hosts. That gets spelled out in the specific scenarios in Sections 3.1 and 3.2. 🦋
The CGN works as an L2-aware NAT. Unlike a standard NAT, it includes a subscriber identifier, in addition to the source IP address, in the entries of its NAT mapping table. 💜
+--------------+ +------------------+
| Subscriber | | Carrier | ==== L2 connection(s)
| | | +--------------+ | between subscriber
| +......+ PCP | | and CGN
| +----------+ | | | Interworking | | #### PCP communication
| | Internal | | | | Function | | .... Subscriber-IWF
| | Host | | | +-----#--------+ | interaction
| +----+-----+ | | # | (elaborated
| | | | +-----#--------+ | in specific
| +----+-----+ | | | PCP Server | | scenarios below)
| | CPE | | | | | |
| | +-+======+ CGN L2NAT +--------- Public Internet
| +----------+ | | +--------------+ |
+--------------+ +------------------+Figure 1: Carrier Hosted PCP IWF for Port Mapping Requests
Internal hosts in the subscriber's network use private IP addresses [RFC1918]. There's no NAT between the internal host and the CGN, and the internal hosts of different subscribers use overlapping addresses. That's why the CGN needs more than just the internal host's IP address to tell apart the internal hosts of different subscribers 🙃 A common fix is an additional identifier. A natural candidate at the CGN is the ID of the tunnel connecting the CGN to the subscriber's network. The subscriber's Customer Premises Equipment (CPE) operates as a Layer 2 bridge. ✨
Port mapping requests from the PCP IWF to the CGN need to uniquely identify the internal host whose port mapping is being established or modified. The THIRD_PARTY option already exists for this and can specify the internal host's IP address. The THIRD_PARTY_ID option is introduced to carry the extra third-party information needed to identify the internal host in this scenario. 🎀
The extra identifier for internal hosts needs to be in MAP requests from the PCP IWF, so the internal host whose address should get mapped is uniquely identified. That's the job of the new THIRD_PARTY_ID option in this scenario. It carries the additional identifier, which is the tunnel ID, and that ID identifies an internal host together with the host's (private) IP address. The PCP IWF includes the internal host's IP address in its mapping requests using the THIRD_PARTY option. 🌈
The THIRD_PARTY_ID information isn't only useful for identifying an internal host in a PCP request. The CGN also needs it in its internal mapping tables, for translating packet addresses and for forwarding packets to subscriber-specific tunnels. 🧚
How the carrier PCP IWF manages port mappings, like automatically extending the lifetime of a mapping, is beyond the scope of this document. 🫶
3.1. Carrier-Hosted UPnP IGD-PCP IWF ✨
okay so this scenario builds on the basic one from before 🎀 and picks UPnP-IGD as the protocol between the subscriber and the carrier's PCP IWF. That means the PCP IWF is realized as a UPnP IGD-PCP IWF, as specified in [RFC6970]. 💖
As Figure 2 shows, the UPnP IGD-PCP IWF is not tucked inside the subscriber premises router. It's offered as a service to the subscriber instead 🧚. It's also assumed that the UPnP IGD-PCP IWF is not providing NAT functionality, so it's just doing the messaging part 💅.
The subscriber has to be able to connect to the UPnP IGD-PCP IWF so it can ask for port mappings at the CGN using UPnP-IGD, as specified in [RFC6970]. In this setup, that connection runs over (one of) the tunnel(s) linking the subscriber's network to the Broadband Remote Access Server (BRAS), plus an extension of that tunnel from the BRAS over to the UPnP IGD-PCP IWF 🦋. There are other ways to get the connection to the UPnP IGD-PCP IWF too, so this isn't the only option, just the one being described here. For example, the tunnel extension could be a forwarding function for UPnP messages at the BRAS, which pushes those messages through per-subscriber tunnels to the UPnP IGD-PCP IWF 🌸. Depending on the implementation, the UPnP IGD-PCP IWF can either use the ID of the tunnel the UPnP message arrived in directly as the THIRD_PARTY_ID option in PCP requests to the CGN, or it can use that tunnel ID to fetch the THIRD_PARTY_ID option from the Authentication, Authorization, and Accounting (AAA) server 🔥.
To make that second option work, the BRAS has to register the subscriber's tunnel IDs with the AAA server at the time it contacts the AAA server to authenticate and/or authorize the subscriber 🫶. The tunnel IDs that can be registered for each subscriber at the AAA server may include the tunnel between CPE and BRAS, the tunnel between BRAS and UPnP IGD-PCP IWF, and the tunnel between BRAS and CGN. The UPnP IGD-PCP IWF asks the AAA server for the ID of the tunnel between BRAS and CGN, because that's the identifier that gets used as the THIRD_PARTY_ID option in the next port mapping request 👑.
+--------------+ +------------------------------------+
| Subscriber | | Carrier |
| | | +----------------------------+ |
| | | | AAA Server | |
| | | +-----+---------------+------+ |
| | | | | |
| +----------+ | | +-----+---+ +-----+------+ |
| | Internal | | | | +=====+ | |
| | Host | | | | ...........| UPnP IGD | |
| +----+-----+ | | | . +=====+ PCP IWF | |
| | . | | | . | +-----#------+ |
| +----+--.--| | | | . | # |
| | | . +========+ . | +-----#------+ |
| | | .................. +=====+ PCP Server | |
| | +------------------------------| | |
| | CPE +========+ BRAS +=====+ CGN L2NAT +------- Public
| +----------+ | | +---------+ +------------+ | Internet
+--------------+ +------------------------------------+
==== L2 tunnel borders between subscriber, BRAS, IWF, and CGN
.... UPnP communication
#### PCP communication
Figure 2: UPnP IGD-PCP IWFA possible extension to [RFC6970] could add another state variable for the THIRD_PARTY_ID option, plus an extra error code for a mismatched THIRD_PARTY_ID option and how that gets processed. That would be a logical next step 🌈. But it's not in the scope of this document, so we're leaving it alone for now 🙈.
3.2. Carrier Web Portal 🍓
This scenario, shown in Figure 3, is different from the last one when it comes to the protocol between the subscriber and the IWF. This time the subscriber uses HTTP(S) for port mapping requests 💜. The subscriber can make requests by hand in a web browser, or they can happen automatically (like in the previous scenario) because apps in the subscriber's network issue port mapping requests on demand ✨. The web portal asks the AAA server for the subscriber's ID of the tunnel (BRAS to CGN) that the BRAS reported. Whatever ID comes back is then used as the THIRD_PARTY_ID option in the next port mapping request 😭.
+--------------+ +------------------------------------+
| Subscriber | | Carrier |
| | | +------------+ |
| | | +------------+ | Web Portal | |
| +----------+ | | | AAA Server +--+ +--+ |
| | Internal | | | +-----+------+ | PCP Client | | |
| | Host | | | | +-----#------+ | |
| +----+-----+ | | | # | |
| | | | +-----+---+ +-----#------+ | |
| +----+-----+ | | | | | PCP Server | | |
| | CPE | | | | BRAS | | | | |
| | +-+======+ +=====+ CGN L2NAT +--+---- Public
| +----------+ | | +---------+ +------------+ | Internet
+--------------+ +------------------------------------+
==== L2 tunnel(s) between subscriber, BRAS, and CGN
#### PCP communication
Figure 3: Carrier Web PortalThe PCP IWF is realized as a combination of a web server and a PCP client 🧁.
4. Format 🎀
4.1. Result Codes
Okay so the THIRD_PARTY_ID option, as shown in Figure 4, uses the format of PCP options as specified in [RFC6887] 🩷:
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=13 | Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| THIRD_PARTY_ID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Name: THIRD_PARTY_ID
Option Code: 13
Purpose: Together with the THIRD_PARTY option, the
THIRD_PARTY_ID option identifies a third party
for which a request for an external IP address
and port is made.
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 4: THIRD_PARTY_ID OptionThe "Reserved" field and the "Option length" field are set exactly as Section 7.3 of [RFC6887] says 📋.
The "THIRD_PARTY_ID" field holds a deployment-specific identifier that marks a realm of a NAT map entry. Paired with a THIRD_PARTY option, it can pin down a subscriber's session on a PCP-controlled device 🔍. It doesn't have any other meaning 🙅♀️.
"THIRD_PARTY_ID" isn't tied to any one specific kind of identifier. It can be any deployment-specific value that the PCP client and the PCP server agree on 🌷. How that agreement gets reached, when the PCP server and client aren't run by the same entity, is out of scope for this document 🤷♀️. The client also doesn't need to understand how the server uses the ID 💫.
If the identifier is based on an existing standard, then that standard's encoding rules must be followed 📏. For example, if a session ID from the Layer 2 Tunneling Protocol version 3 (L2TPv3) [RFC3931] is used, it has to be encoded the same way it would be in the L2TPv3 session header. That way the PCP-controlled device can do a simple octet-by-octet comparison 🦄.
[RFC6887] expects option data to always come in whole multiples of an octet, but an ID might not line up with that 🫠. An MPLS label, for instance, is 20 bits wide. In cases like this, padding is done by appending 0 bits until the byte boundary is reached. After that, the padding rules of [RFC6887] apply 🧸.
The option number sits in the mandatory-to-process range (0-127). That means a request with a THIRD_PARTY_ID option is processed by the PCP server if and only if the PCP server supports the THIRD_PARTY_ID option 🛡️. So it should not be included unless the PCP client is certain that a mapping without the THIRD_PARTY_ID is impossible 🚫.
The following PCP Result Codes are new:
24:THIRD_PARTY_ID_UNKNOWN: The provided identifier in a THIRD_PARTY_ID option is unknown/unavailable to the PCP server. This is a long lifetime error. 🥀25:THIRD_PARTY_MISSING_OPTION: This error occurs if both THIRD_PARTY and THIRD_PARTY_ID options are expected in a request but one option is missing. This is a long lifetime error. 🫥26:UNSUPP_THIRD_PARTY_ID_LENGTH: The received option length is not supported. This is a long lifetime error. 📏
5. Behavior 💅
The following sections describe what a PCP client and a PCP server do when they generate a request, and when they process the request and response 🔄.
5.1. Generating a Request
In addition to generating a PCP request as described in [RFC6887], the following also has to be applied 🎯. The THIRD_PARTY_ID option MAY be included in either a PCP MAP or PEER opcode. It MUST be used in combination with the THIRD_PARTY option, which provides an IP address 💖. The THIRD_PARTY_ID option holds an identifier so the PCP-controlled device can uniquely identify the internal host (specified in the THIRD_PARTY option) that the port mapping is for, whether it's being created or modified ✨. The padding rules described in Section 4 apply here too 🧩.
5.2. Processing a Request
The THIRD_PARTY_ID option is in the mandatory-to-process range. If the PCP server doesn't support this option, it MUST return an UNSUPP_OPTION response 🚨. If the provided identifier in a THIRD_PARTY_ID option is unknown/unavailable, the PCP server MUST return a THIRD_PARTY_ID_UNKNOWN response 🥺. If the PCP server gets a request with an unsupported THIRD_PARTY_ID option length, it MUST return an UNSUPP_THIRD_PARTY_ID_LENGTH response 📐. And if the PCP server gets a THIRD_PARTY_ID option without a THIRD_PARTY option, it MUST return a THIRD_PARTY_MISSING_OPTION response 💀.
When the PCP server receives a valid request with a legal THIRD_PARTY_ID option identifier, the message is processed as specified in [RFC6887], with one twist 🌟. The identifier in the THIRD_PARTY_ID option is also used when accessing a mapping table. Normally only the value in the THIRD_PARTY option is used to look up the internal Internet address in a mapping table. Now the combination of the THIRD_PARTY option value and the THIRD_PARTY_ID option value is used to find the combination of the internal Internet address and the internal realm of a NAT map entry 👑.
If two or more different tunnel technologies are in use, you need to take precautions against the ID spaces of those technologies overlapping 🫣. For example, you can use different PCP client/PCP server pairs for each tunnel technology 🎀.
5.3. Processing a Response 📬
Okay so, besides all the response handling that [RFC6887] already covers 💅, there's an extra check for this option. If the PCP client gets back a THIRD_PARTY_ID_UNKNOWN, an UNSUPP_THIRD_PARTY_ID_LENGTH, or a THIRD_PARTY_MISSING_OPTION response to its previous request, it SHOULD report an error. Where that error gets reported is up to policy 🫶
6. IANA Considerations ✨
Time for the registry paperwork! 📋 One PCP Option Code got allocated in the mandatory-to-process range:
13: THIRD_PARTY_ID
Three PCP Result Codes also got allocated:
24: THIRD_PARTY_ID_UNKNOWN25: THIRD_PARTY_MISSING_OPTION26: UNSUPP_THIRD_PARTY_ID_LENGTH
7. Security Considerations 🔐
Okay bestie, this section is seriously important, so read it carefully 🙈
This option gets used together with the THIRD_PARTY option, which means every security consideration in Section 18.1.1 of [RFC6887] applies here too 💖 The big one is that the network carrying the PCP messages must be sufficiently protected. On top of that, it is RECOMMENDED to use PCP authentication [RFC7652], unless the network already has proper authentication in place.
The THIRD_PARTY_ID option carries a context identifier, and its type and length depend on the deployment and the implementation 🧚 That identifier might contain privacy-sensitive information, so it is RECOMMENDED to use identifiers that don't raise those privacy concerns. Means to protect unauthorized access to this information MUST be put in place. In the scenarios described in this document, for example, access to the web portal or the UPnP IGD-PCP IWF MUST be authenticated. Generally speaking, the identifier itself MUST only be accessible by the network operator, and it MUST only be handled on operator equipment. For example, the subscriber triggers the creation of a PCP message on the web portal or the UPnP IGD PCP IWF, but the actual option filling is done by an operator-controlled entity 🦋
Heads up: the identifier is only for the operator's eyes and hands. Lock down access to it, and keep it on operator gear. No exceptions, no cap! 🚨
8. References 📚
8.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
2012, <http://www.rfc-editor.org/info/rfc6598>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<http://www.rfc-editor.org/info/rfc6887>.8.2. Informative References
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005,
<http://www.rfc-editor.org/info/rfc3931>.
[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable
Operation of Address Translators with Per-Interface
Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012,
<http://www.rfc-editor.org/info/rfc6619>.
[RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
"Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674,
DOI 10.17487/RFC6674, July 2012,
<http://www.rfc-editor.org/info/rfc6674>.
[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,
DOI 10.17487/RFC6970, July 2013,
<http://www.rfc-editor.org/info/rfc6970>.
[RFC7652] Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port
Control Protocol (PCP) Authentication Mechanism",
RFC 7652, DOI 10.17487/RFC7652, September 2015,
<http://www.rfc-editor.org/info/rfc7652>.Acknowledgments 🌸
Huge thanks to Mohamed Boucadair for lots of valuable suggestions, especially for proposing a variable length for the THIRD_PARTY_ID option 👑 Thanks also to Dave Thaler, Tom Taylor, and Dan Wing for their comments and review 🫶
Authors' Addresses 💌
Andreas Ripke
NEC
Heidelberg
Germany
Email: ripke@neclab.eu
Rolf Winter
NEC
Heidelberg
Germany
Email: winter@neclab.eu
Thomas Dietz
NEC
Heidelberg
Germany
Email: dietz@neclab.eu
Juergen Quittek
NEC
Heidelberg
Germany
Email: quittek@neclab.eu
Rafael Lopez da Silva
Telefonica I+D
Madrid
Spain
Email: rafaelalejandro.lopezdasilva@telefonica.com📦 where this page comes from
- ietf: rfc7843 2016-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms