Re: Feedback on draft-linkova-6man-grand-01

[Jen Linkova <[e-mail]>]

Hi Fernando,
Thanks for your review!
Comments inline.

On Wed, Nov 27, 2019 at 11:42 PM Fernando Gont <[e-mail]> wrote:
> >    As the main purpose of sending unsolicited NAs upon configuring a new
> >    address is to proactively create a Neighbor Cache entry on the first-
> >    hop routers, the gratuitous NAs SHOULD be sent to all-routers
> >    multicast address (ff02::2).  Limiting the recipients to routers only
> >    would help reduce the multicast noise level.
>
> In the context of RFC8028, one might argue that you could simply send
> the unsolicited NAs unicast to the routers that advertised this prefix.
> This would:
>
>  * reduce multicast traffic
>
>  * also reduce the number of unnecessary entries in local routers (there
> would be no point to create entries for addresses configured for, say,
> 2001:2b8::/64 at Router A, if you will only use Router B as the default
> router for packets sourced from those addresses).

The main drawback of this approach is it would work in 50% of cases if
the network provides first-hop router redundancy. There is no
guarantee that the traffic is symmetrical - the host can easily choose
a router A as a default gateway but the return flow can reach the LAN
via the router B.
See https://tools.ietf.org/html/draft-ietf-v6ops-nd-cache-init-00#section-2.3.2.2

I'll update the text to clarify it.

> >  As the INCOMPLETE entry means that the router has
> >    started the ND process for the address and the multicast NS has been
> >    sent, the rightful owner is expected to reply with solicited NA with
> >    the Override flag set.
>
> I should re-check the spec. The NA would certainly have the solicited
> flag set. Although I'm not sure it woudl always have the override flag set.

It *SHOULD* unless it's anycast or the device is a proxy:
https://tools.ietf.org/html/rfc4861#section-7.2.4

" If the Target Address is either an anycast address or a unicast
address for which the node is providing proxy service, or the Target
   Link-Layer Address option is not included, the Override flag SHOULD
   be set to zero.  Otherwise, the Override flag SHOULD be set to one."

> >    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, hosts SHOULD silently discard the advertisement.
> >    There is no need to create an entry if none exists, since the
> >    recipient has apparently not initiated any communication with the
> >    target.  Routers SHOULD create a new entry for the target address
> >    with the link-layer address set to the Target link-layer address
> >    option (if supplied).  The entry its reachability state MUST also be
> >    set to STALE.  If the received Neighbor Advertisement does not
> >    contain the Target link-layer address option the advertisement SHOULD
> >    be silently discarded.
>
> Shouldn't this only happen if the "solicited" flag is not set?

Valid point. I do not see any harm is doing it for Solicited but I'm
happy to limit to unsolicited NA only...

> >    Announcing a new address to all-routers multicast address may inform
> >    an on-link attacker about IPv6 addresses assigned to the host.
> >    However hiding information about the specific IPv6 address should not
> >    be considered a security measure as it falls into 'Security through
> >    obscurity' category.
>
> I'd remove the "security through obscurity" bit, and note that this
> information is normally disclosed with dad, anyway, and not just to
> routers, but to all nodes.

Not *exactly* true if the network deploys all those smart WiFi devices
but it's more an operational consideration.
I'll update the text, thanks!

> Food for thought:
> Maybe routers could simply create the ND cache entries, if the entry is
> not present, when the corresponding DAD packets are received?
> This would mean no changes on clients, and just updates on routers.
> (me thinking out loud)

Please note that this draft does not discuss *all* possible
approaches. The operational issue and various solutions are documented
in https://tools.ietf.org/html/draft-ietf-v6ops-nd-cache-init-00.
Your proposal  'why not DAD' is discussed in
 https://tools.ietf.org/html/draft-ietf-v6ops-nd-cache-init-00#section-2.4

I should probably make it explicit in the Introduction section that
the readers of draft-linkova-6man-grand shall read the 6ops doc first.

-- 
SY, Jen Linkova aka Furry