RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (1)

RFC 6887, "Port Control Protocol (PCP)", April 2013

Note: This RFC has been updated by RFC 7488, RFC 7652, RFC 7843

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

Note: This RFC has been updated by RFC 7488, RFC 7652, RFC 7843

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

Note: This RFC has been updated by RFC 7488, RFC 7652, RFC 7843

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.

Report New Errata



Advanced Search