Subject: [Errata Held for Document Update] RFC8200 (5933)

From: RFC Errata System <[email-masked]>
Date: Sun, 1 Mar 2020 19:29:40 -0800 (PST)

The following errata report has been held for document update 
for RFC8200, "Internet Protocol, Version 6 (IPv6) Specification". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5933

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Fernando Gont <[email-masked]>
Date Reported: 2019-12-11
Held by: Suresh Krishnan (IESG)

Section: 4

Original Text
-------------
   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

Corrected Text
--------------
   Extension headers (except for the Hop-by-Hop Options header, or a 
   Destination Options header preceding a Routing header) are not processed,
   inserted, or deleted by any node along a packet's delivery path, until the
   packet reaches the final destination node (or each of the set of final
   destination nodes, in the case of multicast). 

   For packets that do not include a Routing Header, the final destination
   node is identified by the Destination Address field of the IPv6 header. 
   For packets that include a Routing Header, the final destination node is 
   identified by the Destination Address field of the IPv6 header only when
   the Segments Left field of the Routing Header is 0. 

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the final destination node (or each of the set of
   final destination nodes, in the case of multicast). The Hop-by-Hop Options 
   header, when present, must immediately follow the IPv6 header.  Its 
   presence is indicated by the value zero in the Next Header field of the 
   IPv6 header.

   A Destination Options header preceding a Routing Header is not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the destination node (or each of the set 
   of destination nodes, in the case of multicast) identified by the 
   Destination Address field of the IPv6 header. This means that  a 
   Destination Options header preceding a Routing Header will be
   processed by the first destination of the packet (specified by the
   Destination Address field of the IPv6 header at the origin node) and by 
   each node listed in the Routing Header.

Notes
-----
This errata clarifies two different issues:

* It clarifies that nodes other than the final destination do not insert o remove extension headers.

* It clarifies that the Destination Options header preceding a routing header *is* processed along the
   packet delivery's path, but the node(s) identified by the Destination Address of the IPv6 header.

Area Director's Note (Suresh Krishnan):

I am handling this based on the IESG Statement about processing of RFC Errata for the IETF Stream (https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/)

"Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected."

Some people might interpret the text in RFC8200 to mean the replacement text provided above in the erratum but others might read the text exactly as written ("until the packet reaches the node identified in the Destination Address field of the IPv6 header”). Given that the text in RFC8200 had consensus and it is impossible to tell after the fact if the proposed replacement text would have achieved consensus, I believe this erratum falls under the above category. 

The change proposed by this erratum has to be evaluated for correctness and consensus if and when there is an update of RFC8200.

--------------------------------------
RFC8200 (draft-ietf-6man-rfc2460bis-13)
--------------------------------------
Title               : Internet Protocol, Version 6 (IPv6) Specification
Publication Date    : July 2017
Author(s)           : S. Deering, R. Hinden
Category            : INTERNET STANDARD
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 2 Mar 2020 16:59:49 +1300

Hi everybody,

I've realised that we really do need a WG discussion & rough consensus on
this issue. As a matter of fact, RFC 8200 is internally inconsistent,
because there are three mutually incompatible statements (not just two
as implied by erratum 5933):

1. Some non-normative Appendix text that states an intention:

>>    o  Clarified that extension headers (except for the Hop-by-Hop
>>       Options header) are not processed, inserted, or deleted by any
>>       node along a packet's delivery path

>>    in the case of multicast) identified in the Destination Address field

3. In section 4.4, a clear implication that the Segments Left field is
decremented in flight, in violation of that rule:

>>       Segments Left       8-bit unsigned integer.  Number of route
>>                           segments remaining, i.e., number of explicitly
>>                           listed intermediate nodes still to be visited
>>                           before reaching the final destination.

So it's a complete oversight that this exception to the previous rule
is not mentioned. That's additional to Fernando's statement that the 
DA field was intended to refer to the final DA in the routing header,
which some people may disagree about. We goofed, despite all the discussion
on 2460bis.

Regards
   Brian Carpenter

