LAG issue - HowTo solve it

voobscout · Post by **voobscout** » Tue Apr 28, 2009 7:26 pm

Jeruwafi wrote:QUOTE (Jeruwafi @ Apr 28 2009, 08:58 PM) I demand some action from planet admins! :]

EDIT:
I think that HE instructions for XP are easier and shorter, is there any advantage of using netsh?

what is provided on HE page, concerning XP is outdated, it's applicable to pre-SP2 XP and it won't work for anything that has at least SP2 installed.

there's no "advantage" about netsh, it's just a different way of doing it, that simply works. If you actually try to do it the way described for pre-SP2 XP, you'll end up without the needed ipv6 tunnel interface.

voobscout · Post by **voobscout** » Tue Apr 28, 2009 7:45 pm

Jeruwafi wrote:QUOTE (Jeruwafi @ Apr 28 2009, 09:06 PM) I demand some motivational posters for planet admins ! :]

Does anyone know what is meant by sixxs' "Note that a static tunnel requires it to be available
24/7 and if you fail to do that credits will be taken from your account." ? Wtf credits? Currency-v6?
I dont feel like installing anything and static tunnel would be fine for me, but I'm not going to have it 24/7... nearest sixxs pop is a few ms closer than HE

I'm currently investigating sixxs. I'll post results here, when they approve my account. In the meantime, i can say, that the 24/7 probably refers to your own AS(Autonomous System) or at least implies that you have RIPE handles already assigned to you.

I have absolutely no idea what "credits" are they talking about. Once i get my account approved there, i'll contact the techies and sort everything out.

sgt_baker · Post by **sgt_baker** » Tue Apr 28, 2009 7:47 pm

voobscout wrote:QUOTE (voobscout @ Apr 28 2009, 08:26 PM) what is provided on HE page, concerning XP is outdated, it's applicable to pre-SP2 XP and it won't work for anything that has at least SP2 installed.

there's no "advantage" about netsh, it's just a different way of doing it, that simply works. If you actually try to do it the way described for pre-SP2 XP, you'll end up without the needed ipv6 tunnel interface.

The thing that annoys me is that netsh is provided 'as is'. The help commands only tell you what commands are available. Nothing forthcoming when it comes to *what* they actually do.

MS could spend a day improving IPv6 just by including said help.

B

voobscout · Post by **voobscout** » Tue Apr 28, 2009 7:56 pm

sgt_baker wrote:QUOTE (sgt_baker @ Apr 28 2009, 09:47 PM) The thing that annoys me is that netsh is provided 'as is'. The help commands only tell you what commands are available. Nothing forthcoming when it comes to *what* they actually do.

MS could spend a day improving IPv6 just by including said help.

B

http://technet.microsoft.com/en-us/library/cc785383.aspx

that's why MS has technet.... for people like me, who truly don't like working with mustdie dos shells... `gu

parcival · Post by **parcival** » Tue Apr 28, 2009 10:37 pm

I had problems setting up the tunnel with HE. I found out that I had to enable my router to receive pings from them (as soon as tunnel was up I had no problem by disabling pings again).

If I interpret correctly the ping results I got repeating Baker's tests from my end (Greece connected to Frankfurt node) I see little difference with IPv6.
Nevertheless I would love to test a live Alleg server with this, to have a better idea.

sgt_baker · Post by **sgt_baker** » Tue Apr 28, 2009 11:17 pm

Yes. Their 'CAPTCHA' seems to be 'we need to be able to ping you'. I disabled said anti-ICMP aspects of my firewall(s) during the few moments of registering with HE. Works fine once anti-ICMP is re-enabled.

Tones · Post by **Tones** » Wed Apr 29, 2009 4:51 am

If this works it would be awesome, no more 300+ ping. i'm excited.

Jeruwafi · Post by **Jeruwafi** » Wed Apr 29, 2009 2:13 pm

I rethought this matter and I see one "small" flaw in our thinking...

Everything we've tested so far was tested with ipv6 aware apps... even though it uses ipv4 as link layer it's still ipv6...

voobscout · Post by **voobscout** » Wed Apr 29, 2009 2:39 pm

Jeruwafi wrote:QUOTE (Jeruwafi @ Apr 29 2009, 04:13 PM) I rethought this matter and I see one "small" flaw in our thinking...

Everything we've tested so far was tested with ipv6 aware apps... even though it uses ipv4 as link layer it's still ipv6...

there's no such thing as ipv6 "aware" applications... unless it's some piece of networking equipment that has to actually play around with IP packets.

anything that works with ipv4 will inevitably function with ipv6,,,

some software (in very rare and special cases) prefers to assemble IP packets by itself, frankly off the top of my head i'm simply unable to come up with an example... maybe some hardware protocol analyser, that is capable of generating traffic for test purposes, giving you the ability to create malformed IP packets on purpose...

when one goes as high as layer 4 on OSI model (ie transport layer), there just isn't any difference in regards to what lies beneath it... it could even be some twisted x.25 used for path determination, albeit with tcp/ip stack it'd be rather hard to implement...

Jeruwafi · Post by **Jeruwafi** » Wed Apr 29, 2009 4:15 pm

hm,
if you grab eg. Opera 5 or 6 (any really old app) and try to connect to ipv6 address or ipv6 only website it will fail.
if you grab eg. ordinary TightVNC server(any old server app), clients won't be able to connect using ipv6 address (even if you find a place to type it in

).

if you scan open ports using ipv6 address it will show only ports on which ipv6 compatible software is listening (eg. uTorrent)

compare:

Code: Select all

2001:470:1f0a:17c3::2 IPv6
PORT      STATE SERVICE
135/tcp   open  msrpc
50000/tcp open  iiimsf                 //uTorrent ipv6

Code: Select all

83.28.213.215 IPv4
Port            State   Service 
22/tcp  closed  ssh     
5800/tcp        open    vnc-http        TightVNC
5900/tcp        open    vnc     VNC
50000/tcp       open    iiimsf                //uTorrent ipv4

scanned at the same time with same services etc.

EDIT:

from "Interoperability between ipv6 and ipv4: http://ntrg.cs.tcd.ie/undergrad/4ba2.02/ipv6/interop.html

QUOTE The programming APIs for IPv6 will not be the same as for IPv4 - they need to allow programmers to make use of IPv6's added capabilities in the areas of security, QoS and other. They will also have to take into account the longer address length. Current IPv4 programs will simply not be able to address IPv6 hosts without modification.

All current software that makes use of networking capabilities uses IPv4 APIs. IPv6 APIs will probably be supersets of current IPv4 APIs.

Eventually all current software will have to be ported to IPv6. This might be as simple as recompiling using the new APIs, or as complex as having to rewrite proprietary code to store IP addresses as 128 bit numbers rather than 32 bit ones. It completely depends on how the original code was written.

Meanwhile existing binaries should be able to use the IPv4 protocol stack on dual stack machines. Alternstively, two methods have been proposed to allow the OS to automatically generate IPv6 traffic if talking to other Ipv6 nodes - even if using IPv4 binaries. These are called Bump in the Stack and Bump in the API. Bump in the stack is a low level procedure that translates the IPv4 traffic produced into IPv6 traffic, using standard header translation techniques. Bump in the API is a higher leve approach - it detects the IPv4 API invocations and if appropriate, changes them into IPv6 API invocations. This second appoach is thought to be more efficient and elegant in general.[/quote]

EDIT2: