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

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492