On 02-Mar-20 16:29, RFC Errata System wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 01:55:06 -0300

Brian,

Thanks for your timely email. In-line....

On 2/3/20 00:59, Brian E Carpenter wrote:
> which some people may disagree about.

There is more, although orthogonal to what you've pointed out: The 
existing text in RFC8200 does not mention the Destinations Options 
headers that precedes a Routing Header.

Errata 5933 fixed that one.

> We goofed, despite all the discussion on 2460bis.

Now, going back to your original question:
You've noted that we need wg consensus. But I don't believe that's the 
case -- for the same reason that I disagree with Suresh' processing of 
this errata:

While the spec is broken, I do believe that the intent of the spec is 
clear. So this could be easily fixed (*) with an erratum, in the same 
way we fixed the fragmentation related text.

Suresh' rationale for rejecting the erratum I submitted is that the 
existing text achieved wg consensus, and the text I've proposed might 
not. However, as long as the erratum respect the intention of the spec, 
I'm not sure why the text should be subject of a consensus call -- yeah, 
wg review is okay, but wg consensus would be a different thing.

Now, since the text I had originally proposed in my erratum can be 
improved (some of you suggested tweaks after I originally submitted, but 
still there was stuff left out, as you've correctly pointed out), at 
least on my side I will work in a revised version of my erratum, which I 
will submit in a week or so (orthogonal to how things fly here).

What I personally believe would be a correct path forward is to fix 
these things as erratums, clarifying the intent of the spec, and once 
they are processed, publish a rev of RFC8200 that incorporates all of 
them. -- Reality is that we can't have a core IPv6 spec where all of the 
fragmentation and EH handling parts are broken and replaced by some 
other document/erratum. I was a reviewer of the document and yes, we 
really goofed. :-(

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ron Bonica <[email-masked]>
Date: Mon, 2 Mar 2020 16:51:12 +0000

Brian,

RFC 8200 has some fleas on it. When we reviewed the 8200-bis draft, we couldn't see those fleas because we all knew what we meant to say.

Now that the SPRING WG has pointed out those fleas, we really need to fix them. I think that the right mechanism is a draft that updates 8200.

                                                                                                                   Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Sunday, March 1, 2020 11:00 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Errata Held for Document Update] RFC8200 (5933)

Hi everybody,

I've realised that we really do need a WG discussion & rough consensus on this issue. As a matter of fact, RFC 8200 is internally inconsistent, because there are three mutually incompatible statements (not just two as implied by erratum 5933):

>>                           before reaching the final destination.

So it's a complete oversight that this exception to the previous rule is not mentioned. That's additional to Fernando's statement that the DA field was intended to refer to the final DA in the routing header, which some people may disagree about. We goofed, despite all the discussion on 2460bis.

Regards
   Brian Carpenter

On 02-Mar-20 16:29, RFC Errata System wrote:
> The following errata report has been held for document update for 
> RFC8200, "Internet Protocol, Version 6 (IPv6) Specification".
> 
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5933_
> _;!!NEt6yMaO-gk!RKg8k5P9UUQs7aE1Be8zWfSJgETY9KoWesmSX3iXfdMV4AQKQ_owAh
> YkNYLZX3Yn$
> 
> Reported by: Fernando Gont <[email-masked]> Date Reported: 
> 2019-12-11 Held by: Suresh Krishnan (IESG)
> 
> Section: 4
> 
> Original Text
> -------------
> I am handling this based on the IESG Statement about processing of RFC 
> Errata for the IETF Stream 
> (https://urldefense.com/v3/__https://ietf.org/about/groups/iesg/statem
> ents/processing-rfc-errata/__;!!NEt6yMaO-gk!RKg8k5P9UUQs7aE1Be8zWfSJgE
> TY9KoWesmSX3iXfdMV4AQKQ_owAhYkNVDxIN-u$ )
> 
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!RKg8k5P9UUQs7aE1Be8zWfSJgETY9KoWesmSX3iXfdMV4AQKQ_owA
> hYkNeXrA8YD$

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RKg8k5P9UUQs7aE1Be8zWfSJgETY9KoWesmSX3iXfdMV4AQKQ_owAhYkNeXrA8YD$
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Tue, 3 Mar 2020 08:19:31 +1100

Hi Brian,

> as implied by erratum 5933):
<snip>

