Subject: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.txt

From: Brian Haberman <[email-masked]>
Date: Thu, 6 Jan 2005 15:47:12 -0500

All,
      This starts an IPv6 WG Last Call on advancing:

	Title		: Optimistic Duplicate Address Detection for IPv6
	Author(s)	: N. Moore
	Filename	: draft-ietf-ipv6-optimistic-dad-03.txt
	Pages	: 17
	Date		: 2005-1-3
	
as a Proposed Standard.  This last call will end on Jan 20, 2005.
Substantive comments should be directed to the IPv6 WG mailing
list.  Editorial comments can be sent to the list or the document
editor.

Regards,
Bob & Brian
IPv6 WG co-chairs
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Fri, 21 Jan 2005 11:19:56 -0500

All,
      This Last Call ended yesterday with no comments.  At a minimum,
I would like to hear from those people who commented previously
whether or not this version satisfies their concerns.

Regards,
Brian

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 25 Jan 2005 01:40:28 +0900

>>>>> On Fri, 21 Jan 2005 11:19:56 -0500, 
>>>>> Brian Haberman <[email-masked]> said:

> whether or not this version satisfies their concerns.

I think I should have responded during the LC period...sorry for my
poor response.  I've checked the latest version, and I basically have
no objection to submitting this document.

I have one additional question specific to the latest version.  This
one has a new requirement on SEND in section 3.1:

   * Nodes implementing Optimistic DAD SHOULD additionally implement
        Secure Neighbor Discovery [SEND].

I don't recall why this was added, but if this is based on a
consensus, I don't oppose to the requirement itself.  However, I
believe if we use this wording with the SHOULD, the reference to SEND
must be a normative reference (even though the word "additionally"
might weaken the requirement level).  Upgrading the reference won't
become a procedural problem, since the SEND spec is already in the RFC
editor queue and both documents will become a PS.

In any event, this is not a strong opinion.  If others think it's okay
to keep it as an informative reference, I can live with that.  Also,
even if we agree on changing the reference category, I think we can do
that later with IESG comments.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 25 Jan 2005 07:23:48 +1100

> no objection to submitting this document.

Thanks, I was pretty sure you'd be happy since the last version
was 99% there ...

> might weaken the requirement level).

It's just there to address security considerations ... you're right,
it should have been upgraded to a normative reference, I missed that.

> that later with IESG comments.

Yep.  Thanks for your feedback on this and previous versions!

-----Nick

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Jan 2005 10:53:00 +0200 (EET)

> whether or not this version satisfies their concerns.

Hi,

I took a quick look at -03, with comments below.  I think the main 
oDAD functionality is OK, but the draft likely needs a revision to 
make a few textual corrections.

substantial
-----------

Sorry that I did not catch this earlier, but I think the analysis in
Appendix A on collision probability is not quite accurate.

[SOTO] describes the collision of a random interface identifier.  For that,
looking at 62 bits is OK.

What we are mostly concerned with are:
  - manual configuration
  - stateless address autoconfiguration
  - RFC3041 addresses

Now, we cannot really analyze manual configuration mismatches, but we can
analyze the probability of collision of SLAAC addresses.  For RFC3041, the
current calculations would apply, but we should calculate the maximal
feasible probability as it is larger with SLAAC addresses.

And for that, you'll have to use a different instead of 2^62; you could take
for example Ethernet, and analyze 2^48.  Text also needs to be massaged a
bit to state which probability you are actually calculating. (Unfortunately,
as the L2 address lengths are variable, you can't do much better
calculations than this..)

I don't think this changes the results in any meaningful way (the
probabilities are about 16K larger), but this should probably still be
changed.

semi-substantial
----------------

==> I agree with Jinmei's concern.  SEND should be a normative reference if
it's a SHOULD.

    * (modifies 5.5) A host MAY choose to configure a new address as an
         Optimistic Address.  A host which does not know the SLLAO of its
         router SHOULD NOT configure a new address as Optimistic.  A
         router MUST NOT configure an Optimistic Address.

==> Why MUST NOT for routers?  It seems too strong.  Sooner or later (if not
already) folks deploying Mobile Routers (for example) are going to want
to use this for their upstream interface, at least.

Either you should justify clearly somewhere why it's technically unfeasible
to use oDAD on routers, or weaken the text a bit, e.g., to a SHOULD NOT.

