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

From: Ray Hunter <[email-masked]>
Date: Sat, 08 Sep 2012 13:17:53 +0200

I have read this draft, and think this work is important.

Some dumb questions for your consideration:

Since the (tentative) IID and DAD operation is address and interface 
specific; as well as the nonce, should the node also remember on which 
interface the NS(DAD) was sent, and also for which (tentative) address?

Should the node generate a separate nonce per instance of the DAD 
algorithm, or per interface initialisation?
[DAD may be performed multiple times for initialising a single 
interface, and these may run in parallel if there are multiple prefixes 
per interface, or if temporary addresses are in use as well as SLAAC and 
DHCPv6...]

Section 4.3 says "an interface on the node"

What should a receiver do if a node receives its own NS(DAD) on another 
interface other than the source interface which is performing DAD?
[use case: two L3 interfaces on one node connected to one common L2 
link, where one interface re-initialises or wants to use a new temporary 
address and thus performs DAD. That isn't a loopback condition or error 
condition at all if that NS(DAD) packet is received on the other interface.]

I think the text in section 4.3 could do with some clarification on 
sending and receiving interfaces.

There are high availability situations that intentionally cause 
collisions of IID and a virtual IPv6 address [e.g. HSRP IPv6].
Do these need to be explicitly excluded from this draft? Or is that 
someone else's problem?
[There is a table on the relevant manufacturers website labelled Table 
19 "HSRP and IPv6 ND Addresses " which shows when the virtual MAC/ 
Virtual IPv6 is used for messages. AFAIK DAD is never performed on the 
virtual address, as prevention of duplicate addresses is handled in the 
HSRP protocol itself]

There are high availability cases where multiple NICs are connected in 
parallel [Teaming].
Does this require any special treatment? Or simply a clarification that 
DAD is performed on the resulting virtual NIC interface or LACP bundle 
rather, than individual physical links? Or is this plain obvious?

When is it safe for a node to garbage collect the stored nonce?
When should a node garbage collect the stored nonce [e.g. to  cover 
equipment moves and interface re-patching]?
Once DAD completes?

Regards,
RayH

> 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: Sat, 8 Sep 2012 21:44:37 +0000

Ray,

Appreciate the review.  I will send another email to reply to your questions related to use cases.  Other questions have been addressed below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Saturday, September 08, 2012 7:18 AM
To: [email-masked]
Cc: 6man Mailing List
Subject: I-D Action: draft-ietf-6man-enhanced-dad-01.txt

>interface the NS(DAD) was sent, and also for which (tentative) address?

Yes.  Note RFC 4862 is interface-specific for DAD of each IPv6 address used by the interface and RFC 4861 is also interface-specific for the ND protocol. 

>algorithm, or per interface initialisation?

Anytime DAD is performed by a network interface for an IPv6 address, a separate nonce is generated.  The reason is because, by definition, a nonce is used only once and the interface has to perform DAD for each IPv6 address used by the interface.  Our document is using the nonce defined by RFC 3971.  See section 2 of RFC 3971 and the definition of the "Nonce" term on page 5.  Other sections in RFC 3971 has additional details on the Nonce Option.

>equipment moves and interface re-patching]?

Once DAD completes.

Regards,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 9 Sep 2012 12:33:19 +0000

Ray,

Please see responses below for the use cases you raised.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Saturday, September 08, 2012 7:18 AM
To: [email-masked]
Cc: 6man Mailing List
Subject: I-D Action: draft-ietf-6man-enhanced-dad-01.txt

>sending and receiving interfaces.

For your use case, the issue won't happen during DAD for the global IPv6 address assigned to a L3 interface.  A node won't be able to configure two separate interfaces with the same IPv6 global address. The two L3 interfaces have different IPv6 global address(es) and for global address(es) each L3 interface is a separate link-local domain.  It's only for the link-local address that the two L3 interfaces may share one link-local domain.  Say, the two L3 interfaces are int1 and int2.  Then if int1 issues a NS(DAD) for the link-local address, and an identical NS(DAD) is received on int2 the implementation has to deal with DAD duplicates for all interfaces in the same link-local domain.

>rather, than individual physical links? Or is this plain obvious?

I think it's obvious.  The manufacturer has also included documentation highlighting which IPv6 set of addresses are skipped for DAD.  Note, there are other networks where DAD is disabled such as a point-to-point links.

Regards,

Hemant

---

From: Ray Hunter <[email-masked]>
Date: Sun, 09 Sep 2012 20:31:17 +0200

Humbly suggest you read Section 4.3 one more time to double check that 
the text reflects what you mean.

I never claimed the two interfaces would have the same address.

Say Interface 2 is a stable interface. Interface 1 generates a new 
temporary address and performs DAD on it. The node remembers Interface 
1's address is tentative, and the nonce that was sent.

So one interpretation of the current text for me is that if Interface 2 
receives a NS(DAD) for interface1's address (which is in tentative or 
optimistic state) then the node should generate a system management message.

All I'm saying is that IMVHO it isn't entirely clear from the current 
text whether the filtering action is performed at node level, or locally 
per interface, or per (tentative) address.

IMHO the filtering action should only be applied if all 3 of the 
following constraints match:
1) the received nonce in the NS(DAD) message matches a saved nonce, and
2) the interface that received the NS(DAD) message is the same interface 
which was used to send this nonce (and associated NS(DAD) message), and
3) the (tentative) address in the received NS(DAD) message matches the 
(tentative) address associated with this receiving interface.

Then you have a loopback. And I think the text could be improved to make 
that clear.

Equally if a nonce is truly a nonce, then can't the nonce also be 
garbage collected immediately from local storage as soon as the first 
NS(DAD) loopback packet is received i.e. when the received NS(DAD) 
message is dropped? Is there really a need to always wait for DAD to 
complete in that case?

regards,
RayH

> Hemant Singh (shemant) <mailto:[email-masked]>
> 9 September 2012 14:33
> Ray,
>
> Ray Hunter <mailto:[email-masked]>
> 8 September 2012 13:17
> interface, and these may run in parallel if there are multiple 
> prefixes per interface, or if temporary addresses are in use as well 
> as SLAAC and DHCPv6...]
>
> What should a receiver do if a node receives its own NS(DAD) on 
> another interface other than the source interface which is performing 
> DAD?
> link, where one interface re-initialises or wants to use a new 
> temporary address and thus performs DAD. That isn't a loopback 
> condition or error condition at all if that NS(DAD) packet is received 
> on the other interface.]
>
> virtual address, as prevention of duplicate addresses is handled in 
> the HSRP protocol itself]
>
> Does this require any special treatment? Or simply a clarification 
> that DAD is performed on the resulting virtual NIC interface or LACP 
> bundle rather, than individual physical links? Or is this plain obvious?
>
> ------------------------------------------------------------------------