Re: AUTH48 changes to draft-ietf-6man-rfc6434-bis-09

[Tim Chown <[e-mail]>]

> On 20 Dec 2018, at 10:14, Lorenzo Colitti <[e-mail]> wrote:
> 
> I'm saying there is no need to repeat that message in RFC6434. If we do repeat it, we should cite 6980.

OK, understood, but in 6434-bis we already say things like (for example):

" As per RFC 8200, when a node fragments an IPv6 datagram, it MUST
   include the entire IPv6 Header Chain in the first fragment."

or

"As recommended in [RFC8021], nodes MUST NOT generate atomic
   fragments"

So this is in a similar style.

Or should we prefix the text below with something like "To facilitate simple and
   effective countermeasures for Neighbor Discovery attacks...."

Or can you suggest alternative wording?

Tim

> On Thu, Dec 20, 2018 at 7:10 PM Tim Chown <[e-mail]> wrote:
> > On 20 Dec 2018, at 06:34, Lorenzo Colitti <[e-mail]> wrote:
> > 
> > On Thu, Dec 20, 2018 at 3:21 PM Suresh Krishnan <[e-mail]> wrote:
> >   There are two proposed (non-editorial) changes to be made to draft-ietf-6man-rfc6434-bis-09 during the AUTH48 period and I would like to check with the WG if anyone has objections to these changes. I personally think that these are reasonable changes to make.  If I do not hear any objections by end of day December 27th 2018 (AOE), I will approve these changes and send this along the RFC publication path.
> > 
> > Change 1) Text change in Section 5.4. 
> > 
> > Old:
> > Neighbor Discovery SHOULD be supported. RFC 4861 states:
> > 
> > New:
> > Neighbor Discovery MUST be supported with the noted exceptions below. 
> > RFC 4861 states:
> > 
> > Support. This clarifies that the only exceptions for ND are the ones written immediately below. That's pretty clearly the intent of the text already.
> >  
> > Change 2) New text in Section 5.4.
> > ...
> > As per RFC 6980, hosts MUST NOT employ IPv6 fragmentation for sending any of the following Neighbor Discovery and SEcure Neighbor Discovery messages: Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, Redirect, or Certification Path Solicitation.
> > 
> > Why? This new text text places a hard limit on the number and size of the options that may be inserted in such a packet, and provides zero rationale. That's not good for text in a BCP. I don't see why it needs to be included. It's already written in RFC 6980.
> 
> Well, RFC 6980 is standards track (not informational) and was published 5 years ago.  The principal rationale is in the abstract.
> 
> Are you aware of implementations that are still fragmenting such ND messages?
> 
> Are you suggesting we should deprecate RFC 6980. Either we believe it is good practice and encourage its adoption, if some implementations do still ignore it, or we say we no longer believe its applicable.
> 
> Tim
>