 | reply to EZJohnson
Re: 6rd is long as live on at&t! The 6rd (not 6RD BTW) settings are below:
The 6rd service provider prefix is 2602:300::/28. The 6rd IPv4 mask length is 0. The 6rd border router (BR) IPv4 address is 12.83.49.81. The DNS IPv4 server addresses should be set to 99.99.99.53, 99.99.99.153. The DNS IPv6 server addresses should be set to 2001:1890:0FFF:0840::10, 2001:1890:0FFF:0841::10 (if needed) Enable sending all 6rd traffic to the 6rd BR |
|
 | reply to cramer
Re: When will AT&T U-verse have native IPv6 support? It is unclear why folks are complaining about 6rd. It works. |
|
 cramer join:2007-04-10 Raleigh, NC kudos:5 Reviews:
·AT&T Southeast
| It's not NATIVE IPv6. It adds additional overhead, complexity, and delay to any traffic. It depends on a BR to be functional 100% of the time. You still have to have a public routable IPv4 address. AND, it means every AT&T customer is shoehorned through a single (underpowered) router.
Done properly as a native layer, it's just as fast, robust, and resilient as the IPv4 network. 6rd is yet another incarnation (recent enough that a lot won't support it) of IPv6 over IPv4 tunneling.
I can almost guarantee every single piece of infrastructure equipment in AT&T's network (residential, business, and phone) is capable of IPv6. If it isn't, they have *intentionally* chosen to not load IPv6 firmware over the last decade. Not *provisioning* IPv6 throughout their network is a completely different f***-up -- they've had MANY years to set that up with minimal effect to customers. |
|
 | > it means every AT&T customer is shoehorned through a single (underpowered) router.
They aren't underpowered and there isn't just one. |
|
|
|
 | reply to cramer cramer:
You don't actually know if every intervening routing device is capable of supporting IPv6. Carrier class routers are not consumer nor even enterprise routers just needing a "firmware" upgrade or doing process switching through a general purpose CPU. They may have NPs that don't support IPv6 or TCAMs with limited address space unable to support IPv6.
Many of the BRAS and other older carrier routers require new linecards to support IPv6. All the carriers have to invest many millions of dollars to get all their equipment to support IPv6.
6rd does not depend on a single, underpowered BR - it uses anycast and will go to the closest BR that is available. It does not require a public IPv4, private IPv4 can work also - as long as it is routable from the BR.
6rd is just an transitional technology. Many ISPs around the world are rolling it out while they upgrade the rest of their network to eventually support "native" IPv6. With 6rd you will get IPv6 from your ISP several years before you might get "native" IPv6. And it is better than 6to4 because the BR is completely under the ISP control - outbound and return traffic go through the ISPs BRs. With 6to4 you have to be concerned about return traffic going through someone else's broken, unmanaged, under-capacity relay. |
|
 cramer join:2007-04-10 Raleigh, NC kudos:5 Reviews:
·AT&T Southeast
| I know very well what carriers use. Unless they're still running hardware from 10 years ago, the gear supports IPv6 in hardware. Again, unless they're running software from a decade ago, or have intentionally selected software that doesn't support IPv6, the gear supports IPv6. 5+ years ago, those would've been valid excuses. Today, they're lame and just show how cheap (greedy, etc.) you are. We've all known this was coming for a very long time; there's simply no excuse for not having moved forward.
Using private address space is a very bad idea. Any given RFC1918 address can only be used *once* within a 6rd domain (prefix.) Since that address is used to form your global IPv6 address, more than one node cannot use 192.168.1.1 (etc.) without using a different 6rd prefix.
I very seriously doubt AT&T has invested in multiple BR's and setup an anycast system to segment the user base... all for the lame publicity of claiming "we support IPv6." They've wasted enough time and money on yet more tunneling crap. Remember AT&T never setup a 6to4 gateway, and never peered with anyone who did. (or more likely are actively filtering it out.) After the next big IPv6 press day, mark my words, this crap will fall into abandonment. (only when it starts costing them customers will they really care to do it right.)
[Seeing how Cisco's PRE-1 went end-of-support Aug/2011, carriers should've been upgraded to PRE2 or better long ago. So any Cisco shop should be all set for native IPv6.] |
|
 | reply to ccjunk said by ccjunk :6rd is just an transitional technology. Many ISPs around the world are rolling it out while they upgrade the rest of their network to eventually support "native" IPv6. With 6rd you will get IPv6 from your ISP several years before you might get "native" IPv6. .
