Re: SRH insertion vs SRH insertion + encapsulation

Ole Troan <otroan@employees.org> Sun, 08 September 2019 03:02 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 4FE7412018B; Sat, 7 Sep 2019 20:02:39 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 lfSaiS2ul38y; Sat, 7 Sep 2019 20:02:36 -0700 (PDT)
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 8AD8012013C; Sat, 7 Sep 2019 20:02:36 -0700 (PDT)
Received: from [IPv6:2a02:20c8:5921:100:2963:d4f5:b2b:705f] (unknown [IPv6:2a02:20c8:5921:100:2963:d4f5:b2b:705f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 68FEA4E11AC6; Sun, 8 Sep 2019 03:02:35 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-707D5B6A-9A6E-4F18-9C5A-192179F6EC67"
Content-Transfer-Encoding: 7bit
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Subject: Re: SRH insertion vs SRH insertion + encapsulation
Date: Sun, 08 Sep 2019 05:02:32 +0200
Message-Id: <32ED6621-3D17-4EC8-AC11-AFE64F05E6A9@employees.org>
References: <BYAPR05MB5463306B3328F460C2417764AEB50@BYAPR05MB5463.namprd05.prod.outlook.com>
Cc: Robert Raszuk <robert@raszuk.net>, Mark Smith <markzzzsmith@gmail.com>, draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, "6man@ietf.org" <6man@ietf.org>
In-Reply-To: <BYAPR05MB5463306B3328F460C2417764AEB50@BYAPR05MB5463.namprd05.prod.outlook.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
X-Mailer: iPhone Mail (17A5831c)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/5Bcbyto7zET5QwjVO-qnBOUeoBE>
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 Sep 2019 03:02:40 -0000

Ron,

> IMHO, EH insertion modifies the semantics of the IPv6 source address. Today, the IPv6 source address indicates the source of an IP packet and *ALL* of its contents. If transit routers are allowed to insert extension headers, downstream routers can no longer identify the source of a packet and all of its contents.
> 
>  
> 
> Granted, in some cases, transit routers are allowed to modify a packet (e.g., Hop Count, DHCP, mutable options). But there is a big difference between changing a field whose value is know to me mutable and inserting a new option.
> 

6296?

And I am pointing that out because of what feels like moral righteousness and hypocrisy to me, not because I think header insertion is a good idea or even doable. 

Ole