[175049] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: IPv6 Default Allocation - What size allocation are you giving out

daemon@ATHENA.MIT.EDU (David Conrad)
Wed Oct 8 22:25:04 2014

X-Original-To: nanog@nanog.org
From: David Conrad <drc@virtualized.org>
In-Reply-To: <495D0934DA46854A9CA758393724D5906DA244@NI-MAIL02.nii.ads>
Date: Wed, 8 Oct 2014 19:21:00 -0700
To: Erik Sundberg <ESundberg@nitelusa.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

Erik,

On Oct 8, 2014, at 6:18 PM, Erik Sundberg <ESundberg@nitelusa.com> =
wrote:
> I guess the idea of handing a customer /56 (256 /64s) or  a /48 =
(65,536 /64s) just makes me cringe at the waste.

Don=92t cringe. Yeah, a /48 is a crazy amount of space, but that isn=92t =
the resource we are likely to ever need to conserve in the lifetime of =
IPv6 (well, modulo insane allocation policies the RIR communities could =
potentially create, but hopefully rational folks will stop that. =
Hopefully).  If you=92re concerned, do the math: e.g., assume a couple =
of orders of magnitude more allocations per year than the current IPv4 =
burn rate, assume an IPv6 /48 =3D an IPv4 /32 and then see how many =
decades the existing /3 of global unicast IPv6 will last.

The real issue is how we=92re going to scale routing. Allocating /48s to =
all your customers out of your /32 (or /28 or whatever the default ISP =
allocation is this week) won=92t affect that in any significant way.

And besides, allocating all your customers a standard size should make =
your provisioning systems a lot easier, allowing you to conserve what=92s =
really important...

Regards,
-drc



home help back first fref pref prev next nref lref last post