Subject: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Oct 2011 10:45:28 -0500

Folks,

Please review this document. 

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 11:26 AM
To: Hemant Singh (shemant)
Cc: Hemant Singh (shemant)
Subject: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

A new version of I-D, draft-hsingh-6man-enhanced-dad-01.txt has been successfully submitted by Hemant Singh and posted to the IETF repository.

Filename:	 draft-hsingh-6man-enhanced-dad
Revision:	 01
Title:		 Enhanced Duplicate Address Detection
Creation date:	 2011-10-14
WG ID:		 Individual Submission
Number of pages: 7

Abstract:
   Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate
   Address Detection (DAD).  However, [RFC4862] does not settle on one
   specific automated means to detect Loopback of Neighbor Discovery
   (ND) [RFC4861] messages used by DAD.  Several service provider
   communities have expressed a need for automated detection of looped
   backed ND messages used by DAD.  This document outlines an algorithm
   to automate detection of looped back IPv6 ND messages used by DAD.
   Further, for certain access networks the document automates resolving
   a specific duplicate address conflict.

The IETF Secretariat

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Oct 2011 11:03:46 -0500

Broadband access folks,

Of particular interest to you in this document will be this problem from
the Introduction section. 

[In another service provider network, two broadband modems in a home
have the Ethernet ports of each modem connected to a network hub.  The
access concentrator serving the modems is the first-hop IPv6 router for
the modems.  The access concentrator also supports proxying of DAD
messages.  Each modem is IPv4 online.  The network interface of the
access concentrator serving the two broadband modems is enabled for IPv6
and the interface issues a NS(DAD) message for the IPv6 link-
local address.  The NS message reaches one modem first and this modem
sends the message to the hub which sends the message to the second modem
which forwards the message back to the access concentrator.  The looped
back NS message causes the network interface on the access concentrator
to be in a DAD-failed state.  Such a network interface typically serves
over six thousand broadband modems causing all the modems (and hosts
behind the modems) to fail to get IPv6 online on the access network.
Additionally, it may be tedious for the access concentrator to find out
which of the six thousand or more homes looped back the DAD message.
Clearly there is a need for automated detection of looped back NS
messages during DAD operations by a node.]

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Friday, October 14, 2011 11:45 AM
To: IPv6 WG Mailing List
Subject: FW: New Version Notification for
draft-hsingh-6man-enhanced-dad-01.txt

Folks,

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 11:26 AM
To: Hemant Singh (shemant)
Cc: Hemant Singh (shemant)
Subject: New Version Notification for
draft-hsingh-6man-enhanced-dad-01.txt

A new version of I-D, draft-hsingh-6man-enhanced-dad-01.txt has been
successfully submitted by Hemant Singh and posted to the IETF
repository.

Abstract:

The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Oct 2011 17:41:14 -0500

Tassos,

