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

Fernando Gont <fgont@si6networks.com> Thu, 27 February 2020 23:37 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF613A08AB; Thu, 27 Feb 2020 15:37:00 -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=ham 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 W5XB5qXZL7tV; Thu, 27 Feb 2020 15:36:59 -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 E66353A088E; Thu, 27 Feb 2020 15:36:58 -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 56CE382A8B; Fri, 28 Feb 2020 00:36:51 +0100 (CET)
Subject: Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
To: Joe Touch <touch@strayalpha.com>
Cc: Tom Herbert <tom@herbertland.com>, architecture-discuss@iab.org, Internet Architecture Board <iab@iab.org>, Internet Area <int-area@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> <d41a94f5ede994b9e14605871f9f7140@strayalpha.com> <69bd06b8-7eee-dfbc-5476-bba0f71ae915@si6networks.com> <3c307da7e8f52b7a29037a1084daf254@strayalpha.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <a24a3621-99f6-755d-c679-2061b9a67adf@si6networks.com>
Date: Thu, 27 Feb 2020 20:36:41 -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: <3c307da7e8f52b7a29037a1084daf254@strayalpha.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/ietf/FhY8fMBpconEMt6bMkqNH7bNcgA>
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: Thu, 27 Feb 2020 23:37:04 -0000

Joe,

What draft-ietf-spring-srv6-network-programming proposes is to remove a 
segment routing header (SRH) along the packet delivery path, before the 
packet arrives at the final destination. They call it PSP.

Before, folks have also proposed to insert Extension Headers (EHs) while 
packets are en-route to their intended destination, etc.

Thanks,
Fernando




On 27/2/20 20:21, Joe Touch wrote:
> EH isn't a HBH option or extension.
> 
> Joe
> 
> On 2020-02-27 15:06, Fernando Gont wrote:
> 
>> On 27/2/20 19:52, Joe Touch wrote:
>>> FWIW - there are separable issues here:
>>>
>>> - whether an IP header (or parts thereof) should be changed in transit
>>>
>>> AFAICT, the answer has always been yes, but limited to the 
>>> hopcount/ttl in the base header and hop-by-hop options in the 
>>> options/extension headers.
>>>
>>> - whether an IP header length can change in transit
>>>
>>> I see no reason why it can't become smaller, but if it can become 
>>> larger then PMTUD and PLPMTUD don't work.
>>
>> Besides AH (which obviously breaks), hosts typically try to validate 
>> that the error messages they receive correspond to something they 
>> actually sent.
>>
>> EH removal breaks that.


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492