> which some people may disagree about. We goofed, despite all the discussion

Any changes, clarifications etc. would need to continue to allow RFC4302
IPsec AH verification to work. Otherwise AH would need to be changed too,
involving the ipsecme WG.

Regards,
Mark.

> Errata for the IETF Stream (
> https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/)
> >
> > "Changes that modify the working of a protocol to something that might
> be different from the intended consensus when the document was approved
> should be either Hold for Document Update or Rejected. Deciding between
> these two depends on judgment. Changes that are clearly modifications to
> the intended consensus, or involve large textual changes, should be
> Rejected."
> >
> > Some people might interpret the text in RFC8200 to mean the replacement
> text provided above in the erratum but others might read the text exactly
> as written ("until the packet reaches the node identified in the
> Destination Address field of the IPv6 header”). Given that the text in
> RFC8200 had consensus and it is impossible to tell after the fact if the
> proposed replacement text would have achieved consensus, I believe this
> erratum falls under the above category.
> >
> > The change proposed by this erratum has to be evaluated for correctness
> and consensus if and when there is an update of RFC8200.
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Mar 2020 12:30:00 +1300

On 03-Mar-20 10:19, Mark Smith wrote:
> Hi Brian,
> 
> On Mon, 2 Mar 2020, 15:00 Brian E Carpenter, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi everybody,
> 
> Any changes, clarifications etc. would need to continue to allow RFC4302 IPsec AH verification to work. Otherwise AH would need to be changed too, involving the ipsecme WG.

No, AH was already excluded from the discussion:
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-7.5

    Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 3 Mar 2020 10:44:47 +1100

On Tue, 3 Mar 2020, 10:30 Brian E Carpenter, <[email-masked]>
wrote:

> > On Mon, 2 Mar 2020, 15:00 Brian E Carpenter, <
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     Hi everybody,
> >

I don't think they can be claiming to use "IPv6" if AH won't work.

I think AH can serve as an RFC 8200 compliance checklist, and a
specification of what is and isn't allowed to be modified in flight. AH is
enforcement of RFC 8200 processing that should already be occurring without
the use of AH.

For example, AH declares Payload Length immutable. So EH insertion or
removal cannot occur.

If AH can be declared not applicable, then I think it means RFC 8200 can be
ignored in any way that suits. All fields are up for mangling,
reinterpretation and redefinition, while still claiming to be using "IPv6".

A specific statement saying AH doesn't apply means it can't apply, because
standard use of RFC 8200 IPv6 means AH can always apply.

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 2 Mar 2020 15:45:12 -0800

Brian,

Not everyone agreed that SRH should have been granted an exception to
defining how the EH supports AH. In any case,
draft-ietf-6man-segment-routing-header does not consider extension
header insertion/deletion, so the interaction of that with AH would be
a new discussion.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Mar 2020 13:15:56 +1300

Tom,
On 03-Mar-20 12:45, Tom Herbert wrote:
> defining how the EH supports AH. 

Nevertheless, that was declared to be the rough consensus and is
sitting in the RFC Editor queue.

> In any case,

Why? AH is simply out of scope for SRH-using domains. Given that SRH
insertion is forbidden, no packet can contain both AH and SRH.

AH is optional in RFC8504, so not supporting AH at all is compliant.

     Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 21:44:02 -0300

> header insertion/deletion, so the interaction of that with AH would be

PSP even violates draft-ietf-6man-segment-routing-header

---

From: Tom Herbert <[email-masked]>
Date: Mon, 2 Mar 2020 17:08:05 -0800

On Mon, Mar 2, 2020 at 4:16 PM Brian E Carpenter
<[email-masked]> wrote:
> Why? AH is simply out of scope for SRH-using domains.

