Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 07 December 2019 14:13 UTC

Return-Path: <alexandre.petrescu@gmail.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 E3D8E1200A4; Sat, 7 Dec 2019 06:13:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 fmBZ8nYsqZFY; Sat, 7 Dec 2019 06:13:36 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 D519612001E; Sat, 7 Dec 2019 06:13:35 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xB7EDWvq032837; Sat, 7 Dec 2019 15:13:32 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 77CB4200EC4; Sat, 7 Dec 2019 15:13:32 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 600A8200BB4; Sat, 7 Dec 2019 15:13:32 +0100 (CET)
Received: from [10.11.240.4] ([10.11.240.4]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xB7EDVa4026580; Sat, 7 Dec 2019 15:13:31 +0100
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Subject: Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)
To: Sander Steffann <sander@steffann.nl>, Robert Raszuk <robert@raszuk.net>
Cc: rtg-ads <rtg-ads@ietf.org>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>
References: <BN7PR05MB56998A05469327E759B5B671AE5D0@BN7PR05MB5699.namprd05.prod.outlook.com> <3AD3BD11-8C34-41FE-B88F-49A9F2561D78@cisco.com> <BN7PR05MB569946D6AA5C6B78AFC05F6BAE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <8DEDE597-B7B0-48F5-959E-69757315C2AC@employees.org> <BN7PR05MB56996FFC117F512EEA04AFC8AE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <4FAB68A3-C533-471D-94D0-3F6EB1F32FC1@employees.org> <1e36a492-5931-02de-cf85-63339522b13a@si6networks.com> <F6DD2C7C-DBBF-4B48-B890-3C86005FB9CF@employees.org> <bb3be82d-8ea7-6c29-ad0a-61b491ee997d@si6networks.com> <8A9BC46E-A018-41C0-BE47-4BABC30EFE79@employees.org> <20191205222740.GA9637@ernw.de> <C7BCB0CF-1CA3-4CA8-9E71-13A013955938@employees.org> <E3C0E460-9329-40B1-ACF6-B9D8F6E2B3DF@steffann.nl> <CAOj+MMHEb4c_bGH-sV9LC+baHJZisTsXUMpTJNbR1j-YEcyqwA@mail.gmail.com> <741EB111-DA80-4895-A7E3-3B71836E6176@steffann.nl>
Message-ID: <17f92692-9566-78f2-9d84-ba685b6ab63b@gmail.com>
Date: Sat, 07 Dec 2019 15:13:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0
MIME-Version: 1.0
In-Reply-To: <741EB111-DA80-4895-A7E3-3B71836E6176@steffann.nl>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/eArj-TzlYs1ZECxNumjMLgdiseg>
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: Sat, 07 Dec 2019 14:13:38 -0000


Le 06/12/2019 à 17:21, Sander Steffann a écrit :
> Hi Robert,
> 
>> To your specific first question this is very popular deployment 
>> model ... just look at SDWANs. So Internet is just a L3 transport 
>> for all routers in your administrative domain or global WAN. Spot 
>> on. I do sincerely hope that whatever the result be of this debate 
>> all features will be legal to run on my boxes regardless how I 
>> choose to interconnect them.
>> 
>> As (Internet) transit boxes would never be destination addresses
>> of the outermost header what problem do you see running anything
>> one likes on R1 or R2 or R3 and transporting it via open Internet
>> or perhaps some third party networks ?
> 
> So this is basically a tunnel over the open internet with all tunnel 
> endpoints in the same (or cooperating) administrative domain. In
> that case it's indeed up to the participants to deal with and debug.
> 
> So the tunnel model I don't mind. Can we be certain it indeed fits 
> all deployments and leaking isn't possible. Theory and practice are 
> the same in theory, but not in practice :)

YEs, a tunnel is a quantum leap between layers, a wormhole between
Universes; a tunnel makes possible what otherwise can not be imagined:
get restricted web content from a country as if one were there.


The limited domain draft does set a perspective with respect to tunnels,
although one might wonder whether questions like whether two limited
domains connected by a tunnel make for a single limited domain (a
reducibility principle).

Alex

> 
> Cheers, Sander
> 
> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>