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

Lorenzo Colitti <> Tue, 03 November 2015 01:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7A8D11ACD15 for <>; Mon, 2 Nov 2015 17:04:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cvYK3iTrloJi for <>; Mon, 2 Nov 2015 17:04:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 135A01ACD0C for <>; Mon, 2 Nov 2015 17:04:11 -0800 (PST)
Received: by ykdr3 with SMTP id r3so1648264ykd.1 for <>; Mon, 02 Nov 2015 17:04:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mRytb1h7vkBsPWgekGMU76AUVR9TnH19xaubRevbCz0=; b=kUU0HNPknzsIAImoeNFPVDR1bba7OAbD1b8wpUR5r2XmTsYlrp7jAYs9vJ96Nx/ADG CxE+AyaH2GfMLySGqIXj8/vMuryAFA49XeK3ajwUGRt6sDJwLANQEdflOogdO2eFYioB XyH+cAgdFqQ+cOaumtv/TLxR3qvWfEUPlfIaB/xIsPFmF1IHOmH3DNWmvKKiTab2p2jF FWpoViuhXPtXHcPuEgTghpFw04hYD9V6l+i6elkY1z5bA1Rz6xmMNLXaV8QSaXBafb6G 4k9gUcru+AiDlibmmAmnanoljDTlvHKVvgP3za8HikKrgeJfeeS/oTPELQK0SFqqYmJK 0bKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mRytb1h7vkBsPWgekGMU76AUVR9TnH19xaubRevbCz0=; b=QLX0D7pOYzk6rrUjTaN7LfQMeB9k89jSw8upTRxph0Ez06pvSlalTlH8ScbonJyvG+ vsbhdYXcrnpwvr8V+fJfPVuFDUubKSDFHLoQ8c5JqdK2I0roxpE1cnUxbLLv6y5SxFsb gFKBJNNv8FJ+8OP6LfCjCKjk3f6DLubLXo2Or9qxPxh4hwT9gKktDD1EhC9UkhhbjvIU VDQBH6G55w+Z0Uv8uPie/F2zUSm8kpxl1z7+mxmfcbKdLECrRPq8DVxIXksj0wzEve7M Z8+uLtSkgM7acKQYLUJSnxXonFNTY03hZTcO9s2ddWC29wIOJo4BIIjNvZZ+G0LjawEy +GAA==
X-Gm-Message-State: ALoCoQkS10b3RRE1z3sO3SslCoEl4KBr6GCGoityxRmKnspFapTnBH/FwDcfkFFOTARCXIHRPxXd
X-Received: by with SMTP id z189mr18875077ywf.307.1446512650179; Mon, 02 Nov 2015 17:04:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 2 Nov 2015 17:03:50 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Lorenzo Colitti <>
Date: Tue, 3 Nov 2015 10:03:50 +0900
Message-ID: <>
To: "Templin, Fred L" <>
Content-Type: multipart/alternative; boundary=94eb2c06bf26addfab0523987826
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] 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: Tue, 03 Nov 2015 01:04:12 -0000

On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <>

> I have one text addition suggestion and one question. On P. 7, in Table 1,
> suggest adding a new final row as follows:
>   requires DAD               Yes                  Yes
>  No                 N/A
> Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_TA
> must use DAD to check for duplicates on the link they were obtained. In a
> multi-addressing environment where millions of addresses are required,
> this could amount to a substantial amount of DAD multicast traffic. On the
> other hand, DAD is not needed for DHCPv6 PD because the network has
> unambiguously delegated the prefix for the node's exclusive use.

I don't think "Requires DAD: No" is correct. Even if the device gets a /64
prefix entirely for its own use, it still needs to do DAD with any other
devices on that /64 (e.g., tethered devices, VMs, etc.).

I'm not opposed to adding a line to the table, though I don't think it
provides much value - if we put our mind to it, I'm sure we could come up
with lots of things we could add to the table that aren't there at the
moment. My main concern is that if we add something to the table it needs
to be correct.

I have a question also on table 1. Under ""Unlimited" endpoints", why does
> it say "no" for DHCPv6 PD? I think it should say "yes" instead, since a
> prefix
> obtained by DHCPv6 PD can be used to configure an unlimited number of
> addresses on the link over which the prefix was received.

The table is written from the perspective of the network assigning
addresses to devices that connect to it. Therefore, it says "no" because if
you use DHCPv6 PD you can't assign address space to an unlimited number of
endpoints - you are limited to however many /64s you have available.

If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in
theory, an "unlimited" number of addresses to assign to clients. Of course,
that's only true in theory. In practice, there's going to be a limit due to
scaling reasons.