Re: [v6ops] v6ops-host-addr-availability: A Little Pushback

Andrew đź‘˝ Yourtchenko <ayourtch@gmail.com> Wed, 23 September 2015 10:49 UTC

Return-Path: <ayourtch@gmail.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 32BA81ACE70 for <v6ops@ietfa.amsl.com>; Wed, 23 Sep 2015 03:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 eWmgEVyPs--a for <v6ops@ietfa.amsl.com>; Wed, 23 Sep 2015 03:49:42 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 0E54B1ACE67 for <v6ops@ietf.org>; Wed, 23 Sep 2015 03:49:42 -0700 (PDT)
Received: by iofb144 with SMTP id b144so40116413iof.1 for <v6ops@ietf.org>; Wed, 23 Sep 2015 03:49:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EAeJIj70mMn7MGvn/NNaHOgVCNVclS/KJKhnAnu447U=; b=n0bh2q9uPhzRQT0XKMI6E/aheifcB1C5Wf59sJarGEkzqMkqg298Qw48ABdSnW1mB1 kiRbKuzYRRsnHzJ2EjHnAsZ8cO1PffCcAam3nN4AFAKXFMEIKzC5CNQlNE/jcPnkdEQ2 nj3xhQreBCaa9xs29WVb23JJvGuoh+08MFJTOPsydoQtRMeNoJyaTnI4FoTH50xUPquL qY1+7OrUKI709LJg1oNvNNWR8hptBLj7sTjkbLvBqkvnpA+w+XG+WczdsQtGJSCxh1qr IjQ3nRk5ul5pSYkIbcxnBwEzAlh9t+rfkZ1Bs+ljgAsvbILW0j7v3EajTzhdTgOG1S5t EaTQ==
MIME-Version: 1.0
X-Received: by 10.107.170.223 with SMTP id g92mr34917610ioj.79.1443005381475; Wed, 23 Sep 2015 03:49:41 -0700 (PDT)
Received: by 10.107.13.130 with HTTP; Wed, 23 Sep 2015 03:49:41 -0700 (PDT)
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com>
Date: Wed, 23 Sep 2015 12:49:41 +0200
Message-ID: <CAPi140Nw+rnksS3F2n+POAUda2q6006_MuYJnUh5Oo2b1deshw@mail.gmail.com>
From: Andrew đź‘˝ Yourtchenko <ayourtch@gmail.com>
To: "STARK, BARBARA H" <bs7652@att.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ulLHuJ7S6df98HRaPPbJj6eV7og>
Cc: v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback
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: Wed, 23 Sep 2015 10:49:47 -0000

On 9/22/15, STARK, BARBARA H <bs7652@att.com> wrote:
> I read through the draft and found myself feeling that the arguments
> presented were rather uncompelling. So I'm going to provide some pushback.
> Since the draft is presenting itself as recommendations for *all* networks,
> I decided to think about how I would look at it in the context of (1) a
> wireline broadband access service operator, (2) a wireless operator, and (3)
> an enterprise network operator.
>
> Going through the list of benefits, the following struck me:
> 1. Privacy. Changing tracking requirements from needing to track a /128 to
> only needing to track a /64 does not provide for any sort of improved
> privacy against tracking. We need to stop perpetuating this myth.
> draft-ietf-dhc-dhcp-privacy already describes how to provide a single
> address that doesn't give away the MAC address. Other than not giving away
> the MAC, there is no privacy benefit I can see to more easily allowing
> tracking systems to track at the /64 instead of the /128.

I interpret the words in the draft differently: the point is that
instead of storing 8*128 bits of bindings on the access router one can
store 1*64 bits. (and yes you need to store the bindings if you want
to have the secure access today).

This can result in being able to serve more clients on the same hardware.

>
> 2. Several of the listed benefits involve potential use by multiple
> processors on a host, virtual machines on a host, future applications, and
> identifier-locator addressing (ILA). In listing these, there was nothing
> that said "this is incredibly useful, but hosts are prevented from doing it
> (or run into a lot of complexity) if the host is restricted to a single
> DHCPv6-assigned IPv6 address". I didn't read that hosts would have a hard
> time having multiple processors or future applications in the absence of
> multiple addresses, and I didn't get out of the discussion that virtual
> machines and ILAs that require their own address are incredibly compelling
> and hosts and users can't live without them.

Section 4 talks about the complexities of allocating the addresses in
a piecemeal fashion - when I read it, the "IA_NA" is the only thing
that comes to mind because there is no other mechanism that is used to
assign individual addresses.

>
> 3. Tethering and translation (like 464XLAT) tend to be really specific to
> wireless networks. These are the most compelling benefits listed, but they
> don't apply to enterprise and wireline.

I personally had discussions with multiple large-ish enterprises
interested in the 464XLAT or derived tech in their wired networks.

>
> >From an enterprise and wireline perspective, I'm completely unconvinced
> that the suggested benefits are worthy of a BCP recommendation.
>
> >From a wireline perspective, I also see the recommendation as useless,
> since I'm not aware of any wireline architectures (BBF or CableLabs) that
> don't do PD. The wireline operators don't need a BCP to tell them to
> continue doing this. Of course the reason they do PD isn't even listed as
> among the benefits, since they don't do this for the sake of attachment by
> an individual host. They do this so customers can run entire private
> networks behind a fully-functional CE router. But I'm not aware of any
> wireline operator who requires the device requesting IA-PD to be a router.
>
> >From a wireless perspective, I don't really see this as being what would
> convince a wireless operator to deploy PD. The case I try to make is that

IPv6 in 3GPP environments allocate /64 per UE today.

https://books.google.com/books?id=fml06QWRJXQC&pg=PT205&lpg=PT205&dq=3GPP+specification+dedicated+prefix&source=bl&ots=kDZ1vkE3R7&sig=JhdouPCEc9DF0kCxrgUaXnDukuQ&hl=en&sa=X&ved=0CC8Q6AEwAmoVChMIiYLusvyMyAIVSfM-Ch2UaQhH#v=onepage&q=3GPP%20specification%20dedicated%20prefix&f=false

I've been told that the SP WiFi architecture best practice is to also
allocate dedicated per-UE prefix on converged WiFi as well.

> wireless is more and more being used in the same manner as wireline: to
> support an entire LAN of networked devices behind a CE router (usually with
> a USB-connected wireless device). In many places, operators are saying that
> wireless is the deployment model for getting "broadband access" to rural
> areas. If this use case is going to be fully supported with IPv6, then PD
> has to be supplied. Of course, with wireless networks being able to easily
> recognize the type of device used and the user, the network operator will
> always have the ability to selectively offer the PD to only certain users

Every time I mention per-user tweaks with any SP in any context, they
make a lemon face.

--a

> and/or certain devices.
> Barbara
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>