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