[131002] in North American Network Operators' Group
Re: Definitive Guide to IPv6 adoption
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Oct 19 05:09:42 2010
From: Owen DeLong <owen@delong.com>
In-Reply-To: <alpine.BSF.2.00.1010181431330.21349@qbhto.arg>
Date: Tue, 19 Oct 2010 02:06:16 -0700
To: Doug Barton <dougb@dougbarton.us>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Oct 18, 2010, at 2:39 PM, Doug Barton wrote:
> On Mon, 18 Oct 2010, Owen DeLong wrote:
>=20
>> I think it's generally a bad idea. /48 is the design architecture for =
IPv6. It allows for significant innovation in the SOHO arena that we =
haven't accounted for in some of our current thinking.
>=20
> Q: Why are /48s everywhere a good idea?
> A: Because it's the design!
>=20
> Q: Why are /48s everywhere in the design?
> A? Because it's a good idea!
>=20
Which of course ignores the second half of my comment...
> This kind of crap is one of the reasons people get frustrated with =
IPv6 zealotry. If people are actually interested in deploying IPv6 then =
by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like =
the wrong allocation to end users are fixable, especially given that the =
vast majority of end user assignments are dynamic in the first place.
>=20
Unless those problems become endemic and start reducing the lowest =
common denominator to which vendors feel they must implement.
There are advantages to being able to use 16 bits to build various forms =
of hierarchical topology on a dynamic basis within a SOHO environment. =
If we reduce that to 8 bits, we will block innovations that are =
currently underway in this space.
> The model I've been advocating is for ISPs (who have enough space) to =
start off reserving a /48 per customer and then assigning the first /56 =
from it. If after real operational experience it turns out /48 is the =
right answer, you're all set. If /56 turns out to be sufficient, when =
you use up all of the first /56s you can start on the first /56 in the =
second /49, etc.
>=20
Uh, yeah, why not just get your /32 (or whatever larger prefix you =
started with) expanded or get an additional prefix to put the additional =
customers into? Then, you're still set and you haven't had to block or =
reduce capabilities your customers should be able to accept.
Owen
