Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Fernando Gont <fernando@gont.com.ar> Thu, 27 February 2020 22:50 UTC

Return-Path: <fernando@gont.com.ar>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808323A0143; Thu, 27 Feb 2020 14:50:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2TZqFZFJOjR; Thu, 27 Feb 2020 14:50:25 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EFC3A0128; Thu, 27 Feb 2020 14:50:25 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id F281680C8B; Thu, 27 Feb 2020 23:50:21 +0100 (CET)
To: Phillip Hallam-Baker <phill@hallambaker.com>, Tom Herbert <tom@herbertland.com>
Cc: Internet Architecture Board <iab@iab.org>, architecture-discuss@iab.org, Internet Area <int-area@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> <CALx6S36wN7VEi_rxLC1ETcTvkGaPhs20KhQrGWAGGTrCL5OT+g@mail.gmail.com> <CAMm+Lwg+4xMv=EKLfvmZMCgrQz31+38Fv0bYKeJ0fTB5vbXiaw@mail.gmail.com>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <35324c05-e1de-0186-36e3-081648c1c539@gont.com.ar>
Date: Thu, 27 Feb 2020 19:50:16 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAMm+Lwg+4xMv=EKLfvmZMCgrQz31+38Fv0bYKeJ0fTB5vbXiaw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/L2DNkPP9jrNaYt0QDvua9-4PDbk>
Subject: Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 22:50:28 -0000

Philip,

On 27/2/20 19:26, Phillip Hallam-Baker wrote:
> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert <tom@herbertland.com 
> <mailto:tom@herbertland.com>> wrote:
> 
>     Fernando,
> 
>     I think we need to be careful that IETF is labeled as a collection of
>     inflexible architectural purists. We know that standards conformance
>     is voluntary and we haven't seen the last time that someone, possibly
>     even a major vendor, will circumvent the system for their own
>     purposes.
> 
> 
> IP end to end does not mean the IP address is constant end to end. It 
> never has meant that and never will. An IP address is merely a piece of 
> data that allows a packet to reach its destination. There is no reason 
> to insist on it remaining constant along the path.

You seem to be missing the point I was trying to make.

We're talking about IPv6 routers doing heavy surgery on IPv6 packets, 
while en-route to destination.

And we are also talking about violating IETF specs at will, and 
circumventing IETF processes.

This does break things, make troubleshooting painful, etc.

AH may break
PMTUD may break
Error may reporting break


I'm not being purist. I'm just arguing that we probably can do better 
than simply rubber-stamping any hacks a vendor with big pockets may 
bring up.

Otherwise, I don't see the point of all this big structure.

For instance, we have an "Internet Architecture Board", which I guess 
have a say on things that affect architecture?

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1