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

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_Googleconf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0

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.

I see that FiOS did a trial in April 2010
http://newscenter.verizon.com/press-releases/verizon/2010/verizon-begins-testing-ipv6.html
(it mentions special CPE). What about verizon DSL?

Comcast is currently conducting trials:
http://comcast6.net/ (anyone participated in this?)

How about TimeWarnerCable? They don't seem to have any sort of v6
offering, on wholesale or retail services.

Am I missing anyone in the DSL/Cable/FTTH market?

As for wireless broadband providers, there is satellite and 3g/4g/LTE. I
haven't looked at the satellite providers. I know Verizon is offering
dual stack on their LTE service, according to a thread a couple weeks
ago. T-mobile is offering it on the small subset of phones that have v6
capable baseband.

For grins and giggles, how does North America stack up against other
regions, when it comes to access network ipv6 delivery.

Thanks.

- --
Charles N Wyble (charles@knownelement.com)
Systems craftsman for the stars
http://www.knownelement.com
Mobile: 626 539 4344
Office: 310 929 8793

-----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_Googleconf-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

(SNIP)

Comcast is currently conducting trials:

http://comcast6.net/ (anyone participated in this?)

Yes, I am in one of their trials now.
For the trial I am in (Residential cable, 6RD) they shipped me a
Cisco/Linksys running OpenWRT/LuCI.
Mostly been working great ...

/TJ

Found an article talking about at&t v6 support

http://www.networkworld.com/news/2010/102710-att-ipv6.html?page=3

Also found
http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/

TW Cable has no IPv6 offering.

However, TW Telecom provides IPv6 connectivity upon request. By default they only provide a /56 if you need multiple subnets and you have to provide further justification to get a /48.

Antonio Querubin
e-mail/xmpp: tony@lava.net

In message <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com>, Owen DeLong write
s:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
> Is anyone tracking the major consumer/business class access networks
> delivery of ipv6 in North America?
>=20
> 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?
>=20
> =
https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Google=
conf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=3D0
>=20
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.

This comes from using a single 6rd prefix for all the clients.

Those saying this is the way to do this really havn't thought about
what they are going to have to do once they can't get enough IPv4
addresses to give a public one to each customer that needs a IPv4
addresses and also needs 6rd. The "simple" solution of a signgle
prefix doesn't work.

6rd doesn't have to consume space badly and it shouldn't consume
space badly if done right.

DHCP servers don't hand out the same router to each client. They
hand out the same router to all clients on the same subnet. ISP's
are capable of configuring their DHCP servers to do that. Configuring
them to hand out a 6rd prefix on a per subnet basis is no harder.

Just ask for a /48 for each IPv4 address you intend to support 6rd
on. For each block IPv4 block you get from RIR you specify a
matching 6rd prefix. This prefix is stable for the life of the
IPv4 block's allocation. When you get a new IPv4 block you add the
6rd prefix to the configuration system.

If you are using RFC 1918 addresses to connect to your customers
and NATing that you request enough /48's to cover the amout of RFC
1918 space you are using.

If you are re-using space in multiple places then 6rd becomes a
little more complicated as the prefixes need to differ for each
re-uses. Note the naive single 6rd prefix doesn't work in this
situation so ISPs doing this will need do something more complicated.

Also give that address space will almost certainly need to be re-used
while 6rd is also in use I fail to see the objection to doing it
sensibly from the get go.

Down the track I can see 6rd prefixes being allocated on request
being just one more thing that the consumer can request via a web
form. This will allow the ISP to recover the space being used by
6rd.

Stuck with /64 in practice, which will evolve into /60 when the IPv6
support in their Freebox will be better. I don't think that we'll get
anything more than /60 before the next decade...

At least, they have been able to provide pseudo-native IPv6 for years.
If anyone asks, performances of IPv6 over Free's 6rd are almost the same
than IPv4's.

This is all hearsay, but I learned from a shared vendor that AT&T is putting
pressure on them to complete their IPv6 support, so that the vendor is
moving up completion from Q4 to Q2. This was a sales person talking, so who
knows.

Frank

Two good lists are here:
http://www.sixxs.net/faq/connectivity/?faq=native
http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers

Frank

All the leading MSOs are actively working towards IPv6 trials and
deployments, they're just at different stages. Comcast, as we all can see,
is publicly leading, but there are others who are not too far behind.

Frank

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

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

Maybe not NAT but some kind of proxy ND and/or a migration from routing firewalls to bridging firewalls. If the broadband provider is only providing a single /64, it's not likely they're gonna be willing to add routes to your gateway.

Antonio Querubin
e-mail/xmpp: tony@lava.net

