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

[David Lamparter <[e-mail]>]

On Tue, Jul 23, 2019 at 06:59:23PM +0100, Fernando Gont wrote:
> On 23/7/19 12:39, Brian E Carpenter wrote:
> > 1) Yes, we should *obviously* do this.
> > 2) If the charter prevents that, fix the charter.
> 
> I'm all for fixing problems and getting stuff done. And, if there's no
> other way than fixing the charter, so be it.
> 
> However, it would seem to me that, the "bug" here is that we're
> defaulting to "6man wouldn't get this done, so let's do it elsewhere".

The discussion I see here is that we've located an operational issue
with the IPv6 neighbor cache on routers, we have several candidates for
fixing it, and each of these may or may not need a protocol change to go
through 6man.

Discussing whether any particular working group "gets things done" seems
tangential to the question at hand.

> IMO, should be willing to maintain its protocols, improve them, and fix
> problems where necessary.
> 
> If a BCP is to go against the protocol spec recommendation for the
> general case, that's an indication that the protocol should be updated.

Although I don't write the neighbour management code, I do write code
that operates routers and I have absolutely no concerns in understanding
that a particular "SHOULD" statement has turned out to be a bad choice
for the specific situation of first-hop routers.

Whether this is a specification change, to me, is decided by the intent.
The intent under consideration here is:

   When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, the advertisement SHOULD be silently discarded.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target.

The intent I see is that in most cases there's no point in having
devices consume memory, and the "SHOULD" is correct behaviour for hosts.
Routers *DO* "need to create an entry if none exists".  I don't see a
conflict with 4861's intent, which I take as "don't open yourself to DoS
attacks".  The router /will have the neighbor cache entry anyway/, just
with a delay, later, and the resulting annoyance.

4861 just failed to invoke the magic 8-ball correctly to make the
authors omniscient and recognize the specific circumstances under which
this SHOULD is maybe not the best idea.  This is implementation guidance
based on operational experience.  Just write it down and get it out
there.


-David