Subject: [tsvwg] [Editorial Errata Reported] RFC3168 (4754)

From: RFC Errata System <[email-masked]>
Date: Sun, 31 Jul 2016 07:03:33 -0700 (PDT)

The following errata report has been submitted for RFC3168,
"The Addition of Explicit Congestion Notification (ECN) to IP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=4754

--------------------------------------
Type: Editorial
Reported by: Bob Briscoe <[email-masked]>

Section: Header block

Original Text
-------------
Updates: 2474, 2401, 2003, 793

Corrected Text
--------------
Updates: 2474, 2401, 2003, 2473, 793

Notes
-----
RFC 3168 updates RFC 2473 but does not indicate this in its header block.

Specifically, Section 9 of RFC 3168 defined processing of the ECN field for Encapsulated Packets, which updated section 6.4 of RFC 2473, where the creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168 also updated the decapsulation behaviour of the ECN field in an IPv6 tunnel header, which had not been specified in RFC2473.

Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to be tagged (in the RFC index and associated tools outputs) to indicate that it is updated by RFC3168.

Note 2: Originally, the "Updates:" header of RFC3168 did not contain "2003", which was added as a result of Errata ID 2660.

Note 3: The first sentence of section 9.1 in RFC3168 should also be modified as follows:
Original text:
   The encapsulation of IP packet headers in tunnels is used in many
   places, including IPsec and IP in IP [RFC2003].
Corrected text:
   The encapsulation of IP packet headers in tunnels is used in many
   places, including IPsec and IP in IP [RFC2003, 2473].
Comment: 
   Nowadays RFC2473 would be a normative reference, but RFC3168 pre-dated the categorisation of references into normative and informative.

Note 4: Section 9 of RFC3168 has since been updated by RFC6040. Nonetheless, that is already correctly identified in RFC6040.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3168 (draft-ietf-tsvwg-ecn-04)
--------------------------------------
Title               : The Addition of Explicit Congestion Notification (ECN) to IP
Publication Date    : September 2001
Author(s)           : K. Ramakrishnan, S. Floyd, D. Black
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 31 Jul 2016 17:45:56 +0100

David,

You're probably the one best placed to address this erratum, having been 
one of the original authors of the tunnelling part of the ECN spec 
[RFC3168], and also now being the tsvwg chair.
I happened across this problem with RFC3168 while reviewing GUE, which 
uses IPv6 extension headers in the tunnel outer.

I believe it's important to ensure "Updates:" headers are comprehensive, 
because implementers don't necessarily know which RFCs they should 
track, especially given IPv6 tunnel implementers wouldn't expect to have 
to track transport area RFCs.

This erratum points out that RFC2473 "Generic Packet Tunneling in IPv6 
Specification" should also have been in the "Updates:" header.
Both RFC2003 and RFC 2473 were already approved when RFC3168 appeared. 
(RFC2003 was written pre-IPv6 [RFC2460], whereas RFC2473 covered IPv6 
tunnelling.)

Regarding IPv6 tunnel state variables, RFC2473 says:

    The IPv6 Tunnel Packet Traffic Class indicates the value that a
    tunnel entry-point node sets in the Traffic Class field of a tunnel
    header. The default value is zero.  The configured Packet Traffic
    Class can also indicate whether the value of the Traffic Class field
    in the tunnel header is copied from the original header, or it is set
    to the pre-configured value {default zero}.

Once RFC3168 was written, it became inappropriate to treat the the IPv6 
Traffic Class as a single 8-bit field.
I believe the above text is compatible with RFC2983 for the 6-bit 
Diffserv Field, but it is not compatible with RFC3168 (or its subsequent 
updates) for the 2-bit ECN field.

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/