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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 28 August 2015 15:01 UTC

Return-Path: <alexandru.petrescu@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 315051B34A4 for <v6ops@ietfa.amsl.com>; Fri, 28 Aug 2015 08:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 vSW7W2TKtggo for <v6ops@ietfa.amsl.com>; Fri, 28 Aug 2015 08:01:35 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630A31B3497 for <v6ops@ietf.org>; Fri, 28 Aug 2015 08:01:35 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t7SF1XsA013443; Fri, 28 Aug 2015 17:01:33 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 72E87206622; Fri, 28 Aug 2015 17:05:58 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 668D6206625; Fri, 28 Aug 2015 17:05:58 +0200 (CEST)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t7SF1WHB020477; Fri, 28 Aug 2015 17:01:33 +0200
To: "George, Wes" <wesley.george@twcable.com>, "v6ops@ietf.org" <v6ops@ietf.org>
References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <55A6771E.30805@gmail.com> <D1D964E1.5E535%wesley.george@twcable.com>
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Message-ID: <55E077CC.1020208@gmail.com>
Date: Fri, 28 Aug 2015 17:01:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <D1D964E1.5E535%wesley.george@twcable.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/bZIwe45XT0LQxhEZ0gq-XxkLmqg>
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: Fri, 28 Aug 2015 15:01:40 -0000


Le 26/07/2015 03:21, George, Wes a écrit :
>
>
> On 7/15/15, 11:07 AM, "v6ops on behalf of Alexandru Petrescu"
> <v6ops-bounces@ietf.org on behalf of alexandru.petrescu@gmail.com>;
> wrote:
>
>> One problem I see is when operators deliver a single global /64
>> prefix, and that /64 is understood as a single IPv6 global
>> address.
>>
>> Forming multiple IPv6 addresses out of a single /64 is possible
>> for multiple apps running on that device, so that may not be a
>> problem. There may be some privacy concerns though, in that an
>> attacker can identify there is a single device there (the /64 is
>> unique).
>
> WG] that is not a privacy consideration that is unique to this
> document, and as such I recommend that we stay away from it, as it
> just distracts from the main point by essentially asking for rolling
> /64 assignments or multiple /64s. We need to keep the scope of this
> document fairly tight.
>
>>
>> But 'sharing' these IPv6 addresses with some other devices
>> (64share) has more serious drawbacks, typically in the number of
>> subnets - only one subnet is possible.
>
> WG] I fully expect implementations of the type that this draft
> discusses to get by with bridging if they need to share a /64 such as
> for mobile device tethering. If they truly need multiple subnets,
> there is no way to get around supporting DHCP_PD with some sane
> configuration around sending and accepting hints for larger prefixes,
> because that doesn't work for SLACC either. That probably needs to be
> another document, with those specific use cases documented, because
> "always support multiple subnets" is a more significant request than
> "always support multiple addresses"

Makes sense to me.  This document should either say "always support
multiple addresses and always support multiple prefixes" or may we write
another document for the prefixes requirement part.

Alex

>
>
> Thanks,
>
> Wes
>
>
> Anything below this line has been added by my company’s mail server,
> I have no control over it. -----------
>
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or
> subject to copyright belonging to Time Warner Cable. This E-mail is
> intended solely for the use of the individual or entity to which it
> is addressed. If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
>