IETF Logo Mail Archive

Re: Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

Bob Hinden <bob.hinden@gmail.com> Thu, 20 April 2017 17:23 UTC

Return-Path: <bob.hinden@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 5BBDC129B39; Thu, 20 Apr 2017 10:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 msvJ8IX7k2UH; Thu, 20 Apr 2017 10:23:55 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED1E129B2D; Thu, 20 Apr 2017 10:23:53 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id o21so40110990wrb.2; Thu, 20 Apr 2017 10:23:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=O3iMIHR0bzIbosJTGf4I+0nNHLpLFX3U9RHSrDc1yK0=; b=tCGijudyfv+tb5ty2ch1z8kPzANJeR3oBABbqI3rAFh/NrOS8fGFR4WIrmIfgDzDCR G7g4qCYm4SvzeuJ1YVDtTlDtBVq9xvRLBxNK/RnlkFNUA38amu/1VWqhP4NTP0bGL4dn 4yTxSOX/rpwkdJBFq9b+lCREmSad7t5Q7T/2a+91dNUQIdfDHVsTRBHjByfVaYylyDz4 ichs/Yn/vb24wh9kOZZl2X9lVm/U2B1KbAxS9TfAnvEw6N032hDvZ8OaU4chBUWXXEGv 55GO0Wcl9VpT3ATHV7vjbB/qpJZ8xetxDT2VrzQW+WYvom93g8stt6Kthg5wyGO4JI1N qWDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=O3iMIHR0bzIbosJTGf4I+0nNHLpLFX3U9RHSrDc1yK0=; b=Y+T551K/6rNgbN6UrbCGfTnR/H5IVTs3CarcnHN8TcWzJ98QSorxoEfmjKj0gkpNLJ ExBg5w0URv9+Gxl8hdZbfisD+4QEs5b72WGOwvZc2qlrblyNY9W5MCkcEDDBuEPmjQqX 0ih30hH7tGlrUWnhI8YrhX7W5b0qqzSco+Pa7xjHAbVEPjjk2FI9iATCywHPrWKz9aKT h0qk134tUzwLCpsSbwj28ErRSLc+jlNnv5JqrILPmdeD3pI8O2bEIxxPbnhv02bT1gNB zAlP5Fbz4KIImScMR2zRm0yq2HVVI7Mm/++1Hms+Uf9ddEKeR0A5IardiqGG3vvft9iU k1Ew==
X-Gm-Message-State: AN3rC/78xf0DqMcJXeBAAoaNYVddX72la82h7p92pLhJk1qm06Pnqd3H pqeXheJv7QlmVg==
X-Received: by 10.223.176.36 with SMTP id f33mr3581480wra.124.1492709032022; Thu, 20 Apr 2017 10:23:52 -0700 (PDT)
Received: from ?IPv6:2601:647:4d01:db10:9cf5:b82e:11d6:5b43? ([2601:647:4d01:db10:9cf5:b82e:11d6:5b43]) by smtp.gmail.com with ESMTPSA id w186sm8843519wme.26.2017.04.20.10.23.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 10:23:49 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <64E307CB-A01D-4BDA-A369-289E1BD5C43A@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_86A514B6-E149-4616-B4AE-F22C3B51CD5B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)
Date: Thu, 20 Apr 2017 10:23:44 -0700
In-Reply-To: <6532A4A6-D168-4E9A-A6E6-205E8D965A67@cisco.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Fernando Gont <fgont@si6networks.com>, "draft-ietf-6man-rfc2460bis@ietf.org" <draft-ietf-6man-rfc2460bis@ietf.org>, IPv6 List <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, IESG <iesg@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <A5628A89-3830-4851-87F1-AE8329597DAE@gmail.com> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <D7EE44C3-04DB-4CFD-836F-2BFA74A35268@employees.org> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <CA+MHpBr7aeuyd8h5n6U6Q4jD_gtLCKsPJUgQqQuhgkEE3DGwqg@mail.gmail.com> <D41A10C3-74D4-45EE-8161-C344CB30329A@kuehlewind.net> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <6532A4A6-D168-4E9A-A6E6-205E8D965A67@cisco.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/UHDVVeiXrzYKOUeXB00cM-lPbv4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 20 Apr 2017 17:23:57 -0000

Stefano,

> On Apr 20, 2017, at 10:09 AM, Stefano Previdi (sprevidi) <sprevidi@cisco.com> wrote:
> 
> 
>> On Apr 20, 2017, at 5:47 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
>> 
>> Fernando,
>> 
>>> On Apr 20, 2017, at 6:01 AM, Fernando Gont <fgont@si6networks.com> wrote:
>>> 
>>>> ….
>>>> 
>>>> Dropping unknown extension headers in transit networks is relatively
>>>> rare. With the HBH being an exception, with almost a 40% drop. (Note
>>>> that there are no HBH option that would make a lot of sense across
>>>> the Internet, so again chicken and egg.)
>>> 
>>> Based on RFC7872 ("Observations on the Dropping of Packets with IPv6
>>> Extension Headers in the Real World"), your statement is incorrect.
>>> 
>>> Transit routers do filter packets with EHs, whether known or unknown.
>> 
>> I think this confirms that the current text which recommends against defining new EH is correct.
> 
> 
> Well, in fact I believe it’s the exact opposite.
> 
> Definition of new EHs must be done carefully but I don’t see why it should be prevented, knowing also that transit routers would anyway filter EH-packets out (hence mitigate the impact of new EHs introduction).

The current text is:

   Defining new IPv6 extension headers is not recommended.  There has to
   be a very clear justification why any new extension header is needed
   before it is standardized.  Instead of defining new Extension
   Headers, it is recommended that the Destination Options header is
   used to carry optional information that must be examined only by a
   packet's destination node(s), because they provide better handling
   and backward compatibility.

Following this text is the recommended format for new extension headers if they are defined.

I think is inline with what you said, that is “done carefully” and not prevented.

Bob


> 
> EH is probably _the_ most innovative and powerful feature of ipv6.
> 
> s.
> 
> 
>> 
>> Thanks,
>> Bob
>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>

v2.23.0 | Report a Bug | By Email