Reviews:
 ·TekSavvy DSL
| reply to TSI Gabe
Re: IPv6 beta I'm not sure that you want Static IPv6, see if there is an option for IPv6 autoconfiguration (may be labelled IPv6 router solicitation) or PPP IPv6 or IPv6CP. This should fill in the WAN stuff automatically.
LAN IPv6 Prefix: Put the /56 address here
LAN Prefix Length: 64
LAN IPv6 Address: Put the /56 address here but end with ::1 this time
You can leave the IPv6 DNS empty, Teksavvy's v4 DNS return v6 results, or you could put in the Teksavvy ones, HE ones or Google ones if you want.
Router Advertisement: Enable - this should then mean that the computers can now use IPv6. |
|
marcel
join:2013-02-23
Mississauga, ON | OK when I fill it in the way you say I get a message "not a valid IP address!" |
|
marcel
join:2013-02-23
Mississauga, ON | I am not being successful at setting it up at all, I'll give it one more try next weekend and then I'll just give up on this. If anyone has any experience with ASUS router setup for use with IPv6 I would appreciate any suggestions.
I've been reading up about IPv6 tunneling through TunnelBroker using ASUS router apparently that works fine but I am assuming that that is not the same thing.
It kind of sucks to have a router that's suppose to be IPv6 ready and I can't get it going with my ISP. |
|
Reviews:
·TekSavvy DSL
| reply to TSI Gabe
I just pulled up the manual for that router from the ASUS web site and it doesn't even list the options available for IPv6. Page 78 just says contact your ISP, like Teksavvy is meant to know what to click on in the ASUS web interface when ASUS won't even document.
ASUS, your manual sucks!  |
|
Reviews:
·TekSavvy DSL
| reply to TSI Gabe
Anyone noticed the performance of the hsiservice.net logins is poor lately?
Here in High Park (Toronto) logging in via @teksavvy.com = 8ms pings to google.ca and 25/10 perfect.
Disconnecting, logging in via @hsiservice.net with IPV6 and google.ca (over IPV4) is 60-120ms with lots of judder and bandwidth is closer to 8Mbps down (and wildly variable and equally degraded ups).
I can reproduce this 100% of the time right now. |
|
| It's not the login, it's the AGAS links. I know they're doing some maintenance today and the load balancing is either not available or acting strangely. Keep reconnecting until you end up on a non-congested link. |
|
Reviews:
·TekSavvy DSL
| said by squircle:It's not the login, it's the AGAS links. I know they're doing some maintenance today and the load balancing is either not available or acting strangely. Keep reconnecting until you end up on a non-congested link.
Has been an issue for me for literally 2 weeks now, despite maybe a dozen or more disconnects / reconnects. |
|
| Same here. There's another thread about the AGAS problems; I've been having 200+ms first-hop ping times for weeks, slow speeds...
Anyways, I'm assuming that's why they're fiddling with the AGAS links today (to hopefully resolve the problem). |
|
| Affected yonge/401 as well. Seems to get worse in evenings. |
|
| reply to squircle
said by squircle:Same here. There's another thread about the AGAS problems; I've been having 200+ms first-hop ping times for weeks, slow speeds... That would be this thread:
»[DSL] Network congestion tonight?
TSI was saying they saw nothing wrong from their end (no single link near max) but I get 100-300ms ping and jitter all over the place with @hsiservice.net while on the other hand I get almost normal pingtest results with @teksavvy.com
Off-peak, both @teksavvy.com and @hsiservice.net give me 23-26ms ping and 0-2ms jitter.
During peak, @teksavvy.com gives me 35-65ms ping and 4-8ms jitter while @hsiservice.net gives me 100-330ms ping and 10-130ms jitter.
@hsiservice.net is effectively unusable for VoIP during peak hours. |
|
brad
join:2007-09-06
Etobicoke, ON | said by InvalidError:TSI was saying they saw nothing wrong from their end (no single link near max) but I get 100-300ms ping and jitter all over the place with @hsiservice.net while on the other hand I get almost normal pingtest results with @teksavvy.com
The necessity for separate logins should have been eliminated a year ago at the latest. |
|
|
|
| reply to InvalidError
I'm seeing exactly what InvalidError reports, see my posts in that thread mentioned. Switching back and forth between the two logins is showing the v6 login is showing congestion that the v4 doesn't have. |
|
| reply to InvalidError
Oddly enough, I get quite bad performance on both logins, but it's quite a bit better with the IPv4-only login than the @hsiservice.net login. Strange; I hadn't noticed the performance discrepancies before. |
|
| reply to brad
said by brad:The necessity for separate logins should have been eliminated a year ago at the latest. Why would they ever want to do that? TSI has different domains because each domain targets a separate subset of their ERX pool. Everyone has a standard @teksavvy.com login and extra logins for whatever add-on features like static/MLPPP and IPv6.
One other advantage of this is if one domain/ERX is borked, subscribers can switch to other logins on their account to verify whether or not it is a login/ERX-specific issue.
Even if Bell implemented a method for TSI to steer session toward specific AHSSPIs based on account features and load balance to make them land on the ERXes that support those features, they would likely keep the multiple domains so people can use alternate domains for troubleshooting and other purposes. |
|
brad
join:2007-09-06
Etobicoke, ON | said by InvalidError:Why would they ever want to do that? TSI has different domains because each domain targets a separate subset of their ERX pool. Everyone has a standard @teksavvy.com login and extra logins for whatever add-on features like static/MLPPP and IPv6.
I was talking about for v6 only, not all of the login realms. |
|
| said by brad:I was talking about for v6 only, not all of the login realms. Since TSI's IPv6 logins are running on only the subset of ERXes on which IPv6 routing is enabled due to being BETA (as in "not officially supported but works properly most of the time"), I doubt TSI would want to force BETA stuff on everyone.
If you meant that as in "IPv6 should have been standard by now, not BETA" then yes, I agree it should have become a standard stable feature and not require special login a long time ago.
Half-hearted (and often nonexistent) support and pushing from consumer hardware manufacturers is making the IPv6 transition take a lot longer than it should. |
|
brad
join:2007-09-06
Etobicoke, ON | said by InvalidError:Since TSI's IPv6 logins are running on only the subset of ERXes on which IPv6 routing is enabled due to being BETA (as in "not officially supported but works properly most of the time"), I doubt TSI would want to force BETA stuff on everyone.
If you meant that as in "IPv6 should have been standard by now, not BETA" then yes, I agree it should have become a standard stable feature and not require special login a long time ago.
Half-hearted (and often nonexistent) support and pushing from consumer hardware manufacturers is making the IPv6 transition take a lot longer than it should.
That was what I was getting at. After 3 years it shouldn't be beta anymore. It shouldn't be using a separate set of logins on AFAIK separate gear. Just add v6 to the existing teksavvy.com logins and whatever the realm was for static/MLPPP. For the teksavvy.com realm users (as in most of them) that would mean running on the E320 kit.
This would also resolve the long standing complaint about not being able to have IPv6 and static IP/subnets on the same login.
On top of that they should be utilizing DHCPv6-PD for prefix delegation to the CPE. This would eliminate the need for manual configuration for most users. |
|
| said by brad:On top of that they should be utilizing DHCPv6-PD for prefix delegation to the CPE. This would eliminate the need for manual configuration for most users. Windows seems to have no problem getting a working IPv6 address when its dialer handles PPPoE when I tried that so there seems to be some auto-configuration mechanism in there... IPv6CP/SLAAC? |
|
Reviews:
·TekSavvy DSL
| Yes, there is IPv6CP and SLAAC running, that doesn't fix the problem brad refers to.
DHCPv6-PD is for when a gateway router brings up the PPPoE link. It will use the IPv6CP link local information and the SLAAC for the global IPs on the link. However it needs an additional IPv6 prefix to hand out to the machines behind the gateway router. This is IPv6 so it's a real global prefix and not the equivalent of the RFC1918 192.168.x.x that gets handed out in a NAT IPv4 scenario. The problem is how to tell the gateway router what this prefix is. Currently it is by hand, DHCPv6-PD solves this problem. |
|
Reviews:
·TekSavvy DSL
| reply to InvalidError
said by InvalidError:said by brad:I was talking about for v6 only, not all of the login realms. Since TSI's IPv6 logins are running on only the subset of ERXes on which IPv6 routing is enabled due to being BETA (as in "not officially supported but works properly most of the time"), I doubt TSI would want to force BETA stuff on everyone. If you meant that as in "IPv6 should have been standard by now, not BETA" then yes, I agree it should have become a standard stable feature and not require special login a long time ago. Half-hearted (and often nonexistent) support and pushing from consumer hardware manufacturers is making the IPv6 transition take a lot longer than it should. At this point it's really not consumer manufacturers that are the hold up anymore. Most of the D-Link / Cisco / Asus routers you can buy at FS/BB/Staples all support IPV6 without issue now. Apple has supported it for a while on DHCP/Cable based connections (native IPV6 on PPPoE is still broken alas).
Google, Facebook, Youtube, Netflix and Akamai are all pushing IPV6 when asked for it now.
Carriers are basically the hold-up at this point. If Rogers started doing native IPV6 on their cable network tomorrow the usage of IPV6 on their network would probably hit double digit% on the first day I'd guess, just from people who have it enabled / supported by default and aren't getting addresses.
Given that -everyone- seems to peer through HE right now I'd guess that Rogers isn't sure that their peering can handle a wide deployment though. TekSavvy is maybe in the same boat. |
|