said by "http://networkingexchangeblog.att.com/enterprise-business/what-you-need-to-know-about-ipv6-infographic/#more-3612" :Regarding UVerse/IPDSLAM, almost all RGs/modems will be field upgradeable to support IPv6. This will eliminate the need for new CPE, as the users will just be enabled once we roll it out. Our implementation is 6rd based. But from the users point of view, it looks like native dual stack on the LAN behind the RG. Eventually on the Lightspeed services we will be using DHCPv6 on the WAN. Again, xDSL will NEVER see true native IPv6.
/M |
|
 cramer join:2007-04-10 Raleigh, NC kudos:5 Reviews:
·AT&T Southeast
| By that, it's rather clear they never intend to offer native IPv6 to Uverse. FastAccess DSL will never see IPv6 of any kind. (and honestly, 90% of the aged modems there will never have IPv6 firmware.) And their definition of "most" is very flawed.
Also, the "it's just on" one day is going to be a f'ing nightmare for everyone. One day, at random, every machine that had previously been tucked away from the internet by NAT will be completely wide open to the internet. We're aware of how windows boxes fare in such an environment -- they'll be hacked into DDoS zombies in under 30sec once someone finds them. (and don't let the IPv6 idiots fool you... even in a /64 namespace, it's not that hard to find the machines. esp. when they're generating traffic.) |
|
 1 edit | reply to The Chef
Re: 6rd is long as live on at&t! In other news, does anyone have this actually working? My setup is having issues and I'm not sure if it's my router or AT&T.
I can ping6 stuff just fine, ipv6.google.com loads just fine, but anything that actually transfers data doesn't work. hxxps:// hangs at 'connected', hxxp:// hangs at 'waiting for ...', all speedtests time out, and scp copies just hang. It looks like PMTU discovery is totally broken from the internet, and that's kinda important when tunnelling! Actually, it looks like ALL ICMP to/from the 6rd gateway is filtered...
I can run `ping6 -M do -c1 -s1440 2607:f878::xyz` from inside my network to my dedicated server and it correctly returns: PING 2607:f878::xyz(2607:f878::xyz) 1440 data bytes From 2602:306::zzz icmp_seq=1 Packet too big: mtu=1480
But when I run it from my server back to my network here, it simply times out (1 packets transmitted, 0 received, 100% packet loss, time 2873ms). It works fine as long as I use -s1432 or less.
Can anyone using 6rd post a IPv6 speedtest?
/M
Edit: found a ipv6-only site big enough to not load: »ipv6.bjornerback.com/ . I can `wget` it from my server just fine, but nada from AT&T's connection. Does it work for anyone else? |
|
 | reply to cramer
Re: When will AT&T U-verse have native IPv6 support? > One day, at random, every machine that had previously been tucked away from the internet by NAT will be completely wide open to the internet.
That is not the case. The AT&T implementation supports Explicit Context Based Access Control (Reflexive ACL) by default (as recommended in IETF RFC 4864), which means it will provide the same behavior as NAPT in terms of only allowing (by default) inbound traffic in response to outbound traffic. |
|
 | reply to cramer (duplicate of above - deleted) |
|
 ccjunk join:2006-06-29 Austin, TX | reply to mackey
