RE: Next steps on Extension Header Insertion

<mohamed.boucadair@orange.com> Thu, 03 November 2016 07:45 UTC

Return-Path: <mohamed.boucadair@orange.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 A2B2E129448 for <ipv6@ietfa.amsl.com>; Thu, 3 Nov 2016 00:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.195
X-Spam-Level:
X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_GREY=0.424] autolearn=no 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 lHPf-ltW2U0k for <ipv6@ietfa.amsl.com>; Thu, 3 Nov 2016 00:45:41 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F258126CD8 for <ipv6@ietf.org>; Thu, 3 Nov 2016 00:45:40 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 6BFE92643CF; Thu, 3 Nov 2016 08:45:38 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3EB3A4C099; Thu, 3 Nov 2016 08:45:38 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0319.002; Thu, 3 Nov 2016 08:45:37 +0100
From: mohamed.boucadair@orange.com
To: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Subject: RE: Next steps on Extension Header Insertion
Thread-Topic: Next steps on Extension Header Insertion
Thread-Index: AQHSMITR4SJ7rSjJuEijqI67+Sjw4KDG6oQA
Date: Thu, 03 Nov 2016 07:45:37 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DA995A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <B291E9E6-A803-423F-BFA5-87A74DCFB784@gmail.com>
In-Reply-To: <B291E9E6-A803-423F-BFA5-87A74DCFB784@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dYhoPXKVsqbD0Frz6nf4VdTTK6M>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 03 Nov 2016 07:45:42 -0000

Dear Bob,

I don't see evidence for (A). I'm tempted to live with (C). 

(B) may be good to have, but some of the issues apply also for encapsulation. Identifying issues that are unique to EH insertion would be valuable.

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Bob Hinden
> Envoyé : jeudi 27 octobre 2016 21:03
> À : IPv6 List
> Cc : Bob Hinden
> Objet : Next steps on Extension Header Insertion
> 
> Hello,
> 
> The chairs believe the bis drafts for moving the IPv6 to Internet Standard
> are close to being done with one exception, text in rfc2460bis on
> Extension Header Insertion.  This topic has been discussed extensively on
> the list and in working group sessions.  Prior to declaring a consensus
> and advancing the documents to the IESG we would like some feedback from
> the working group.
> 
> The current text regarding header insertion in draft-ietf-6man-rfc2460bis-
> 07.txt (and has been there since the -05) is:
> 
>   The insertion of Extension Headers by any node other than the source
>   of the packet breaks PMTU-discovery and can result in ICMP error
>   messages being sent to the source of the packet that did not insert
>   the header.
> 
>   The current approach to allowing a header to be inserted is to
>   encapsulate the packet using another IPv6 header and including the
>   additional extension header after the first IPv6 header, for example,
>   as defined in [RFC2473].
> 
> Based on recent face to face and mailing list discussions, we think the
> text could be improved as follows:
> 
>   The insertion of Extension Headers by any node other than the source
>   of the packet causes serious problems.  Two examples include breaking
>   the integrity checks provided by the Authentication Header Integrity
>   [RFC4302], and breaking Path MTU Discovery and can
>   result in ICMP error messages being sent to the source of the packet
>   that did not insert the header.
> 
>   One approach to avoid these problems is to encapsulate the packet
>   using another IPv6 header and including the additional extension header
>   after the first IPv6 header, for example, as defined in [RFC2473]
> 
> The change in the first paragraph is more accurate as it notes there is
> more than one problem.  The change in the second paragraph makes it clear
> that encapsulation isn’t necessarily the only approach.
> 
> Our current take after reviewing the discussion in Berlin and on the
> mailing list we think there is consensus on the first paragraph as it
> accurately describes the issue with header insertion.  There is a much
> rougher consensus on the second paragraph, but don’t see it as the real
> issue which is the first paragraph.
> 
> While we both think that the intent of IPv6 was not to support header
> insertion we don’t see there being a consensus in the working group ban it
> outright as was proposed in the -01 draft:
> 
>   Extension headers must never be inserted by any node other than the
>   source of the packet.  IP Encapsulation must be used to meet any
>   requirement for inserting headers, for example, as defined in
>   [RFC2473].
> 
> We think the choice before the working group at this point is to either do
> something like the proposed text, or to not say anything at all about this
> topic.  This would be no change from RFC2460.   We would like your
> feedback on these choices between now and 13 October.  We have created a
> survey so we can better gauge where the working group is.  We are hoping
> that by using the survey, we will get more responses then by email alone.
> 
> To summarize, we think there are three choices.
> 
> (A) Banning header insertion outright:
> 
>   Extension headers must never be inserted by any node other than the
>   source of the packet.  IP Encapsulation must be used to meet any
>   requirement for inserting headers, for example, as defined in
>   [RFC2473].
> 
> (B) Describe the problems caused by header insertion:
> 
>   The insertion of Extension Headers by any node other than the source
>   of the packet causes serious problems.  Two examples include breaking
>   the integrity checks provided by the Authentication Header Integrity
>   [RFC4302], and breaking Path MTU Discovery and can
>   result in ICMP error messages being sent to the source of the packet
>   that did not insert the header.
> 
>   One approach to avoid these problems is to encapsulate the packet
>   using another IPv6 header and including the additional extension header
>   after the first IPv6 header, for example, as defined in [RFC2473]
> 
> (C) Not say anything at all about header insertion in rfc2460bis
> 
>   [No text in rfc2460bis about header insertion]
> 
> Note: If in case (B) or (C), it might be good to write a new draft that
> describes the issue in depth and makes recommendations.  We could then see
> if we can build a consensus around a draft like that, but it would be
> separate from the effort to move the IPv6 specifications to Internet
> Standard.
> 
> Please fill in the poll at
> 
>     https://www.surveymonkey.com/r/QG5QPVR
> 
> before November 4, 2016.  The poll allows you to express you preference
> for each choice, with 1 being the highest preference, and 3 being the
> lowest.  We will publish the results after the poll closes.
> 
> Thanks,
> Bob & Ole
> 
> 
>