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

[Jen Linkova <[e-mail]>]

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