Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

"C. M. Heard" <heard@pobox.com> Sun, 19 April 2015 01:19 UTC

Return-Path: <heard@pobox.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21641ACDC0 for <v6ops@ietfa.amsl.com>; Sat, 18 Apr 2015 18:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 0jPUYI3cC3G5 for <v6ops@ietfa.amsl.com>; Sat, 18 Apr 2015 18:19:34 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F771ACDBF for <v6ops@ietf.org>; Sat, 18 Apr 2015 18:19:34 -0700 (PDT)
Received: (qmail 2117 invoked from network); 18 Apr 2015 18:07:43 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Apr 2015 18:07:42 -0700
Date: Sat, 18 Apr 2015 18:07:42 -0700
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: v6ops <v6ops@ietf.org>
In-Reply-To: <D1567F3B.43843%evyncke@cisco.com> <5532BC9C.20600@gmail.com>
Message-ID: <Pine.LNX.4.64.1504181206360.2557@shell4.bayarea.net>
References: <552CD2CE.3070801@si6networks.com> <D1567F3B.43843%evyncke@cisco.com> <41AF40EF-C4CB-41F7-8BC4-567A02A49FF4@cisco.com> <D157BDE1.44CEE%evyncke@cisco.com> <5532BC9C.20600@gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/UoASvir1rGmAAnC0vi83sNgY08w>
Cc: Merike Kaeo <merike@doubleshotsecurity.com>, "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" <draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org>, Fernando Gont <fgont@si6networks.com>
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Apr 2015 01:19:34 -0000

On Fri, 17 Apr 2015, Eric Vyncke (evyncke) wrote:
> I would suggest a slightly stronger text:
> "The results presented in this document indicate that in the scenarios
> where the corresponding measurements were performed, the use of IPv6
> extension headers can lead to packet drops. We note that
> packet drops occurring at transit networks [are] undesirable
> and it is hoped and expected that this situation will improve over time."

I concur with this proposal (modulo correction in square brackets).  
It is consistent with RFC 7045, which reaffirms that intermediate 
nodes SHOULD process extension headers as described in RFC 2460 
(i.e., act upon the options in a Hop-by-Hop Options extension header 
and ignore all other extension headers).

> Should we say something around the lines of "... Undesirable except when
> Those packets cannot be forwarded without impacting the performance and
> the health of the network devices" ?

No.  From the standpoint of the user of the general internet, such 
drops by transit providers are never desirable.  They may in some 
cases be a practical necessity (e.g., due to inability to process 
Hop-by-Hop Options at wire speed), but they are still undesirable.

On Sun, 19 Apr 2015, Brian E Carpenter wrote:
> IMHO we should not be messing with that (or other) standards track
> statements in this Informational document.

Exactly.

//cmh