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

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Nov 2019 09:42:26 -0300

Hello, Jen,

Here are comments on the I-Ddraft-linkova-6man-grand-01.

Meta: I think this is a problem worth solving. Some might think of it as
 a minor annoyance... but if things evolve toward more transient
addresses (as in per-application addresses, and/or use-and-throw-away
addresses), this may be more of a recurrent problem, and a more
significant annoyance.

**** Technical: ****

>    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).

>  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.

>    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?

>    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.

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)

**** Editorial: ****

>    However when a host sends traffic to off-link destinations the
>    different scenario is observed. 

s/the/a/

> This document summarized
>    the proposed neighbor discovery updates to address the issue.

s/summarized/summarizes/

> 
>    SLLA: Source link-layer Address, an option in the ND packets
>    containing the link-layer address of the sender of the packet
>    ([RFC4861]).
> 
>    TLLA: Target link-layer Address, an option in the ND packets
>    containing the link-layer address of the target ([RFC4861]).
> 
>    GUA: Global Unicast Address ([RFC4291]).

Please remove the parenthesis, for consistence with the other bullets.

>    The reasoning behind dropping unsolicited Neighbor Advertisements
>    ("the recipient has apparently not initiated any communication with
>    the target") is valid for onlink host-to-host communication but, as
>    discussed in [I-D.ietf-v6ops-nd-cache-init] does not really apply for

s/does not really/it does not really/

> 
>> IT would would recover the cache entry and set the
>>    LLA to the one of the rightful owner.  
> 

s/IT/It/

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Jen Linkova <[email-masked]>
Date: Thu, 28 Nov 2019 11:36:30 +1100

Hi Fernando,
Thanks for your review!
Comments inline.

> 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.

> 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."

> 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...

> 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!

> This would mean no changes on clients, and just updates on routers.

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