Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

Jared Mauch <jared@puck.nether.net> Fri, 24 February 2017 03:05 UTC

Return-Path: <jared@puck.nether.net>
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 D1927129AF9; Thu, 23 Feb 2017 19:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 kgw40jKK6_oc; Thu, 23 Feb 2017 19:05:40 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id D5D9C129A9A; Thu, 23 Feb 2017 19:05:40 -0800 (PST)
Received: from [IPv6:2603:3015:3603:8e00:c505:8fff:dbfd:7e6f] (unknown [IPv6:2603:3015:3603:8e00:c505:8fff:dbfd:7e6f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id E9221540C70; Thu, 23 Feb 2017 22:05:23 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAKD1Yr2-yS-tX9Pe0Rk_74hnXa9Rc-yTHV0m=Kbi2q0wvYGgPg@mail.gmail.com>
Date: Thu, 23 Feb 2017 22:05:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D8C452B-FC3D-465A-A2CE-9ECD9E4F02F1@puck.nether.net>
References: <20170221101339.GC84656@Vurt.local> <CAKD1Yr33oQb=gMGaEM++hLgmMtxMdihiDrUihEsjs63vy8qRbA@mail.gmail.com> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <CAKD1Yr28iQHt0iuLvR3ndrT3Hfct=4k9dxjJeu3MAjDjOogEvA@mail.gmail.com> <CAL9jLaZgTp++PJ9KGHEWuPoVm6t3b8QfVDCEhz5h4fv-0fuUAA@mail.gmail.com> <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <CAKD1Yr3K+SJb_4ksZ96yNypVKJE-fXopuVaXNhhKp1gkh1=QEg@mail.gmail.com> <20170222144147.GC89584@hanna.meerval.net> <CAKD1Yr2n=ogFo7LJYgjcraoFxioQQzmo8HYxzNRJ10VA8xMVOg@mail.gmail.com> <20170222153129.GE89584@hanna.meerval.net> <CAKD1Yr2-yS-tX9Pe0Rk_74hnXa9Rc-yTHV0m=Kbi2q0wvYGgPg@mail.gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/X7ML0-amviVQwydWsGbpb4CMdm8>
Cc: draft-ietf-6man-rfc4291bis@ietf.org, 6man-chairs@ietf.org, 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>
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: Fri, 24 Feb 2017 03:05:42 -0000


> On Feb 22, 2017, at 10:56 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> 
> RFC6583-style attacks (of which the class addressed by RFC6164 is a subset) are low payoff and pretty easy to mitigate using very small changes to ND implementations

The duration of time it takes to roll out new code is measured in years in a backbone.  Some vendors are still missing negative-arp caching for v4 in 2017, so I’m having trouble treating this as a low-payoff attack.  Even when it’s not intended as an attack, the side-effects are well documented, and is something the IETF NOC team has experienced first-hand.

Not all vendors, hardware or implementations are equal, and convergence here takes some time.  Setting the right standard in the first place helps, and when doing a -bis, it’s furthermore important to incorporate the operational lessons learned.  If the WG decides to not listen, that’s certainly it’s prerogative but does not move the standards forward.

For me, this is just one of many things in IPv6 that requires servicing, so not the end of the world if this one doesn’t get fixed, but being overly prescriptive here is begging for trouble.

- Jared