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

[Bernard Aboba <[e-mail]>]

I think that there are still some issues in the revised draft. 

 

"

4.5.1.  Neighbor Solicitation messages


   This section describes the contents of the neighbor solicitation
   probe messages sent during the probing procedure.

   Source Address:           A link-local address assigned to the
                             probing host.

   Destination Address:      The link-local address of the router being
                             probed as learnt from the SDAT.

   Hop Limit:                255

   ND Options:

   Target Address:           The link-local address of the router being
                             probed as learnt from the SDAT.

   The probing node SHOULD include a Source link-layer address option in
   the probe messages if the address was obtained using DHCPv6 and the
   lease has not expired.  Otherwise the probing node SHOULD NOT include
   the Source link-layer address option in the probe messages.
"

 

[BA] This section does not mention the destination MAC address.   Unless that is set to the unicast MAC address of the router, it is possible that the NS could be received by another router using the same linklocal address.  After all, linklocal addresses need not be globally unique. 

 

"
   

4.5.2.  Router Solicitation messages


   This section describes the contents of the router solicitation probe
   message sent during the probing procedure.

   Source Address:           A link-local address assigned to the
                             probing host.

   Destination Address:      The all-routers multicast address.

   Hop Limit:                255

   The probing node SHOULD include a Source link-layer address option in
   the probe messages if the address was obtained using DHCPv6 and the
   lease has not expired.  Otherwise the probing node SHOULD NOT include
   the Source link-layer address option in the probe messages.

"

 

[BA] Including the SSLAO in the RS seems odd because it is sent to a multicast address.  Unlike the NS, the RS is not constructed for a particular router, and therefore its construction should not depend how the address was obtained -- since another router could receive it.  In the case where the address was obtained from DHCPv6, and the host is on one of the probed links, we'd expect the unicast NS to be responded to, and since that does include the SSLAO, I think we're covered. 

 

4.6.  Sending DHCPv6 probes


   Where the host has acquired addresses from DHCPv6 or the host does
   not have a global prefix, it MAY prefer to use DHCPv6 messages either
   before or simultanously with Neighbour Discovery probing.


[BA] Doing DHCPv6 *before* NS probing does not make sense to me.  Earlier, it is said that NS probing occurs simulataneously with sending the RS, right after "link up".  This sentence seems to contradict that. 

 

Also, linking DHCPv6 procedures to DNA seems odd.  In DNAv4, it is made clear that DNA did not resut in any changes to DHCPv4 procedures.  Is that the intent here, or does DNA have some impact on how/when DHCPv6 messages are sent? 

 

  

4.7.  Response Gathering


   When a responding Neighbour Advertisement is received from a test
   node, the host MUST verify that both the IPv6 and link layer (MAC)
   addresses of the test node match the expected values before utilizing
   the configuration associated with the detected network (prefixes, MTU
   etc.).


[BA] It seems odd to check the MAC address in a response, but not to talk about the destination MAC address in the request. Was this intentional? 

 

Section 4.9

 

  If the confirmed address was assigned manually, the implementation SHOULD
   NOT unconfigure the manually assigned address and SHOULD log an error
   about the mismatching prefix.


[BA] Elsewhere the draft talks about stateless autoconfig and DHCPv6-assigned addresses, but not manual assignment.   Is the intent of the document to suggest use of DNAv6 for configuration of manually assigned addresses?  If so, then some of the caveats discussed in the DNAv4 document could apply.   For example, NS probes don't need much if any retransmission because alternatives (RS, DHCPv6) are retransmitted.  But if we are talking about manual assignment, then these alternate mechanisms may not help -- and NS probe retransmission can become more important. 

 

 


From: [e-mail]
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Date: Thu, 9 Jul 2009 10:20:53 -0700
Subject: Re: [dna] AD review of draft-ietf-dna-simple



> > 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.