comments on draft-ietf-6man-enhanced-dad-04

Jouni Korhonen <> Mon, 10 February 2014 16:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0F4481A086D for <>; Mon, 10 Feb 2014 08:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V4f4Q9w0hxW9 for <>; Mon, 10 Feb 2014 08:05:24 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22a]) by (Postfix) with ESMTP id C91121A0320 for <>; Mon, 10 Feb 2014 08:05:23 -0800 (PST)
Received: by with SMTP id u14so5002509lbd.1 for <>; Mon, 10 Feb 2014 08:05:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=ImzJfAg3vx1LvrvNWUo3lHllsNNxWreC3Acj4tigYUY=; b=yQGGeTb6SuQarRQAkJpuSlTridgBzvcr+4KkbPOxQkUJQGUHp4/lxxY7tuocZavzaS gg+5M4mnNmOBvNedxaUHyn4ZCYti5myD1g6vzwku3AEQIWBIl8HPKCKnaQ3z//A1wVjP HqBBgLngp4Y5G6rLtBOQQydK079zL0Mm/KpXUPJphwK/sCaTPr6QiCfDus9Vc4ZnUdOu mzbGprIAfFmflmeERnws1848xgtuSNyrCflTkUfzEjJteEbEkXe6KG+jAaa6a2HHuq+9 PBOo3vf31oY5BJeqtPohMpewBqmH1a68n3nlsQ4/MGddKeWIKsH9eOyFAO6RxMwhZpTO eD1Q==
X-Received: by with SMTP id lc11mr22695667lac.29.1392048322846; Mon, 10 Feb 2014 08:05:22 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 10sm22915354lan.5.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 08:05:22 -0800 (PST)
From: Jouni Korhonen <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: comments on draft-ietf-6man-enhanced-dad-04
Message-Id: <>
Date: Mon, 10 Feb 2014 18:05:21 +0200
To:, IPv6 IPv6 List <>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Feb 2014 16:05:26 -0000


I have a read on this document. I find it good and informative. Few 
comments and questions inline.

** Abstract

o There is no mention that this document updates RFC4861 and RFC4862.

** Section 1

      specified in [RFC4862].  Failure also includes if the Target
      Address is optimistic.  Optimistic DAD is specified in [RFC4429].

o I do not understand the sentence "Failure also includes if the Target
  Address is optimistic." Some word missing there?

** Section 3.2

   This solution requires no protocol changes.  This solution SHOULD be
   enabled by default, and MUST be a configurable option.

o I would clarify here, just to be clear on the context, that the above
  MUST applies only if the layer 2 has an ability to detect looped back
  messages. Proposed text:

   This solution requires no protocol changes.  This solution SHOULD be
   enabled by default, and MUST be a configurable option if the layer 2
   technology provides means for detecting loopback messages on an
   interface circuit.

** Section 4

   SEND.  See more details in the Impact on SEND section.  Since a nonce

o I would point explicitly to the section number as well.
o The algorithm description in the second paragraph is somewhat hard to
  follow. I had to read it quite many times.. On the other hand, the
  algorithm description in Section 4.2 is far more readable. Consider
  having the algorithm description only in one place.

** Section 4.2

   NS(DAD) messages sequence continues until the stop condition is

o Or manual administrative actions are taken, right?

o The stop condition and ending the probing means the interface moves
  the Target Address to assigned state, right? I would say that 

** Section 4.4

   detecting looped back ND messages.  If this document updates
   [RFC4862], SEND should be updated to integrate with the Enhanced DAD
   algorithm.  A minor update to SEND would be to explicitly mention

o "If this document updates.." well it does. Propose changing the text to
  something like "Since this document.."
o Why there is no proposal for those "minor" SEND updates?

** Section 4.5

   The following text is added to [RFC4862].

o Added where in RFC4862? Propose an explicit place.
o The added text should probably have a reference to this document.

** Section 4.6

o Changes where exactly in RFC4861? Propose an explicit place.
o The added text should probably have a reference to this document.

** Section 6

   algorithm.  SEND is recommended for this exploit.  For any mitigation

o I would say SEND is not recommend for this exploit rather SEND is recommended
  to circumvent this exploit.

** Section 9

o Obsolete normative reference to RFC1247 (obsoleted by RFC1583)
o No reference to RFC2119 (also there is no typical RFC2119 boilerplate text)
o draft-ietf-6man-impatient-nud -> RFC7048

- Jouni