I switched to JaguarPC for an unmanaged Debian VPS after my old provider had my VPS down 5 days, didn't communicate with me well and ultimately never got my VPS and data back. (I kept my own backups, luckily.) JaguarPC had a special running and had been in business 10 years at the time, so I gave them a try. Never a problem. 3 years later they upgraded my resources and lowered my fee, and did it without having to restart my VPS. I once got an email that they were experiencing a DDoS attack that might affect me and pointed me to a website with running updates, but it didn't seem to affect me. Much better service than I had before and have seen with my friends' providers who would have issues, look at the status page and get a false "everything is fine!" message. I'm about to leave them to self-host at home, so I wrote them a thank-you blog singing their praises.

Unfortunately, after you program it you no longer know where it is.

Crap, how would I pay for prostitutes?

On the other hand, I just wrote two checks to family (um, not for services previously mentioned in this post). It seems like there should be a way to wire/ACH funds between individuals.

Then again, there are certain places (besides prostitutes) I would not trust with the information necessary to debit my accounts.

djbdns is a collection of programs. The 512B limit doesn't apply to all of them. The resolver dnscache would be the program of concern in this context, and it can both request and serve requests over 512B on TCP in the default build. I am currently using other resolvers for IPv6 reasons, but I don't expect dnscache to have a problem with DNSSEC on the root servers.

Oh no, not again...

Some clients may erroneously think they have working IPv6, get an AAAA address and timeout trying to use it before falling back to IPv4. This really annoys users. It wouldn't be Google's fault that this happens, but their sites would be perceived as very slow and they'd lose users.

It is not clear to me exactly what they're doing. They might be whitelisting networks and not individual resolvers. If so then your home resolver may work when your ISP signs up with them.

Short answer: No problem. You will have many addresses to use in your LAN, and your packets will not enter the internet to go to a local file server.

Slightly longer explanation: IPv6 routing is quite similar to IPv4 routing. I think you might be misunderstanding what is keeping your current local traffic from bouncing over the WAN link.

There is RDNSS which my router advertisement daemon supposedly supports, but I haven't tried it and don't know how ubiquitous it is.

But yeah, now that you mention it DNS support isn't quite homogeneous yet on IPv6.

Actually with 6to4 you get a /48. Handy to know in case you need more than 2^64 IPv6 hosts behind your IPv4 address. Or if you want multiple IPv6 subnets behind an IPv4 address which seems more likely.

Others mention private alternatives; I'll summarize them here:

Site-local addressing fec0::/10 , deprecated . This is deprecated, but I don't expect these addresses to be reused for other purposes in...ever, I guess. Just pick a network address beginning with fec0: through feff: and have fun.

Unique local addressing fc00::/7 . For various reasons described elsewhere IETF would prefer all addresses be unique even if they aren't globally routable. Pick your own /48 between fc00:0:0: through fcff:ffff:ffff: and have fun. Or you can go to SixXS and have one non-authoritatively registered to you.

6to4 2002::/8 . If you have a public static IPv4 address then you automatically have a /48 starting with 2002: and then your hex-encoded IPv4 address. If not, then there should be no harm in using a private IPv4 address to make your 6to4 /48. For example, if your NAT router is 192.168.1.1 then your 6to4 subnet could be anything from 2002:c0a8:0101:0::/64 through 2002:c0a8:0101:ffff::/64 . (If you want to be sure no private packets escape to the real internet then null route 2002:/8 or 2002:c0a8:/16 at your IPv6 router if you have one.)

See the SixXS link above. There is no official ULA registry, but they're the only ones I know of that are trying so far. The ULA addresses are not publicly routable, so a collision is not really a problem unless your network needs to someday merge with a colliding network. I could see that happening with major corporations, but it's not likely a problem with the typical home LAN.

Helpful tinkerer hint: Whenever you get an IPv6 range you generally get a /48, but as you assign IPv6 networks and routes to your network you will want to use /64 subnets. You don't have to, but things generally tend to make more sense that way, and default settings tend to assume that setup.

Now if you want to be on the live global IPv6 network then you can go to a tunnel broker and request a tunnel and/or subnet, and then you get a live address range. I'm in North America and use the free SixXS.

Surely most of each assigned range. It is intended that each local LAN segment will have 2^64 usable addresses, half of which are intended to be globally unique and half which aren't. However this is nothing to stop someone from subnetting smaller networks than a /64; it will just break the stateless autoconfiguration ability so you need to assign static addresses or use DHCP6.

Heck, I have a /48--2^16 networks of 2^64 useable addresses--through a tunnel broker and I'm using less than a dozen addresses.

They are. For each packet a router has to compare the destination to a list of routes to determine where to send the packet. If all the addresses starting with 2001:0db8: by design are accessible by the same border router then your routing tables can be much simpler. That is not the case with IPv4, and the routable address space is about to increase by many orders of magnitude.

Simplified routing makes a huge difference on backbone routers.

They made it that way because it's similar in structure to IPv4 and made it long not to make 2^128 addressable devices but to make (theoretically up to) 2^64 collision domains with the possibility for 2^63 globally Unique IDentifiers and 2^63 non-globally-unique ID's. But a lot of people are going to ignore the global ID part and use (network)::1, (network)::2, etc. or have fun with hex letters with (network)::dead:beef and such. (Luckily--actually by design--these simplified IPv6 addresses will usually happen to be be in the non-globally-unique range.)

They intend to waste a lost of potential addresses to make routing tables simpler. Ideally the IPv6 network map will be a hierarchical structure of networks.

If you don't have DNS handy there are a growing number of peer-to-peer name resolution protocols that I expect will become more popular with IPv6 addressing.

So the answer is that the "horrible alphanumeric sequences" are designed to make easy-on-core-routers hierarchical routing feasible while squaring the theoretical maximum number of addressable hosts. And they really expect people to use managed or peer name resolution, anyway.

It's already enabled by default in Linux distributions and Windows Vista and Server 2008. The major backbones should be able to handle it. Many businesses use proxy and other gateway servers for intranet-to-internet access, so if a company is not ready to migrate the intranet to IPv6 right away they can just put it on their proxy, gateway and public servers.

I'm not saying it will happen, but I don't think the obstacles are technical at this point. I think what needs to change is to put all the porn on IPv6-only servers. Or YouTube, FaceBook, MySpace, etc.. Okay not literally, but either the customers or the service needs to be accessible by IPv6 only before it make sense for everyone to make the effort. I'm guessing it will be forced when governments or militaries have large masses of users on IPv6 and the IPv6-IPv4 gateways start getting overloaded.

What JournalSpace didn't say is that their mirrored drives are actually 30GB Zunes. Just let them run down overnight, charge them back up and everything will be fine tomorrow.

I actually worked for a company that did have a recovery plan and tested it several times a year. I was impressed. They maintained multiple DR sites and would send a small team or sometimes an entire department to work a real shift at the DR site. The backups were well organized, had daily offsite transport and were tested. Awesome. Then they laid a bunch of us off. Oh well.