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

From: "Black, David" <[email-masked]>
Date: Mon, 1 Aug 2016 13:08:29 +0000

Bob,

> 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'm sorry, but RFC 2474 made that change to the IPv6 traffic class field definition, not RFC 3168.  The general approach taken at the time was to wait for tunnel specs to be updated as opposed to retroactively changing them.

I don't think it's appropriate to add RFC 2473 as Updated by RFC 3168, particularly via an Errata (Erratum?), as that was not intended at the time.  There's no text in RFC 3168 indicating what it changes in RFC 2473, in contrast to the lengthy discussion of IPsec tunnels.  At the very least, this is not an Editorial change to RFC 3168.

I'd suggest covering RFC 2473 in your RFC 6040 update draft, and I caution that having that draft update a bunch of existing RFCs to render most implementations non-compliant with a new SHOULD is heavy-handed, and not consistent with your request for fast processing of that draft.   It may still be the proverbial "right thing to do" but it is not a straightforward simple change due to the existence of "running code."

Thanks, --David

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]]
> Sent: Sunday, July 31, 2016 12:46 PM
> To: Black, David
> Cc: RFC Errata System; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Editorial Errata Reported] RFC3168 (4754)
> 
> 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
> 
> On 31/07/16 15:03, RFC Errata System wrote:
> > 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
> >
> 
> --
> ______________________________________________________________
> __
> Bob Briscoe                               http://bobbriscoe.net/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Aug 2016 08:27:05 +1200

> I'm sorry, but RFC 2474 made that change to the IPv6 traffic class field definition, not RFC 3168.  The general approach taken at the time was to wait for tunnel specs to be updated as opposed to r…

And to be 100% clear, 2474 says this about the bits now known as ECN:

    A two-bit currently unused
   (CU) field is reserved and its definition and interpretation are
   outside the scope of this document.  The value of the CU bits are
   ignored by differentiated services-compliant nodes when determining
   the per-hop behavior to apply to a received packet.

Also, RFC 2983 (Differentiated Services and Tunnels) refers only to the DSCP
(six bits) and says absolutely nothing about the CU bits.

> I'd suggest covering RFC 2473 in your RFC 6040 update draft, 

That seems the right thing to do. Looking at 2473 today for the first time in years,
I see that its treatment of the flow label is also a bit heavy-handed, which we didn't
pick up in the latest flow label RFC. But for both the traffic class and the flow label,
the language is quite permissive. "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 ...". That is not prescriptive - it only states the default and
the *possibility* of a blind copy. It isn't wrong, it's just incomplete. 6040bis
could carry an Updates: 2473 to fix this.

Regards
     Brian

> and I caution that having that draft update a bunch of existing RFCs to render most implementations non-compliant with a new
SHOULD is heavy-handed, and not consistent with your request for fast processing of that draft.   It may still be the proverbial
"right thing to do" but it is not a straightforward simple change due to the existence of "running code."

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 1 Aug 2016 23:23:54 +0100

David,

> I'm sorry, but RFC 2474 made that change to the IPv6 traffic class field definition, not RFC 3168.  The general approach taken at the time was to wait for tunnel specs to be updated as opposed to r…
You are commenting on text in my email that was intended to provide 
background for the text I put in the erratum (quoted lower down).
Of course you are correct that RFC2474 split the ToS octet in two, but 
that wasn't my point. RFC2474 didn't define anything to do with 
tunnelling (of either part). That was defined in RFC2983 and RFC3168 
(obviously you know that because you authored both). The text in 2473 is 
consistent with 2983 (for the 6-bit DS field), but inconsistent with 
3168 (for the 2-bit ECN field). That's why my proposed erratum only 
corrects 3168, not 2983.

> I don't think it's appropriate to add RFC 2473 as Updated by RFC 3168, particularly via an Errata (Erratum?), as that was not intended at the time.  There's no text in RFC 3168 indicating what it c…
I beg to differ.

