Re: [v6ops] new draft: draft-shishio-v6ops-dpvt

Owen DeLong <owen@delong.com> Tue, 26 February 2013 19:46 UTC

Return-Path: <owen@delong.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 4A6C221F8900 for <v6ops@ietfa.amsl.com>; Tue, 26 Feb 2013 11:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epdPMP2W77eF for <v6ops@ietfa.amsl.com>; Tue, 26 Feb 2013 11:46:10 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1887521F88C1 for <v6ops@ietf.org>; Tue, 26 Feb 2013 11:46:09 -0800 (PST)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1QJg80Z011515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2013 11:42:08 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1QJg80Z011515
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361907728; bh=MmEFX/nj0L3tDm/OoJd3cIdcraA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jJLG8NIkmTusuXa2I59qnK2V5ujT4nG/0eB4Akay/1caK9QNMJA5LyfREBA+/xgXw dSIo824vqFx6wB4dnUqvyS8G3j4brnthzatybdz62nQBI7pBAEPxGNWMF/E8d7bwAW ml4BBNbe+4H7cXPGO2AQFygY5mWkEAW484NUGLdM=
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <512D0A20.3060505@dougbarton.us>
Date: Tue, 26 Feb 2013 11:42:04 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C73F9008-BBFC-4B99-B05C-9A7C4650C115@delong.com>
References: <201302181345.r1IDj0J04495@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BC8A@SRVHKE02.rdm.cz> <51239D09.10305@cisco.com> <1808340F7EC362469DDFFB112B37E2FCC6CFB3BF8F@SRVHKE02.rdm.cz> <5126BA74.5080508@cisco.com> <B823D57C-F630-42D6-B4DF-BCFF60ACBB21@delong.com> <CAKD1Yr2JMjcP7EoSeXfNyw3RB1eKRfyBVBW6vM_jU6ApW1kweg@mail.gmail.com> <B0FEE42A-03BD-41DC-98E9-68DAF1C89A4A@delong.com> <512D03AC.5050005@gmail.com> <512D0740.1040801@dougbarton.us> <CB5768AA-1B08-444C-B0C8-D6B35DF0A3EA@delong.com> <512D0A20.3060505@dougbarton.us>
To: Doug Barton <dougb@dougbarton.us>
X-Mailer: Apple Mail (2.1499)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 26 Feb 2013 11:42:08 -0800 (PST)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt
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: Tue, 26 Feb 2013 19:46:11 -0000

On Feb 26, 2013, at 11:16 , Doug Barton <dougb@dougbarton.us> wrote:

> On 02/26/2013 11:09 AM, Owen DeLong wrote:
>> At least in North America, it's pretty easy to get a very large amount of IPv6 space.
> 
> I think that's true pretty universally, and is likely to remain so for well past our lifetimes. :)
> 
>> Being unable to obtain space is clearly not a valid reason to use longer prefixes and I certainly think that your proposed compromise is an improvement over dense-packing long prefixes. However, I have yet to hear from anyone any legitimate reason for using longer prefixes to begin with. Nobody has yet stated any benefit to doing so.
> 
> People have given reasons, you just don't agree with them. :)
> 

I literally haven't seen anything that is even alleged to be a benefit of longer prefixes.

Here's what I've seen:

	Comcast:	"Covers buggy hardware/software"
		I've already agreed that I accept this. However, that's /128s and /64s. Not /60s and /56s vs. /48s.

	A few others:
		"We shouldn't give it out liberally because we'll run out. Have we learned nothing from IPv4?"

		This isn't a benefit. This is fear mongering. The solution to this is, IMHO, Let's try it liberal until
		we're 50 years down the road or until 2000::/3 is fully allocated to RIRs, whichever comes first.
		If we fully allocate 2000::/3 to RIRs in less than 50 years, then we have plenty of time to talk
		about more conservative ways to allocate the next /3 and we still have 4 other /3s (1/2 of the
		total IPv6 address space) that remains untouched.

If you've seen someone stating an actual benefit (outside of "it covers for the bugs"), then please share... I really have literally missed it. If someone can show a truly valid reason for longer prefixes that involves either a benefit or a real downside to shorter ones, I really am open to being convinced.

> Personally I am ambivalent, I have sympathy for the argument that we don't want to "waste" space since we thought IPv4 was "effectively infinite" at the time too. OTOH, the math on available IPv6 space is so astonishingly huge that humans literally have a difficult time understanding the amount of space we have available.

I have a certain amount of sympathy for "don't waste space". However, providing bits to allow radical new autoconfiguration mechanisms for autonomous topological hierarchies in the residential environment is not a waste IMHO. Providing enough bits that residential end users are not treated as second class citizens for addressing purposes compared to businesses is not a waste IMHO.

If we define "wasted addresses" as "addresses not utilized to number hosts", then, no matter what we do, IPv6 is designed for and depends on huge amounts of waste. However, if we seriously consider the numbers, we see that the waste of giving out /48s to everyone still doesn't really have much of an impact.

UN's highest estimate of world population for 2100 is just under 16,000,000,000 (16 Billion). Let's assume that every single person represents a household that needs a /48 and that each person also has their own business that also needs a /48 (obviously a ridiculous over-estimation). That's a total need for 32 Billion (32,000,000,000) /48s. 2000::/3 provides 2^45 or 35,184,372,088,832, so we would still have more
than 35,150,000,000,000 /48s remaining in 2000::/3 with which we can number ISPs, infrastructure, servers, etc.

That's still within 1/8th of the total IPv6 address space.

> Given that there are hard and fast opinions on both sides of this debate, and neither group is likely to change their mind, the compromise I propose covers all the bases. Then 10 or 20 years from now we'll have a much better idea about who was right.

As I said, your compromise is better than what is being done today. However, both have distinct drawbacks and there are at least potential benefits to providing /48s (or at least /48s on request). Since there are no drawbacks (potential or actual) to issuing shorter prefixes, I really am at a loss as to how the other side justifies its position.

Owen