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

[Ron Bonica <[e-mail]>]

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



Juniper Business Use Only

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

On 03-Mar-20 23:54, Philip Homburg wrote:
>> 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.

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.)

> It seems to me that the bigger question is whether there would be 
> 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.
 
> 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.

As a matter of fact, many of us are extremely unhappy about NAT64, but it's forced on us by operational requirements.
 
> 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.

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