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

"George, Wes" <wesley.george@twcable.com> Sun, 26 July 2015 01:21 UTC

Return-Path: <wesley.george@twcable.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 BC14D1ACD94 for <v6ops@ietfa.amsl.com>; Sat, 25 Jul 2015 18:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.664
X-Spam-Level: *
X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 uiSZTxryTCbl for <v6ops@ietfa.amsl.com>; Sat, 25 Jul 2015 18:21:05 -0700 (PDT)
Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 96E021ACD9C for <v6ops@ietf.org>; Sat, 25 Jul 2015 18:21:04 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.15,544,1432612800"; d="scan'208";a="337351810"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Jul 2015 21:17:53 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Sat, 25 Jul 2015 21:21:04 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Date: Sat, 25 Jul 2015 21:21:03 -0400
Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
Thread-Index: AdDHQVbQlv070Q+zTtWTeTckXzcR1Q==
Message-ID: <D1D964E1.5E535%wesley.george@twcable.com>
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>
In-Reply-To: <55A6771E.30805@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.3.150624
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/J88D3fMIkTSxlPcYuDrro-OcMY4>
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: Sun, 26 Jul 2015 01:21:06 -0000


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"


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.