As well as updating IPsec tunnelling, RFC3168 defined the ECN tunnelling 
behaviour for IP in IP (see the start of section 9.1, as you know). 
Given ECN field processing in IPv4 and IPv6 are identical, and both IPv4 
and IPv6 tunnelling had been defined before RFC3168, then RFC3168 should 
have identified that it updated both RFC2003 (IPv4) and RFC2473 (IPv6).

RFC3168 cited RFC2003, but it didn't cite RFC2473. However, clearly 
RFC3168 did not intend to only update IPv4 tunnelling and not IPv6 
tunnelling. That is the editorial error corrected by this erratum. 
RFC3168 only cites 2003 once. So the erratum suggests
     s/[RFC2003]/[RFC2003, RFC2473]/

FYI, an earlier erratum (Errata ID 2660) has already been verified that 
RFC3168 should have listed 2003 in its "Updates:" header. And, as a 
result, in the RFC index RFC2003 is now shown as updated by RFC3168.

> I'd suggest covering RFC 2473 in your RFC 6040 update draft, and I caution that having that draft update a bunch of existing RFCs to render most implementations non-compliant with a new SHOULD is h…
It was while I was updating the text of my RFC6040 update that I 
realised that RFC2003 was approved before IPv6 [RFC2460] (previously I 
had always assumed that RFC2003 applied to both IPv4 and IPv6). Then I 
unearthed RFC2473 and I realised that both RFC3168 and RFC2983 
overlooked citing 2473.

I thought about this carefully, and realised it is not the job of my 
RFC6040-update to update 2473, because 3168 did that update in the 
technical sense - it just didn't do the update in the editorial sense.

Hence the editorial erratum.

Bob

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Aug 2016 14:45:50 +1200

On 02/08/2016 10:23, Bob Briscoe wrote:

Big snip...

> I thought about this carefully, and realised it is not the job of my RFC6040-update to update 2473, because 3168 did that update in the technical sense - it just didn't do the update in the editorial sense.

Well yes, but, from a practical point of view, what' more likely - that interested
parties will rake not of 6040bis or of an editorial erratum on 3168?

BTW I am far from certain that 2473 even matters. IPv6 Node Requirements (RFC 6434)
doesn't even cite it - the main tunnel reference is RFC 4213, which cites RFC 3168.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Aug 2016 17:21:51 +1200

Hmm. Some jet-lagged typing there. Please s/rake not of/take note of/ .

Regards
   Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 2 Aug 2016 09:43:59 +0000

> On 2 Aug 2016, at 03:45, Brian E Carpenter <[email-masked]> wrote:
> 

Well, we are updating RFC6434, so if you have suggestions for text there…

Tim

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 2 Aug 2016 14:22:45 +0100

Brian & Tim,
Responses to you both inline...

>> doesn't even cite it - the main tunnel reference is RFC 4213, which cites RFC 3168.
I'm certainly not as expert as you on v6 RFCs, but I believe RFC2473 is 
the basic RFC that defines the IPv6 tunnelling /implementation/.
That is what RFC3168 updated.

RFC6434 is about operations and configuration of a specific use of 
tunnelling (for transition) isn't it?
This might help explain why it doesn't cite RFC2473.
Also, due to this limited scope, RFC6434 is only about v4 in v6 or v6 in 
v4, so it doesn't cover v6 in v6.
> Well, we are updating RFC6434, so if you have suggestions for text there…
I haven't read it, but on a search for words like "tunnel", "IPsec", 
"encap", "decap", etc. I think the appropriate place for more about 
tunnelling would be the end of section 4. "Sub-IP layer."

