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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Brian

I’ve participated to multiple corridor discussions on that topic and seen agreement that NA(O) to ff02::2 that proactively sets the cache in the routers is better than the current state of affairs which is a NS from the router that is broadcasted to all hosts at L2. 

For one thing it is a lot easier for the proxy infra to cancel on wireless interfaces where there is no router than a NS for which the target is unknown.

Another thing that the draft should do imho is a more comprehensive review of the problems that are associated with reactive. Coming from the router side I’m probably more sensitive to that than others and I’d de happy to contribute.

All that can be done in a round or 2, there is no black magic. I wish to prove you right that it can be done in a matter of months.

Note that it will provide little difference to what we currently do with ND snooping, just will improve the chances to create the state in case the dad was lost. Our biggest problems with snooping are elsewhere and the need for the 6lo -type registration and the unicast lookup does not change a bit. 

All the best,

Pascal

> Le 23 juil. 2019 à 21:53, Brian E Carpenter <[e-mail]> a écrit :
> 
> As has been extensively discussed on another thread, we sadly lack a method
> of getting operational notes with *rough* consensus out quickly, because
> our process for BCP, or worse for standards track, can take years instead
> of weeks.
> 
> Y'all can prove me wrong by sending this draft to the IESG in a month
> or so, and then worry about updating RFC4861 at normal IETF speed.
> 
> (After writing that, I am a bit embarassed that RFC6343 took six months.)
> 
> Regards
>   Brian
> 
>> On 24-Jul-19 07:19, David Lamparter wrote:
>>> 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
>> .
>> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops