Re: [dna] AD review of draft-ietf-dna-simple

[Jari Arkko <[e-mail]>]

Bernard,

Thanks for your response. I think I understand the logic better now. 
Suresh, can we change the draft as suggested by Bernard?

Jari

Bernard Aboba wrote:
> > > The probing node SHOULD include a Source link-layer address option in
> > > the probe messages. If the node believes that the source address of
> > > the NS may not be unique on the newly attached link, it MAY omit the
> > > Source link-layer address option in the probe messages.
> >
> > I would like to understand this better. How does a general purpose
> > operating system implementation deal with the above? How does it know
> > that "the source address of the NS may not be unique"?
>
> The goal of DNA is not only to detect network attachment, but also to
> seed the ND cache so as to immediately enable incoming and outgoing
> communications.  By including the SLLA in unicast probe messages, the
> node can seed the ND cache of the router tgo enable communications
> in the opposite direction. 
>
> > AFAICT, if you omit the SLLA and no link change happened, then most
> > likely the router will remember your NC anyway, and be able to respond.
>
> Only if the ND cache entry had not expired.   Remember, the biggest win
> for DNA is when moving between links.
>
> > However, if it does not remember you, a new NS/NA would be required, 
> but
> > DNA would still succeed, albeit a bit slower.
>
> > However, if the host did move to a new link, then including the SLLA
> > might cause disruption for another host that already holds the same
> > address but uses a different link layer address.
>
> The probes are sent to a unicast IP and MAC address.  Therefore they
> can only be received if the node moves to a link on which the node has
> a valid IP address.
>
> > Why is the recommendation written as it is above? Is the assumption 
> that
> > colliding addresses are so rare that the optimization makes sense? On
> > the other hand, it would appear that even without the SLLA DNA would
> > still work in most cases.
>
> There are situations in which a node is unlikely to encounter
> collisions, and therefore DAD is not required.  One is where the IP 
> address
> was allocated via DHCP, and the lease has not yet expired.  If the DHCP
> server is properly implemented, it will not hand out the same address to
> more than one host.  DNAv4 makes this assumption.
>
> During development of the draft, there was discussion as to whether there
> were other situations in which this assumption could be made as well.
> For example, in situations where an IPv6 address is not manually or
> randomly assigned, but is based on a MAC address, would it be
> reasonable to include the SLLA (and also not to do DAD).   As I
> recall, the decision was made *not* to override any of the existing
> recommendations on DAD.  For consistency's sake then, the SLLA
> should not be included in those same cases.
>
> > In any case, I don't think we can require general purpose
> > implementations to assess the likelihood of collisions.
>
> Sure -- but the document should be written so as to clearly spell
> out the situations under which the SLLA is included.  Those are the
> same circumstances in which the document should enable DAD to
> be avoided.  However, currently the document is not consistent in
> this regard.
>
> > Perhaps it would  be easier to require that by default, no SLLA is 
> included
> > and that only  through specific configuration option the SLLA use 
> can be turned on and
> > DNA made to operate faster/more reliably.
>
> If the SLLA is only included in situations where DAD can be avoided, then
> I don't think this is an issue.  That's how DNAv4 works.
>
> > > For the purpose of sending neighbor solicitations to previous
> > > routers, the host first needs to pick a subset of operable IPv6
> > > addresses (candidate set) that it wishes to use. How this subset of
> > > addresses is picked is based on host configuration. e.g. The host
> > > may select configured addresses from each of zero, one or two
> > > previously connected links.
> >
> > Please specify a default strategy. E.g., "How this subset of addresses
> > is picked is based on host configuration. By default the host should
> > select configured addresses from two previously connected links."
>
> DNAv4 enables the host to send probes to all routers representing links
> with valid IP addresses.  There is no language about subsets.  This hasn't
> been an issue in practice, since a host will typically not have a 
> large number
> of valid IP addresses.  So I'd prefer that this language be removed 
> entirely.
>
> > > Where flooding may cause performance issues within the LAN, host
> > > SHOULD limit the number of unicast solicitations.
>
> This is a red herring that should have been removed from the document long
> ago.  The initial deployment of DNAv4 uncovered some AP implementations
> that were non-compliant with IEEE 802.1D, but those issues have long since
> been fixed.  There is no known "flooding" issue at this time.
>
> > Again, the guidance for general purpose implementations in inadequate.
> > Please specify a default strategy. I believe limiting the number of
> > unicast solicitations to some small number (4?) by default is adequate
> > (there are a number of messages on a new link even on DNAv4 and 
> regular ND).
> >
> > > The probing node SHOULD NOT include a Source link-layer address
> > > option if it has not performed duplicate address detection [RFC4862],
> > > for the source address of the NS, on the newly attached link.
> >
> > Performed DAD, when? Presumably it has been performed when the address
> > first configured, no? And since DNA is the first thing that runs 
> after a
> > link change, DAD has not been run at this point either. So what does
> > your recommendation really mean here? Never include SLLA?
>
> It means that you only include SLLA in situations in which DAD can be
> avoided (such as where DHCPv6 is in use).
>  
> > In any case, at this point we do not yet *know* if we are on a newly
> > attached link or not. Therefore, we do not know if we've run DAD in the
> > past on this link.
>
> The probe is constructed to test whether the node is on the link or not.
> If the address was assigned by DHCPv6 on the link, then the probe can
> omit the SLLA and if the probe succeeds, then DAD is not required.
>
> >
> > Please clarify.
> >
> > > Hosts checking their network attachment are unsure of their address
> > > status, and may be using Tentative link-layer addressing information
> > > in their router or neighbour solicitations.
> > >
> > > A router which desires to support hosts' DNA operations MUST process
> > > Tentative Options from unicast source addressed Router and Neighbour
> > > Solicitations, as described in [I-D.ietf-dna-tentative].
> >
> > This is the first time dna-tentative is referenced in this document. I
> > wonder if there's really a need to have a normative reference, or even
> > mention this.
>
> I don't think so, since the WG decided to not modify DAD procedures
> except for the DHCPv6 case.
>
> >
> > > 7. Constants
> > >
> > >
> > > These constants are described as in [I-D.ietf-dna-protocol].
> > >
> > > UNICAST_RA_INTERVAL
> > >
> > > Definition: The interval corresponding to the maximum average
> > > rate of Router Solicitations that the router is prepared to
> > > service with unicast responses. This is the interval at which
> > > the token bucket controlling the unicast responses is
> > > replenished.
> > >
> > > Value: 50 milliseconds
> > >
> > > MAX_UNICAST_RA_BURST
> > >
> > > Definition: The maximum size burst of Router Solicitations that
> > > the router is prepared to service with unicast responses. This
> > > is the maximum number of tokens allowed in the token bucket
> > > controlling the unicast responses.
> > >
> > > Value: 20
> > >
> >
> > None of these appear to have anything to do with the Simple DNA
> > procedure. Please remove. The only item that I can see be of relevance
> > in this section is SEND_NA_GRACE_TIME.
>
> I agree. Not sure why this material remains in the document.
>
> > > When providing fast responses to router solicitations, it is possible
> > > to cause collisions with other signaling packets on contention based
> > > media. This can cause repeated packet loss or delay when multiple
> > > routers are present on the link.
> > >
> > > As such the fast router advertisement system is NOT RECOMMENDED in
> > > this form for media which are susceptible to collision loss. Such
> > > environments may be better served using the procedures defined in
> > > [I-D.ietf-dna-protocol].
> >
> > This does not appear to have anything to do with Simple DNA either
> > (router-side fast responses are not a subject of this specification).
> > Delete?
>
> Yup.
>
> > > The host MAY delay SEND_NA_GRACE_TIME after transmission before
> > > adopting a new default router, if it is operating on a network where
> > > there is significant threat of RA spoofing.
> >
> > I would simply say that this delay MAY be imposed when the host's
> > current default router is a SEND-secured one. This prevents the
> > downgrade from SEND to non-SEND, but does not require any 
> configuration,
> > and it doesn't slow things down when you were already using a non-SEND
> > router.
> >
> > > It is easy for hosts soliciting without SEND to deplete a SEND
> > > router's fast advertisement token buckets, and consume additional
> > > bandwidth. As such, a router MAY choose to preserve a portion of
> > > their token bucket to serve solicitations with SEND signatures.
> >
> > Again, this has very little to do with this specification. Move this to
> > the fast RA spec instead.
> >
> > Editorial:
> >
> > Move draft-ietf-dna-protocol to informative references.
>
> Right.
>