Re: [arch-d] Fiddling with IP packets in the network, IPv6-style (Fwd: Question about SRv6 Insert function)

"S. Moonesamy" <sm+sdo@afrinic.net> Thu, 05 September 2019 08:53 UTC

Return-Path: <sm@afrinic.net>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01657120CDF for <architecture-discuss@ietfa.amsl.com>; Thu, 5 Sep 2019 01:53:15 -0700 (PDT)
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 or2D1hh9nql3 for <architecture-discuss@ietfa.amsl.com>; Thu, 5 Sep 2019 01:53:13 -0700 (PDT)
Received: from board.afrinic.net (board.afrinic.net [IPv6:2001:42d0:0:404::83]) (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 C81B4120CAA for <architecture-discuss@iab.org>; Thu, 5 Sep 2019 01:53:12 -0700 (PDT)
Received: from [102.115.170.8] (port=54191 helo=DESKTOP-K6V9C2L.afrinic.net) by board.afrinic.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <sm@afrinic.net>) id 1i5nVp-0005vp-P6; Thu, 05 Sep 2019 12:53:06 +0400
Message-Id: <6.2.5.6.2.20190905013002.11e9acd0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 05 Sep 2019 01:52:37 -0700
To: Fernando Gont <fgont@si6networks.com>, architecture-discuss@iab.org
From: "S. Moonesamy" <sm+sdo@afrinic.net>
In-Reply-To: <e1895609-e462-e47a-b408-568a5c5363b1@si6networks.com>
References: <a7b5255b-8570-0e4b-da17-7557e7ca18c1@si6networks.com> <e1895609-e462-e47a-b408-568a5c5363b1@si6networks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/2b8Hopo3x5hH0ssu-3DwLZIa5CA>
Subject: Re: [arch-d] Fiddling with IP packets in the network, IPv6-style (Fwd: Question about SRv6 Insert function)
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2019 08:53:15 -0000

Dear Fernando,
At 05:47 PM 04-09-2019, Fernando Gont wrote:
>There seems to be ongoing working group item in the spring wg
>(https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01)
>that essentially proposes the insertion of IPv6 Extension Headers by
>middle boxes in the middle of the network, which goes against a very
>explicit requirement in the IPv6 spec (RFC8200) -- that notes that EHs
>cannot be inserted in the middle of the network.
>
>This begs a number of questions (e.g., how come that one wg is working
>on something that goes against a spec that is not under its charter).

That would be an IETF process question instead of one about architecture.

>But given this is an architecture list, I wonder if anybody has a say on
>the topic? (including the IAB). Is that the way IPv6 is expected to
>work? What can we expect from IPv6?

The participants in that discussion have a say in the (existing or 
proposed) standards.  There is a discussion of extensions headers in 
RFC 7045.  There is the address allocation aspect which is also 
discussed in other venues, e.g. RIR venues.  There are the security 
and privacy aspects.  At this stage, it may be better to have the 
working group discuss the issues before requesting wider input.

Regards,
S. Moonesamy