dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
29
« Service in Richmond Hill[Outages] out in London »
page: 1 · 2 · next
This is a sub-selection from IPv6 beta
34764170 (banned)
join:2007-09-06
Etobicoke, ON

1 recommendation

34764170 (banned) to InvalidError

Member

to InvalidError

Re: IPv6 beta

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.
InvalidError
join:2008-02-03

1 recommendation

InvalidError

Member

said by 34764170:

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.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned)

Member

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.
InvalidError
join:2008-02-03

1 recommendation

InvalidError

Member

said by 34764170:

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.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

1 recommendation

34764170 (banned)

Member

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.
InvalidError
join:2008-02-03

InvalidError

Member

said by 34764170:

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?
notfred
join:2012-09-15

notfred

Member

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.

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

1 recommendation

SimplePanda to InvalidError

Premium Member

to InvalidError
said by InvalidError:

said by 34764170:

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.
InvalidError
join:2008-02-03

1 recommendation

InvalidError

Member

said by SimplePanda:

At this point it's really not consumer manufacturers that are the hold up anymore.

The point was that we should have been at this point at least half a decade ago. If consumer hardware and devices had started supporting IPv6 10 years ago, the transition would be practically over by now.

Today, many devices (tablets, smartphones, smart appliances, etc.) are still IPv4-only.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

1 recommendation

34764170 (banned) to SimplePanda

Member

to SimplePanda
said by SimplePanda:

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.

I am not sure about double digit % depending on how much of their coverage area is upgraded to enable v6 but they sure would have more than enough users out of the gate. Either way it still provides real users with a diverse collection of CPE in a real world environment via their network.

TSI is AFAIK running v6 on all of their transit links to Peer 1/Limelight/TATA and Hurricane so capacity is not an issue. The incumbent carriers have transit capacity now and if they needed to turn up sessions through existing links currently carrying v4 traffic only is fairly easy and straightforward. It's just rolling out service at the edge that is the real issue.
34764170

1 edit

1 recommendation

34764170 (banned) to InvalidError

Member

to InvalidError
said by InvalidError:

The point was that we should have been at this point at least half a decade ago. If consumer hardware and devices had started supporting IPv6 10 years ago, the transition would be practically over by now.

Today, many devices (tablets, smartphones, smart appliances, etc.) are still IPv4-only.

Unfortunately so true.

Although that is true there is also a good percentage of tablets, smartphones and some appliances that do have IPv6 support as well especially if based on iOS, Android, Blackberry 10/Tablet OS's, Symbian, Windows Phone 8.

Skype not support v6 yet is a pain. That is one of the most visible services still holding out.

I am also interested to see how Nintendo, Sony and Microsoft handle rolling out v6 for their consoles and online gaming especially with Wii U being out and PS4 / Xbox (Durango) coming out soon.
InvalidError
join:2008-02-03

1 recommendation

InvalidError

Member

said by 34764170:

I am also interested to see how Nintendo, Sony and Microsoft handle rolling out v6 for their consoles and online gaming especially with Wii U being out and PS4 / Xbox (Durango) coming out soon.

Since much of it is a chicken-and-the-egg problem (ISPs/incumbents are being lazy implementing IPv6 because few consumer modem/routers/devices support it) and consumer equipment manufacturers were being lazy doing IPv6 because no ISP/incumbents/routers supported it, things should start running a lot more smoothly now that the first IPv6 chickens have hatched.

We have finally reached the stage where people at least starting to notice IPv6 as a checkbox feature (they may not know what it does but they do notice that router/service A advertises support while router/service B does not) when buying routers and some other devices or services.

I'm curious to see whether or not Sony and Microsoft will choose to check the box or not. Considering how many router-related problems IPv6 would eliminate, it would be a shame if they decided to skip it completely. (As in neither at launch nor future patch.)
34764170 (banned)
join:2007-09-06
Etobicoke, ON

1 recommendation

34764170 (banned)

Member

said by InvalidError:

Since much of it is a chicken-and-the-egg problem (ISPs/incumbents are being lazy implementing IPv6 because few consumer modem/routers/devices support it) and consumer equipment manufacturers were being lazy doing IPv6 because no ISP/incumbents/routers supported it, things should start running a lot more smoothly now that the first IPv6 chickens have hatched.

