Re: IPv6 header insertion in a controlled domain

otroan@employees.org Sun, 08 December 2019 16:19 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C077012008F for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 08:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 WWxRCxruTE3j for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 08:19:57 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B34D120052 for <ipv6@ietf.org>; Sun, 8 Dec 2019 08:19:57 -0800 (PST)
Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 414DF4E11B57; Sun, 8 Dec 2019 16:19:57 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id BE25E255480D; Sun, 8 Dec 2019 17:19:54 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: IPv6 header insertion in a controlled domain
From: otroan@employees.org
In-Reply-To: <8b9e34fe-7a7d-31eb-ce23-056f34c7ba8f@joelhalpern.com>
Date: Sun, 08 Dec 2019 17:19:54 +0100
Cc: 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <47EEC396-94F2-4F41-8416-1579D6F79961@employees.org>
References: <CALx6S3588ja9AZzBQ0dqwx0j-ki6A5tusye+odQKPyAyF+hEww@mail.gmail.com> <10E890EA-3278-44EE-881E-EBC91D419587@employees.org> <88287cb0-c0c3-f990-4dd7-338df87c7fb2@joelhalpern.com> <4E76C386-FB1E-4E48-814D-BB626466BEE3@employees.org> <CAO42Z2ze7tmkGh=E-YrPuJHMeD8V6EuxgjjaJ33iz+Ms3abNsA@mail.gmail.com> <ED9B7C60-ACDE-4107-A121-AE2DAEA6B640@employees.org> <8b9e34fe-7a7d-31eb-ce23-056f34c7ba8f@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/kK-M5H-85caq9OeRFG9r7wYRZwk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2019 16:19:59 -0000

Joel,

> Ole, as far as I can tell, to answer the apparently simple quesiton you propose "is there a s safe way to do header insertion?" we would need
> o a clear definition of the domain in which it is to be done
> o a clear definition of the participants
> o and a full re-examination of the discussion which led to the prohibition against doing so in RFC 8200
> 
> We do not have in front of us a document which achieves either of the first two bullets. Without that, it is very hard for us to perform the third bullet.

While I appreciate the filibustering, for this particular thread I am only interested in exploring if there is _any_ topology where header insertion can be considered workable.
The topology in question is as I stated initially, A -- B -- C. Using ULA addresses.
If we find that even in this case, you cannot do header insertion safely, then I think we can at least suspect that there is no topology where this can be done.
But so far I have not seen any technical argument for what would break in this case.

And after multiple documents and thousands of emails I'm pretty sure you also can reason quite well about this simplistic example.

Best regards,
Ole



> I note for example that the presentation in Sngapore did not disucss the implications or behaviors of hosts inside the Segment Routing v6 domain.  But the rfc-to-be explicitly includes hosts inserting the information in the original header.
> the presentation in Singapore did not discuss how SR header creators will deal with errors caused by in=-path header insertion, when the errors arrive at places that did not perform the insertion.
> 
> But there is a more important issue.  The usual IETF practice (not the rule, but a practice we have found to be good) is to ask what problem is being solved BEFORE we evaluate solutions.  There are many good reasons why we have found this helpful.  You seem to be asking for the opposite.
> 
> I find myself forced to repeat my question:  what benefit is header insertion bringing to justify working group consideration.
> I understand your earlier request not to repeat points.  But for me at least, it is very hard to answer your question without that.