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

I support the idea to adopt the draft and document the general problem that’s behind it.
The attack vectors on the router are part of that general problem.

As I understand Lorenzo ‘s point, the full solution probably belongs to 6man. We are now finding that we need to reconsider the reactive behavior of ND AR. Tricking the current model can improve things but only so far. 

Regards,

Pascal

> Le 23 juil. 2019 à 09:05, David Lamparter <equinox@diac24.net> a écrit :
> 
> +1
> 
> -David
> 
>> On Tue, Jul 23, 2019 at 08:02:30AM -0400, Timothy Winters wrote:
>> I also think this should be working group draft, as I mentioned at the mic
>> I'm happy to help survey what current implementations are capable of.
>> 
>> I also agree with Lozenzo last statement.
>> 
>> ~Tim
>> 
>> On Tue, Jul 23, 2019 at 7:39 AM Brian E Carpenter <
>> brian.e.carpenter@gmail.com> wrote:
>> 
>>> 1) Yes, we should *obviously* do this.
>>> 2) If the charter prevents that, fix the charter.
>>> 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.
>>> 4) In any case, if the IETF rules are alleged to prevent doing the obvious
>>> right thing, the IESG can vary the rules, as allowed by BCP9.
>>> 
>>> Regards
>>>   Brian Carpenter
>>> 
>>>> On 23-Jul-19 20:29, Fred Baker wrote:
>>>> In yesterday's meeting, the sense of the room and a discussion of
>>> charters at the mike suggested that draft-linkova-v6ops-nd-cache-init
>>> should become a working group draft. Doing so will require 6man to agree to
>>> let v6ops suggest specific changes to RFC 4861 under the rubric of
>>> "operational solutions", as discussed in the draft and
>>> https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-operational-considerations-00;
>>> the argument for not kicking those out to 6man is that the authors of RFC
>>> 4861 are no longer in a position to approve errata to it, which would be
>>> the other obvious approach (I'm not sure that's true of Erik Nordmark, but
>>> whatever). It would also need to be considered to update RFC 4861.
>>>> 
>>>> Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group
>>> draft?
>>>> 
>>>> Ron and I look through this thread next week and take the necessary
>>> action, whatever the outcome might be.
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> .
>>>> 
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops