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

Lorenzo Colitti <lorenzo@google.com> Wed, 23 September 2015 22:48 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 408BE1B2CFC for <v6ops@ietfa.amsl.com>; Wed, 23 Sep 2015 15:48:57 -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 DyHRay8KUxQV for <v6ops@ietfa.amsl.com>; Wed, 23 Sep 2015 15:48:54 -0700 (PDT)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 A05CE1A913F for <v6ops@ietf.org>; Wed, 23 Sep 2015 15:48:54 -0700 (PDT)
Received: by ykft14 with SMTP id t14so57117055ykf.0 for <v6ops@ietf.org>; Wed, 23 Sep 2015 15:48:54 -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=/l7HMMHVrjFVh9i/sdjl/isIl1TuBnn1xFMb/MAA8ck=; b=HeNjbOltNc5AwNW5uD8Ct05U4tqa79+S4Lu9MZfrsL0u4AacRNdSB6bV6Z/MJCJdIN T7zdeL5Q5weQOTKdh9S/S1pP1M+X/T+AoFeas5GPSEh7r+Z3ccWvF2GtycVfiC/vVu0x n2sl8s1F9nP1J2yfHxoHLomC4kKOenZ/FtwJtTi2oRfLRd9Bmf0Zo9SdIGXxepXKj1+c awt44+TiDMmKHaIvzT09sfJamMeJ7tspMU588HtFzDO+gM4T7ZwDUX3kaAmVj0rjlMhA fITAxnxtQVW8D8ehcSuQP5aiAgDhsYdQlYd7Obn5SLQcAuAHisQtl7hsGs7nmO1o2r3t 9NuQ==
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=/l7HMMHVrjFVh9i/sdjl/isIl1TuBnn1xFMb/MAA8ck=; b=AkQyk3l0Z9yFP3xNGTmSJiHTw/znQuUpvBuu8JrJ1fZA4h4Ymn/1RYM3TAfM6li7Hs BEVBXmPk9ImHwlxKmH2N0D7NAWbwrZMeBMqIN0h5JqHJGDQJWDRGSN6QFKQhcXyICUkW AjYt130gbRA37wB9CQYSExHvhCps4MBqMDHMHbujHrVrTizJ+IG8HftmrcLIYqtQaieN RYhjrPUtm78n0CtR3jaEO0bUF0+DvBuqkE6PsPmWfYZmWTPZAxtvCjiGICHQsxoztIG+ ZzIpRMzQozVUGTl+Gmnqzc+xSCxg8ik7UTAetY3sfVC8p78MRoACW7U3LVAm8tug844u ZkDw==
X-Gm-Message-State: ALoCoQndjyJsa6NYyAiRiBb8dTjALUeR9YdmIVAWvUJ3sAMp5CzUcxVbArz9K+bwxrj/Q55H/nKr
X-Received: by 10.13.254.3 with SMTP id o3mr28339058ywf.161.1443048533761; Wed, 23 Sep 2015 15:48:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.52.204 with HTTP; Wed, 23 Sep 2015 15:48:34 -0700 (PDT)
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA15C83@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAKD1Yr0cGrY1bGHcbcPZZnZ97PDaT7cx17BqtJ45HKo6HoSj-Q@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6113AA15C83@GAALPA1MSGUSRBF.ITServices.sbc.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 24 Sep 2015 07:48:34 +0900
Message-ID: <CAKD1Yr2W84qa1hMDmeH1ZevZUb1sxdTVSGiZ-51nrjQQTH-GTA@mail.gmail.com>
To: "STARK, BARBARA H" <bs7652@att.com>
Content-Type: multipart/alternative; boundary="94eb2c054c904005dc052071ebd3"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/dlCIPxoJq-C_NlgshuXGiKTdLBQ>
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 22:48:57 -0000

On Wed, Sep 23, 2015 at 11:57 PM, STARK, BARBARA H <bs7652@att.com> wrote:
>
> Here's one privacy benefit that requires the ability to form multiple
> addresses: change your privacy address as often as you want, instead of how
> often the operator wants. Or, use different addresses to talk to different
> sites (e.g., a web server and an advertising server). These are both useful
> benefits if the network is trustworthy but the the attack is pervasive
> monitoring outside the network (e.g., by a national security agency).
>
>
>
> <bhs> Privacy addresses can help with 2 privacy functions: (1) they
> obscure the MAC address; (2) self-generated SLAAC privacy addresses reduce
> the ability to do external-to-the-local network tracking down to the /64
> prefix level. When the /64  is shared among multiple devices, there can
> potentially be a little bit of additional privacy from tracking – but even
> that depends, given all the info browsers hand out to HTTP servers. When a
> /64 is dedicated to a device, and the /64 never changes, the benefit of
> privacy addresses is reduced to obscuring the MAC address. A single
> unchanging privacy address within the unchanging prefix provides exactly
> the same obscuring of the MAC address as dozens of constantly changing
> privacy addresses. We need to stop perpetuating this privacy myth.
>

I think what you're saying is not relevant to this discussion? "A single
unchanging privacy address" is not what I wrote above - in fact it is the
exact opposite. What I wrote was that there's a benefit to frequently
changing addresses within the same prefix, or even using different
addresses for every website.


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

>
> As someone who has worked on the ePDG implementation on Android devices, I
> can assure you that the architecture that's used to ensure that the
> baseband processor and the application processor could share an IP address
> is pretty contorted - you might even say nightmarish.
>
>
>
> <bhs> But it’s been done? Now if you said that not using this nightmarish
> code would improve battery life of the devices, that would be a real
> benefit (from an operator perspective – who is your target audience). But
> if the code is done and works, then I don’t see why an operator should care
> how nightmarish it was for the OS implementation.
>

When the code is complex, everybody (users, operators, developers, ...)
suffer from a higher incidence of bugs, higher maintenance costs, and
increased development cost / development time needed to evolve the code for
new features. If you say that's not the operator's problem... well, I like
to think that some (perhaps most?) operators strive to do better for their
users than that. And anyone trying to advance the state of the Internet,
like we do here at the IETF, should be trying to ensure that standards do
not force that sort of complexity on implementations.


> <bhs> I didn’t say VMs didn’t need their own addresses. What I said was I
> wasn’t convinced that all hosts needed VMs in order to do whatever it was
> the user wanted them to do. You haven’t provided a compelling reason why
> VMs are beneficial in hosts. Without that, I don’t understand why I should
> care whether or not  all hosts can run VMs.
>

The question is not whether all hosts need to run VMs. The question is
whether some hosts need to run VMs or do other things that benefit from
multiple addresses.


> ... which is really the point here. What we're trying to say here is not
> that these use cases are hard or impossible without multiple addresses.
> What we're trying to say is that they exist, and that they can either be
> met using multiple addresses or (in most cases) by performing NAT66 in the
> host. We're recommending that we do not go to an architecture where hosts
> need to implement NAT66, and thus we recommend that the network should
> assign enough addresses that NAT66 is not necessary.
>
>
>
> <bhs> NAT66 is not something that hosts inside enterprise networks need to
> be worried about.
>

Why? I know lots of users of my enterprise network that run VMs, run
Android / iOS emulators on their development machines, use ePDG services,
etc. With only one /128 per host, you can'd to that without NAT66.


> Yes, I can see that it’s a problem for UEs in a wireless network.
>

NAT66 is currently not a problem on 3GPP wireless networks, because when
the wireless standards organizations came to the IETF for advice when
designing IPv6 support in 3GPP (I suppose at that time it must have been
called GSM), the IETF gave them the same advice given in this draft - that
a /128 per device is not enough and that a /64 was needed.


> Also, I'm not sure exactly what you're trying to say here. Are you saying
> that:
>
>    1. You disagree that if the network assigns a single /128, hosts will
>    implement and use NAT66; that they will instead reduce or disable (possibly
>    user-visible) functionality.
>    2. You believe that it's fine if networks assign a single /128 to a
>    device, even if it means that hosts will (possibly widely) implement NAT66.
>    3. Something else?
>
> <bhs> I’m saying that you haven’t presented your case in a very compelling
> manner. The case for (the interior of) enterprise networks is non-existent.
>

So, to be clear - when you say "the case for enterprise networks is
non-existent", you're saying that you expect hosts inside enterprise and
educational networks (let's not forget about those, BTW) to need to run
NAT66 to support features that require multiple addresses, and that's not a
problem?