shared IP

[askme]

Hi,

hope this is the right place, i was trying to request a tunnel but it said that i couldnt because some one else already has done so from this ip. the problem is that my ip is shared by about 200 people so i was wondering if there would be away round this?

thanks

[jimb]

Unfortunately 6in4 doesn't support situations like this because without "snooping" into the 6in4 packet, there's no real way for a NAT device to map more than one 6in4 session using a single public IPv4 address to an internal host.

I posted some idea about how someone could possibly write a iptables handler or "fixup" type module to allow connection tracking of multiple 6in4 sessions through one public IP by looking at the IPv6 addresses contained inside the 6in4 packets and using those as a way of identifying the origin IPv4 of the tunnel.  But not sure if anyone ever implemented like that.

Best bet is to use a provider which uses something like AYIYA for the v6 tunnel.  Or get your IT people to dedicate a public IPv4 to you.  :P

[askme]

OK thank you. does that mean only one can have a tunnel in a situation like mine? or its not possible for anyone to have a tunnel. I think sixxs is the only one that does AYIYA but their sign up form feels a bit intrusive. I don't suppose its possible too get a static ipv6 off teredo? or have two teredo connections on one pc?

cheers

[Nick Pais]

When I had this sort or problem, I went with gogo6 and it worked fine. You should try them.

[askme]

i would but their tunnel are very slow only 200kB compared to 900kB.

[cholzhauer]

Yeah, GoGo6 has been having traffic issues lately.

You're right when you say the SIXXS signup is a little "different", but really, if you want IPv6 connectivity, it's going to be your best bet.

[lukec]

The person who already has the tunnel (assuming same organisation) could if "connected" to you serve IPv6 on the LAN side of his device (hopefully a router) from his router /64 and you could use his device as your IPv6 Gateway...
Regards
lukec

[jimb]

Yeh.  Basically you need some way that can do a IPv6 tunnel that's NAT traversal capable.  6in4 really isn't.  To have a many-to-one NAT work, a firewall needs something to identify internal hosts' connections for return traffic, since all the return traffic comes back to the same public IP. 

With TCP and UDP that's possible, since it simply uses the source port of the traffic and in effect extends the IPv4 address by two bytes.  The NAT box will note the source port traffic went out on to say, a web server, and when that traffic returns, it will have a source port of 80, and the destination port will use the source port that the traffic went out on.  So then it just looks up who used that source port in a connection table, and thus figures out who sent that traffic out, and routes it back to that internal IP.  6in4 doesn't have ports, so there's nothing for a NAT box to use to uniquely identify the return traffic.  Therefore, there can only be one session through one public IPv4.  That old post I made suggested that FW NAT implementations could use the IPv6 address in the 6in4 packets to identify the inside hosts, and be able to handle multiple 6in4 connections in cases like yours.  But a lot of people seemed to resist the idea for some reason.   :P

Teredo should work for you as long as your firewall doesn't have a symmetric NAT setup, and it's not being blocked.  Teredo tunnels IPv6 through UDP which is NAT traversal friendly.  But Teredo would be even slower.  And also, under windows, most apps won't use a Teredo IPv6 connection when there's an IPv4 address available because windows is set up so that each application must say "it's OK to use Teredo".  Not sure if there's a way to globally change that, but you wouldn't want to anyway, since Teredo is usually pretty darn slow.

PPTP might have worked for you, since although PPTP uses GRE which isn't exactly NAT friendly, most firewall devices have a PPTP specific "fixup" for it that uses fields inside the PPTP/GRE packet to associate with and identify each session/internal host to allow NAT traversal.  But unfortunately HE has suspended PPTP.

I really think HE should put out something that uses UDP or TCP for tunneling.  Maybe AYIYA or something like that.

[askme]

i found a place that does pptp tunnelbroker.ru/ although i cant get pptp to work as it tunnel every thing through pptp not just ipv6. im running xp

[jimb]

BTW, have you tried a different tunnel server?  It may or may not work determined by whether the NAT device considers the reply traffic source IPv4 in matching a connection table entry.

Technically, a NAT device could handle multiple 6in4 connections NATed through the same public IPv4 if each session used a different 6in4 server since it could use the tuple (ingress interface, IPv4 protocol, source,destination) to look up the "inside" IPv4 destination when de-NATing.  But it would depend on the NAT implementation of the particular NAT/FW device you're going through.

[askme]

yeah i have, i tired the russian one. cant seem to get it too work. they do offer pptp but im not sure how to set that up, it seems to route all my traffic through the vpn rather than just the ipv6. the only ones i can seem to get too work are gogo6 - too slow and teredo - only get one ip where i need a subnet, well at a minium 3 ips

[cholzhauer]

SIXXS, if you can deal with all the red tape

[jimb]

yeah i have, i tired the russian one. cant seem to get it too work. they do offer pptp but im not sure how to set that up, it seems to route all my traffic through the vpn rather than just the ipv6. the only ones i can seem to get too work are gogo6 - too slow and teredo - only get one ip where i need a subnet, well at a minium 3 ips

I meant a different HE tunnel server IP.  Just to see if it works.  If someone is already going to the closest one, he basically takes that connection table entry.  If you go to a different tunnel server, it might create and use a unique connection table entry and work.  Of course, the moment someone else behind that NAT uses that host, things will go downhill fast.  :P

[broquea]

Won't matter, we store IPs as unique for the client side. Once it is in the system, no more tunnels can be created against it until it is no longer associated with a tunnel. No this won't be changing.

[jimb]

Yeh.  He'd obviously have to delete his current tunnel and create a new one on another server...