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

[Gyan Mishra <[e-mail]>]

Jen

The changes that you are proposing to RFC 4861 have you tested in a lab environment to ensure no adverse consequences to the changes or collateral damage by changing something might break something else With ICMPV6 RS/RA state machine.

Here is a github link to a test done related to the override flag being set and ND cache resiliency when an address gets recycled. In this case the address is recycled to different Mac and so the override flag has to be set to update the entry.

https://gist.github.com/leblancd/e550d41cad5a1c0ecb81837dfbc93cc5

This relates to Section 3 and 3.1 avoiding disruption. So I understand you would set the override flag to clear if the address is optimistic but you don’t state to set the override flag if the address is Valid and preferred.  So this is a corner case with the optimistic DAD state you are addressing to not set the override flag to avoid disruption in case of duplicate address.  Have you been able to recreate this issue occurring in the lab with the current RFC 4861 stack.


Section 3.2

I am getting lost reading this section.  Where it says that the rightful owner does not use the address for communication.

Is DAD not complete and is the rightful address not used because the interface is in some other DAD state and not Valid/Preferred.  So the off link default traffic is not able to get back to the optimistic address.  The optimistic address is on the same subnet routable as long as RA RIO has been received.  

3.2. Neighbor Cache Entry Does Not Exist If there is no entry then it would be created/updated with the supplied LLA and its state set to STALE. In that case as soon as the entry is used for sending traffic to the host, the entry state will be changed to DELAY and the Neighbor Unreachability Detection would be started and the rightful owner LLA will be entered in the cache. So in the scenario when the rightful owner does not use the address for communication then it might be a short (a few seconds) period  time when the data packets sent from the outside could reach the host
with the optimistic address. However it seems likely that hosts using Optimistic DAD would start sending/receiving traffic right away, so the first return packet would trigger the NUD process and rewrite the cache.
 

There are a lot of scenarios and permutations to think of with the updates mentioned in the draft.  Should  all of those be spelled out in this update or only corner cases with issues you have encountered that you are addressing with the update? 

 I think addressing all scenarios would help to ensure the change being made is not breaking another scenario and other with the RS/RA state machine.

Gyan

Sent from my iPhone

> On Nov 27, 2019, at 7:36 PM, Jen Linkova <[e-mail]> wrote:
> 
> 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
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------