All the leading MSOs are actively working towards IPv6 trials and
deployments, they're just at different stages. Comcast, as we all can see,
is publicly leading, but there are others who are not too far behind.

See "U.S. cable companies embrace IPv6"
    http://www.networkworld.com/news/2010/102810-cable-ipv6.html

Thomas

I guess I won't need to add routes to my gateway, only subnetting on the
inside will probably do for the time being (a hub/spoke topology,
routing only between directly-connected subnets). And many ISPs allow
you to buy your own CPE.

Using an AirPort Extreme (or other home router with similar features)
in bridged mode would do the trick, i guess.

:slight_smile:

cheers,

Carlos

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

In message <C966C429.7FD46%john_brzozowski@cable.comcast.com>, "Brzozowski, John" wri
tes:

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.

No it doesn't require /16 to deploy 6rd with /48's. It does however
require the ISP to do more than say "this is our 6rd prefix" and
shove all 32 bits of IPv4 address into the delegated prefix. The
moment the ISP needs to re-use IPv4 addresses for customers the
simple "this is our 6rd prefix" fails to work.

If an ISP has 34/8 and 35.0/9 then it needs two blocks of IPv6
addresses on a /24 and one a /25, which would be used like this:

  [P1 24 bits][low 24 bits][subnet 16 bits][host 64 bits]
  [P2 25 bits][low 23 bits][subnet 16 bits][host 64 bits]

The 6rd routers for P1 know that P1 means the top 8 bits are 34.
The 6rd routers for P2 know that P2 means the top 9 bits are 35.0.

The DHCP server for subnets in 34/8 are configured to hand out 6rd
prefix info for P1 (6rdPrefixLen=24, IPv4MaskLen=8). Similarly
35.0/9 and P2 (6rdPrefixLen=25, IPv4Masklen=9). This really shouldn't
be to hard for the provisioning systems to handle.

If the ISP was using 10/8 twice to connect to its customers then
it would need two /24's (P1 and P2). P1 and P2 would both have
6rdPrefixLen=24, IPv4MaskLen=8.

See RFC 5969 (RFC 5569 describes what Free originally did).

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.

Why?

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.

You should be able to do that today if you're so inclined, but, you lose
some features.

Maybe not NAT but some kind of proxy ND and/or a migration from routing firewalls to bridging firewalls. If the broadband provider is only providing a single /64, it's not likely they're gonna be willing to add routes to your gateway.

If they're routing a /64 to your gateway, you're all set. If they're not,
then, how are you getting the /64 in the first place?

None of the providers I've talked to are using single /64s for any
other reason that CPE limitations. The worst case I'm aware of
today is Free.FR who is limiting their customers to a /64 today
due to CPE problems, but, has allocated /60 per customer and
plans to make /60s available as soon as the CPE can support
it.

Owen

I agree with you, but, will it happen? The same fixed boundary
behaviour that makes the /64 so convenient for LAN addressing ends up
making the same /64 very convenient for ISPs as well. They associate
the /64 with the "single public IP" they issue to customers nowadays.

Again, I would *love* to be wrong on this one. Seriously. This is an
argument I sincerely hope to lose, but after being in the ISP business
for more than 10 years, I wouldn't expect my local ISPs at least to
issue anything shorter than a /64 to customers.

And... the argument for this will have a commercial background as
well. They will perceive customers who want multiple subnets as
customers who can pay more. They will make customers who want multiple
subnets go through hops to get a shorter prefix. Justifications and
such. Very few people will do it.

warm regards

Carlos

I agree with you, but, will it happen? The same fixed boundary
behaviour that makes the /64 so convenient for LAN addressing ends up
making the same /64 very convenient for ISPs as well. They associate
the /64 with the "single public IP" they issue to customers nowadays.

Most are not. I don't know where you are getting your information.

Again, I would *love* to be wrong on this one. Seriously. This is an
argument I sincerely hope to lose, but after being in the ISP business
for more than 10 years, I wouldn't expect my local ISPs at least to
issue anything shorter than a /64 to customers.

Then embrace victory. You are wrong. One of the largest residential
broadband providers in the world just told you that you are wrong.
(John is running IPv6 for Comcast. He speaks with a pretty authoritative
voice on the topic.) I talk to a lot of these providers on a pretty
regular basis. I talked to groups of them about IPv6 in 30 countries
on 6 continents last year. I have yet to encounter a single provider
that thinks a single /64 is the be-all-end-all for residential services
in IPv6.

And... the argument for this will have a commercial background as
well. They will perceive customers who want multiple subnets as
customers who can pay more. They will make customers who want multiple
subnets go through hops to get a shorter prefix. Justifications and
such. Very few people will do it.

If they do, that will be a radical change from the current state of
the environment, possibly brought about by people telling them
that is what they expect.

Owen