From: Tassos Chatzithomaoglou [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 6:29 PM
To: Hemant Singh (shemant)
Cc: IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

>I was wondering...wouldn't the flow label be a "better" field for storing this random number?
>If i remember correctly, early drafts of RPL were using it for loop detection (ok, in a very different way), although in the later ones a new option was chosen.
>Sure, RFC 3697 is very strict on its specification, sure SEND already uses the Nonce option, but since we are talking about ND only (=before any real src/dst flow) i would like to know the >rationale behind of this decision; choosing an extra option instead of a mandatory -useless until recently- field. Maybe then, all ND messages could be supported (less impact on memory?).

>I may have missed some talks about this in the past (or maybe i'm talking nonsense  :-[ ), so please forgive me if this is the case.

No forgiveness needed ☺.  You have been a great reviewer for lot of documents!  The flow label was the first field I and another colleague of mine at Cisco thought of.   However yet another colleague of mine shot down the use of Flow Label with the following comments in double quotes.

“Using the flow label for this is likely to be highly controversial.  I can already hear people claiming it's not a "flow", etc.”

The flow label has another nuance.  It's a 20-bit field and thus a nonce generated with such number of bits has one in a million chance of a duplicate.  The community may prefer at least a 32-bit nonce or higher.  That is why I decided to just use the Nonce Option from SEND in RFC 3971.

Thus can we move away from the Flow Label and use the Nonce Option from SEND?

Thanks,

Hemant

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sat, 15 Oct 2011 01:42:22 +0300

Hi,

I was wondering...wouldn't the flow label be a "better" field for
storing this random number?

If i remember correctly, early drafts of RPL were using it for loop
detection (ok, in a very different way), although in the later ones
a new option was chosen.

Sure, RFC 3697 is very strict on its specification, sure SEND
already uses the Nonce option, but since we are talking about ND
only (=before any real src/dst flow) i would be interested to know
the rationale behind of this decision; choosing an extra option
instead of a mandatory -useless until recently- field. Maybe then,
all ND messages could be supported (less impact on memory?).

I may have missed some talks about this in the past (or maybe i'm
talking nonsense ), so please
forgive me if this is the case.

Also, i have some comments...

When the IPv6 network interface issues a NS(DAD) message, the
interface includes the Nonce Option in the NS(DAD) message and saves
the nonce in local store. Subsequently if the interface receives an
identical NS(DAD) message, the interface logs a system management
message, updates any statistics counter, and drops the looped back
NS(DAD). If the DupAddrDetectTransmits variable for the interface is
greater than one, subsequent NS(DAD) messages for the same Target
Address should be suppressed. If the interface receives a NS(DAD)
message with a different nonce, the interface logs a DAD-failed
system management message, updates any statistics, and behaves
identical to the behavior specified in [RFC4862] for DAD failure.

I know we are talking about DAD, but maybe it should be re-written
as....

If the interface receives a NS(DAD)
message with a different nonce but the same Target address, the interface logs a DAD-failed
system management message, updates any statistics, and behaves
identical to the behavior specified in [RFC4862] for DAD failure.

Six bytes of random nonce is sufficiently large for nonce collisions.
However if there is a collision because two nodes generated the same
random nonce, then the algorithm will incorrectly detect a looped
back NS(DAD) when the NS(DAD) was issued to signal a genuine
duplicate. Since each looped back NS(DAD) event is logged to system
management, the administrator of the network will have to intervene
manually.

The same applies here...

However, if there is a collision because two nodes (that are using the same Target address in their NS(DAD)) generated the same
random nonce, then the algorithm will incorrectly detect a looped
back NS(DAD), while the NS(DAD) was issued to signal a genuine
duplicate.

3.3. Processing Rules for Receivers

The node has been configured to use the algorithm of this document.
If an interface on the node receives any NS(DAD) message that matches
the interface address (in tentative or optimistic state), the
receiver compares the nonce in the message with the saved nonce. If
a match is found, the node logs a system management message, updates
any statistics counter, and drops the received message. If the
received NS(DAD) message includes a nonce and no match is found with
the saved nonce, the node logs a system management message for DAD-
failed and updates any statistics counter.

Also, some recommended changes about the above paragraph.

If the node has been configured to use the algorithm of this document and
an interface on the node receives any NS(DAD) message that matches
the interface address (in tentative or optimistic state), the
receiver MUST compare the nonce in the message with the saved nonce. If
a match is found, the node SHOULD log a system management message, SHOULD update
any statistics counter, and MUST drop the received message. If the
received NS(DAD) message includes a nonce and no match is found with
the saved nonce, the node SHOULD log a system management message for DAD-
failed and SHOULD update any statistics counter.

Lastly, i have a question about your example with the provider in
"2. Introduction".

Although i don't have the whole picture (the DAD proxying part
confused me a little bit) and the term access concentrator isn't
very clear to me (we use dsl, not cable), shouldn't there be a
warning about duplicate mac or mac-flapping somewhere?

I mean, if i understand correctly the topology, the NS(DAD) message
followed the path AC => MODEM1 => HUB => MODEM2 => AC
without changing its src mac. Unless the modems are also acting as
ND proxies.

Am i thinking something wrong?

Regards,

Tassos

Hemant Singh (shemant) wrote on 14/10/2011 18:45:

Folks,

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 14, 2011 11:26 AM
To: Hemant Singh (shemant)
Cc: Hemant Singh (shemant)
Subject: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

Abstract:

The IETF Secretariat

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Oct 2011 18:02:47 -0500

Tassos,

>Lastly, i have a question about your example with the provider in "2. Introduction".
>Although i don't have the whole picture (the DAD proxying part confused me a little bit) and the term access concentrator isn't very clear to me (we use dsl, not cable), shouldn't there be a >warning about duplicate mac or mac-flapping somewhere? 
>I mean, if i understand correctly the topology, the NS(DAD) message followed the path AC => MODEM1 => HUB => MODEM2 => AC without changing its src mac. >Unless the modems are >also acting as ND proxies.

The cable modems are essentially bridges and so is the hub.  That is why the NS(DAD) totally reflected back to the AC as is without changing any src mac.  I thought it would be clear because if a packet is reflected back or looped back, the devices in the path have got to be bridges.  

Ah, I meant a CMTS which is one example of an access concentrator.  I believe the IETF used the term of access concentrator first in RFC 4388.   CMTS is a Cable Modem Termination System and one Cisco CMTS can support about 40K cable modems with an average of one host PC/CPE route behind each cable modem.  The DSL deployment is a L2/L3 segmented network and thus one device such as the CMTS may not be their L2 and L3 combined device in a DSLAM but the same concept applies to DSL networks as well.  Between cable and DSL the worldwide broadband subscribers are over 300 million in number.  

Let me explain the DAD Proxy.  You see, if you have a simple Ethernet LAN corporate network, then the ND traffic between the hosts in the LAN is seen by all the hosts but not the router in the LAN segment.  The router has to implement a DAD Proxy before the router can see all DAD messages of the LAN segment.  Moving away from the trusted Ethernet LAN corporate network to a cable broadband CMTS deployment, the CMTS is a trusted node in the SP domain while the clients the CMTS serves, reside in a un-trusted domain.  The subscriber homes have hacked up modems or rouge PCs etc.  That is why in such a network, the CMTS implements a DAD Proxy so that the CMTS defends each IPv6 link-local or a global address of a client before any client is allowed in the cable network.  Note the DSL broadband folks also have a DAD Proxy draft in the IETF 6man WG in  http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/.   Cable IPv6 standards were completed about 5-6 years back and thus a CMTS already supports a DAD Proxy.

Regards,

Hemant

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sat, 15 Oct 2011 02:30:46 +0300

Hemant Singh (shemant) wrote on 15/10/2011 01:41:
>> Sure, RFC 3697 is very strict on its specification, sure SEND already uses the Nonce option, but since we are talking about ND only (=before any real src/dst flow) i would like to know the>rationale behind of this decision; choosing an extra option instead of a mandatory -useless until recently- field. Maybe then, all ND messages could be supported (less impact on memory?).
That is ok with me. Just wanted to know the background story.;-)

