Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

Lorenzo Colitti <lorenzo@google.com> Tue, 07 July 2015 01:19 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 BF0F51A887B for <v6ops@ietfa.amsl.com>; Mon, 6 Jul 2015 18:19:38 -0700 (PDT)
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 vQjocQwei8au for <v6ops@ietfa.amsl.com>; Mon, 6 Jul 2015 18:19:37 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 633361A8837 for <v6ops@ietf.org>; Mon, 6 Jul 2015 18:19:37 -0700 (PDT)
Received: by oiyy130 with SMTP id y130so130946625oiy.0 for <v6ops@ietf.org>; Mon, 06 Jul 2015 18:19:36 -0700 (PDT)
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=2seCD2FJr69DTjHP5A9VdGkQ0kU+R10Ry/iZvWl87HQ=; b=F9D5DEtlNbaIU9EBmSon/IndGIltqp4TZNP4t/ngtYIxi/rT8Kx0QiEtOejaYpALa9 24zRSaatEBzIDypt65ibSqo3Ctlqz7HgLaiuGf0jRRGeoiF1NhubYwJlfpJtz1D3z4hO RavUkb5jEQQm+QY8BPo3ICfMdwJnq8Yvuq4Xihn0kb78OVi+OlhixeXmJ1Fey5sgD+0e 3FkqGa2+046H5aHOyd1ET8pZpGVYdvPIjvJ6njosPt9pfEFbMSh3lPJ9UjLL/Vlzb5Rc 2WtsMBeMo64EHxTb8vHTiZxU35mrdDtNw7Ousdx5ft3mqbzcwogNEwbfkuPePdKulVtw J+XQ==
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=2seCD2FJr69DTjHP5A9VdGkQ0kU+R10Ry/iZvWl87HQ=; b=nHeCque2yJ0k/BiKM0epuxk5ESJh8lJa4dQHJgx3DLjTHG3A0WUEldDjcMUXfOrEW4 HUrz3/Ohnx5wDrgVFMcVBY/cdlJPDpwG9vZUYm2IyZzT2OdymCCjdkFysQAaOpG6QwM5 SEjZy7ya5LXPNgVoFrT01UX4Zk1D5WquwyMU/5mtnp0BQMxT7DFpWM91eu2KzuWa2oUn Qi1RWkppd7NF+qYmoYx2eS1ET4ezojXfKLdxwXJJUa8XMwSRcWvJEpbS92llpxau1kiV vn/u7k4S/ij7h9jCogtGAVKGPWQ0Dg/bkLkiTUt6yGjAAkqT73FI3YI2HUlv+tjsihJN GXKw==
X-Gm-Message-State: ALoCoQnu5uiWASkuvWZE54Pw7nghYwnMwRXJ+TatIUfP4sZfB6UgLfCumvhbD9S63esPKf0frwih
X-Received: by 10.60.174.39 with SMTP id bp7mr1548345oec.70.1436231976622; Mon, 06 Jul 2015 18:19:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.134.198 with HTTP; Mon, 6 Jul 2015 18:19:16 -0700 (PDT)
In-Reply-To: <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com>
References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 07 Jul 2015 10:19:16 +0900
Message-ID: <CAKD1Yr07M6mXtbL=ewpL7daR4MdvB7fJ_Vu1tyDvmQkzM6zN0w@mail.gmail.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: multipart/alternative; boundary="089e01184684c86505051a3ed015"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/Da2I25qheXVCk5F_BY0kDt17nNM>
Cc: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" <draft-colitti-v6ops-host-addr-availability@tools.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
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, 07 Jul 2015 01:19:38 -0000

On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) <fred@cisco.com> wrote:

> The statement that I don't see in the document, which would help me
> personally, is a problem statement. I would guess that the problem
> statement is "we think some networks are limiting host interfaces to a
> single IPv6 address." I'd want a little more detail, but I'll bet that's
> the crux of it.
>

Not necessarily "are limiting" today, but "will limit" in the future.

Suppose that all operating systems of interest to a given network support
DHCPv6 and it is thus possible to run a network without SLAAC and without
IPv4 without denying service to substantial percentages of users.

Let's consider what would happen in such a DHCPv6-only network. How many
addresses would be available to each host? Because DHCPv6 requires an
explicit request to the network before an address can be used, the answer
is, by definition, "as many as the network administrators decide to make
available".

In some of these networks, the "as many as the network administrators
decided to make available" may equate to just one. There could be lots of
reasons for this: technical reasons such as "our IPAM and logging systems
support only one address per host and it's tied into our legal intercept
system so we can only give out one address per host", "we only have enough
TCAM entries for one address per host", "one address per host is what we do
in IPv4, and we want to be consistent with that".

If that sounds unreasonable, now consider what would happen in a hotel
network that charges $5 per device. How many addresses would be available
to hosts on such a network? At best, one for every $5 paid. More likely, if
the billing system does not support more than one IPv6 address (why would
it?), the answer would become "one per MAC address".

I hope we agree that such networks provide suboptimal service, and that
there are a number of things that users would like to do that require
either the availability of more than one IPv6 address.

If we are able to agree on that, then it is a useful statement to make, for
two reasons:
1. The network administrators might listen to the statement.
2. Client and server implementations can implement network configuration
protocols such as DHCPv6 in a way that does not lead to this suboptimal
scenario.

Cheers,
Lorenzo