We have finally reached the stage where people at least starting to notice IPv6 as a checkbox feature (they may not know what it does but they do notice that router/service A advertises support while router/service B does not) when buying routers and some other devices or services.

I'm curious to see whether or not Sony and Microsoft will choose to check the box or not. Considering how many router-related problems IPv6 would eliminate, it would be a shame if they decided to skip it completely. (As in neither at launch nor future patch.)

Well, ya, there were a lot of issues that needed to reach a certain point of maturity and availability whether it is OS stack support, apps, IP transit, CDN support, etc etc etc. but we're hitting a sweet spot where enough of these things have happened that the old excuses are nothing but excuses any more.

I doubt the consoles will have v6 enabled out of the box at this point but I'm betting that support or the framework for supporting v6 exists within the OS now and most likely games are using the AF independent network API as is done for UNIX/Windows apps now. The API would just do the right thing once the v6 stack is enabled with the underlying OS. I could see Nintendo (since Wii U is already out and AFAIK does not support v6) rolling out an update at the end of this year or early next and we'll see how PS4/Xbox goes.

Another area that will benefit greatly from IPv6 is VoIP. SIP is a total pain with NAT.
InvalidError
join:2008-02-03

1 recommendation

InvalidError

Member

said by 34764170:

Another area that will benefit greatly from IPv6 is VoIP. SIP is a total pain with NAT.

The main reason for the pain is simply the requirement to keep an inbound port open on the accidental firewall created by NAT's IP:port S:D connection tracking: can't forward inbound until you know who to forward the traffic to.

You would run into many of the same problems with a basic IPv6 firewall that denies inbound by default much the same way NAT routers do.

As far as I can see, the main potential problem IPv6 does fix for VoIP and similar services is the potential confusion in a scenario where someone owns multiple SIP devices that attempt to connect to the same server while using the same inbound port. On IPv4, the router would have no way to know which client packets belong to since they all have the same signature. Letting UPnP pick the inbound port or configuring clients with different ports both solve this IPv4 problem - assuming the router and SIP client's UPnP implementations are both working properly... though this goes for the IPv6 firewall as well.

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

1 recommendation

SimplePanda to 34764170

Premium Member

to 34764170
said by 34764170:

Unfortunately so true.

Although that is true there is also a good percentage of tablets, smartphones and some appliances that do have IPv6 support as well especially if based on iOS, Android, Blackberry 10/Tablet OS's, Symbian, Windows Phone 8.

Skype not support v6 yet is a pain. That is one of the most visible services still holding out.

I am also interested to see how Nintendo, Sony and Microsoft handle rolling out v6 for their consoles and online gaming especially with Wii U being out and PS4 / Xbox (Durango) coming out soon.

iOS and Android both support V6 without issue, as does Windows 8 / Windows RT. That gets you pretty close to all tablets in the market.

Phone wise, same boat with the exception of pre-BB10 devices that still hold a few market percentage points. Obviously feature/non-smart phones aren't included in this but their general lack of IP connectivity makes that moot.

Same issue here as well though: carrier support is really the problem, at least in Canada. Verizon and T-Mobile are sending IPV6 over the air now, but nobody in Canada is to my knowledge. Rogers definitely is not, but that's no surprise considering Rogers can't even seem to keep their 6rd BR's up and running.

Console wise I don't expect Sony or Nintendo to be really -with it- on this issue given their lineage. Since the 360 (and theoretical 720) are Windows based I can see them getting V6 "for free" as part of the operating system stack, but Sony and Nintendo would have to bake V6 in by choice and I don't really see either of them having the foresight.
SimplePanda

1 edit

1 recommendation

SimplePanda to InvalidError

Premium Member

to InvalidError
said by InvalidError:

said by SimplePanda:

At this point it's really not consumer manufacturers that are the hold up anymore.

The point was that we should have been at this point at least half a decade ago. If consumer hardware and devices had started supporting IPv6 10 years ago, the transition would be practically over by now.

Today, many devices (tablets, smartphones, smart appliances, etc.) are still IPv4-only.

No I totally agree with you on what the main point is. The movement to IPV6 should be far further along by now. Google is stating 1.14% of all of their traffic as of today:

»www.google.com/ipv6/stat ··· ics.html

This should be much higher by now.

re: tablets/smartphones etc - this is quite untrue. Basically all smartphones and tablets (which basically all run iOS or Android) support IPv6 natively and without issue.