btw, draft-asati-v6ops-dad-loopback seems to be dealing with the same problem too (but from a different perspective). 
Section 3.2 of it is quite similar though.
Are there any plans to merge these two docs? If not, will there be any references of each other?

PS: previous email came from my old address, so i messed things a little bit.

Regards,
Tassos

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Oct 2011 12:43:47 +1300

Also remember that 3697 is obsoleted by draft-ietf-6man-flow-3697bis,
which is fully approved and very close to becoming an RFC.

Regards
   Brian

On 2011-10-15 12:30, Tassos Chatzithomaoglou wrote:
>>> detection (ok, in a very different way), although in the later ones a
>>> new option was chosen.
>>> Sure, RFC 3697 is very strict on its specification, sure SEND already
>>> uses the Nonce option, but since we are talking about ND only
>>> (=before any real src/dst flow) i would like to know the>rationale
>>> behind of this decision; choosing an extra option instead of a
>>> mandatory -useless until recently- field. Maybe then, all ND messages
>>> could be supported (less impact on memory?).
>>> talking nonsense  :-[ ), so please forgive me if this is the case.
>> No forgiveness needed ☺.  You have been a great reviewer for lot of
>> documents!  The flow label was the first field I and another colleague
>> of mine at Cisco thought of.   However yet another colleague of mine
>> shot down the use of Flow Label with the following comments in double
>> quotes.
>>
>> “Using the flow label for this is likely to be highly controversial. 
>> I can already hear people claiming it's not a "flow", etc.”
>>
>> The flow label has another nuance.  It's a 20-bit field and thus a
>> nonce generated with such number of bits has one in a million chance
>> of a duplicate.  The community may prefer at least a 32-bit nonce or
>> higher.  That is why I decided to just use the Nonce Option from SEND
>> in RFC 3971.
>>
> btw, draft-asati-v6ops-dad-loopback seems to be dealing with the same
> problem too (but from a different perspective). Section 3.2 of it is
> quite similar though.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Oct 2011 18:57:00 -0500

