>>>>> "a" == alex <alex@xxx> writes: >>>>> "il" == Isaac Levy <ike@xxx> writes: il> Does anyone on this list, in NY or America in general run IPv6 il> services? I did for about two years, until OCCAID cut me off. They used to give tunnels to v6 experimenters, but now they've gone ISP-club-only. And James at TowardEX is now actually charging his colo customers *extra* if they want v6 in addition to v4 (used to be included free for TowardEX colocators, but was mad flakey). OCCAID shut down their ewr2 pop (and moved to some kind of ewr2a pop), and ditched all the old members connected there. The alternative now is SixXS, which gets transit from OCCAID but has lots of automation for serving Interweb users. Unfortunately they also have fewer pops. OCCAID had great connectivity (rtt usually matching or beating v4 from Alex), and they did BGP so I got to look at a full view of all 600 - 700 routes in the IPv6 default-free zone. very fun, very reliable. OCCAID, and their new partners SixXS, seem to be generally technically competent, but they have crippling layer 10 issues. It is stuffed full of those people who claim they want to be ``apolitical'' and then run their organization like some kind of pathetic nerd mafia. problems like: o SixXS problems o AUP forbids irc clients o AUP forbids irc servers o AUP forbids shell servers even when not used for irc o a series of kiddie-heuristic harassment tests when you sign up (``the ten easy steps to ipv6!'') o horror stories from many people who try to use them. If they cut you off, they always cut you off first and ``inform'' you later or not at all. One guy said they kept deleting his account because they didn't believe the name he gave sounded real enough (it was his real name). o OCCAID/SixXS problems I've had in the past o putting mailing lists under ``emergency moderation'' when they feel embarassed by the discussion o offering better support to ``insiders'' on an unpublished irc channel and worse support to people on the mailing list, then banning and klining people from that channel if they're insufficiently sycophantic o AUP forbids so-called ``DNS spam'' which is any DNS reverse lookup that spells an English phrase or sounds excessively cute. I guess this is another anti-irc thing, but I'm not happy about indignities like this and don't think it's in the spirit of the Internet, and I really bristle at the idea of passing on a restriction like that to _my_ users. so, if you can live with that, SixXS is the way to go. I can't stand them, but I will probably sign up soon to get back some kind of censored politicized v6 (albeit without BGP now). We'll see how long it takes them to find an excuse to boot some guy who posts on public mailing lists that he has major problems with their attitude. A year ago I reported the ``DNS spam'' to Declan's politech list. Once Declan's report came out, they hurriedly 404'd all the URLs on their site in Declan's message, reversed their policy, and whistled ``nothing to see here'' for a few months. Then they put the policy back. Hurricane Electric tunnels are, for me, not even worth looking at, because they block irc. I'm not spending $600/mo on Internet so I can put up with this T-Online/Verizon port blocking bullshit. I *will* pay for IPv6, but this second-class interweb crap completely defeats the purpose of an experimental protocol. There's another huge problem with Hurricane Electric. If you set up v6 at your site, it is really, really important that your v6 access be almost as fast and reliable as your v4 access. It should have similar bandwidth and rtt. It should be very, very seldom that v4 is up but v6 is down. At every site I've seen (aside from my own before I was cut off), this is *not* the case. I've even seen sites promoting ipv6 that advertise a broken AAAA for their web server, but work fine over v4. I've had to nag my secondary DNS guy to remove his nameserver's AAAA record when TowardEX's colo v6 has gone down again. The reason this is important: most software does, and should, try v6 before v4. This includes ssh and bind. On most OS's, it includes SMTP, telnet/netcat, NFS, FTP, lynx/links, basically everything. If your v6 is unreliable or has a high rtt or high packet loss, users will first learn that your Internet connection is ``crappier than what I have at home, at least for some sites.'' Probably the crappiness will be, sorta weirdly, for all sites, because it will slow down DNS resolving for anything near to the '.' root where v6 is deployed (first access to a new web site will take 4 seconds, then fast from then on). The second phase of user response to IPv6-crappyness is to learn about these -4 options to all commands. Sometimes sysadmins do this, too---like they will start bind with '-4' and cut off access to any subdomain that has v6-only DNS servers, to make regular resolving faster with their crappy v6. Sysadmins may get into the action by putting stuff in /etc that makes each program prefer v4 instead of v6. The third phase of response to v6 crappyness is, sadly, well underway. It's the _developer_ response to crappy v6 tunnels. We've got all these short-sighted Windows refugee developers working on free software now, who just bang away and hurl feces at problems until they sorta work. irssi's wrapped getaddrinfo() to make it prefer v4 for a while, unless you set it back to v6 in the template config file as I do, and even then it won't effect users who started irssi before you realized the problem and set it back because they'll all have local .irssi/config files. Firefox, on some ``distros'' of Linux anyway, now ships prefering v4 over v6. meaning you will actually have v6, go to kame.net and NOT see the dancing kame. You have to go into some arcane Javascript file to undo their brain damage. Firefox on Solaris still works right, but I guess it's an old version. getaddrinfo() is actually v4/v6-agnostic---it could work with ISO CLNP or IPv2000 or whatever comes next, with no modification to programs that call it in the most generic way possible, once DNS rules for the new protocol were invented. so these new programs are making their calls to getaddrinfo() less portable by hardcoding in an understanding of v4 and v6 address families. The right way to do the third phase is, well, not at all. But the less wrong way is to have a v6 stack that sorts the results of getaddrinfo based on a system-wide config file like /etc/netconfig or /etc/inet/ipaddrsel.conf. but NetBSD doesn't have these files, and on Solaris they don't seem to do what the documentation says. These phases are the Hidden Obstinance to IPv6, aside from uncooperative ISP's or heads-in-the-sand American ``businesses.'' Some of the things that can make your v6 crappy: 1. using a high-rtt tunnel. HE's tunnel endpoint is in Fremont, so to connect to another site here in NYC, your packets cross the US twice, adding 40 - 100ms latency. This is enough for ssh users to notice that v6 sucks and type 'ssh -4'. Hurricane has presence in NYC, but they won't give tunnels from here, and they won't do colocation here so you can make your own tunnel, either. besides he.net, xs26.net in Europe has this problem, too, since your tunnel endpoint is 100ms away. (also, their web site seems down right now, so I dunno if they can meet the ``up almost as often as v4'' criteria) some people make a big deal about ``native'' v6, meaning v6 over the Ethernet cable. Not having tunnels definitely makes routing problems easier to track down, but I really don't think it's faster or intangibly ``better'' somehow. The problem is when the two ends of the tunnel are far apart. The tunnel should only be a couple ms long, not spanning countries or oceans, so routing is still close to optimal. It's the rtt, not the tunnel itself, that sucks. 2. bad neighbor ISP's (cough *Abliene* cough) that fuck up the v6 routing table. with OCCAID I had packets crossing the Atlantic twice to get to Hurricane Electric. stupid. OCCAID blamed HE and said they were doing something wrong and ignoring OCCAID's complaints. Who knows what the real story is. 3. not maintaining your v6 well. If your site depends on some ``tunnel broker'' with a dynamic address on your end, then inevitably the broker machine gets rebooted a couple times a month and loses your site's state. If your tunnel broker client is buggy and crashes, or isn't running at all, then your v6 goes down for weeks until someone notices. so, that covers almost every v6 deployment I've seen. not good. a> If you want your *glue* to be AAAA - well, its a> a bad idea - nobody could get to anything in your domain if a> you have only AAAA glue. but chia.arin.net and a.gtld-servers.net both have AAAA records. so, if you are going to configure your nameserver with v6 _connectivity_ as well as just v6 records, be damn sure your v6 is good, or you will get 4sec delays resolving ~everything. a> There's no demand, cause, well, why'd you *want* ipv6. I'll pay you $50 extra per month for v6 right now. I want it so I can reach and be reached by v6-centric friends in Germany (and apparently also Japan). Not having stable v6 connectivity is a huge problem for me. I use v6 on my LAN, and it's a major pain-in-the-ass to renumber, to remove or add back the v6. And if you have the v6 without a working default route, just to use locally, it makes problems for some OS's (like Solaris). v6 /32's are free from ARIN as long as you are (1) an ISP, (2) an ARIN ``member'' (have v4 blocks from ARIN, or pay $500/yr), and (3) have a plan to assign 200 /48's within 5 years. I think several tier 1 ISP's already to v6. Cisco IOS is much less of a flakey piece of shit on v6 now. so it may be mostly a matter of your time to set it up. I'm intensely frustrated with all these crappy flash-in-the-pan high-rtt port-blocked tunnels and layer 10 bullshit. and, in general, basically with people who have Alex's attitude, which I think is both wrong and pervasive.
Attachment:
pgpimvg8yIKRY.pgp
Description: PGP signature