We have added a regular tunnel-server in Prague.  It is now live and available to choose when creating a tunnel. Again if you would like your existing tunnel's IPv4 endpoint to use the new tunnel-server, please delete your existing tunnel then pick the new location to create your tunnel on.

*REMINDER* - Deleting your old tunnel means deallocating your IPv6 blocks, and you will be assigned NEW allocations based on the tunnel server you pick.

If you have any problems and want to report them, please email ipv6@he.net to open a trouble ticket.

So...

We have added regular tunnel-servers in Berlin and Warsaw. They are now live and available to choose when creating a tunnel. Again if you would like your existing tunnel's IPv4 endpoint to use one of the new tunnel-servers, please delete your existing tunnel then pick the new location to create your tunnel on.

*REMINDER* - Deleting your old tunnel means deallocating your IPv6 blocks, and you will be assigned NEW allocations based on the tunnel server you pick.

If you have any problems and want to report them, please email ipv6@he.net to open a trouble ticket.

The differing block may be a policy change on their side.  The receipt of only a link-layer address on PPP is expected, since RA is supposed to be used to handle any additional dynamic addressing on a PPP link.  They opted to not add an extension to IPCP to define anything more than the LLs.

Should be fixed now.

Definitely secret sauce on this side.

Hey, there's a little bug in there.  Should be fixed shortly.

The page will now keep the input field visible if there's nothing in it at the time it loses focus.

Deleting the existing contents of the field overwrites the clipboard. So if I first copy the new IP to the clipboard, then delete the old IP from the field, then paste, it will be pasting the old IP instead of the new.

Nothing in the JavaScript for that touches the clipboard.  I paste addresses in there all the time.  That particular behavior would either have to be something amiss on your side, or some really weird jQuery action in an edge case configuration.  In any case, I'll still see about keeping it an input field while it's blank and unfocused.

Hah.  I see it now.  Probably has to do with the Dialer interface.  Null is probably there to trigger the dialer to come up if it's down and sink the traffic if it doesn't.

You'll get 'badip' in any of the following cases:

• Invalid IP address format
• No 'myip' variable set, and somehow the server couldn't figure out the connecting address (unlikely)
• Trying to update endpoint to an IPv6 address (ensure you're using ipv4.tunnelbroker.net/nic/update to keep this from happening)
• IP is already assigned to a different tunnel (you'll get nochg if it's the tunnel you're currently trying to update)
• IP isn't pingable

That means it's picking the correct route? Can you explain that command means?

It means to pipe "show running-config" through the 'include' command, which is effectively a grep.  This is the Cisco equivalent of "cat file.cfg | grep blah"

A better way to see if something's hiding in your configuration would be to check for the null, and not the prefix.  It's possible you have something within that prefix assigned to Null0 with a /56 mask, which wouldn't necessarily be caught by the previous command.  It would be odd, but the one thing you can always rely on with networking gear, is that the odd things happen.

How about trying "sh run | i ull" which should pull all your configuration lines which reference null in any fashion.  Yes, I'm just searching for 'ull', just in case it's also going to case-match.

Have it in your clipboard before losing focus on the input field, for now.  I'll look at this tomorrow and see about improving the flow if you lose focus with an empty field.

"badip" gets returned in a bunch of cases, which aren't always due to a bad ip per-se.  Just a limitation of the error types returnable by something that's Dyn-compatible.  If there was a mechanism to append supplemental information (akin to SMTP's extended status codes: "550 5.7.1 Useful text here"), we would be using it.

Back to "badip".  You'll get this if any of the following occur:

• Invalid IP address format
• No 'myip' variable set, and somehow the server couldn't figure out the connecting address (unlikely)
• Trying to update endpoint to an IPv6 address (ensure you're using ipv4.tunnelbroker.net/nic/update to keep this from happening)
• IP is already assigned to a different tunnel (you'll get nochg if it's the tunnel you're currently trying to update)
• IP isn't pingable

Lion enables what is often termed "Happy Eyeballs" for anything using the higher level networking functions (CFStreamSocket and higher).  Basically, it'll try v4 and v6 at the same time, and whatever responds first will be tried first the next time.