Smart appliances are another issue but are relatively uncommon right now.
SimplePanda

1 recommendation

SimplePanda to InvalidError

Premium Member

to InvalidError
said by InvalidError:

said by 34764170:

Another area that will benefit greatly from IPv6 is VoIP. SIP is a total pain with NAT.

The main reason for the pain is simply the requirement to keep an inbound port open on the accidental firewall created by NAT's IP:port S:D connection tracking: can't forward inbound until you know who to forward the traffic to.

You would run into many of the same problems with a basic IPv6 firewall that denies inbound by default much the same way NAT routers do.

An additional portion of this problem is that there still isn't a very well defined port management system for IPV6 firewalls.

With V4 we have NAT-PMP and UPnP (gross) to handle this. V6 still doesn't really have a counterpart to tell the firewall to open ports as needed by opening/closing applications.

The port problem is compounded by address randomization on V6 networks by default in most OS's in SLAAC environments. DHCPv6 can solve this to some extent in that you can configure your router manually to always give your computer a specific address and then manually open ports needed but that's a pretty lousy solution compared to the relatively transparent operating of a NAT with PMP/UPnP support.

This is one area where Apple can show some real leadership - updating NAT-PMP to work well with IPv6 and really push it as a standard. Alas, Apple seems to care about 0% about IPv6, as evidenced by their V6 stack on OS X (happy eyeballs always on and can't be disabled) and their routers (PPPoE IPv6 completely unsupported).

Sigh.
InvalidError
join:2008-02-03

1 recommendation

InvalidError to SimplePanda

Member

to SimplePanda
said by SimplePanda:

re: tablets/smartphones etc - this is quite untrue. Basically all smartphones and tablets (which basically all run iOS or Android) support IPv6 natively and without issue.

While I have no doubt that Android devices should technically support IPv6 since they are based on the Linux kernel, their UIs do a very good job not making any mention of it if IPv6 is actually enabled on them.

What the OS supports is moot if vendors either do not include the hardware/connectors to use it or do not enable those features on their products... and this being Linux we are talking about, compiling a kernel without IPv6 support to save a few hundred KBs on the kernel and related support tools is always an option.

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

1 recommendation

SimplePanda

Premium Member

said by InvalidError:

said by SimplePanda:

re: tablets/smartphones etc - this is quite untrue. Basically all smartphones and tablets (which basically all run iOS or Android) support IPv6 natively and without issue.

While I have no doubt that Android devices should technically support IPv6 since they are based on the Linux kernel, their UIs do a very good job not making any mention of it if IPv6 is actually enabled on them.

What the OS supports is moot if vendors either do not include the hardware/connectors to use it or do not enable those features on their products... and this being Linux we are talking about, compiling a kernel without IPv6 support to save a few hundred KBs on the kernel and related support tools is always an option.

The UI portion is mixed. The main status screen lacks V6 address display for sure but the APN configuration has V4/V6 configuration for WWAN so it's in there. Most Canadians of course would never notice this as there are no WWAN providers handing out V6 anyways.

re: vendors - V6 support doesn't depend on hardware. If the device was Wifi or a cell radio and supports V4 it can support V6 via software without issue and almost always does.

In practice, as an Android developer, I've never seen an Android device in the last couple of years that didn't support V6 if it was offered by the LAN. Leaving out V6 from the kernel to save on resources is pretty much pointless on any modern or quasi-modern device. Testing V6 connectivity where possible is part of the standard test procedure for our connected apps so this is something I've had a pretty good look at.

And of course, iOS has supported V6 fully and includes status displays to indicate as such when enabled.
InvalidError
join:2008-02-03

1 recommendation

InvalidError

Member

said by SimplePanda:

re: vendors - V6 support doesn't depend on hardware. If the device was Wifi or a cell radio and supports V4 it can support V6 via software without issue and almost always does.

The part about hardware was intended for software/OS in general. The Linux kernel (or Windows) supports millions of things that will never get attached to a tablet since tablets/smartphones/etc. lack the ports required to use them.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

1 recommendation

34764170 (banned) to SimplePanda

Member

to SimplePanda
said by SimplePanda:

Android both support V6 without issue

Console wise I don't expect Sony or Nintendo to be really -with it- on this issue given their lineage. Since the 360 (and theoretical 720) are Windows based I can see them getting V6 "for free" as part of the operating system stack, but Sony and Nintendo would have to bake V6 in by choice and I don't really see either of them having the foresight.

Unfortunately that is not true. Android has somewhat big warts with its v6 support. No DHCPv6 support, no RFC6106 support, it can't connect to v6-only networks over wireless, no UI support for displaying v6 info, it seems to have issues dropping RA packets/ICMP more than enough to cause problems, issues with its wireless (as in 3G/4G) support. AFAIK all of these issues do not exist with iOS. Apple over all has done a much better job (although they're not 100% perfect).

