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

[Suresh Krishnan <[e-mail]>]

Hi Jari/Bernard,
   I will try to come up with a new revision incorporating your comments 
by the deadline.

Thanks
Suresh

On 09-07-09 02:04 PM, Jari Arkko wrote:
> 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.
>>
>