IPv6 enabled carriers?

Does anyone have a list of carriers who are IPv6 capable today?

I would assume this would be rolled out in larger cities first but
anything outside of "testbed environments" and "trials" as in
Comcast's recent announcement seems to be all that is available.

I'm being tasked with coming up with an IPv6 migration plan for a data center.

Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business
and Qwest are capable as those are the typical ones I deal with.

Thanks...Chuck

Ones I have personal experience with:

GLBX - yes
SAVVIS - no
VZB - yes, good luck
ATT - "Beginning in 1Q2010 MIS will provide the ability to support IPv6
in a dual stack mode."

When I disconnected my SAVVIS circuit in November 2009 I explicitly told
them IPv6 was a deciding factor. Not all of Verizon's pops are IPv6
enabled, which may cause you trouble ordering it. It's put me in month
11 of trying to turn up a dual-stack circuit because they refuse to read
the order and keep putting it in Sacramento (v4 only) when it needs to
go to San Jose (dual-stack). Sprint wasn't on your list, but they are
rolling out native IPv6 support on all of 1239. I've been using their
6175 testbed since 2005.

~Seth

I believe most of the ones you've listed have service offerings in various stages of availability.

You should be able to pop over here:

telnet route-views.equinix.routeviews.org

and take a look at the table easily enough to determine what providers have it enabled. Some have been operating with a different ASN for a number of years, including ATT and Sprint.

If you're not feeding route-views, and are IPv6 enabled, please do. It helps those interested in routing research and is a valuable community asset.

- Jared

We have a dual-stack 10G link to XO here in Seattle so they are doing it
as well... Savvis is not doing v6 yet either so far as I know, we are
going to make that an issue at our next renewal. I am told that
level3 is working on a full dual-stack roll-out currently and that it
should be available "soon" and will replace the current tunneled options
they have.

Thanks,

John van Oppen
Spectrum Networks (AS11404)

SixXS maintains a list here:
http://www.sixxs.net/faq/connectivity/?faq=ipv6transit.
The IPv6 BGP weather map is a good resource:
http://bgpmon.net/weathermap.php?inet=6
You can also use Geoff Huston's IPv6 CIDR report:
http://www.cidr-report.org/v6/as2.0/

<plug>I should also note that my employer, tw telecom, offers IPv6
everywhere on 4323 - you have to ask for it, but it is available.</plug>

~Chris

Recent experience with VZB in a major central European city:

VZB: we can tunnel 6 to you over 4 but the /48 we give you will probably change down the line once we roll out "real" v6.

We are getting native IPv6 from HE and Qwest at this time. Qwest was
doing a beta of IPv6 that we were (are) a part of. Not sure of they
have ended the beta and rolled out to production.

---- ---- ---- ----
Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
http://uplogon.com | +1 906 774 4847 | chris@uplogon.com

Does anyone have a list of carriers who are IPv6 capable today?

I would assume this would be rolled out in larger cities first but
anything outside of "testbed environments" and "trials" as in
Comcast's recent announcement seems to be all that is available.

Check out http://www.getipv6.info there is some information there.

Hurricane Electric has a full production dual-stack environment.

I'm being tasked with coming up with an IPv6 migration plan for a data center.

Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business
and Qwest are capable as those are the typical ones I deal with.

To the best of my knowledge, each of those has varying degrees of IPv6
availability and none is "full production product" yet. My information could
be old.

Owen

> Does anyone have a list of carriers who are IPv6 capable today?
>
> I would assume this would be rolled out in larger cities first but
> anything outside of "testbed environments" and "trials" as in
> Comcast's recent announcement seems to be all that is available.
>
> I'm being tasked with coming up with an IPv6 migration plan for a data center.
>
> Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business
> and Qwest are capable as those are the typical ones I deal with.
>

Ones I have personal experience with:

GLBX - yes
SAVVIS - no
VZB - yes, good luck
ATT - "Beginning in 1Q2010 MIS will provide the ability to support IPv6
in a dual stack mode."

When I disconnected my SAVVIS circuit in November 2009 I explicitly told
them IPv6 was a deciding factor. Not all of Verizon's pops are IPv6
enabled, which may cause you trouble ordering it. It's put me in month
11 of trying to turn up a dual-stack circuit because they refuse to read
the order and keep putting it in Sacramento (v4 only) when it needs to
go to San Jose (dual-stack). Sprint wasn't on your list, but they are
rolling out native IPv6 support on all of 1239. I've been using their
6175 testbed since 2005.

