Newbie wondering : what can TunnelBroker bring over automatic 6to4 ?

[Ninho]

Hi! I have a very basic question, hope this is the right section : right now, using Windows XP (in fact, even Windows 2000 + the Microsoft Research IPv6 stack "preview", which I have just installed), I'm able to configure a 6to4 tunnel using a 2002:: address based off my ISP-assigned IPv4 ; this gives me a connectivity towards IPv6-only sites.

Can you please explain in simple terms what setting up a tunnel with HE will bring to my (small home) network in place of, or addition to, the manually configured 6to4 tunnel using the 2002: address and 192.88.99.1 multicast as 6to4 server ?

Thank you VM in advance, with regards,

[broquea]

If your IPv4 address is assigned by DHCP and changes, so does your 6to4 address. You'd then have to update any DNS information that was using the old addresses. Also where you hear the anycasted 192.88.99.1 address can change or initially start off thousands of miles away.

A static tunnel doesn't have the IPv6 addresses change if the IPv4 endpoint does, you simply update your endpoint in the system. You also get to pick a POP closest to you (ideally based off latency, not geography). Also reverse DNS management for routed blocks.

[Ninho]

Aha, this is becoming less muddy in my head, TY very much indeed.  Oops, muti- for anycast above was but a typo, honest ;=)

I grasp the point about getting a fixed IPv6 with TunnelBroker.

One more Q if you please : you say TunnelBroker will allow me to set local routed network(s). Is the same impossible to achieve using the 2002:myIPv4::/48 prefix ? I have only set up one machine ATM, per MS old docs, I assigned the low 48-bits of this machine's IPv6 according to a bizarro "hex coded decimal" scheme from the external IPv4 again. But in principle, couldn't I use /any/ number under the /48 , or does 6to4 require a unique address so constructed ?

[broquea]

So with the 6to4 tunnel, your machine is allocated a /48. You can use any IP in that entire giant range on that machine. You can also use a /64 + RA on that machine and act as gateway for other hosts on the lan. Again, this changes when your IPv4 address changes.

With our broker, by default a /64 is used as the point-to-point link address, as well as a second /64 statically routed through your side of that point-to-point address. So if you want that machine to act as a gateway, you have a separate /64 to use, and get to manage rDNS for. If you have multiple LANs or subnet requirements, then you can elect to ask for an additional /48, which can then be broken down into /64s or however you want to use it. You also get rDNS management over this range.

[kristiankrohn]

Just for the record: 6to4 reverse DNS is also possible: http://6to4.nro.net/

(I'd still go with a tunnelbroker though.)

[jimb]

Also where you hear the anycasted 192.88.99.1 address can change or initially start off thousands of miles away.

So true.  When I was playing with 6to4 at a friends place in Fremont, CA, the 6to4 anycast traced to Sweden.  Same thing happened on another friend's BSD box I was sshed into up in Nova Scotia which used Eastlink as an ISP. 

[Ninho]

Thanks, Gentlemen!

Hmm, one more fancy : my regular ISP has started blocking ingoing (towards customers) TCP port 25,
thus 'protecting' me from running an SMTP server in house. Is it technically feasible for a tunnel broker to manage some TCP port translation trick at the same time you do the v4/v6 en/de/capsulation ? Or am I just taking nonsense ?

[jimb]

Thanks, Gentlemen!

Hmm, one more fancy : my regular ISP has started blocking ingoing (towards customers) TCP port 25,
thus 'protecting' me from running an SMTP server in house. Is it technically feasible for a tunnel broker to manage some TCP port translation trick at the same time you do the v4/v6 en/de/capsulation ? Or am I just taking nonsense ?

Incoming SMTP traffic in your IPv6 tunnel (either 6to4 or 6in4) will not likely be blocked by the ISP since it's in a tunnel.  Unless they're doing some sort of deep inspection of the traffic (e.g. looking into the tunnel payload at the IPv6/TCP packets) it won't block it.

For IPv4, you'd either have to tell them not to do it for you (it's an option with my ISP's web management interface), or you'd also have to tunnel IPv4 traffic from somewhere else into your MX.

[Ninho]

Incoming SMTP traffic in your IPv6 tunnel (either 6to4 or 6in4) will not likely be blocked by the ISP since it's in a tunnel.  Unless they're doing some sort of deep inspection of the traffic (e.g. looking into the tunnel payload at the IPv6/TCP packets) it won't block it.

  Of course! Was I stupid...! It's evident once told out, thanks.
I bet the ISP wouldn't even think of inspecting proto 41 IP packets, let alone know how-to at the moment.
Not that a IPv6-only MX would be very useful either, would it ? Will regular sending SMTPs on the cloud interact with them successfully ?

For IPv4, you'd either have to tell them not to do it for you (it's an option with my ISP's web management interface), or you'd also have to tunnel IPv4 traffic from somewhere else into your MX.

My for-the-Mass type ISP won't do case per case exceptions. As for your second suggestion, would you kindly precise what's in your mind ?