[nycbug-talk] IPv6 NY-US Roll Call
carton at Ivy.NET
Thu Mar 22 19:15:09 EDT 2007
>>>>> "a" == alex <alex at pilosoft.com> writes:
>>>>> "il" == Isaac Levy <ike at lesmuug.org> writes:
il> Does anyone on this list, in NY or America in general run IPv6
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.
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
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
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
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
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 304 bytes
Desc: not available
More information about the talk