IETF Logo Mail Archive

Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft

Ole Troan <otroan@employees.org> Tue, 23 July 2019 19:08 UTC

Return-Path: <otroan@employees.org>
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 5DD311200CC; Tue, 23 Jul 2019 12:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 XFyXB37NwKOn; Tue, 23 Jul 2019 12:08:28 -0700 (PDT)
Received: from clarinet.employees.org (unknown [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906B21206B2; Tue, 23 Jul 2019 12:08:26 -0700 (PDT)
Received: from astfgl.hanazo.no (dhcp-8137.meeting.ietf.org [31.133.129.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 8C2A44E128F6; Tue, 23 Jul 2019 19:08:25 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 332AF194D804; Tue, 23 Jul 2019 15:08:24 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CAFU7BAS_XSLK8PL_B8ShNCjw8u1k+VoHzscTr4jkg7HOxnKoaQ@mail.gmail.com>
Date: Tue, 23 Jul 2019 15:08:23 -0400
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Fred Baker <fredbaker.ietf@gmail.com>, IPv6 Operations <v6ops@ietf.org>, 6man Chairs <6man-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <42690CE6-D3FB-409A-AF2E-04CDB7903DA0@employees.org>
References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> <ea7438f2-b917-60eb-88bc-a375246a0cf9@gmail.com> <CAFU7BAS_XSLK8PL_B8ShNCjw8u1k+VoHzscTr4jkg7HOxnKoaQ@mail.gmail.com>
To: Jen Linkova <furry13@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/AXojL0S70ZstJuke8dPiCgRyiY0>
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 19:08:30 -0000

> <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 believe this requires an update to RFC4861. And I don't see any reason why that work shouldn't happen in 6man.

Best regards,
Ole (6man co-chair).

v2.23.0 | Report a Bug | By Email