That surprises me.  They won't allow IPv6 glue on domain registrations (I asked them this in February)

Was this for all TLDs/ccTLDs?

That updates on Fridays, although we might change it to daily.

What's it actually measuring, I assumed it was tunnel end point pinging the remote end of tunnels setup on the server and then averaged over x hours, but if it only updates fridays, does that mean it averages over the whole week or?

Yes, it is only for turning up BGP tunnels.

Are you going to show latency stats for the tunnel servers connected, because on one of the other graphs it indicates there is 17 tunnels connected.

I believe Sam is prepping it to be a BGP only tunnel-server (meaning for tunnels that will be doing BGP with us). I'll check with him.

Is this still the case?

The server I have a tunnel to is now only 0.8ms from an end point so I'm cheering

Not trying to nitpick, but when I did a mtr the reverse lookup on the tunnel end point in chicago came back as www.cyberaction.com

It is irrelevant what I have.

I fail to see how, you might have an internet2 link which has a rather large MTU, then again if you are using a HE tunnel this isn't very likely. There is a very good reason for the MTU being set to what it is, since if you have a cable connection or PPPoA you'll most likely have a MTU of 1500, PPPoE is 1492 etc, to run IPv6 over IPv4 you have a bunch of overheads and bumping the MTU will just fragment packets possibly unnecessarily etc.

What sort of link do you have?

I forgot to include it in my replies but anything that currently have a IPv4 address will end up with a /48, it's only things that only have NAT IPs now that are likely to only get /64's

Enterprise or local domain subnetting is finally gone. Every subnet is a 2^64 address space. This eliminates any or perhaps most needs for renumbering. Change of upstream provider (prefix) can be almost automatically handled by advertising the prefix.

LANs technically only need 2^48 bits of space, and since you can't duplicate the same MAC on the same LAN I'm still left wondering if they really can justify the extra 16 bits for padding. I fail to see how a change of upstream provider is going to be fun, we were all promised portable subnets but like they were ever going to come good on that one, in any case this is going to be as much work if not more then renumbering IPv4 subnets, especially when you start getting into DNS etc.

The /64 allocation prefix space alone is large enough to give every soul in the milky way an address space of many times the current Internet for the next few billion years.
The vastness of the space of the IPv6 Internet as a whole and likely empty (smaller) vastness between active IP addresses makes port scanning over sections of the Internet unfeasible and security by obscurity may be possible.

Actually IPv6 doesn't handle the latency of space apparently, I remember from a few years ago of talk about IPv8 being designed to deal with it over inter-planetary distances.

at the moment I'm splitting my /64 into /96's so each vlan has as much space as the IPv4 internet

I might up to a /48 just to try autoconfig

You technically don't need to, I'll probably get shot for saying this, but if you set the 6to4 tunnel IP to xxxx::2/128 you can use xxxx::3/64 on the lan interface. This works because the /128 is more specific it will override the /64 route.

although if I was the IETF I'd issue many a /120 as that would have one IPv4 octet of space and thats more than enough for most
and use a /128 for the tunnels or /120 and have all users of a tunnel end-point use the same /120 for the ptp and a differant /120 for their side of their end as well as offer multiple /120's per tunnel in case of vlans and a /104 in case of companies that use a 10.x.x.x scheme for easy transition

that would be a direct fix for the current IPv4 issue as people aren't running low on lan private addesses just on public addesses as well as take care of Mars networking (when that happens) (maybe some web cam sats of mars) (that would be cool)

If only they had had the foresight to include a backward compatability, but alas they didn't.

Before you call the world "stupid" you really should read the specs first and try to understand the new addressing system and its philosophy, unless you want to raise questions as to your own caliber.

Perhaps I could have been a little more careful with my words, but at the same time it just seems silly to make such a large IP space and then turn round and be so libral with it.

And as to the prospect of running out of IP addresses again: the potential size of the new allocation space (/64) is the SQUARE of the old IPv4 Internet, with each allocation of the potential size of the SQUARE of the size of old Internet. This, if you look at the address space through IPv4 glasses.

The amount of IPs wasn't my entire argument, I just wasn't able to conscisely put it any better.

Yes was my fault, NXDOMAIN was being set and it shouldn't have been, but since I always pick the interesting topics to do stuff on it's hard to find someone that knows more to tell me where I screwed up

Sounds correct.  Resolvers are supposed to query for AAAA records first, and if there's a non-error answer, use the IPv6 address.

There were errored answered being sent, or maybe I was screwing things up some how on the DNS server side of things hmmmm.

the current BCP from the RFCs disagrees with you.

No, I just disagree with it

Is it wasteful?  Yes.  However, the practice is Internet-wide.  Allocations no longer in use can be returned to the registries.

APNIC used to hand out /35s but you can upgrade to a /32 for free!

As for HE, I don't really see the purpose in allocating TWO /64's just to have one that has an X::1 and X::2 that simply ping each other to make certain the tunnel still works (effectively a /126).

Erm don't you mean 1 /64 for the PtP ? At least that's the only allocation I'm aware of and currently abusing

You really only need a /128 for the PtP connection, I also thought you needed network/broadcast yesterday then I remembered they did away with them in IPv6.

of 2001:470::/32 should be routed over the tunnel anyway (if not ::/0, 2000::/3, or other subnet greater than /32

It's been a while since I played with IPv6 serious (2002 or there abouts), back then we were only supposed route 2000::/3 not ::/0 has something changed or are people just being lazy and routing everything when they shouldn't be?

I vaguely recall the ::/0 shouldn't be routed because it contained multicast space as well as unicast.

Remember that even with any tunnel, one can additionally use the 6to4 mechanism - and should have the 2002::/16 route sent to the primary IPv6-encapsulation interface.  With Linux, I've seen the source code that will auto-extract the IPv4 component of such addresses and auto-tunnel the packets to the appropriate host.  I don't know if KAME-based IPv6 stacks have that encoded or not (e.g. freeBSD). Sending 6to4 over a different IPv6 tunnel from a dual-stacked host is "taking the long way around."  However, as 6to4 along with the IPv6 tunnel service here and elsewhere are transition mechanisms, in a purely native IPv6 Internet, they will eventually disappear.

Ok now you've got me, I'm using linux but I'm not entirely sure what you're talking about here.

As far as DHCPv6 is concerned, part of the original plan for IPv6 is that such would be unnecessary.  IPv6 is meant to be "big brother's dream" - everything wired to everything else all the time.

Yes and I have a nice pair of 240v wires here big brother can stick up his you know what

Oh and if it's not a waste of IPs, I wonder how many privacy concerns were addressed when the brilliant person thought up to send the MAC address  as the IP, I'm surprised the EFF or similar organisation hasn't made a fuss over this considering how much of a fuss has been made over tracking cookies and this seems much worst.