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

"Templin, Fred L" <> Mon, 16 November 2015 16:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 59E0C1A6F61 for <>; Mon, 16 Nov 2015 08:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.887
X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6_ZsDJxHCIAD for <>; Mon, 16 Nov 2015 08:41:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA28D1A6F58 for <>; Mon, 16 Nov 2015 08:41:42 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id tAGGfgsx015331; Mon, 16 Nov 2015 10:41:42 -0600
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tAGGfWlX015261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 16 Nov 2015 10:41:33 -0600
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Mon, 16 Nov 2015 08:41:30 -0800
From: "Templin, Fred L" <>
To: "Hemant Singh (shemant)" <>, "Mukom Akong T." <>
Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
Thread-Index: AQHRFogofPNeczqv2U2vJopouDkBSJ6LeFYwgAa8AYCAAeLTIIAJg1aAgAFM4PA=
Date: Mon, 16 Nov 2015 16:41:30 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
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: Mon, 16 Nov 2015 16:42:00 -0000

Hi Hemant,

> -----Original Message-----
> From: Hemant Singh (shemant) []
> Sent: Sunday, November 15, 2015 4:26 AM
> To: Templin, Fred L; Mukom Akong T.
> Cc:
> Subject: RE: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
> Fred,
> 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.
> >Cc:
> >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
> >>interface.
> >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.]

Correct; that is exactly why I said "MUST NOT".

> 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.

This is starting to diverge from the case I originally intended this discussion to
examine. The case I am interested in is as follows:

- Node N receives a /64 prefix delegation for prefix P over interface eth0.
- N assigns P to the lo interface as a /64 route. This is done to black-hole
   unused portions of P.
- N configures address A from prefix P, and assigns it to eth0.
- N need not perform DAD for A over eth0, because the delegating router
   has made sure that the routing system will route all packets with a
   destination address from P to node N, and not to any other node.

In this way, N can function as an ordinary host according to the strong end
system model even though it acted as a "requesting router" in procuring a
prefix from the delegating router. No other node X on the same link as
N can therefore configure an address from P and have the routing system
return packets to X. In fact, any node X that configures an address from P
can be considered an "attacker", and the use or non-use of DAD has no
way of preventing that. In fact, the use of DAD could give X a clue as to
which addresses from P are ripe for attacking. So, it is in fact better to

Thanks - Fred

> Hemant