That's not what the SRH draft says. It says "As such the SR Domain
does not rely on the
   Authentication Header (AH)" and "Future documents may define use of
SRH with AH and its processing.". That is not the same thing as saying
AH and SRH MUST NOT
>  Given that SRH
Brian,

That's not what the SRH draft says. It says "As such the SR Domain
does not rely on the Authentication Header (AH)" and "Future documents
may define use of SRH with AH and its processing." That is not the
same thing as saying AH and SRH MUST NOT both be present
simultaneously in a packet.

The point we're making here is that if insertion/deletion of extension
headers is defined, then the interaction with AH must be addressed.

Tom

---

From: Philip Homburg <[email-masked]>
Date: Tue, 03 Mar 2020 11:54:12 +0100

> RFC 8200 has some fleas on it. When we reviewed the 8200-bis draft,
> we couldn't see those fleas because we all knew what we meant to
> say.

It seems to me that the bigger question is whether there would be 
consensus to update RFC8200 to allow whatever SPRING wants to do.

To some extent I'm surprised by this discussion. We allow NAT64 which
violates core IPv6 specifications in serious ways. We happily write
specifications for NAT64 without granting an explicit exception.

And then for a relatively besign operation such as removing a routing
header, we have to be as strict as possible.

Ultimately, the important part is not what is written in RFC-8200.
The important part is whether there is consensus that whatever SPRING
tries to do a good thing or that it is damaging the internet.

---

From: Andrew Alston <[email-masked]>
Date: Tue, 3 Mar 2020 12:44:00 +0000

Philip,

While I'm very much on the fence about some of the rest of your email - and hence - will reserve comment for now - what is said above is something that deserves a response.  In order to evaluate what is a good thing, or what is damaging, there needs to be a clear demonstration of *why* it is so necessary.  My major issue here is that - despite request after request - we still do not have a clear demonstrated use case in my view that shows why this is necessary.  I point out that options have been put forward to move the contentious section of the document into a separate document - and let the rest move forward.  This was rebuffed - no reason given.  There have been requests many times over for solid reasons as to why doing this is actually necessary - again - rebuffed.

Perhaps if we really understood the necessity for this - alternative solutions could be found that would lead to some form of consensus - but - while they authors steadfastly refuse to make a solid case for this - we cannot evaluate the question you pose, and as such, the general rule in my view is - don't break things or change them - without good reason - do not fix what is not broken.

Just my thoughts

Andrew

---

From: Philip Homburg <[email-masked]>
Date: Tue, 03 Mar 2020 14:00:45 +0100

>    In order to evaluate
>    what is a good thing, or what is damaging, there needs to be a
>    clear demonstration of *why* it is so necessary.  My major issue
>    here is that - despite request after request - we still do not
>    have a clear demonstrated use case in my view that shows why
>    this is necessary.  I point out that options have been put
>    forward to move the contentious section of the document into a
>    separate document - and let the rest move forward.  This was
>    rebuffed - no reason given.  There have been requests many times
>    over for solid reasons as to why doing this is actually necessary
>    - again - rebuffed.

I don't understand what is going on there. It would be nice if there
would a clear draft that updates RFC 8200 and that clearly describes
why this change is necessary. It seems that the authors don't want to
do that and that they also want to advance all functionality together.

However, the lack of effort from SPRING doesn't mean that we should
spend a lot of time discussing what RFC 8200 is actually saying. Ultimately,
RFC 8200 is not set in stone.

---

From: Ron Bonica <[email-masked]>
Date: Tue, 3 Mar 2020 13:57:47 +0000

Philip,

I am working frantically to produce the draft that you are asking for. Please stand by.

                                                Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Philip Homburg
Sent: Tuesday, March 3, 2020 8:01 AM
To: [email-masked]
Subject: Re: [Errata Held for Document Update] RFC8200 (5933) 

>    over for solid reasons as to why doing this is actually necessary

