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/
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