Tassos,

-----Original Message-----
From: Tassos Chatzithomaoglou [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 7:31 PM
To: Hemant Singh (shemant)
Cc: IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

>Are there any plans to merge these two docs? If not, will there be any references of each other?

The asati document uses a probe after a first NS has been sent and the NS is looped back.  The probe has a timer too.  Further the asati document does not mention what state is the node in during the probe.   There are open questions and no completed state machine that doesn't make the solution 2 workable as described in the -01 asati document.  I would have talked to Rajiv but the week we released out document he is out on vacation for the whole week.  I already emailed one proposal for how to deal with the two documents to v6ops and I believe also cced to 6man.  

I proposed that the asati document removes section 3.2 and any other section that proposes an automated solution to detect reflected DADs.  Then the asati references draft-hsingh-6man-enhanced-dad for an automated solution.  That changes the asati document as a Problem Statement document that also includes Mitigation remedies and the document can be moved in v6ops.  

No problem.

Regards,

Hemant

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sat, 15 Oct 2011 03:17:06 +0300

I have no objection Brian. I can understand the reason for keeping the flow label "clean".

I was just wondering if there were any plans to use the flow label for ND traffic too, or 
we should consider that there are no real flows there.

Regards,
Tassos

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Oct 2011 19:24:54 -0500

Brian,

Thanks for the reference.  BTW, I was relatively sold on using the Flow Label to stick a nonce into for ND traffic because ND traffic remains in the link-local domain and is control traffic.  It's not like a nonce labeled Flow Label data packet is leaking out to the wide area network.  Also with the Flow Label there is less confusion vs. when we use the Nonce Option defined from SEND.  In a mixed SEND and unsecured (no SEND) network, the lengths of the nonces MUST be the same.  Otherwise some sloppy implementation can cause a buffer overrun parsing the nonce.  

It was the 20-bits in the Flow Label that was one big reason to ditch using it and then other was what my colleague said about overloading the Flow Label. 

Regards,

Hemant

-----Original Message-----
From: Tassos Chatzithomaoglou [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 8:17 PM
To: Brian E Carpenter
Cc: Hemant Singh (shemant); IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

Regards,
Tassos

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sat, 15 Oct 2011 03:28:54 +0300

> I proposed that the asati document removes section 3.2 and any other section that proposes an automated solution to detect reflected DADs.  Then the asati references draft-hsingh-6man-enhanced-dad…

That works for me.

--
Tassos

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sat, 15 Oct 2011 14:49:32 +0300

Also, looking at draft-ietf-6man-flow-3697bis-07, i can see the
following under introduction:

A stateful
scenario is one where a node that processes the flow label value
needs to store information about the flow, including the flow label
value.

...

The flow label can be used most simply in stateless scenarios. This
specification concentrates on the stateless model and how it can be
used as a default mechanism. Details of stateful models, signaling,
specific flow state establishment methods and their related service
models are out of scope for this specification.

Does this mean that the usage of flow label on ND/DAD is out of
scope of 3697bis?

--

Tassos

Hemant Singh (shemant) wrote on 15/10/2011 03:24:

Brian,

Regards,

Hemant

-----Original Message-----
From: Tassos Chatzithomaoglou [mailto:[email-masked]]
Sent: Friday, October 14, 2011 8:17 PM
To: Brian E Carpenter
Cc: Hemant Singh (shemant); IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

Regards,
Tassos

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 15 Oct 2011 07:55:31 -0500

I certainly don’t believe so.   The usual use of Flow Label seems to assume the labeled packet traverses more than one hop.  After all, the typical use of the Flow Label is to let each hop know what processing to do based on the Flow Label.   However, a link-local domain whose traffic is restricted to within one link with no traversal across a router/hop, the Flow Label does not have a hop-by-hop use but certainly if some information needs to be provided to all nodes the flow label can be used.  But such information is best provided by the control protocol of ND used in the link.  So why overload the Flow Label.   Anyway, some folks may not like the small size of 20 bits to be used in a nonce .

Hemant

From: Tassos Chatzithomaoglou [mailto:[email-masked]] 
Sent: Saturday, October 15, 2011 7:50 AM
To: Brian E Carpenter
Cc: Hemant Singh (shemant); IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

Also, looking at draft-ietf-6man-flow-3697bis-07, i can see the following under introduction:

A stateful

...

Does this mean that the usage of flow label on ND/DAD is out of scope of 3697bis?

--
Tassos

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Oct 2011 08:18:28 +1300

Answering Tassos' question specifically, if the use of the flow label for
ND/DAD requires a signalling phase to tell the other end the flow label
value in use, it is clearly out of scope for 3697bis. (Not forbidden,
just not described.)

However, I can't imagine how you would signal anything before
performing neighbour discovery.

I thnk it's just orthogonal to 3697bis. The usage of the flow label
in link-local scope before completing address assignment doesn't seem to me
to be constrained by 2460, 3697 or 3697bis.

However, I agree that 20 bits is small for a nonce. It puts you into
birthday-paradox territory on a LAN with a few hundred nodes.

   Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 17 Oct 2011 09:14:21 -0500

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Saturday, October 15, 2011 3:18 PM
To: Hemant Singh (shemant)
Cc: Tassos Chatzithomaoglou; IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

>However, I agree that 20 bits is small for a nonce. 

Note SEND in RFC 3971 has left the length of the Nonce Option to be 6 bytes or higher.  I personally would like any reflected-DAD algorithm to settle on one fixed length for the nonce.  Thus a question to the mailer.  Which of 48 or 62 bits do folks prefer as length of the nonce for the reflected-DAD algorithm?  I hope folks do not want to go any higher than 62 bits.  Note the Nonce Option has specified that the option end on an 8-byte boundary and since the option is in TLV format, 16 bits are already taken by the Type and Length fields of the option.

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 17 Oct 2011 10:25:19 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Philip Homburg
Sent: Monday, October 17, 2011 11:00 AM
To: Hemant Singh (shemant)
Cc: IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for
draft-hsingh-6man-enhanced-dad-01.txt 

>I think 20 bits should be already be more than enough. For simplicity,
I would
>just go for 64 bits.

Appreciate the quick reply.  Note BrianC already noted that 20 bits will
not suffice by saying "It puts you into birthday-paradox territory on a
LAN with a few hundred nodes.".  His email is at the URL below.

http://www.ietf.org/mail-archive/web/ipv6/current/msg14835.html

We can go for a 62 bits long nonce in the Nonce Option.  Can't pick 64
because the Nonce Option will then not end in an 8-byte boundary.  See
the details from RFC 3971 below. 

Regards,

Hemant

5.3.2.  Nonce Option

   The purpose of the Nonce option is to make sure that an advertisement
   is a fresh response to a solicitation sent earlier by the node.  The
   format of this option is described in the following:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |  Nonce ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    |                                                               |
    .                                                               .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      14

   Length

      The length of the option (including the Type, Length, and Nonce
      fields) in units of 8 octets.

   Nonce

      A field containing a random number selected by the sender of the
      solicitation message.  The length of the random number MUST be at
      least 6 bytes.  The length of the random number MUST be selected
      so that the length of the nonce option is a multiple of 8 octets.

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Oct 2011 17:43:49 +0200

> the details from RFC 3971 below. 

I think you mean 48 bits.

Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Oct 2011 17:00:07 +0200

In your letter dated Mon, 17 Oct 2011 09:14:21 -0500 you wrote:
>Note SEND in RFC 3971 has left the length of the Nonce Option to be 6 bytes or
> higher.  I personally would like any reflected-DAD algorithm to settle on one
> fixed length for the nonce.  Thus a question to the mailer.  Which of 48 or 6
>2 bits do folks prefer as length of the nonce for the reflected-DAD algorithm?
>  I hope folks do not want to go any higher than 62 bits.  Note the Nonce Opti
>on has specified that the option end on an 8-byte boundary and since the optio
>n is in TLV format, 16 bits are already taken by the Type and Length fields of
> the option.

I think 20 bits should be already be more than enough. For simplicity, I would
just go for 64 bits.

Assuming hosts generate sufficiently strong pseudo-random numbers, 20 bits
means that once every one million cases of a genuine duplicate address,
both hosts may mistakenly assume there is a loopback problem.

Given that duplicate addresses should be exceedingly rare already, one 
millionth of that is something that essential doesn't happen. 

There is however one thing to worry about: small devices without persistent
state. If those devices end up with the same MAC address, then there is good
chance that they will generate the same random number as well.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 17 Oct 2011 17:41:05 +0200

>http://www.ietf.org/mail-archive/web/ipv6/current/msg14835.html

I'm not sure how you would get a birthday paradox here. Applying the birthday
paradox, you would get that if you have a network with a 1000 nodes, and all
nodes try to configure the exact same IPv6 address at the same time, then
there is a probability of about 0.5 that two nodes will mistakenly assume that
there is a loopback situation and all the others will detect a duplicate
address.

That's not a problem I would worry about.

So it looks like the shortest nonce is 6 octets or 48 bits and then the next
longer one is 14 octets or 112 bits.

SEND doesn't seem to say anything about the length of the nonce. I guess that
48 bits should be enough to be secure. I think 48 bits is more than enough
for DAD.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 17 Oct 2011 10:57:55 -0500

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Monday, October 17, 2011 11:44 AM
To: Hemant Singh (shemant)
Cc: Philip Homburg; IPv6 WG Mailing List
Subject: Re: New Version Notification for

>I think you mean 48 bits.

Ah, I had suggested 48 or 62 bits in my first email for the mailer to
pick one.  Since Philip suggested to go with 64, I picked 62 bits due to
the 8-byte boundary alignment of the nonce in the Nonce Option.  I am
open to 48 bits which is the minimum specified for length of the nonce
in RFC 3971.

Cheers,

Hemant

---

From: Thomas Narten <[email-masked]>
Date: Tue, 18 Oct 2011 06:14:35 -0400

The WG should produce one single document, not two. This is pretty
simple stuff here and we don't need 2 documents, each only 5 pages
long.

Indeed, I think it's sort of unfortunate that we have started out with
two competing documents, for no good reason that I can see. Its not
like the proposed approaches are different.

Per previous mailing list discussion, the problem and solution are
pretty straightforward. Let's ensure that one document gets
published quickly.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 18 Oct 2011 10:28:08 -0500

Thomas,

Totally agree.  Around the day I published our document, I contacted the
Chairs of 6man and also contacted a v6ops Chair to discuss resolving the
two documents.  I and Wes would have totally worked with Rajiv to
resolve the two documents issue.  However, during last week Rajiv was
out on PTO and this week he is away too.  That is why closing the issue
has taken time.  The draft-asati-01 does not have a workable solution
yet.  See

http://www.ietf.org/mail-archive/web/ipv6/current/msg14828.html

The email in the URL above also proposes a path moving forward for one
document in 6man.  See other questions asked of the draft-asati that
haven't been closed yet.

http://www.ietf.org/mail-archive/web/v6ops/current/msg10411.html

That is why we wrote our document because we need a solution ASAP for
broadband network DAD loop back issues.  

Hemant

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2011 6:15 AM
To: Hemant Singh (shemant)
Cc: Tassos Chatzithomaoglou; IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for

Thomas