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

[Gyan Mishra <[e-mail]>]

Jen

After reading this draft again I agree this is a much needed draft to speed up ND cache entry creation and I fully support.  

Since IPv6 has ND cache state machine states incomplete, stale, delay, probe, reachable RFC 4861 for the ND cache entry to only get built with  NA in response to an NS.  With IPv4 the arp cache gets built immediately.  So with this draft with having the Gratuitous RA with override set, it creates NC so the TCP flow can start immediately rather then waiting for the receiver to send an NS to trigger NA for the entry to be created to start TCP flow.  

The document is well written and covers all the scenarios I can think of.  That’s great that you have it tested with Cisco IOS.

You covered the Optimistic DAD with the override not set following the same as RFC 4429  done with NA with override flag not set.

Only comment I have is with verbiage In section 4.1.1 below 

I think this is what you meant to write.  You copied the verbiage completely at the top where it says “there is no need to create entry”


UpDATED NEW TEXT: When a valid Neighbor Advertisement is received (either solicited or unsolicited), the Neighbor Cache is searched for the target's entry.  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.

Section 4.1.2 for preferred did you mean override should be set

NEW TEXT: In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited Neighbor Advertisement messages to the all-nodes multicast address. These advertisements MUST be separated by at least RetransTimer seconds. A host may also wish to notify its first-hop routers when it configures a new global IPv6 address so the routers can proactively populate their neighbor caches with the corresponding entries. In such cases a host SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT Neighbor Advertisement messages. If the address is preferred then the Override flag SHOULD NOT (did you mean SHOULD) be set. If the address is in the Optimistic state then the Override flag MUST NOT be set. The destination address SHOULD be set to the all-routers multicast address. These advertisements MUST be separated by at least RetransTimer seconds. The first advertisement SHOULD be sent as soon as one of the following events happens:


Thank you

Gyan

Sent from my iPhone

>> On Dec 2, 2019, at 1:26 AM, Jen Linkova <[e-mail]> wrote:
>> 
>> On Mon, Dec 2, 2019 at 4:52 PM Gyan Mishra <[e-mail]> wrote:
>> 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.
> 
> I did some tests using Cisco with glean enabled (IOS already has the
> proposed changes and more implemented).
> 
>> 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
> 
> I looked at that file and I'm a bit confused. I'm not sure how that
> test is relevant to the proposed changes. What I see in that file is
> the standard ND behaviour.
> 
>> 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.
> 
> The section 2.1 states:
> "To minimize the potential disruption in case of duplicate addresses
>  the host SHOULD NOT set the Override flag for a preferred address and
>   MUST NOT set the Override flag if the address is in Optimistic
>   [RFC4429] state"
> 
>> 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.
> 
> Please note that ' MUST NOT set the Override flag if the address is in
> Optimistic state' requirement is actually coming from RFC4429 which
> explicitly prohibits setting Override flag in Neighbor Advertisements
> for Optimistic Addresses (section 2.2 of
> https://tools.ietf.org/html/rfc4429). So, my draft just follows
> RFC4429 recommendations.
> 
>> Section 3.2
>> I am getting lost reading this section.  Where it says that the rightful owner does not use the address for communication.
> 
> The Section 3.2  describes the scenario when the router does not have
> a NC entry for the address. Therefore the address is either unique (no
> disruption), or the rightful owner has not been receiving any traffic
> via that router for a while (if it has then the router would have had
> the entry).
> The latter case is discussed in the section.
> If you could elaborate what is not clear in the section I'd be happy
> to update the text..
> 
>> Is DAD not complete and is the rightful address not used because the interface is in some other DAD state and not Valid/Preferred.
> 
> The scenario described is that the rightful owner (host A) might have
> an address in preferred state but just not use it for
> sending/receiving traffic.  Then another host (host B) joins the
> network and configures the same address in the Optimistic state first.
> If the host B does not send any unsolicited NAs, everything works as
> before. If it does send an NA, then the entry would be created in the
> STALE state. As soon as the host B starts sending traffic, the return
> traffic would trigger address resolution.
> 
>> 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?
> 
> Well, I tried to enumerate all of them but I could have missed smth indeed.
> So let me try again. Let's say a host gets an address assigned and
> it's uniqueness has not been confirmed yet (the address is still
> Optimistic).
> Scenario #1:  The router does not have any entry for the address: see
> section 3.2
> Scenario #2: The router has INCOMPLETE entry: see section 3.3.
> Scenario 3: The router has an entry and it's in some other state: see
> section 3.1
> 
> What did I miss?
>> 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.
> 
> totally agree. Any pointers to the scenarios I missed are highly appreciated.
> 
> Thank you!
> 
>> 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
>> --------------------------------------------------------------------
> 
> 
> 
> -- 
> SY, Jen Linkova aka Furry