Re: What's the current state of major access networks in North America ipv6 delivery status?

["Brzozowski, John" <John_Brzozowski () Cable Comcast com>]

I am definitely *NOT* an advocate of NAT66 nor am I an advocate of further
subneting a /64 into longer prefixes.

Where additional IPv6 prefixes are required a prefix shorter than a /64
should be delegated.

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski () cable comcast com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================




On 1/27/11 7:56 AM, "Carlos Martinez-Cagnazzo" <carlosm3011 () gmail com>
wrote:

> Reading this thread, and building on many comments to a previous one,
> I definitely see the need for subnetting a /64 arising sooner than
> later.
>
> It might not be perfect, It might be ugly, but it will happen. And, if
> you ask me, I would rather subnet a /64 than end up with a ipv6
> version of NAT, a much worse alternative.
>
> cheers,
>
> Carlos
>
> On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John
> <John_Brzozowski () cable comcast com> wrote:
> > In order to deploy /56 to end users would require an IPv6 /24 be
> > dedicated
> > to 6rd, /48s would require a dedicated IPv6 /16.  This assumes an
> > operator
> > wants/needs to provide IPv6 via 6rd to end users where their IPv4
> > address
> > is fully unique.  There is quite a bit of IPv6 address space that does
> > not
> > gets utilized in this model.
> >
> > The routers we are using as part of the trials only support /64 as such
> > we
> > are using an IPv6 /32.
> >
> > It is also important that operators plan for the ability to delegate
> > prefixes that are shorter than a /64.  There are several cases that we
> > have seen where the router can only make use of a /64.  This is better
> > than nothing when referring to legacy devices that have been able to
> > introduce some support for IPv6 and would have otherwise been IPv4 only
> > devices.
> >
> > John
> > =========================================
> > John Jason Brzozowski
> > Comcast Cable
> > e) mailto:john_brzozowski () cable comcast com
> > o) 609-377-6594
> > m) 484-962-0060
> > w) http://www.comcast6.net
> > =========================================
> >
> >
> >
> >
> > On 1/26/11 5:02 PM, "Owen DeLong" <owen () delong com> wrote:
> >
> > > On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote:
> > >
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > >
> > > > Is anyone tracking the major consumer/business class access networks
> > > > delivery of ipv6 in North America?
> > > >
> > > > I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly
> > > > looked into 6rd. Is this a dead end path/giant hack?
> > > >
> > > >
> > > > https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo
> > > > gl
> > > > econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
> > > It's a fairly ugly way to deliver IPv6, but, as transition technologies
> > > go, it's the least dead-end of the options.
> > >
> > > It at least provides essentially native dual stack environment. The
> > > only difference is that your IPv6 access is via a tunnel. You'll
> > > probably
> > > be limited to a /56 or less over 6rd, unfortunately, but, because of the
> > > awful way 6rd consumes addresses, handing out /48s would be
> > > utterly impractical. Free.fr stuck their customers with /60s, which is
> > > hopefully a very temporary situation.
> > >
> > > > I spoke with impulse.net last year, which appears to serve large
> > > > portions of the AT&T cable plant in Southern California. They were
> > > > willing to offer native ipv6. Not sure how (one /64, a /48) etc.
> > > You should definitely push your providers to give you a /48 if
> > > possible. If /56 or worse /60 or worst of all, /64 become widespread
> > > trends, it may significantly impact, delay, or even prevent innovations
> > > in the end-user networking/consumer electronics markets.
> > >
> > > Owen
>
>
>
> -- 
> --
> =========================
> Carlos M. Martinez-Cagnazzo
> http://www.labs.lacnic.net
> =========================