Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

神明達哉 <> Fri, 13 November 2015 02:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 09C2A1B3EC9 for <>; Thu, 12 Nov 2015 18:36:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qVAf5LTaFfMI for <>; Thu, 12 Nov 2015 18:36:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 612651B3EF1 for <>; Thu, 12 Nov 2015 18:36:29 -0800 (PST)
Received: by ioir85 with SMTP id r85so44393741ioi.1 for <>; Thu, 12 Nov 2015 18:36:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GxRAD0RTtg1g4ASkRtSozoqnPUUAtQDTY5k0WizwbYo=; b=gzXU1PlIWr67cYBzV5fsaC1iwdvTy0VLMZ9gT19KZzZzJk/F0epKjLKC6fqE15yAOv heS4d83EQBeC6QldGvBuF7kor0KDK3ZO3mgEXs9FBpxvfy34sgLmKCRRvZpGRmYNdtnn XVtBiWsdcNfwOYYzPJ2zvwN7xZ1lEqe65Nmu30YIMljPCSeM/+RBxMPoSsYRfCGTFrLj ksdriQI+vtSBl2Zcw8UBJ3+lDBVjAXt+VLPxf8QcMBJbwUK2Z3LfRI/KPIy6YtbcDaQ+ XpkdJqxQKflOxp+o5GvdZ2rridUjZ6fSYm+T3J4PHlzMJISOeyyJ9x+3M1RZmqiQ3gBq oddQ==
MIME-Version: 1.0
X-Received: by with SMTP id i9mr2815658iof.4.1447382188042; Thu, 12 Nov 2015 18:36:28 -0800 (PST)
Received: by with HTTP; Thu, 12 Nov 2015 18:36:27 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 12 Nov 2015 18:36:27 -0800
X-Google-Sender-Auth: QGujrLBU-d9PsZl2B-XXAsy-soI
Message-ID: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
To: "Templin, Fred L" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Nov 2015 02:36:31 -0000

At Mon, 9 Nov 2015 19:59:30 +0000,
"Templin, Fred L" <> wrote:

> 3) 'N' assigns 'P' to the loopback interface and assigns 'A' to the WAN interface.
>     Again, 'N' does not do DAD on the WAN interface because (again) 'P' is not
>     assigned to that interface.
> I don't think this  is correct. DAD will be done for the WAN interface for address A irrespective of whether P is 'assigned' to it (just as DAD is performed for Link Local Addresses).
> FLT>>> RFC4862 says:
> FLT>>>    -  An interface whose DupAddrDetectTransmits variable is set to zero
> FLT>>>       does not perform Duplicate Address Detection.
> FLT>>> This shows that the node has latitude in when it can deem DAD as unnecessary
> FLT>>> for a given interface. In this case, the address A is not matched by a prefix in the
> FLT>>> Prefix List for the WAN interface and it is known that the prefix will never
> FLT>>> never be added to the Prefix List for the WAN interface by node N nor any
> FLT>>> node on the WAN link.

I think I understand what you are trying to say, and I tend to agree
that it would be quite unlikely that someone else than node 'N' is
using address 'A' in the WAN link in practice in this scenario.
However, I think it's dangerous to just jump to the conclusion that
DAD is not necessary in this case in some kind of standard document.
In my understanding, DAD is designed to cover "quite unlikely
scenarios" including cases with some broken implementations/operation.
In this particular scenario, I would say that the original intent of
DAD covers an "unlikely" case where the remote (or some other,
depending the type of link) node of the WAN link is broken or some
invalid operation and is actually using address "A".

I would not necessarily be opposed to the idea of allowing this
particular use case to set DupAddrDetectTransmits to 0, but I don't
think we can casually say so in
draft-ietf-v6ops-host-addr-availability.  IMO, that would require a
separate standard track document that updates RFC4862 with providing
sufficient rationale of why this can be considered an exception (and
why it's that important).

JINMEI, Tatuya