Re: 6rd is long as live on at&t! said by mackey:In other news, does anyone have this actually working? My setup is having issues and I'm not sure if it's my router or AT&T.
... But when I run it from my server back to my network here, it simply times out (1 packets transmitted, 0 received, 100% packet loss, time 2873ms). It works fine as long as I use -s1432 or less.
Are you running 6rd on the AT&T provided CPE or on your own router? If on your own router then you may need to set the MTU for the 6rd tunnel interface. 1472B should be safe (1500-20B 6rd header and 8B PPPoE header if on PPP based DSL; although PPP overhead should not present on U-Verse). |
|
 | said by ccjunk:Are you running 6rd on the AT&T provided CPE or on your own router? If on your own router then you may need to set the MTU for the 6rd tunnel interface. 1472B should be safe (1500-20B 6rd header and 8B PPPoE header if on PPP based DSL; although PPP overhead should not present on U-Verse). Both actually. I mainly use my own router, but what you posted is irrelevant - outgoing (which is what is affected by the interfaces' MTU) works just fine for all packet sizes, it's the INCOMING that's failing. I can run tcpdump on the WAN interface and see the tunnelled smaller packets coming in, but the big ones never make it that far.
/M |
|
 cramer join:2007-04-10 Raleigh, NC kudos:5 Reviews:
·AT&T Southeast
| reply to The Chef
Re: When will AT&T U-verse have native IPv6 support? While you certainly want such a firewall configuration in place, it needs to be something *YOU* put there and are thus *fully* aware of and aware of the consequences. The grandmothers of the world will never know one way or the other -- they won't even know they're using IPv6. Others will slowly run head-long into the i-didn't-know-it-was-there firewall. (pretty much the same as the i-turned-off-the-frakin-firewall firewall in the 2wire's. Or the DOCSIS3 crowd's firewall-is-still-on-in-bridge-mode firewall.)
Breaking a fundamental foundation of IPv6 ("end to end transparent") is a bad path forward (esp. if it's done on the ISP side) -- now, just like the always hated mess of IPv4 NAT, you need the same ever growing stack of protocol handlers to inspect outbound traffic so holes can be opened for dynamic inbound connections. (SIP being the biggest pain in the ass in this respect.)
E-CBAC would explain a few of the problems I've seen people report w.r.t. internet traffic not being able to reach them. And by extension why certain ICMP functions are broken. (read: buggy as hell implementation.)
[The more I look at it, the longer the list of stupid gets. And not just AT&T's specific brand of Stupid(tm).] |
|
 | reply to ConstantineM is there a 6rd border router that is in LA? -- 150/75 mbit Verizon FiOS connection FTW! |
|
 ccjunk join:2006-06-29 Austin, TX | reply to mackey said by "http://networkingexchangeblog.att.com/enterprise-business/what-you-need-to-know-about-ipv6-infographic/#more-3612" :Regarding UVerse/IPDSLAM, almost all RGs/modems will be field upgradeable to support IPv6. This will eliminate the need for new CPE, as the users will just be enabled once we roll it out. Our implementation is 6rd based. But from the users point of view, it looks like native dual stack on the LAN behind the RG. Eventually on the Lightspeed services we will be using DHCPv6 on the WAN.
Again, xDSL will NEVER see true native IPv6. /M Why do you say that? Both U-Verse and IPDSLAM are VDSL and ADSL2+ respectively. And in that quote they say they will support DHCPv6 in place of 6rd on the CPE WAN interface eventually. Do you define "true native IPv6" as something different? |
|
 lanbrown join:2009-04-05 West Bloomfield, MI | reply to cramer said by cramer:I know very well what carriers use. If that were true, you wouldn't be making all these assumptions like you do.
said by cramer:Unless they're still running hardware from 10 years ago, the gear supports IPv6 in hardware. This just shows that you do not actually know what is being used. it is no secret that Alcatel is the integrator behind U-verse. So one only needs to look at Alcatel to see what the capabilities of the equipment are to see what it supports.
»www.alcatel-lucent.com/wps/Docum···n_AN.pdf
quote: IOM2 hardware modules for the Alcatel-Lucent 7750 SR support a number of IPv6 support capabilities, such as for business services. For IPv6 residential service deployment the IOM3-XP and hardware modules are required, not only for the superior density, capacity and performance, but also to provide additional subscriber management capabilities to function as an IPv6 BRAS/IPv6 BNG due to the inherent differences between IPv4 and IPv6.
The IOM3-XP modules have NOT been available for the past decade which is contrary to your assumptions. They have been available for about three years now. U-verse has been around longer than three years. So that means that a lot of the network would have the older modules and thus to support native IPv6 would require a lot of cards to be upgraded. The IOM doesn't actually have any ports on it, it is just a module where the cards with the physical ports plug into.
One just cannot put the IOM3's in either, they take more power and the power supplies need to be upgraded as well. So while it is not a forklift upgrade, it isn't just a simple change either and clearly more than just putting IP's on the equipment itself like you tend to believe. |
|
 cramer join:2007-04-10 Raleigh, NC kudos:5 Reviews:
·AT&T Southeast
| reply to ccjunk No, they said "on the Lightspeed services"... i.e. FTTH, which is 0.001% of their installs. They say NOTHING about EVER rolling out native IPv6. And their "almost all" claim is most certainly a lie, or gross overestimate at best.
Uverse means the non-ATM, non-PPPoE, non-legacy customers -- VDSL or ADSL, they're still Uverse. "ADSL" means the millions of legacy ATM cell based dsl customers, most of whom are out of range of the Uverse gear. They *could* be upgraded to IPDSLAM, but that means spending money on hardware upgrades, and AT&T is "done with the Uverse rollout", so that's not likely to happen. (they're perfectly happy continuing to cash those millions of checks.) |
|
 lanbrown join:2009-04-05 West Bloomfield, MI | said by cramer:They *could* be upgraded to IPDSLAM, but that means spending money on hardware upgrades, and AT&T is "done with the Uverse rollout", so that's not likely to happen. (they're perfectly happy continuing to cash those millions of checks.) 1) If they did upgrade to an IPDLAM that may not actually mean native IPv6 support as the CPE equipment could be quite old and it itself doesn't support it.
2) What advantage does IPv6 really bring to anyone? Everything that is accessible IPv6 can be access via IPv4. How many sites/services are actually dual-stacked on the Internet? You can access far more with IPv4 than you can with IPv6. |
|
 cramer join:2007-04-10 Raleigh, NC kudos:5 Reviews:
·AT&T Southeast
| reply to lanbrown (I sware it's like dealing with a f'ing 5yo)
Go work for a few ISPs, build a few dozen networks, and then get back to me.
Yes, there are legacy, "10 year old", devices in ISP networks... it's part of the "if it ain't broken, don't break it" mantra. Until there's a reason to upgrade it, it'll sit there doing what it's been doing for years. HOWEVER, the number of those devices is low, and they aren't "in the core" -- because they aren't supported by the vendor, and traffic loads have increased well beyond their capabilities. Good ISPs plan ahead and budget for equipment refreshes, upgrades, and additions. (they're prepared for it to fail and have spares at the ready.) But you're smart, so you knew all that already.
The document you linked is ~3 years old, and is mostly manager dazzling drivel. (I'll have to look again, but it didn't see any mention of 6rd in it.) AT&T's choice of hardware is a check in the "intentionally selected non-IPv6 capable hardware/software" column. (and shame on Alcatel for building something without IPv6 support.) The majority of the network is layer-2 transparent, so IPv6 will flow across it just fine; it's the aggregation point(s) that have to deal with it at layer-3 -- it's not like they have to go replace the line cards in every VRAD in the country, they have to upgrade gear they knew was going to be an issue from day one.
I made no assumptions on the age of AT&T's Uverse gear. "Decade old" is a general reference to *everyone*, not just AT&T. And AT&T's network is not exclusively uverse gear. (uverse, vdsl, and ipdslam aren't that old, but the legacy ADSL network is over a decade old.) I find it amazing people will design, and buy, core networking gear without considering it's IPv6 capabilities. But, given the engineers are rarely the one's who make such decisions, I'm not *that* surprised. (hell, *residential consumers* are starting to look for IPv6 on the tin when shopping around.) [I know how that conversation went... the engineers point out the lack of IPv6; the exec(s) in charge of the billion dollar purchase mention it over saki at the local sushi bar; the alcatel sales rep(s) say they'll support it "in the next revision" -- and they are, of course, lying.] |
|