I don't understand what is going on there. It would be nice if there would a clear draft that updates RFC 8200 and that clearly describes why this change is necessary. It seems that the authors don't want to do that and that they also want to advance all functionality together.

However, the lack of effort from SPRING doesn't mean that we should spend a lot of time discussing what RFC 8200 is actually saying. Ultimately, RFC 8200 is not set in stone.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UEiMp3cIO-YH17WXXo5J6e03gA3xjNX9EL7HPsQKnFtMmutgyGJWxYpp8Vp2Dn34$
--------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 3 Mar 2020 15:13:08 +0100

> specifications for NAT64 without granting an explicit exception.

Since an IPv6 application can not know if it talks to an IPv6 or an IPv4 endpoint behind a NAT64, I think this means IPv6 applications are forced to implement NAT traversal, and in essence can not make any assumptions about an end to end property of the network. It's very difficult to see why this is not detremental to the benefits of IPv6. I am digressing.

> tries to do a good thing or that it is damaging the internet.

Well said.

This reflects my sentiment too. RFC8200 is the core IPv6 specification and reflects what is required by every IPv6 implementation to interoperate.
We should not change the core specification to accommodate whatever consenting adults chose to do in a limited domain.
The purview of spring is to ensure that the mechanism is described and does not have any unintended collateral damage (with the help from 6man).
No update to RFC8200 is needed.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Mar 2020 10:43:20 +1300

>> we couldn't see those fleas because we all knew what we meant to

I didn't know what we meant to say, because I never thought for one
moment how the text applied to routing headers, where the destination
address essentially becomes a variable instead of a constant, and where
the Segments Left field is mutable by construction. So it isn't a "flea";
IMHO it's a major omission. (I feel a bit guilty, because we first missed
it in RFC7045.)

> consensus to update RFC8200 to allow whatever SPRING wants to do.

SPRING is not asking for an update to 8200; their claim is that it
already allows the PSP action. You might disagree, of course.
 
> specifications for NAT64 without granting an explicit exception.

As a matter of fact, many of us are extremely unhappy about NAT64, but
it's forced on us by operational requirements.
 
> tries to do a good thing or that it is damaging the internet.

IMHO the questions of principle (does it violate the words in RFC8200,
and are those words correct?) are much less important than Robert Raszuk's
question: what harm does this do? And we have the answers to that, I think:

- doesn't harm PMTUD, because making a packet shorter on the last hop can't
possibly harm PMTUD.

- doesn't describe AH rules (which fields are mutable), but AH is not used in
SRH domains.

- may affect OAM mechanisms.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Mar 2020 19:46:12 -0300

On 3/3/20 18:43, Brian E Carpenter wrote:
[....]
> already allows the PSP action. You might disagree, of course.

FWIW, segment-routing-header also argued that en-route insertion was 
allowed.

[....]
> - may affect OAM mechanisms.

FWIW, one would expect that whether this functionality violates RFC8200 
should be connected with whether this causes harm.

If it doesn't then RFC8200 is being overly prescriptive, and should be 
relaxed (updated)

If it does cause harm, and violated RFC8200, then that might be an 
indication that a different solution should be evaluated.