editorial
---------

    The existing IPv6 address configuration mechanisms provide adequate
    collision detection mechanisms for the static hosts they were
    designed for.

==> s/static/fixed/ ?

   SAA - Stateless Address Autoconfiguration.  The process described in
         [RFC2462]

==> "SAA" is ambiguous, because it could as well be Stateful AA.  I suggest
using either SLAC or SLAAC (both have been used).

4.2 Collision case

==> this section does not explicitly state at which point the ON
unconfigures the address.  Should it say that?

    When considering collision probability, the Birthday Paradox is
    generally mentioned.  When randomly selecting k values from n
    possiblities, the probability of two values being the same is:

==> s/possib/possibi/

    When considering the effect of collisions on a individual nodes, we

==> "a invididual nodes" ?

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 27 Jan 2005 20:43:11 +1100

> make a few textual corrections.

G'day Pekka,

	Thanks for looking at the draft ... looks like there's still
I few things I missed, dang!

> Appendix A on collision probability is not quite accurate.

Ah, Appendix A is new.  And you're right, I should have made it
much clearer that I was talking about 3041 addresses.  My main
reason for including the text in Appendix A was to provide a
permanent home for the work done by Soto et al.

Ethernet-derived addresses are indeed also an issue, but they're
hypothetically unique ... so we're back to estimating the 
inestimable ... are they less likely to collide than 3041 because
of this supposed uniqueness, or more likely to collide because
of the possibility of human error?

> probabilities are about 16K larger), but this should probably still be

I'm open to suggestions ... I can just do the analysis with
N=2^48 in parallel with N=2^62 if that seems useful ... but the
non-random distribution of Ethernet addresses I think negates
that point.  I should definitely mention it.

Would it be sufficient to change the first para of Appendix A to:

| In assessing the usefulness of Duplicate Address Detection, the
| probability of collision must be considered.  Various mechanisms,
| such as SLAAC [RFC2462] and DHCPv6 [RFC3315] attempt to guarantee
| uniqueness of the address, but they add complexity to address
| configuration and may introduce a risk of collision due to 
| misconfiguration.
|
| Privacy Extensions to SLAAC [RFC3041] avoid this issue by 
| picking an Interface Identifier (IID) at random from 2^62 possible
| 64-bit IIDs (allowing for the reserved U and G bits).  No 
| attempt is made to guarantee uniqueness, but as the following
| discussion shows, probability is exceedingly unlikely.

... or do I need to be even clearer?

>     [...] 
>     [...]

I agree on all of these, and will fix them immediately.  

Thanks heaps for your scrutiny!

-----Nick

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Jan 2005 12:12:25 +0200 (EET)

> of the possibility of human error?

Good question.. The reason why Ethernet MAC addresses would not be 
unique would probably be either human error (manually configuring the 
mac address) or a manufacturing error -- and in either case, it's not 
certain how much analysis on 2^48 would help..

> ... or do I need to be even clearer?

I'm open to hearing if others have thoughts about this.

If we go through this kind of text, which would be basically OK by me, 
a couple of modifications will be needed, because the first paragraph 
seems to assign blame on SLAAC and DHCPv6 for complexity and 
recommending using RFC3041 instead.  That's not good, the text needs 
to be more balanced.  RFC3041 have many drawbacks, e.g., about their 
renumbering and the use for longer term than they are valid, and are 
solution only in some limited cases.

Maybe use the following rewording? (I would also have wanted to say 
that due to these factors, it is impossible to calculate the collision 
probability of SLAAC in particular, but couldn't find the right words 
for that)

  In assessing the usefulness of Duplicate Address Detection, the
  probability of collision must be considered.  Various mechanisms,
  such as SLAAC [RFC2462] and DHCPv6 [RFC3315] attempt to guarantee
  uniqueness of the address.  The uniqueness of SLAAC depends on the
  reliability of the manufacturing process (so that duplicate L2
  addresses are not assigned) and the human factors if L2 addresses are
  manually. The uniqueness of DHCPv6 assigned addresses relies on the
  correctness of implementation in ensuring that no two nodes can be
  given the same address.

  Privacy Extensions to SLAAC [RFC3041] avoid these potential error
  cases by picking an Interface Identifier (IID) at random from 2^62
  possible 64-bit IIDs (allowing for the reserved U and G bits).  No
  attempt is made to guarantee uniqueness, but the probability can be
  easily estimated, and as the following discussion shows, probability
  is exceedingly unlikely.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings