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

"Hemant Singh (shemant)" <> Sun, 15 November 2015 12:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EC7971B33BA for <>; Sun, 15 Nov 2015 04:25:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.186
X-Spam-Status: No, score=-13.186 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nsxESUSDn2_A for <>; Sun, 15 Nov 2015 04:25:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E17A91B33B9 for <>; Sun, 15 Nov 2015 04:25:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1916; q=dns/txt; s=iport; t=1447590338; x=1448799938; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+Xgkj+SHlcCLsk3B+Rtu+qBSmfo5wFEqB32zXcZgc6Q=; b=KoFzbVCjdLmhz8vjEL2gUKSlvEuY6N/JjYk61vhw6oVbFjDJ2DRVD59m Oo3pkG8VwKHE7P9BqAJwlDgntu+VvfwrewR0O7Hs1CKxKmfZvDZ1VFNGh 8IPIkkluSId/c6MsVrnE9Ij8X0Q7rzKIdda2h+pYAiEkjxQb4G/9IUiq0 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.20,297,1444694400"; d="scan'208";a="207141038"
Received: from ([]) by with ESMTP; 15 Nov 2015 12:25:36 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id tAFCPaFg003262 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 15 Nov 2015 12:25:36 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 15 Nov 2015 07:25:35 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Sun, 15 Nov 2015 07:25:35 -0500
From: "Hemant Singh (shemant)" <>
To: "Templin, Fred L" <>, "Mukom Akong T." <>
Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAIkUDw
Date: Sun, 15 Nov 2015 12:25:35 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Sun, 15 Nov 2015 12:25:40 -0000


Sorry for the delay.  I am catching up with the original thread.   Please see below.

>From: v6ops [] On Behalf Of Templin, Fred L
>Sent: Monday, November 09, 2015 3:00 PM
>To: Mukom Akong T.
>Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>>'N' sends a DHCPv6 PD Solicit over the WAN interface
>>and receives a prefix delegation 'P'. 'N' can now assign prefix 'P' to either the
>>loopback interface or the LAN interface, but MUST NOT assign 'P' to the WAN

>This is correct, since this WAN interface would have already gotten legitimate non-link-local addresses by other means.

There is another reason.  The prefix delegation (PD) RFC in RFC3633 says

[the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router.]

The reason RFC3633 has such a restriction is because if it were possible, then the WAN IPv6 global address is on-link to the northbound SP router.   The delegated prefix in P is supposed to be not on-link on the WAN.   Thus if a loopback (lo) interface is configured with an IPv6 address from prefix P, the  IPv6 address is not on-link and thus the lo interface does not initiate DAD for the address.

However, if an address is configured on the lo interface manually and the address is not using an address from a DHCPv6 PD, what transpires?   The intent of the admin is to configure an address which is not on-link to the directly connected network.   The only other case is if the directly connected network includes a node who manually assigned its IPv6 address (or is broken) and the address happens to match the address on the lo interface - now DAD is needed.