The requirements in RFC8200 sets expectations on what happens to IPv6 
packets. Encouraging a disconnect between what the spec says, and what 
actually happens (particularly when it's us doing that) is, IMO, harmful.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Mar 2020 19:53:37 -0300

On 3/3/20 11:13, [email-masked] wrote:
[....]
> We should not change the core specification to accommodate whatever consenting adults chose to do in a limited domain.

THe IETF hasn't embraced any concept of limited domains. We don't have 
"IPv6 for the datacenter", "global IPv6", or "IPv6 for limited domains".

> The purview of spring is to ensure that the mechanism is described and does not have any unintended collateral damage (with the help from 6man).

If spring wants to describe what a vendor has done, then Informational 
or Experimental might be the right tracks. And the IESG should probably 
add a nice boilerplate to the front page, stating that the document 
doesn't represent IETF consensus, and that it violates existing standards.

Thanks,

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 4 Mar 2020 05:43:53 +0000

Hi Brian,

Please see in-line.

Thanks

Regards … Zafar

<snip>

[ZA] As discussed in [https://mailarchive.ietf.org/arch/msg/spring/Y1D6AKAtrSZBBFWbxD1T3OLZYy4/]…
The IPv6 OAM tools will mimic the data packets and send OAM probes encoding the PSP SID in the packet.
The penultimate node does not, cannot and should not differentiate between the data packets and OAM probes and executes the exact same PSP SID.
None of the IPv6 OAM tools has any dependency on the SRH presence.
I took an AI to add clarification in the OAM draft. I will add the text and share the revision.

Thanks

Regards … Zafar

    Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Mar 2020 08:21:23 +0100

> On 3 Mar 2020, at 22:43, Brian E Carpenter <[email-masked]> wrote:
> 

You should not feel guilty.
Isn’t the IETF mantra to write specifications to ensure interoperability. The goal isn’t to write enough legalese to prohibit future uses (or abuses) of the specifications. De jure standards (would require a significant change to organizational structure) and compliance certification?

In addition rfc8200, has only a place holder for source routing. It was expected that details would have to be specified in the documents defining the new source routing mechanisms. 

I don’t think you should have been expected to have the foresight and imagination to believe it feasible that someone would invent a source routing header that with network programming changes the basic premise of destination based forwarding in IP. 

Cheers 
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Mar 2020 09:01:48 -0300

On 4/3/20 04:21, Ole Troan wrote:
> Isn’t the IETF mantra to write specifications to ensure interoperability. The goal isn’t to write enough legalese to prohibit future uses (or abuses) of the specifications. 

Isn't there a procedure to update existing specs, when needed?  -- 
that's what some of us have been arguing about...

Thanks,

---

From: [email-masked]
Date: Wed, 4 Mar 2020 13:43:59 +0100

> Isn't there a procedure to update existing specs, when needed?  -- that's what some of us have been arguing about...

I have indeed seen that argument repeated over the last few hundred messages.
Yes, there is a procedure.
No, I am not convinced that RFC8200 requires any change.

Best regards,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Wed, 4 Mar 2020 20:01:58 +0000

Brian,

I think a better formulation might be:

	 - PSP breaks anything that relies on the immutability of the Payload Length and Next Header fields
	- AH relies on the immutability of the Payload Length and Next Header fields, but AH and SRH are incompatible anyway
	- We don't know what else relies on the immutability of the Payload Length and Next Header fields.

If operators are lucky, nothing will break. If they aren't lucky, they will be unlucky.

                                                      Ron

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Tuesday, March 3, 2020 4:43 PM
To: Philip Homburg <[email-masked]>; [email-masked]
Cc: Ron Bonica <[email-masked]>
Subject: Re: [Errata Held for Document Update] RFC8200 (5933)

On 03-Mar-20 23:54, Philip Homburg wrote:
>> we couldn't see those fleas because we all knew what we meant to say.

I didn't know what we meant to say, because I never thought for one moment how the text applied to routing headers, where the destination address essentially becomes a variable instead of a constant, and where the Segments Left field is mutable by construction. So it isn't a "flea"; IMHO it's a major omission. (I feel a bit guilty, because we first missed it in RFC7045.)

> consensus to update RFC8200 to allow whatever SPRING wants to do.

SPRING is not asking for an update to 8200; their claim is that it already allows the PSP action. You might disagree, of course.
 
> specifications for NAT64 without granting an explicit exception.

As a matter of fact, many of us are extremely unhappy about NAT64, but it's forced on us by operational requirements.
 
> tries to do a good thing or that it is damaging the internet.

IMHO the questions of principle (does it violate the words in RFC8200, and are those words correct?) are much less important than Robert Raszuk's
question: what harm does this do? And we have the answers to that, I think:

- doesn't harm PMTUD, because making a packet shorter on the last hop can't possibly harm PMTUD.

- doesn't describe AH rules (which fields are mutable), but AH is not used in SRH domains.

    Brian