It currently says:

    In addition to traditional physical link-layers, it is also possible
    to tunnel IPv6 over other protocols.  Examples include:
    -  Teredo: ... [RFC4380 <https://tools.ietf.org/html/rfc4380>]
    -Section 3 <https://tools.ietf.org/html/rfc6434#section-3>  of ... [RFC4213 <https://tools.ietf.org/html/rfc4213>]

Is it really not a "MUST" requirement to support transition mechanisms?
Whatever, surely this needs to say that if an IPv6 node implements 
tunnelling, it MUST comply with IPv6 encap and decap [RFC2473].

Whether it needs to cite more RFCs that update RFC2473 is a matter of style.
IMO, an implementer should be able to use the RFC index (and tools built 
on it) to track which RFCs update other RFCs.
Nonetheless, I guess you could also helpfully say "At the time of 
publication, propagation of the ECN field within the Traffic Class field 
in RFC2473 tunnels was updated by RFC3168 (itself updated by RFC6040). 
Also RFC2983 gives guidance on propagation of the DS field within the 
Traffic Class field".
Also, I think section 5.6 on PMTUD will need to cite the relevant RFCs 
about PMTUD in tunnel situations (sorry can't help with RFC numbers 
without getting even more distracted from my original task).

However, whether you can say that RFC3168 updates RFC2473 depends on the 
outcome of this conversation about this erratum!

Bob

---

From: Tim Chown <[email-masked]>
Date: Tue, 2 Aug 2016 13:52:52 +0000

Hi,

On 2 Aug 2016, at 14:22, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:

Brian & Tim,

On 2 Aug 2016, at 03:45, Brian E Carpenter <[email-masked]><mailto:[email-masked]> wrote:

Big snip...

I'm certainly not as expert as you on v6 RFCs, but I believe RFC2473 is the basic RFC that defines the IPv6 tunnelling /implementation/.
That is what RFC3168 updated.

RFC6434 is about operations and configuration of a specific use of tunnelling (for transition) isn't it?

Well, it’s about IPv6 Node Requirements in general, and tunnelling support is a small part of that.

This might help explain why it doesn't cite RFC2473.
Also, due to this limited scope, RFC6434 is only about v4 in v6 or v6 in v4, so it doesn't cover v6 in v6.

An interesting point, noted for RFC6434-bis.

I haven't read it, but on a search for words like "tunnel", "IPsec", "encap", "decap", etc. I think the appropriate place for more about tunnelling would be the end of section 4. "Sub-IP layer."

It currently says:

   In addition to traditional physical link-layers, it is also possible
   to tunnel IPv6 over other protocols.  Examples include:
   -  Teredo: ... [RFC4380<https://tools.ietf.org/html/rfc4380>]
   -  Section 3<https://tools.ietf.org/html/rfc6434#section-3> of ... [RFC4213<https://tools.ietf.org/html/rfc4213>]

Is it really not a "MUST" requirement to support transition mechanisms?
Whatever, surely this needs to say that if an IPv6 node implements tunnelling, it MUST comply with IPv6 encap and decap [RFC2473].

Whether it needs to cite more RFCs that update RFC2473 is a matter of style.
IMO, an implementer should be able to use the RFC index (and tools built on it) to track which RFCs update other RFCs.
Nonetheless, I guess you could also helpfully say "At the time of publication, propagation of the ECN field within the Traffic Class field in RFC2473 tunnels was updated by RFC3168 (itself updated by RFC6040). Also RFC2983 gives guidance on propagation of the DS field within the Traffic Class field".
Also, I think section 5.6 on PMTUD will need to cite the relevant RFCs about PMTUD in tunnel situations (sorry can't help with RFC numbers without getting even more distracted from my original task).

However, whether you can say that RFC3168 updates RFC2473 depends on the outcome of this conversation about this erratum!

OK, so we might not say anything about RFC6040, but would it be appropriate to add a note about ECN in RFC6434-bis? At the moment RFC6434 is silent on the Traffic Class field, though it does talk about the Flow Label field, and how it SHOULD be used.

Tim

Bob

Tim

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 2 Aug 2016 15:18:38 +0100

Tim,

On 02/08/16 14:52, Tim Chown wrote:
>>>> On 2 Aug 2016, at 03:45, Brian E Carpenter<[email-masked]>  wrote:
>>>>
>> I'm certainly not as expert as you on v6 RFCs, but I believe RFC2473 
>> is the basic RFC that defines the IPv6 tunnelling /implementation/.
Sorry, I meant 4213 but I said 6434.

> An interesting point, noted for RFC6434-bis.
Again I meant 4213 but I said 6434.
>>> Well, we are updating RFC6434, so if you have suggestions for text there…
For the avoidance of doubt, now I really am talking about 6434...

>> tunnelling, it MUST comply with IPv6 encap and decap [RFC2473].
Did you note these two suggestions?
If transition mechanisms are a MUST, then I don't think you'll need to 
say the "If" in "If an IPv6 node implements tunnelling".
>> IMO, an implementer should be able to use the RFC index (and tools 
>> built on it) to track which RFCs update other RFCs.
>> publication, propagation of the ECN field within the Traffic Class 
>> field in RFC2473 tunnels was updated by RFC3168 (itself updated by 
>> RFC6040). Also RFC2983 gives guidance on propagation of the DS field 
>> within the Traffic Class field".
>> Also, I think section 5.6 on PMTUD will need to cite the relevant 
>> RFCs about PMTUD in tunnel situations (sorry can't help with RFC 
>> numbers without getting even more distracted from my original task).
>>
>> However, whether you can say that RFC3168 updates RFC2473 depends on 
>> the outcome of this conversation about this erratum!
>
> OK, so we might not say anything about RFC6040, but would it be 
> appropriate to add a note about ECN in RFC6434-bis? At the moment 
> RFC6434 is silent on the Traffic Class field, though it does talk 
> about the Flow Label field, and how it SHOULD be used.

Yes, describing Traffic Class field propagation with reference to 2983 
(INF) 3168 (PS) and 6040 (PS) would be worthwhile, given the purpose of 
a Node Requirements RFC is largely to help implementers navigate to all 
the necessary RFCs. In this vein I think it would be OK to cite 6040 as 
well as 3168. 6040 also updates IPsec [RFC4301] (making ECN propagation 
consistent between IPsec tunnelling and all other IP-in-IP tunnelling).

Bob

>> Bob Briscoehttp://bobbriscoe.net/
>

---

From: Tim Chown <[email-masked]>
Date: Tue, 2 Aug 2016 15:21:37 +0000

On 2 Aug 2016, at 15:18, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:

Tim,

On 2 Aug 2016, at 14:22, Bob Briscoe <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

Brian & Tim,

Big snip...

It currently says:

Is it really not a "MUST" requirement to support transition mechanisms?
Whatever, surely this needs to say that if an IPv6 node implements tunnelling, it MUST comply with IPv6 encap and decap [RFC2473].
Did you note these two suggestions?
If transition mechanisms are a MUST, then I don't think you'll need to say the "If" in "If an IPv6 node implements tunnelling”.

I think that given RFC6434 outlines requirements for a general IPv6 node, there was a general consensus to minimise the MUSTs.  It itself updated RFC4294 from 5 years previously, so it’s due a refresh again now.  But points noted for discussion.

Yes, describing Traffic Class field propagation with reference to 2983 (INF) 3168 (PS) and 6040 (PS) would be worthwhile, given the purpose of a Node Requirements RFC is largely to help implementers navigate to all the necessary RFCs. In this vein I think it would be OK to cite 6040 as well as 3168. 6040 also updates IPsec [RFC4301] (making ECN propagation consistent between IPsec tunnelling and all other IP-in-IP tunnelling).

OK.  We’ll see what level of detail the 6man WG thinks is appropriate, but again noted.

Tim

Bob

Tim

Bob

Tim

---

From: "Black, David" <[email-masked]>
Date: Tue, 2 Aug 2016 22:40:45 +0000

> have identified that it updated both RFC2003 (IPv4) and RFC2473 (IPv6).

Or neither ...

>      s/[RFC2003]/[RFC2003, RFC2473]/

... IMHO, "update" -> "provide design guidance for" is what was intended
at the time RFC 3168 was written, even though RFC 2119 keywords were used.

In contrast, RFC 3168 contains detailed, specific IPsec updates to RFC 2401,
and hence updated that RFC.

> result, in the RFC index RFC2003 is now shown as updated by RFC3168.

I probably signed off on that errata at the time.  I would not recommend
approval if it were submitted as a new errata today.

The point about consistency of treatment of whether RFC 3168 updates
RFC 2003 and 2473 is well-taken (RFC 3168 should update both or neither).
I'll defer to the ADs on what to do here.

Thanks, --David

> Sent: Monday, August 01, 2016 6:24 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> > I'm sorry, but RFC 2474 made that change to the IPv6 traffic class field
> definition, not RFC 3168.  The general approach taken at the time was to wait for
> tunnel specs to be updated as opposed to retroactively changing them.
> > I don't think it's appropriate to add RFC 2473 as Updated by RFC 3168,
> particularly via an Errata (Erratum?), as that was not intended at the time.  There's
> no text in RFC 3168 indicating what it changes in RFC 2473, in contrast to the
> lengthy discussion of IPsec tunnels.  At the very least, this is not an Editorial
> change to RFC 3168.
> I beg to differ.
> 
> > I'd suggest covering RFC 2473 in your RFC 6040 update draft, and I caution that
> having that draft update a bunch of existing RFCs to render most
> implementations non-compliant with a new SHOULD is heavy-handed, and not
> consistent with your request for fast processing of that draft.   It may still be the
> proverbial "right thing to do" but it is not a straightforward simple change due to
> the existence of "running code."

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 4 Aug 2016 17:22:46 +0100

David,

> and hence updated that RFC.
I think your bar for "detailed and specific" is set far too high.

As Spencer said recently, it helps if an update gives word-for-word 
update text. But an RFC doesn't have to give word-for-word editing 
commands to update another RFC. An RFC is an update if it specifies 
sufficiently detailed technical changes to another RFC.

Section 9.1 of RFC3168 gives detailed, specific and normative 
specifications of how the ECN codepoints should be handled at encap and 
decap in all IP tunnels, including IP-in-IP and IPsec.

Certainly, RFC3168 then includes section 9.2 specific to IPsec that 
re-states the above updates as word-for-word editorial updates to the 
handling of the Traffic Class field and the negotiation of attributes 
that had already been defined in RFC2401. But isn't that because RFC2401 
had already defined negotiation of handling of the Traffic Class field 
in detail, at encap and decap? Whereas RFC2003 just said the ToS field 
was copied at encap.

Extreme detail in section 9.2 (IPsec) doesn't make the detailed, 
specific and normative technical updates in section 9.1 (all IP tunnels) 
any less detailed, specific and normative. I'll leave the ADs to see if 
they think S9.1 is only guidance, but it certainly doesn't look like 
just guidance to me.  Here's a brief digest...

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Section 9.1 gives the scope as IPsec and IP in IP [RFC2003] tunnels at 
the start. And it goes on to motivate the two modes of ECN tunnelling, 
saying very clearly that either mode applies to all IP tunnels, and that 
the phrase "IP tunnel" means both IPsec and all other IP-in-IP tunnels:

    The result is that there are two viable options for the behavior of
    ECN-capable connections over an IP tunnel, including IPsec tunnels:

       * A limited-functionality option ...

       * A full-functionality option ...

It then defines the behaviour of these two options in detail, codepoint 
by codepoint, and normatively says:

       (1) An IP tunnel MUST modify the handling of the DS field octet at
       IP tunnel endpoints by implementing either the limited-
       functionality or the full-functionality option.
[...]
    All IP tunnels MUST implement the limited-functionality option, and
    SHOULD support the full-functionality option.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
That's in a Proposed Standard - it's clearly not just guidance.

Regards

Bob