360 does NOT use Windows. It along with the original Xbox use their own custom OS. That seems to be a common misconception. It doesn't even use DirectX either but a derivative API.
34764170

1 recommendation

34764170 (banned) to SimplePanda

Member

to SimplePanda
said by SimplePanda:

An additional portion of this problem is that there still isn't a very well defined port management system for IPV6 firewalls.

With V4 we have NAT-PMP and UPnP (gross) to handle this. V6 still doesn't really have a counterpart to tell the firewall to open ports as needed by opening/closing applications.

The port problem is compounded by address randomization on V6 networks by default in most OS's in SLAAC environments. DHCPv6 can solve this to some extent in that you can configure your router manually to always give your computer a specific address and then manually open ports needed but that's a pretty lousy solution compared to the relatively transparent operating of a NAT with PMP/UPnP support.

This is one area where Apple can show some real leadership - updating NAT-PMP to work well with IPv6 and really push it as a standard. Alas, Apple seems to care about 0% about IPv6, as evidenced by their V6 stack on OS X (happy eyeballs always on and can't be disabled) and their routers (PPPoE IPv6 completely unsupported).

Not really true. UPnP has already been updated for IPv6 and there are already implementations out there supporting it now.

The privacy address issue shouldn't be an issue if the UPnP client is doing its job properly. It should be able to monitor the OS to see the new privacy address being added and as new connections are being made outbound using the new address the UPnP client should know to open the ports with the new IP address too.

I can't say as I agree about Apple and v6. There execution and implementation has not been perfect but in a lot of regards they have done a better job than most of the other vendors over all.

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

1 recommendation

SimplePanda to 34764170

Premium Member

to 34764170
said by 34764170:

Unfortunately that is not true. Android has somewhat big warts with its v6 support. No DHCPv6 support, no RFC6106 support, it can't connect to v6-only networks over wireless, no UI support for displaying v6 info, it seems to have issues dropping RA packets/ICMP more than enough to cause problems, issues with its wireless (as in 3G/4G) support. AFAIK all of these issues do not exist with iOS. Apple over all has done a much better job (although they're not 100% perfect).

360 does NOT use Windows. It along with the original Xbox use their own custom OS. That seems to be a common misconception. It doesn't even use DirectX either but a derivative API.

re: Android our app tests all show it works well in the lab. This is SLAAC configured and with IPv4 DNS servers that will return AAAA records, hence why we never see issues with it I suppose. I do know there are "v6 only" issues with Android for sure.

re: iOS the one place iOS wasn't doing well was in V6 over WWAN. At WWDC Apple mentioned that iOS 6 now supports V6 over both Wi-Fi -and- LTE, which I took to mean that a) it didn't support V6 over WWAN previously and possibly b) it won't support V6 over HSPA. I didn't think to clarify with anyone.

re: 360; true enough. The MSDN blogs have some good info about this. It's basically a fork of Windows kernel and is entirely custom on top, using a subset of Win32. Interesting stuff but also suggests that V6 bake-in would need to be intentional.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

1 recommendation

34764170 (banned)

Member

said by SimplePanda:

re: Android our app tests all show it works well in the lab. This is SLAAC configured and with IPv4 DNS servers that will return AAAA records, hence why we never see issues with it I suppose. I do know there are "v6 only" issues with Android for sure.

You need RFC6106 support to receive the name servers on a v6-only network using RA or DHCPv6 and some environments like universities and corp. will insist on DHCPv6. Without those there is no point worrying about v6 only networks but they're a dependency.
said by SimplePanda:

