[167133] in North American Network Operators' Group
Re: AT&T UVERSE Native IPv6, a HOWTO
daemon@ATHENA.MIT.EDU (Rob Seastrom)
Mon Dec 2 10:47:10 2013
To: Jean-Francois.TremblayING@videotron.com
From: Rob Seastrom <rs@seastrom.com>
Date: Mon, 02 Dec 2013 10:46:30 -0500
In-Reply-To: <OF0B25B15A.B5BD2FE4-ON85257C35.005455F3-85257C35.0054D7D3@videotron.com>
(Jean-Francois TremblayING's message of "Mon, 2 Dec 2013 10:26:43 -0500")
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Jean-Francois.TremblayING@videotron.com writes:
>> IPv4-thinking. In the fullness of time this line of reasoning [...]
>
> Hopefully, the fullness of time won't apply to 6RD (this is what
> was being discussed here, not dual-stack).
I agree but there's a subtlety here - we don't want to get people used
to parsimony in IPv6-land via chintzing out on deployments with a
transition technology. There are dinosaurs in every organization who
cling to the "monetizing addresses/subnets" model and will want to
charge more for a /48 or a /56 and point to the market being used to a
/60 or a /64, and it becomes the unfortunate task for folks like us to
argue against that line of thinking. We've got a little over two
decades worth of IPv4 penny-pinching to undo here, and the interim
deployments ought to help that to the degree possible.
> Most MSOs are planning /56s for native. ARIN 2011-3 is great, but
> it came a bit late (January 2012) for those who already had planned
> their network.
Yep, we're planning /56es for native at $DAYJOB too. Worse than /48s,
not as bad as /64s or /60s. Not that ARIN policies constrain this at
all; it was certainly possible before 2011-3 to get more than a /32 of
space, it just wasn't as easy (certainly there was more than one org
that managed to do it). As for the 6rd part, there was no 2010-12 6rd
policy before December 2010... then again, before August 2010 there
was no 6rd. :) I'm unfortunately quite familiar with the internal
costs of a do-over in a large organization.
-r
