Print

[snarked]

If you're on a dynamically assigned IPv4, shouldn't you be using a "6to4" address (2002::/16) for IPv6?  You may dynamically update your AAAA records in DNS for your domain instead (of a tunnel endpoint).  In other words, what exactly is the point of having a fixed IPv6 allocation when your IPv4 varies?  You're not a server and/or probably aren't supposed to be running them per your IPv4 ISP - else you'd have a fixed IPv4 allocation which makes the question moot.

[broquea]

If you're on a dynamically assigned IPv4, shouldn't you be using a "6to4" address (2002::/16) for IPv6?  You may dynamically update your AAAA records in DNS for your domain instead (of a tunnel endpoint).  In other words, what exactly is the point of having a fixed IPv6 allocation when your IPv4 varies?  You're not a server and/or probably aren't supposed to be running them per your IPv4 ISP - else you'd have a fixed IPv4 allocation which makes the question moot.

6to4 is indeed a good option for people, aside from tunnel brokers. We are looking at deploying a few 6to4 devices on our network to help make more of these available (no ETA). Personally on my Speakeasy DSL, I found that I was connecting to one automatically after turning up a linux machine. The only strange part was that the 6to4 router I was connecting to was in Sweden O.o? So I had 180ms right off the bat. I think that people opt to use the broker even with dynamic IPs because they can easily select a location close to them.

[normanr]

If you're on a dynamically assigned IPv4, shouldn't you be using a "6to4" address (2002::/16) for IPv6?  You may dynamically update your AAAA records in DNS for your domain instead (of a tunnel endpoint).  In other words, what exactly is the point of having a fixed IPv6 allocation when your IPv4 varies?  You're not a server and/or probably aren't supposed to be running them per your IPv4 ISP - else you'd have a fixed IPv4 allocation which makes the question moot.

I run my server with dynamic DNS records.  It's quite a relief to be able to assign static IPv6 addresses to everything :-) Using 6to4 would be a royal pain, also you don't get reverse dns with 6to4 (although I think 6to4 should have automagic reverse dns to the IP that it points to - that's another discussion).  As it happens my 'closest' 6to4 router is in Switzerland (I'm in South Africa).

[mindlesstux]

If you're on a dynamically assigned IPv4, shouldn't you be using a "6to4" address (2002::/16) for IPv6?  You may dynamically update your AAAA records in DNS for your domain instead (of a tunnel endpoint).  In other words, what exactly is the point of having a fixed IPv6 allocation when your IPv4 varies?  You're not a server and/or probably aren't supposed to be running them per your IPv4 ISP - else you'd have a fixed IPv4 allocation which makes the question moot.

Most 6to4s I find are like someone said, a good half second around the world.  Having a dynamic ip does indeed suck but having a tunnel from a location I choose improves the connection greatly.  Actually my cable connections does not change ips very often even though they dont offer static ips, :/.

[normanr]

Mmm, same here.  I keep the same IPv4 as long as I don't get disconnected (or if I reconnect promptly if I'm ever disconnected).

Unfortunately the latency differences between 6to4 and tunnelbroker.net are not that much different - there's no local tunnel server provided by _anyone_ in South Africa that I can find!

[snarked]

... also you don't get reverse dns with 6to4 ...

Not true - https://6to4.nro.net/ is where one registers it for FIXED IPv4 (and thus fixed 6to4).  It's been around for 3.5 years.  Now, granted that there really isn't a DNS reverse zone for dynamic 6to4 (where the IPv4 is dynamic), but that's not even universal for IPv4 itself.  I still get plenty of web page requests (both v4 and v6) that have no reverse.

Here in Los Angeles (btw, it's one of HE's peering points - at LAIIX), the "network nearest" 6to4 gateway appears to be in Amsterdam, yet geographically, Micro$oft's 6to4 gate near Seattle, WA would be the geographic nearest.  LA, being the second largest peering point (actually, 3-4 points as there are that many exchanges here) and population center in North America should have its own gateway (and so should NYC at NYIIX).  I use my HE tunnel only for NA and Asian/Pacific routes, and still use my 6to4 for European routes because for some reason, it usually has RTTs about 5-10ms less, but not always.  I did not test South America or Africa because I have no regular traffic headed that way.

I can see some benefit in having a local tunnel over 6to4 (lower RTT), but only because 6to4 is poorly deployed, especially in North America.  I believe that everyone assumes that everyone-else will deploy such gateways.  In contrast, also note that two 6to4 hosts will end up using the direct IPv4 path between them if properly set up ("2002::/16" -> dev sit0 [or whatever the encapsulation interface is called on your system] with NO gateway), while two IPv6-tunneled hosts will have usually longer routes - each to its tunnel's other endpoint and the distance between the two tunnel brokers.

As far as those who do have dynamic IPv4 assignments that don't change often, consider yourself lucky.  My DSL assignment at home (not my co-located server which has my tunnel) does seem to changeabout every 10 days.

[normanr]

Hrm, when I tried to get to 6to4.nro.net yesterday it just timed out, so I assumed it was down/neglected.

Seeing as they don't require a password if you're connecting from your 6to4 address, then it should work fine from a dynamic IP - just hit their wget'able url from ppp's ip-up scripts.  This should override any previous assignments and set up the reverse DNS without any issues.

As it happens I kept the same IPv4 for the whole of February, but it's changed 6 times in March so far. So it's really random - actually it more depends on how often we have power outages.

[snarked]

6to4.nro.net loads slowly - and I believe the bottleneck is its .css stylesheets.

Also note that if you use the service for dynamic allocations, you may leave an artifact that you can't delete when your IPv4 changes if you're not careful.  Removal will need an email/password combination as it can't come in via the IPv6 subnet as "method=direct", which should be set when one registers the subnet in the first place.  Forgetting to remove it could cause you additional DNS traffic when the next people use that dynamic assignment and don't redirect it to themselves, as well as cause confusion.

Note that the 3rd paragraph under "password access" on their "about" page at "https://6to4.nro.net/6to4_reverse/non_2002/index.html" indicates that they expect dynamic allocations to use their service.

[broquea]

I've split this out to a separate topic since it isn't directly related to Tunnelbroker.net services.

[normanr]

6to4.nro.net loads slowly - and I believe the bottleneck is its .css stylesheets.

The css's are all loaded from the same hostname, so I doubt it was that.  Maybe it just just a glitch in the matrix :-)

Also note that if you use the service for dynamic allocations, you may leave an artifact that you can't delete when your IPv4 changes if you're not careful.  Removal will need an email/password combination as it can't come in via the IPv6 subnet as "method=direct", which should be set when one registers the subnet in the first place.  Forgetting to remove it could cause you additional DNS traffic when the next people use that dynamic assignment and don't redirect it to themselves, as well as cause confusion.

True, I guess a good plan would be to set an email/password combination and then delete the old delegation before creating the new one. (I store the old IP address anyways, so that I know to only do the update when it changes).  A good thing is that the password doesn't even need to be a secure one, because it's so easy to re-set the delegation

[normanr]

Hrm, it seems that 6to4_reverse_wget.pl?method=remote is 'NOT supported yet'. Could just be be, but it looks like I'll be setting up delegations that'll last forever :-)