re: iOS the one place iOS wasn't doing well was in V6 over WWAN. At WWDC Apple mentioned that iOS 6 now supports V6 over both Wi-Fi -and- LTE, which I took to mean that a) it didn't support V6 over WWAN previously and possibly b) it won't support V6 over HSPA. I didn't think to clarify with anyone.

iOS supported v6 over HSPA already. The issue was with LTE only on the iPad and Wifi must have been with the iPad only too since it already worked with the iPod and iPhone with 5.x
said by SimplePanda:

re: 360; true enough. The MSDN blogs have some good info about this. It's basically a fork of Windows kernel and is entirely custom on top, using a subset of Win32. Interesting stuff but also suggests that V6 bake-in would need to be intentional.

That wasn't to imply adding v6 support is impossible or anywhere near it and I think they very much could upgrade the 360 to support v6. But I wouldn't bet on it much with Xbox Durango coming out soon. I'm not sure if it will have it enabled out of the box or supported but it would be down the road just as Wii U/PS4 will.

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

SimplePanda

Premium Member

said by 34764170:

iOS supported v6 over HSPA already. The issue was with LTE only on the iPad and Wifi must have been with the iPad only too since it already worked with the iPod and iPhone with 5.x

iPad has supported V6 over Wifi only for a while so it must have been an LTE specific update.
johnwhelan
join:2013-03-15

johnwhelan to InvalidError

Member

to InvalidError
I'm not sure how active this thread is but I'd like to add IPv6 to an ASUS rt-n66u running 3.0.0.4.220 firmware.

The options I get on the router under connection type are
Native with DHCP-PD
Static IPV6
and various tunneling options.

I have my /56 and /64 numbers from Teksavvy.

What should I enter and where?

Thanks John
marcel31
join:2013-02-23
Mississauga, ON

marcel31

Member

I have RT-AC66U same options and I have pretty much given up on getting it to work with Teksavvy. I am not an expert on this stuff so I am not really sure who to blame but although I love my router Documentation on how to set up IPv6 simply sux. I wish it was automatic. I think that's what "DHCP-PD" connection would do if it was supported by Teksavvy.
johnwhelan
join:2013-03-15

johnwhelan

Member

It sounds like we need the static IP side but what the values for
WAN IPv6 Address
WAN Prefix Length
WAN IPv6 Gateway

LAN IPv6 Prefix
LAN Prefix Length
LAN IPv6 Address

IPv6 DNS Server 1
IPv6 DNS Server 2
IPv6 DNS Server 3

are I'm unclear. Perhaps someone can translate the terms into Teksavvyish.

Thanks John

SimplePanda
BSD
Premium Member
join:2003-09-22
Montreal, QC

SimplePanda

Premium Member

N66u is easy to configure with TekSavvy.

Yes, you do use "Static IPv6". In the future hopefully this will move to automatic with DHCPv6-PD but for now static is the way it's done.

Configure your PPPoE connection for your @hsiservice.net login first and verify that regular IPv4 works fine, then...

Assuming TekSavvy assigned you:

IPV6 /64: 2607:f2c0:a000:aa::/64
IPV6 /56: 2607:f2c0:f00f:bb::/56

You would fill in the following on your 66u:

WAN IPv6 Address: 2607:f2c0:a000:aa::1
WAN Prefix Length: 64
WAN IPv6 Gateway: 2607:f2c0:a000:aa::1 (same as your address)

LAN IPv6 Prefix: 2607:f2c0:f00f:bb::
LAN Prefix Length: 56
LAN IPv6 Address : 2607:f2c0:f00f:bb::1

So, the WAN is your /64 address with "1" on the end (or could be anything, it's just an assignment you give) and a 64 prefix (hence /64).

The LAN prefix is your /56 without any address (so ending in ::), 56 as the prefix lenght, and your prefix with "1" at the end (or whatever you want) as the LAN address.

You can leave the DNS servers blank as TSI's v4 name servers resolve AAAA without issue and I've found TSI's v6 name servers be a little unreliable.

Once this is done you can go to »test-ipv6.com

If it shows the following:

Your IPv6 address on the public Internet appears to be XXXX

then it works. Hope that helps.
johnwhelan
join:2013-03-15

johnwhelan

Member

I now have the IPV6 setup as static with the addresses in.

>Configure your PPPoE connection for your @hsiservice.net login first and verify that regular IPv4 works fine, then...

I'm still running on the old login not the @hsiservice.net so how do I change this?

Thanks John