Re: IPv6 header insertion in a controlled domain

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 08 December 2019 16:10 UTC

Return-Path: <jmh@joelhalpern.com>
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 C2228120047 for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 08:10:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 tJk78YxX5aZz for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 08:10:28 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E44F12001E for <ipv6@ietf.org>; Sun, 8 Dec 2019 08:10:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47WBBD1NZmz6G7bk; Sun, 8 Dec 2019 08:10:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1575821428; bh=6va5EUSw9fqR9Jchq8sVq9NEjmFkqFGxNCVx9sFjpdg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=W8t1FxTxF3U1L+EAhmR2F7+ZPgJZRYnLuIRVbxOG1TppLxy/iNe5b8mix61+mawSV X7TL2CGT/OxkbDA3mOcv3IuRadFKEF6fpJi9sgieO18Ur8F+M9FkFAt8v32Mp7PG5T 9SverpfUoHq/uPY4AaKLpofxcSAq+RKTLcTKh8Qo=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 47WBBC4vHgz6G7T8; Sun, 8 Dec 2019 08:10:27 -0800 (PST)
Subject: Re: IPv6 header insertion in a controlled domain
To: otroan@employees.org
Cc: 6man WG <ipv6@ietf.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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <8b9e34fe-7a7d-31eb-ce23-056f34c7ba8f@joelhalpern.com>
Date: Sun, 08 Dec 2019 11:10:25 -0500
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: <ED9B7C60-ACDE-4107-A121-AE2DAEA6B640@employees.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JqxFcKi3w0UhYiZwgMYfRQAUwDA>
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:10:30 -0000

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.

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.

Yours,
Joel

On 12/8/2019 4:24 AM, otroan@employees.org wrote:
> Mark,
> 
> [...]
> [renamed thread]
> 
>> Take an example of 3 routers A, B and C that is under the same control.
>> Traffic travels from left to right.
>>
>> A -- B -- C
>>
>> A has a tunnel to C using ULA source and destination.
>> A packet ingresses on A, is encapsulated and forwarded towards C.
>> A has for reasons unknown to us outsourced a function to B. Where B insert an extension header in the packet originated by A.
>> C is also in on the game, being a tunnel end-point, removing the encapsulating header and extension header.
>>
>> If you can leave the nuances of SR and the whatever they propose on the shelf for a minute.
>>
>> Do you agree in principle that this approach of "header insertion in a controlled domain" can be made to work,
>> and should be indiscernible from A inserting the extension header itself?
> 
> Yes, there are obviously many ways of skinning this cat.
> In this thread I don't want to try solve whatever problem the EH insertion camp wants solved. I don't think I understand it well enough.
> And I'm unconvinced the 6man group in general understands the underlaying routing problems leading to the proposed solution.
> What I was interested in exploring in this thread was if we could reach agreement that there in principle is a safe way of doing header insertion.
> 
> In my simple example above.
> Do you agree that in a controlled distributed system there is no perceivable difference between node A inserting the header or node B doing it?
> Conceptually you could think of it as a tunnel with muliple endpoints (although that's a bit hard to visualize ;-)).
> 
> Can we agree that inserting headers and changing the packet size among participating nodes in a distributed system is not inherently unsafe?
> As far as I can think of the only complication to be considered is that node A must be aware of packet size changes when doing PMTU estimation.
> (typically though in these types of networks, one simply declares that "MTU must be well managed. i.e. large enough".
> 
> Cheers,
> Ole
> 
>