+ Tata AS6453, production network since quite some time now, dual stack.

mh

Owen DeLong wrote:
[..]

Hurricane Electric has a full production dual-stack environment.

I'm being tasked with coming up with an IPv6 migration plan for a data center.

Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business
and Qwest are capable as those are the typical ones I deal with.

To the best of my knowledge, each of those has varying degrees of IPv6
availability and none is "full production product" yet. My information could
be old.

Always fun to read how people who work for some place (you might want to
use either your work address or actually disclose directly why you are
pimping something) like to bash their competition else while they run a
'full production' network without providing true arguments to counter
that, nevertheless lets take a look at that "full production network":

3 10g-3-2.core1.sjc2.ipv6.he.net (2001:470:0:3c::1) 66.649 ms 66.555
ms 66.511 ms
4 10g-3-2.core1.pao1.ipv6.he.net (2001:470:0:32::2) 59.644 ms 62.214
ms 62.164 ms
5 3ffe:80a::b2 (3ffe:80a::b2) 61.770 ms 62.135 ms 62.506 ms
6 hitachi1.otemachi.wide.ad.jp (2001:200:0:4401::3) 182.958 ms
181.156 ms 181.346 ms
7 2001:200:0:1c04::251 (2001:200:0:1c04::251) 183.827 ms 181.617 ms
181.554 ms

