Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC

David Conrad <drc@virtualized.org> Tue, 04 January 2011 08:45 UTC

Return-Path: <drc@virtualized.org>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C673A6B53 for <v6ops@core3.amsl.com>; Tue, 4 Jan 2011 00:45:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSFYvO8xgSnb for <v6ops@core3.amsl.com>; Tue, 4 Jan 2011 00:45:16 -0800 (PST)
Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 4A9403A6B5C for <v6ops@ietf.org>; Tue, 4 Jan 2011 00:45:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 56086FFCBEF; Tue, 4 Jan 2011 00:47:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at virtualized.org
Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VAu12DxIGsV; Tue, 4 Jan 2011 00:47:20 -0800 (PST)
Received: from [10.0.1.3] (cpe-72-130-197-233.hawaii.res.rr.com [72.130.197.233]) by virtualized.org (Postfix) with ESMTP id DDEB4FFCBDE; Tue, 4 Jan 2011 00:47:19 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: David Conrad <drc@virtualized.org>
In-Reply-To: <C94805B3.6166%yiu_lee@cable.comcast.com>
Date: Mon, 03 Jan 2011 22:47:17 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <694163C9-D39C-40F5-9544-3FB1FD6733F3@virtualized.org>
References: <C94805B3.6166%yiu_lee@cable.comcast.com>
To: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
X-Mailer: Apple Mail (2.1082)
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] A good "state of the art" overview of IPv6 Transition from FCC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 04 Jan 2011 08:45:17 -0000

On Jan 3, 2011, at 6:02 PM, Lee, Yiu wrote:
> Well, when DHCPv6 is getting more popular, we may be able to work around
> this limitation. However, 18 trillion^2 addresses are still a lot^2.

This is sort of missing the point.  Absolute numbers are pretty much irrelevant.  What matters is the rate of consumption.

For example, let's say the amount of IPv6 address space that can be assigned is 2^45 (using the minimum /48 and chopping off 3 bits because we're only supposed to use 1/8th of the IPv6 address space for global unicast).  If you take the current IPv4 address consumption rate (call it 200 million a year for sake of argument) and map that into /48s, you'll see that the current 1/8th of IPv6 address space will last 2^45/200,000,000 = 175,921 years.  Even if you increase the rate of consumption by 1000, it's still 176 years. 

But this sort of analysis assumes rational (that is, technically justified) assignment policies.  Current RIR policies suggest /48s as the minimum recommended assignment size.  However, as Randy mentions, current allocations to ISPs (and others) are a minimum of /32, and many folks are able to justify more.  There have been a number of allocations made by the RIRs according to policy that are shorter than /20.  One might note that there are the same number of /20s in IPv6 as there are in IPv4. And this is the result of policy processes that are influenced primarily by technical folks.  There is increasing pressure from the non-technical world (e.g., governments) to use non-technical justification for IPv6 address space (e.g., "we demand our IPv6 /12 because we're a nation-state").

I still believe it's unfortunate that we focused on the "32" instead of the "fixed" part in "fixed 32-bit address" when IPv6 was being defined, but that's water under the bridge.  It does, however, mean technical folks need to be vigilant about how address policy is defined and by whom. 640K really wasn't enough for everyone.

Regards,
-drc