Re: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

[Andrew Alston <[e-mail]>]

Mark,

I seriously wonder as I see all this if it wasn’t a mistake to not declare srv6 an entirely new protocol with a new protocol number back at the start of this.

Because it looks more and more like Robert was right when he said that srv6 was not ipv6 - that or we seem to have forgotten the very basics of standardization.

The problem here is that it seems to be a slow drift - and the delta between these minor corruptions of each aspect of the specification in each new draft is small enough that we seem to be content to let it slide.  Unfortunately each time this happens - the delta between the original spec and whatever we have by the time we take all of this combined is well - rather large.

Sooner or later we are going to have to decide - continue to allow the protocol to mutate while still claiming it is ipv6 - or do what maybe should have been done in the first place - give it a new protocol number and let people decide if they want ipv6 or whatever this is.

Andrew

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: ipv6 <[e-mail]> on behalf of Mark Smith <[e-mail]>
Sent: Sunday, October 17, 2021 2:58:08 AM
To: Michael Richardson <[e-mail]>
Cc: 6man WG <[e-mail]>; SPRING WG <[e-mail]>
Subject: All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

On Sun, 17 Oct 2021, 06:36 Michael Richardson, <[e-mail]> wrote:
>
> Mark Smith <[e-mail]> wrote:
> > In fight changing DAs also will break AH protection of the IPv6 header.
>
> AH is dead. It's been dead for decades.
> I say this as an IPsec enthusiast who wishes this wasn't true.
> But it is.


Then all IPv6 field immutability while the packet is in flight is also dead.

"Controlled domain" == redefine any field, field semantics, and field
processing we like in an existing protocol, yet claim we're still
using the original protocol.

That has been tacitly endorsed via standards track RFC8986. The Next
Header field is not supposed to be modified in flight per internet
standard RFC8200, yet standards track RFC8986 specifies the behaviour
via PSP.

This SRH compression ID is redefining the IPv6 DA field semantics. It
encodes multiple network hop destinations in the single IPv6
destination address field.

Structured Flow Label -
https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/<https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label>
is redefining the IPv6 flow label field.

This will be an operational nightmare in the future, when there are
multiple applicable RFCs that conflict with each other. I don't want
to have to spend time getting into arguments with vendors about which
protocol variant RFC their implementation should or shouldn't have to
comply with while I have 1000s, 10s or 100s of 1000s of customers
off-line.

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