Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03

joel jaeggli <joelja@bogus.com> Sat, 08 June 2013 08:24 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0BA21F99F2; Sat, 8 Jun 2013 01:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.103
X-Spam-Level:
X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwvRCbHsNvLU; Sat, 8 Jun 2013 01:24:34 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AFDB021F99FE; Sat, 8 Jun 2013 01:24:34 -0700 (PDT)
Received: from wifi-216-56.mtg.afnog.org (wifi-216-56.mtg.afnog.org [196.200.216.56]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r588OM0j067706 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 8 Jun 2013 08:24:26 GMT (envelope-from joelja@bogus.com)
Message-ID: <51B2EA36.5040403@bogus.com>
Date: Sat, 08 Jun 2013 10:24:22 +0200
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0
MIME-Version: 1.0
To: Owen DeLong <owen@delong.com>, Lorenzo Colitti <lorenzo@google.com>
References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <CAKD1Yr1tSy9XZ5A8Zc-doBTfWiPX1TkqGuJeqty9=mhwwHPRKA@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> <CAKD1Yr0Y2_-k0sj=RsSicubJT6dUq7FJDvBoCv5h_DUTjY9ZOw@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751C86DF@mbx-01.win.nominum.com> <CAKD1Yr0EQwqEzPe_FK+XnN+mOGaVU2NWW2Sr5toGZhKiMwkW2A@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751C90F7@mbx-01.win.nominum.com> <CAKD1Yr3frpGOYDoDBfvZR+XocgQZzYeK-_G=3sbtASb3ZfuRSQ@mail.gmail.com> <932B5FC1-FDAB-458B-9117-56E543CC911E@delong.com>
In-Reply-To: <932B5FC1-FDAB-458B-9117-56E543CC911E@delong.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 08 Jun 2013 08:24:30 +0000 (UTC)
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, "<draft-jiang-v6ops-semantic-prefix@tools.ietf.org>" <draft-jiang-v6ops-semantic-prefix@tools.ietf.org>, "ipv6@ietf.org 6man-wg" <ipv6@ietf.org>
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sat, 08 Jun 2013 08:24:37 -0000

On 6/8/13 4:17 AM, Owen DeLong wrote:
>> 2. Comcast only appears to have a /29 and a /28 (2001:558::/29, 2601::/28). That's only 1.5M /48s, and they have about 10x that many customers. They likely can't use /48 plus semantic prefixes, because if ARIN doesn't accept "semantic prefixes" as using space efficiently (and word from ARIN on this thread seems, well, negative on the matter), then they won't be able to get more space from ARIN. That means that there is a fundamental tension between using semantic prefixes and giving more address space to customers.
>>
> It also means that Comcast has a dramatically undersized allocation and will most likely be depriving their customers.
Wierdly, I know them not to been fools.  one observation that can be 
made about larger assignments made at a later time is that:

A. they have been at this a long time and thinking/application has need 
a long time in coming.

B. They're managing their resource assignment.
> Owen
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>