e2e [was: Non routable IPv6 registry proposal]

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 23 January 2021 21:48 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 66ADE3A0C64 for <ietf@ietfa.amsl.com>; Sat, 23 Jan 2021 13:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id sjQD9twHyOBZ for <ietf@ietfa.amsl.com>; Sat, 23 Jan 2021 13:48:03 -0800 (PST)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266913A0C5D for <ietf@ietf.org>; Sat, 23 Jan 2021 13:48:03 -0800 (PST)
Received: by mail-pl1-x62f.google.com with SMTP id e9so5326152plh.3 for <ietf@ietf.org>; Sat, 23 Jan 2021 13:48:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iWIw8xj49SIFNXxFix6L7vQ6Pgurg0uaihpGuRFdi74=; b=JVZXN6KHL/6TuoxXYYlvFViz/CK+h9aBVs/+ydKItBUOZNI2ZAICQjsD2GMqmkrJLY 5HlhXV/MeLfCSI7KouKaVCM2XfT3jAlzHqaXg3hoL9SQOOl82r6sTjLheoXrUCKPX1qf b+zC0T5ff+Fc1+rjVpA3MswsoOgVmVH7miIrFOGWbQonoy/AtSN31k/Qa+UL8jkPSBUj qSzcW9cjyECEY7fiqAxo/Dfi7brli+hxM7QxA9LAUKUj60yv5ocvXGQOqEkfJB6iSNFo JPeEBBC3Fujwfw9L8BxJcDivDjtxoaAABdC7+9d3IDhMTsODDSmplfnWC2zJ+yNqi5wE hg8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iWIw8xj49SIFNXxFix6L7vQ6Pgurg0uaihpGuRFdi74=; b=r6ocJtnS5A4DKgPFTwFNAB2SdU/HZrFGEsubFJTXH0y43lvoZrueP/KZttTQHHljvv akd9UenI3J85ZeirCVCv5xwsYKfdr3RmbPhgVO4uIR1llkeGd9WEiIqemPpZWKOLJyBY iTgtEoyF1BhXahkNW75c27DNFadslrdbBbM+sgR7M47+CdpF8GjDUmW0XPWWeRbp5ILM Qc3PilF2Wuybhlrqt8JU5aoaV3DFHVUNm3oN9Z7p6AcObg4ka2RNTbcqsA44oWYga3fz kE26BT+qCsU71SbZww9WPfZ0IYpRJTzgU2jRPmNlDNecAHpf8IycWGiiZ8C+2IlbkzdL 1Mcw==
X-Gm-Message-State: AOAM530G0A/SiBCxfvjtCnXlR/RnjahHMPzP0bd0LmcJYfNC/jAuE07m OIQLpxMnqi7vKSMDMTRFbx9crnnGUrbjAw==
X-Google-Smtp-Source: ABdhPJyqTecPkMbGnzdV4xMGy8wxkwvs/Le/WOK9dHjg6IvrgO0y0KRBhE9GqogBRM1O5he/YaRe8g==
X-Received: by 2002:a17:90a:9915:: with SMTP id b21mr13170481pjp.101.1611438482105; Sat, 23 Jan 2021 13:48:02 -0800 (PST)
Received: from [] ([]) by smtp.gmail.com with ESMTPSA id m18sm9528854pfd.206.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jan 2021 13:48:01 -0800 (PST)
Subject: e2e [was: Non routable IPv6 registry proposal]
To: Fernando Gont <fgont@si6networks.com>, Joseph Touch <touch@strayalpha.com>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
References: <CAMm+LwjNiE0P7RAVqzKMypNbh3=9BeqiWn_hGv3E=zX7-YmSXQ@mail.gmail.com> <72F969A9-AF94-47B6-B48C-B3CD4D9A7C72@strayalpha.com> <7cc9e38c-5a00-ec59-a8c2-10503cc40d50@si6networks.com> <CB1A6DF0-8CDD-495D-9F7B-80BF72F08C1E@strayalpha.com> <53d7190a-3e1f-66b3-0574-8e8fbb3a7a5e@si6networks.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <6d2f587f-6b8a-dfe0-04cd-cc66fcdf44dd@gmail.com>
Date: Sun, 24 Jan 2021 10:47:56 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <53d7190a-3e1f-66b3-0574-8e8fbb3a7a5e@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/l_ecMtOFe82v0U-5PCFAlYmID_c>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Jan 2021 21:48:05 -0000

On 23-Jan-21 20:36, Fernando Gont wrote:
> Hi, Joe,
> On 21/1/21 14:17, Joseph Touch wrote:
>>> On Jan 20, 2021, at 3:27 PM, Fernando Gont <fgont@si6networks.com>
>>>  wrote:
>>> On 20/1/21 17:25, Joe Touch wrote:
>>>>> On Jan 20, 2021, at 12:07 PM, Phillip Hallam-Baker 
>>>>> <phill@hallambaker.com> wrote:
>>>>> 0) Nowhere does the 'end to end' principle demand that the 
>>>>> source and destination addresses on an IP packet remain 
>>>>> constant
>>>> IP addresses is the only means for identifying an Internet 
>>>> endpoint per RFC 1122. While I agree that there may be utility of
>>>> having proxied endpoints (e.g. NATs) with effectively internal
>>>> addresses behind them, it doesn’t help the case to begin with
>>>> this inaccurate assertion.
>>> I'd have agreed with you. BUt since 
>>> draft-ietf-spring-srv6-network-programming has been approved by the
>>> IESG, you probably cannot make such assertion anymore.
>> One draft that doesn’t update or obsolete numerous others does not 
>> undermine 40 yrs of E2E.
>> Esp. when (AFAICT) that doc series never mentions how transport 
>> protocols are supposed to deal with indeterminate endpoint addresses
>>  in their pseudo headers or the impact to security protocols at the 
>> transport (not transport content) layer.
> One *internet-draft* certainly doesn't undermine E2E. However, I guess
> that an *RFC* published as a "Proposed Standard" probably does 
> (undermine) E2E? -- (draft-ietf-spring-srv6-network-programming has been 
> approved by the IESG).
> At the end of the day, I guess we cannot publish a PS that clearly
> breaks E2E, while at the same time claim or pretend that we keep/have 
> E2E....

Much as I had concerns about draft-ietf-spring-srv6-network-programming,
I think we should be clear about what e2e is about. It *isn't* about
idealised transparency or even about forbidding packet mangling.
For example, what we said in RFC1958 is:
"The basic argument is that, as a first principle, certain required end-
to-end functions can only be performed correctly by the end-systems
That wasn't the last word, of course: see RFC3724, for example.

Of course, that version of e2e does mean that any kind of packet
mangling needs to be checked to see if it harms the e2e principle.
For example, the e2e principle tells us that the decision to
retransmit a damaged or lost packet needs to be taken at the
originating host (which is why performance enhancing proxies are
obnoxious). And it tells us that decryption keys must only be
available at the final destination. But IMHO it *doesn't* tell us
that a routing header must not be deleted by the penultimate
hop, because it's of no value to the final destination anyway.

(Logically, it's also a no-op, because the final destination
ignores routing headers. Go figure.)

> (Full-disclosure: I was on the side of keeping E2E
> (https://www6.ietf.org/iesg/appeal/gont-2020-04-22.txt))
> Thanks,