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

Robert Raszuk <robert@raszuk.net> Thu, 27 February 2020 23:04 UTC

Return-Path: <robert@raszuk.net>
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 5C27F3A0442 for <ietf@ietfa.amsl.com>; Thu, 27 Feb 2020 15:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 YDujQbmxnXz7 for <ietf@ietfa.amsl.com>; Thu, 27 Feb 2020 15:04:54 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 BCDC53A0768 for <ietf@ietf.org>; Thu, 27 Feb 2020 15:04:53 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id q84so1017141oic.4 for <ietf@ietf.org>; Thu, 27 Feb 2020 15:04:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0rBv0363yaZdi8mqIVKBY4lDwldZi9eix+k78cHGhOQ=; b=faBjYQd67u9Muk3/aqbpv1k0sO8vkl0/jOOcQf+o+JwVTFZfIHrsC8s4U2l3w+Ccpa XLNdhgI+DcDxDt5fBTltnurJ4yvEIk9kCP0Drvv3AKjm66jxe3ThqAFwSwIp3f5QXnYo XNDGj4yh8gK+ba3MUF4F/JVQXdB+31swKafkfrenI/aO9E9XD9ichvhmjopyS6eFDdp0 RsvZ7C6EF+drbG/qKE1fEiSwfdDneXezWBS0SkTuAJ9zR81mT6hbWK7Q7jm1GzEFLYZI uH6UL6wHc4LvthzA/rQZw2PtsPME7QP4UqREpovSu9Qw6NItACrQEk2ymS/BaYG64OS2 e1Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0rBv0363yaZdi8mqIVKBY4lDwldZi9eix+k78cHGhOQ=; b=o4bs08anCu1FHtCY45Sf4l56+KREVnH7zbAK+/bu5B2/eTGE5R9xqioKfY5dTbWMtM 05mJu4qjnyC9jBJhAyynX5wHemArjZngbdBy7JVLU6qXH6c6oC0uixU9VNK3hePVMJBL KZYh9nzPTNjQPi8XxJh8FJWKwJBHKsV3I8XlPBGzWHjHevY+VPKADcigsQX4G1vmONWD XhL3Zt6au90H9SQ4xIssJ9IfUgTRmgckNE8PVCEObrJQ0B3t7spiUun+1Q9sZnzVFWWC pOHQc7y7ZkBtoNjJaLVsSmw/zqbmfY8Xe+RoixBgcDBMInXMmSJ5+P//Ot4kWFqKAm2+ 0JfQ==
X-Gm-Message-State: APjAAAXdL2XdXwlAq7OOyxAL9ntx4/gFhXR1YFZtrSRtqNJVTnnXaVPg NXFln9mjGcuC8ycpkc1YPwNyExSFHzFR3hGljElDH8YO
X-Google-Smtp-Source: APXvYqxckpDm6rMBlY/6/RWqwiw4FCBXlwrWRgKjzMXv8kfdDaiZU/3yYVTSJkyCYwcbx++uL9M2xLKB4LWWB1KLw3k=
X-Received: by 2002:a05:6808:611:: with SMTP id y17mr1040604oih.146.1582844693064; Thu, 27 Feb 2020 15:04:53 -0800 (PST)
MIME-Version: 1.0
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> <CALx6S36wN7VEi_rxLC1ETcTvkGaPhs20KhQrGWAGGTrCL5OT+g@mail.gmail.com> <d41a94f5ede994b9e14605871f9f7140@strayalpha.com>
In-Reply-To: <d41a94f5ede994b9e14605871f9f7140@strayalpha.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 28 Feb 2020 00:04:43 +0100
Message-ID: <CAOj+MMFo=7G6ygCNEkwNXzzzdbYh7Aw6SzcjL_Atg6RGyDJdjA@mail.gmail.com>
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>, Internet Architecture Board <iab@iab.org>, architecture-discuss@iab.org, Internet Area <int-area@ietf.org>, IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aa3df0059f96bf07"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/1tY_uQC8-k-WLSCMfmNTsZ8gVDo>
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:05:02 -0000

Joe, all,

Just to clarify something Fernando purposely missed in his call for action:

All operations on the packets discussed in SPRING WG are happening NOT on
the original (end to end) packet header. They are all defined to happen
within new imposed outer encapsulated header (IPv6 in IPv6 to be precise).

So original packet just get's tunneled between various points of the
network. Last time I checked that operation is allowed by RFC2473.

Its subtle detail, but fundamental one to this entire context/discussion.

Kind regards,
R.


On Thu, Feb 27, 2020 at 11:54 PM Joe Touch <touch@strayalpha.com> 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.
>
> So the question isn't just what is wanted, it's what is feasible.
>
> Joe
>
>