RFC Errata
Found 4 records.
Status: Verified (1)
RFC 6887, "Port Control Protocol (PCP)", April 2013
Source of RFC: pcp (int)
Errata ID: 3621
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stuart Cheshire
Date Reported: 2013-05-14
Verifier Name: Ted Lemon
Date Verified: 2013-05-15
Section 15.1 says:
In requests where the requested Lifetime is 0, the Suggested External Address and Suggested External Port fields MUST be set to zero on transmission and MUST be ignored on reception, and these fields MUST be copied into the assigned external IP address and assigned external port of the response.
It should say:
In requests where the requested Lifetime is 0, the Suggested External Port field MUST be set to zero on transmission and MUST be ignored on reception. The Suggested External Address field must be set to the appropriate all-zeros address, depending on whether the request is deleting a mapping for an External IPv4 address or an External IPv6 address. Both the Suggested External Address and Suggested External Port fields are copied into the assigned external IP address and assigned external port of the response.
Notes:
Since a given internal address+port can have *two* mappings -- an IPv4 one and an IPv6 one -- the deletion request needs to signify which one is being deleted.
Status: Held for Document Update (1)
RFC 6887, "Port Control Protocol (PCP)", April 2013
Source of RFC: pcp (int)
Errata ID: 3891
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Dainty
Date Reported: 2014-02-14
Held for Document Update by: Ted Lemon
Date Held: 2014-02-17
Section 13.3 says:
The Prefix Length indicates how many bits of the address are used for the filter. For IPv4 addresses (which are encoded using the IPv4-mapped address format (::FFFF:0:0/96)), this means valid prefix lengths are between 96 and 128 bits, inclusive. That is, add 96 to the IPv4 prefix length. For IPv6 addresses, valid prefix lengths are between 0 and 128 bits, inclusive. Values outside those ranges cause the PCP server to return the MALFORMED_OPTION result code. To remove all existing filters, the Prefix Length 0 is used. There is no mechanism to remove a specific filter.
It should say:
The Prefix Length indicates how many bits of the address are used for the filter. For IPv4 addresses (which are encoded using the IPv4-mapped address format (::FFFF:0:0/96)), this means valid prefix lengths are between 97 and 128 bits, inclusive. That is, add 96 to the IPv4 prefix length. For IPv6 addresses, valid prefix lengths are between 1 and 128 bits, inclusive. Values outside those ranges cause the PCP server to return the MALFORMED_OPTION result code. To remove all existing filters, the Prefix Length 0 is used. The Remote Peer Port and Remote Peer IP Address fields MUST be set to zero on transmission and MUST be ignored on reception. There is no mechanism to remove a specific filter.
Notes:
A mapping with a filter containing an address-specific prefix length of 0 doesn't provide any value as it's no different to a mapping with no filters at all.
Since a prefix length of 0 is not even possible for IPv6 addresses, it should not be possible for IPv4 addresses either. Therefore the valid prefix length range for IPv4 addresses should be 97 to 128 bits inclusive and the valid range for IPv6 addresses should be documented as 1 to 128 bits inclusive in addition to a prefix length of 0 being documented as the special case.
Also clarify in that special case that it doesn't matter what the remote peer port and IP address fields are and therefore follow the convention throughout the RFC of setting to zero on transmission and ignoring on reception.
Status: Rejected (2)
RFC 6887, "Port Control Protocol (PCP)", April 2013
Source of RFC: pcp (int)
Errata ID: 3887
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Channy Zhang
Date Reported: 2014-02-11
Rejected by: Ted Lemon
Date Rejected: 2014-02-12
Section N/A says:
N/A
It should say:
N/A
Notes:
How PCP applies in the Dual-Egress NAT scene?
If the gateway device has two or more out interfaces to internet were doing different nat conversion in the ISP.
PCP MAP mode does not include the destination address, the gateway device how to choose the out interfaces? And how to choose the different NAT address pools?
This scene is very common in the ISP, it means that PCP does not apply in this scene?
--VERIFIER NOTES--
This is not the right way to address the issue you have raised. Please raise this issue in the PCP working group, so that the working group can come up with a consensus answer to the question.
Errata ID: 4255
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ad Steijvers
Date Reported: 2015-02-03
Rejected by: Ted Lemon
Date Rejected: 2015-02-03
Section 11,12 says:
Notes:
Add (preferable at the start of both section 11 and 12) the actual numerical definition of the OpCode explained in the section.
There is a lot of mentioning of the MAP and PEER opcodes in the document, but nowhere in the text can be found what the actual OpCodes are. Everywhere where the MAP OpCode or PEER OpCode is mentioned is the reader directed to section 11 or 12 respectively, 'where the OpCode is defined'. But in those sections there is no definition of the OpCode.
e.g.: section 7.1, in the field description of a PCP request packet:
"Opcode: A 7-bit value specifying the operation to be performed. MAP
and PEER Opcodes are defined in Sections 11 and 12."
I had to search the internet and found them at:
https://www.iana.org/assignments/pcp-parameters/pcp-parameters.xhtml
Where is stated:
Value Description Reference
0 ANNOUNCE [RFC6887]
1 MAP [RFC6887]
2 PEER [RFC6887]
The above three numerical definitions are nowhere to be found in the RFC6887 document and seem quite crucial for correct PCP implementations. Should the OpCodes already be defined in some other RFC document and is the reader expected to know about it, then I'd suggest to put a link to that other RFC document at the start of sections 11 and 12.
--VERIFIER NOTES--
The numerical opcodes are defined in section 19.2. I agree that the use of the term "opcode" is confusing, and it would be good to clarify that in a future update to the document, but the erratum as written is not correct.