Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft
David Lamparter <equinox@diac24.net> Tue, 23 July 2019 20:55 UTC
Return-Path: <equinox@diac24.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F3012097F; Tue, 23 Jul 2019 13:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 rqtUH7m5ldtD; Tue, 23 Jul 2019 13:55:56 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFBF1209CF; Tue, 23 Jul 2019 13:55:56 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from <equinox@diac24.net>) id 1hq1p7-000c5y-Af; Tue, 23 Jul 2019 22:55:49 +0200
Date: Tue, 23 Jul 2019 22:55:49 +0200
From: David Lamparter <equinox@diac24.net>
To: Ole Troan <otroan@employees.org>
Cc: Jen Linkova <furry13@gmail.com>, IPv6 Operations <v6ops@ietf.org>, 6man Chairs <6man-chairs@ietf.org>
Message-ID: <20190723205549.GG258193@eidolon.nox.tf>
References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <ea7438f2-b917-60eb-88bc-a375246a0cf9@gmail.com> <CAFU7BAS_XSLK8PL_B8ShNCjw8u1k+VoHzscTr4jkg7HOxnKoaQ@mail.gmail.com> <42690CE6-D3FB-409A-AF2E-04CDB7903DA0@employees.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <42690CE6-D3FB-409A-AF2E-04CDB7903DA0@employees.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/6aQB-PMRJhVnusXpRMT1PEHyAZw>
Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 23 Jul 2019 20:56:09 -0000
On Tue, Jul 23, 2019 at 03:08:23PM -0400, Ole Troan wrote: > > <brian.e.carpenter@gmail.com> wrote: > >> 3) I'm not convinced it needs to update 4861. If what it does is explain the conditions in which an RFC2119 "SHOULD" should be ignored, that is *not* an update to the standard. To me it sounds exactly like a Best Current Practice. > > > > That's was my impression as well, glad to see I'm not alone ;) > > > > "SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > > there may exist valid reasons in particular circumstances when the > > particular behavior is acceptable or even useful, but the full > > implications should be understood and the case carefully weighed > > before implementing any behavior described with this label." > > > > So I guess as long as we document the case and implications, > > recommending routers to have a configuration knob to ignore "SHOULD" > > is not violating RFC4861. > > Probably getting the document reviewed by 6man WG would make sense as > > well to ensure that implications are understood. > > We have decades of experience with gratuitous ARP in IPv4. Updating > IPv6 ND to also support (and make it recommended practice) gratuious > ND seems sensible. I think we're jumping the gun here, let's enumerate solutions first. > I believe this requires an update to RFC4861. And I don't see any > reason why that work shouldn't happen in 6man. Ack. However, "gratuitous ND" is only one possible fix here, and a costly one at that since it needs updates on both the host to send this new "gratuitous ND" as well as the router to understand and process it. This discussion about the meta of "SHOULD" is based on the router-only change in behaviour to listen to all DAD that hosts send already - and one vendor seems to already be doing it. What's your opinion on where that would go? -David
- [v6ops] draft-linkova-v6ops-nd-cache-init to work… Fred Baker
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Fernando Gont
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Lorenzo Colitti
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Brian E Carpenter
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Timothy Winters
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … David Lamparter
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Lorenzo Colitti
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Pascal Thubert (pthubert)
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Lorenzo Colitti
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … JORDI PALET MARTINEZ
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Igor Gashinsky
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Jen Linkova
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Fernando Gont
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Lorenzo Colitti
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Fernando Gont
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Fernando Gont
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Ole Troan
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Lorenzo Colitti
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … David Lamparter
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Fred Baker
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Jen Linkova
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … STARK, BARBARA H
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Pascal Thubert (pthubert)
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … David Lamparter
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Brian E Carpenter
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Pascal Thubert (pthubert)
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Eric Vyncke (evyncke)
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … David Lamparter
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Lorenzo Colitti
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … David Lamparter
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Ole Troan
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Pascal Thubert (pthubert)
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Lorenzo Colitti
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Ole Troan
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Fernando Gont
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Jen Linkova
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Mikael Abrahamsson
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Yannis Nikolopoulos
- Re: [v6ops] draft-linkova-v6ops-nd-cache-init to … Erik Nygren