Subject: I-D Action: draft-ietf-6man-enhanced-dad-01.txt

From: [email-masked]
Date: Thu, 06 Sep 2012 08:19:07 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : Enhanced Duplicate Address Detection
	Author(s)       : Rajiv Asati
                          Hemant Singh
                          Wes Beebee
                          Eli Dart
                          Wes George
                          Carlos Pignataro
	Filename        : draft-ietf-6man-enhanced-dad-01.txt
	Pages           : 11
	Date            : 2012-09-06

Abstract:
   Appendix A of the IPv6 Duplicate Address Detection (DAD) document in
   RFC 4862 discusses Loopback Suppression and DAD.  However, RFC 4862
   does not settle on one specific automated means to detect loopback of
   Neighbor Discovery (ND of RFC 4861) 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
   includes mitigation techniques and then outlines the Enhanced DAD
   algorithm to automate detection of looped back IPv6 ND messages used
   by DAD.  For network loopback tests, the Enhanced DAD algorithm
   allows IPv6 to self-heal after a loopback is placed and removed.
   Further, for certain access networks the document automates resolving
   a specific duplicate address conflict.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-dad

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-enhanced-dad-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Sep 2012 22:33:55 +0000

I thought it's prudent to also include the 6man mailer in my reply to Tina.

Regards,

Hemant

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Friday, September 14, 2012 4:56 PM
To: Tina TSOU; [email-masked]
Cc: [email-masked]
Subject: RE: I-D Action: draft-ietf-6man-enhanced-dad-01.txt

Tina,

Humble apologies for the delayed reply.  Please see below. 

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2012 4:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-enhanced-dad-01.txt

>The draft proposes the use of Enhanced DAD Algorithm for detecting looped back NS ( DAD) message. It suggests the use of Nonce option in the SEND >message.  Considering that two router might generate the same nonce, would it be preferable to have unique nonce id? Since the nonce option is of 6 >bytes, the problem of two ipv6 nodes generating same random nonce option would be to most extent rectified. 
 
Do you really think a 6 bytes number has a chance of collision?  It's very less likely.  Besides, the Enhanced DAD algorithm has no problem for your use case.  Each router interface processes a looped back DAD if one is looped back.  

>Moreover depending on the number of interfaces running IPv6, would each interface have its own nonce number used for DAD? Or does the IPv6 node maintain >one common nonce for all its interfaces running IPv6?
 
Please see the above question answered in the 6man mailer.  Each interface uses a nonce per IPv6 address used by the interface.

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

>Moreover, the enhanced DAD algorithm is to enabled on both sides of the interfaces right? 

Same as RFC 4862.  Whatever side of an interface RFC 4862 works on, the Enhanced DAD also does the same.  Our document hasn't said anything to the contrary.

>If the nonce option does not match, and the target address is same ( genuine duplicate address), the interface will be disabled? So would this be >automated or manual intervention would be required for disabling the interface? Automated disabling would be preferred considering the increase in the >number of routers. Would Enhanced DAD support automated disabling? If so, in all cases or specific cases?
 
See section 5 of the document where automated actions are recommended for access networks.  Thus cable and DSL access networks will benefit with the automated action.  

Thanks and regards,

Hemant