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

Lorenzo Colitti <lorenzo@google.com> Tue, 03 November 2015 02:36 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032C01ACE54 for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 18:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xfftnUSw23t for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 18:36:09 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCEB1ACE3F for <v6ops@ietf.org>; Mon, 2 Nov 2015 18:36:09 -0800 (PST)
Received: by ykba4 with SMTP id a4so3200711ykb.3 for <v6ops@ietf.org>; Mon, 02 Nov 2015 18:36:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MGzxUY1N6p5fK9rs8jJQa9ZrRCNxziU9RypQRaFAefo=; b=pwX1ObuRZM5IgkrJT9A6xkj3CnSj46F8QedTJqCLel1almobFAXozA4/PJxfYZu0ru rNL/e6Y48D9Vc6jy003Btez35pNyXTwrGpn/V3WynNwZr5HylB9DObIV56zBv/g+GaPl o3OhImxpCQU1W2ki4CHnCF6YtimJ0BMPz9O8eMY/3LkULZ8l/bjOQmdXBEaX1dyqX4bd suqAFOxqooluwmBTnuCrLv83j79etSNzldpkTGBD0fnN5BjfpwFqG/CG6mFVVrkhtSLS m4q00KZZi/2W/KWM39BJEKd+dGg4Qd9gLg+qvOFdnBrekv+OXYiug2il4JSEInZAODip 6hlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MGzxUY1N6p5fK9rs8jJQa9ZrRCNxziU9RypQRaFAefo=; b=je/TGZ2oeaHd/apsi9hAEtOGiZHNKhVmgia6skYdajyL+u3l2WdGcd9oYrGwfsb0Hh AOtNPQ7LowyLLMi3Vn0l906GBJzl8E0EFRYoKDlNUwqfl/XEuPpXctgFMg+UpFFWZtFi P554ELl4zANGLaTpgintmQnlf+3rFEL15VUiXw32CYmIkkDjAAnggUDhNHFiANVtMqWa tKidb3m9UtBNSkrMqhXJhYcOChfsbxkciz+yEk4KjSLdZOtgl1hvB2z0wN8GzCe25Y3S 9fOjMtFdD9CgVgkk+pgzuNz/LUVU5+yYMx/pS4V0k4umpN6iSAgJjmNuVYFib/Z+5t39 6UQg==
X-Gm-Message-State: ALoCoQlJxxMAaooob2ovyFHRaSRV+EUXJ5Ih6aamdXHYxwvMq1nHBDI81sYisQtNlDMzAU2wWTdb
X-Received: by 10.129.137.198 with SMTP id z189mr19091853ywf.307.1446518168271; Mon, 02 Nov 2015 18:36:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.87.197 with HTTP; Mon, 2 Nov 2015 18:35:48 -0800 (PST)
In-Reply-To: <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com>
References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <CAKD1Yr15C-uoxUw0kgWO-d=LmUK8qWGLS7vt+22W+k8xXtDY+g@mail.gmail.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 3 Nov 2015 11:35:48 +0900
Message-ID: <CAKD1Yr14B0Mvj5x9QvK58cD4OxrGMBWAa++_+n4vFUiHWYsxFQ@mail.gmail.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Content-Type: multipart/alternative; boundary=94eb2c06bf26952310052399c14a
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/PXnTEYRP6kX8digRi7bSoCf-nj4>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 02:36:11 -0000

On Tue, Nov 3, 2015 at 10:24 AM, Templin, Fred L <Fred.L.Templin@boeing.com>
wrote:
>
> 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.
>
>
>
> What I mean is “Requires DAD on the interface over which the prefix was
> received”,
>
> but that was too long to fit in the table. Let’s call the interface “A”.
> If the node gets
>
> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface “A”, then it
> needs
>
> to do DAD on interface “A” for each such address. If the node gets a
> DHCPv6 PD
>
> over interface “A”, however, it does not need to do DAD over interface “A”
> at all.
>
>
>
> If the node assigns the delegated prefix to interface “B”, then you are
> right that
>
> that DAD will be required among all tethered devices, VMs, etc. on
> interface “B”.
>
> But, there will still be no need for DAD on interface “A”. Does that
> clarify?
>

I didn't need clarification, I already knew what you meant. My point is
that:

   - I don't think we can clarify it without overflowing the space in the
   table cell
   - If we clarify it using text outside the table cell, then that means we
   need to explain the other table rows as well, for consistency.
   - That opens us up to fresh discussions on what text to write in those
   explanations, which could potentially become long and involved.
   - It's not clear to me that the above is worth having this extra row in
   the table.

Thus I'd prefer not to an extra row.

> 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.
>
>
>
> I don’t understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA can be used
>
> to assign an unlimited number of addresses to interface “A”. But, so can
> DHCPv6
>
> PD. When the node receives the delegated prefix (e.g., a /64), it can
> assign as
>
> many unique IPv6 addresses as it likes to interface “A”. And again, it
> need not
>
> do DAD for any of them.
>

I think you're confusing unlimited addresses with unlimited endpoints. With
IA_NA or SLAAC, you can number billions of endpoints, each of which might
only have a few addresses. With DHCPv6 PD, you can only number as many
endpoints as you have /64s. Each of those endpoints might be using an
unlimited number of addresses, but there is still a limited number of them.