Yes, 6bone is still alive (sing along to that well known Portal tune :wink:

I, and others, have mentioned that problem already several times since
2006-06-06, you know the day that 6bone got shut down.

It is also still amazing that "full production networks" are not able to
do proper uRPF or let alone IRR based filtering as in that case you
would not even see that nonsense...

Also if you are running such a "full production network" you might want
to disclose the traffic levels that you do. Or is there something to
hide there?

Thus: please actually FINALLY fix your "full production network" by
finally renumbering at PAIX. You are peering with other folks, thus you
know who is on the other side, as such, after 4 years, you might want to
finally move on from this 6bone space and possibly deploy uRPF.
Then again, you'll notice those traffic levels one day when you will go
into history as the source of the first large spoofed DoS attack against
whatever truly important service.

Thanks for your attention.

Greets,
Jeroen
  (who has no true ISP hat :wink:

I think that list should also include TeliaSonera. TSIC does offer v6 transit, although their product sheet only mentions IPv4.

Pekka Savola wrote:

SixXS maintains a list here:
http://www.sixxs.net/faq/connectivity/?faq=ipv6transit.

I think that list should also include TeliaSonera. TSIC does offer v6
transit, although their product sheet only mentions IPv4.

"Updates & addons can be directed to The SixXS Staff." aka info@sixxs.net :wink:

All of these entries have been requested by the company themselves as
such the company states that they can deliver.

As the page states, peeringdb is also an excellent place to figure out
where those providers are truly present (again according to what they
provide to these systems).

Greets,
Jeroen

To pile on in the spirit of "if people don't complain, nothing will change" - is VZB still insisting on filtering >/32 at their peers? While ARIN is allocating /40s and /48s directly?

-C

As far as I know, yes.

~Seth

I believe so ... will be even more impactful as LTE gets deployed.

Another nit - They are also blocking Protocol41 on their EV-DO network.
While this is a 'noble, if poorly thought out, effort' to prevent IPv6 from
impacting their cel phone users - it kind of messes up those of us who have
aircards (and got used to 6to4 for quick and dirty IPv6 connectivity).

/TJ

TJ wrote:

To pile on in the spirit of "if people don't complain, nothing will change"
- is VZB still insisting on filtering >/32 at their peers? While ARIN is
allocating /40s and /48s directly?

I believe so ... will be even more impactful as LTE gets deployed.

Another nit - They are also blocking Protocol41 on their EV-DO network.
While this is a 'noble, if poorly thought out, effort' to prevent IPv6 from
impacting their cel phone users - it kind of messes up those of us who have
aircards (and got used to 6to4 for quick and dirty IPv6 connectivity).

If you want quick&dirty then 6to4 is not going to help you in most cases
anyway, as you are mostly landing behind a NAT, as such Teredo (miredo
on non-windows boxes) is a way out and there is of course TSP which can
run over TSP and AYIYA. For some magical reason I prefer the last :wink:

Also note that is it is their network, they can filter all they want,
just like you do you in your own.

(How did you btw determine that it is filtered, maybe the 6to4 packets
are just not coming back from a broken relay somewhere, that is very
hard to determine)

Greets,
Jeroen

<snip>
Sprint wasn't on your list, but they are
rolling out native IPv6 support on all of 1239. I've been using their
6175 testbed since 2005.

~Seth

Not trying to make a big shameless plug here, but I thought I should at least confirm this to be true. Mostly domestic until ~mid-year, limited port availability in the next couple of months, more sites and port speeds available as the year and the rollout progresses.
www.sprintv6.net or your Sprint sales droid will have updates as they're available.

Thanks,
Wes

TJ wrote:
>
>> To pile on in the spirit of "if people don't complain, nothing will
change"
>> - is VZB still insisting on filtering >/32 at their peers? While ARIN is
>> allocating /40s and /48s directly?
>>
>
> I believe so ... will be even more impactful as LTE gets deployed.
>
> Another nit - They are also blocking Protocol41 on their EV-DO network.
> While this is a 'noble, if poorly thought out, effort' to prevent IPv6
from
> impacting their cel phone users - it kind of messes up those of us who
have
> aircards (and got used to 6to4 for quick and dirty IPv6 connectivity).

If you want quick&dirty then 6to4 is not going to help you in most cases
anyway, as you are mostly landing behind a NAT, as such Teredo (miredo
on non-windows boxes) is a way out and there is of course TSP which can
run over TSP and AYIYA. For some magical reason I prefer the last :wink:

In general, yes - but VZW's EV-DO (currently) always hands-out a public IP
...

Also note that is it is their network, they can filter all they want,
just like you do you in your own.

Sure, and ISPs that do this (too much) get bad press and lose customers ...

(How did you btw determine that it is filtered, maybe the 6to4 packets
are just not coming back from a broken relay somewhere, that is very
hard to determine)

Because someone (who may have been employed by my employer) showed them that
cel phones were horrendously exposed (I am looking at you, Windows Mobile
devices) to IPv6 via Prot41 ... and their answer, rather than fix the
problem, was to just block Prot41 (whether this is an ACL or they black-hole
192.88.99.1 I don't care, they should (IMHO) stop). Atleast that was what I
heard, and 6to4 currently fails - leading me to believe this to be the case.

(I also believe they are munging AAAAs queries or replies, but haven't taken
the time to poke into that or work around it as I just use less-quick and
less-dirty IPv6 connectivity - which may include the options you plugged :slight_smile:
  )

To pile on in the spirit of "if people don't complain, nothing will change"
- is VZB still insisting on filtering >/32 at their peers? While ARIN is
allocating /40s and /48s directly?

I believe so ... will be even more impactful as LTE gets deployed.

how so exactly?? LTE is really just a 'last mile' tech... whether it's
v4 or v6 doesnt' seem to matter (to the fact that it's LTE)

Another nit - They are also blocking Protocol41 on their EV-DO network.

<cough>vzw not vzb</cough>

While this is a 'noble, if poorly thought out, effort' to prevent IPv6 from
impacting their cel phone users - it kind of messes up those of us who have
aircards (and got used to 6to4 for quick and dirty IPv6 connectivity).

there are other carriers ya know?

>

>> To pile on in the spirit of "if people don't complain, nothing will change"

>> - is VZB still insisting on filtering >/32 at their peers? While ARIN is

>> allocating /40s and /48s directly?

>>

>

> I believe so ... will be even more impactful as LTE gets deployed.

how so exactly?? LTE is really just a 'last mile' tech... whether it's

v4 or v6 doesnt' seem to matter (to the fact that it's LTE)

Agreed. But, the hope is that LTE will be a "green field" IPv6 deployment both to the end-user device and in the infrastructure. There are some material difference in LTE (dual-stack bearers) that make LTE more IPv6 friendly.

> Another nit - They are also blocking Protocol41 on their EV-DO network.

vzw not vzb

> While this is a 'noble, if poorly thought out, effort' to prevent IPv6 from

> impacting their cel phone users - it kind of messes up those of us who have

> aircards (and got used to 6to4 for quick and dirty IPv6 connectivity).

there are other carriers ya know?

And, some of those carriers, are working very hard to deploy native IPv6 to the customer, and have beta networks on the air now.

http://www.ietf.org/mail-archive/web/3gv6/current/msg00269.html

-Cameron [t-mobile employee]