Re: RIPE is just more fun.
Jared, I yanked the mp3 out of the youtube flv: http://blyon.com/ routers_died.mp3 -Barrett On Oct 26, 2007, at 1:19 PM, Jared Mauch wrote: On Fri, Oct 26, 2007 at 03:42:27PM -0400, Leo Bicknell wrote: http://www.youtube.com/watch?v=_y36fG2Oba0 Cool. Time for a remix as well! Maybe i'll go to RIPE next time!
ipv6/v4 naming nomenclature [Was: Apple Air...]
On Sep 18, 2007, at 1:30 PM, David Conrad wrote: HI, On Sep 18, 2007, at 5:45 AM, Jeroen Massar wrote: Please please please, for the sake of a semi-'standard', please only use the following forms in those cases: www.domain www.ipv6.domain www.ipv4.domain Don't come up with any other variants. The above form is what is in general use around the internet and what some people will at least try to use in cases where a DNS label has both an and A and one of them doesn't work. You can of course add them, it is your DNS, but with the above people might actually try them. What RFC (or other standards publication) is this documented in? Where did the www.ipv6 and www.ipv4 standard come from? As for end- users such as normal non-network people, having a standard that adds more characters than necessary (that eventually may become arbitrary) seems rather silly. Why wouldn't w4.domain or w6.domain suffice for this purpose rather than making it overly scientific? I can understand the want to use ipv4 etc to separate out other services such as DNS, SMPT, etc, but everyone does what they want with those services anyway. -Barrett
Re: Apple Airport Extreme IPv6 problems?
Getting back to my original discussion with Barrett, what should we do about naming? I initially though that segregating v6 in a subdomain was a good idea, but if this is truly a migration, v4 should be the interface segregated. Personally I find separation of the A/ somewhat of a dysfunctional way to deal with this issue. Users that opt-in to dual-stack will be accepting of the downfalls in the v6 deployments out there. In that case, it should be fine to provide a seamless experience with overlapping DNS records. However, users are not getting a choice or even an education on what is happening on the tunnel and are getting impacted from overlapping /A records. This is the breakdown, I think that if we start segmenting DNS to fix a symptom and not the problem itself, we're just adding more ducktape. I would actually think Apple (and any other vendor that default enable v6 tunnels without notifying the user) should react to this and provide a fix that allows their current user base to opt-in to their pre-existing tunnels with education on what that means to the user. It's great to be progressive, but it's not good to do it when it can impact users. Regarding segmented v4/v6 DNS, this may already exist, but it may also be a good idea for the web masters out there to create a v6 logo or marking denoting that a user has reached a v6 page vs. a v4 page. This could also be more helpful and also allow users to choose which protocol is used to reach the site. It also creates a reason to have both an overlapping /A www. and a special www.v6./w6. and www.v4. alias. If that framework accompanied the overlapping DNS, then HREFs could shuffle users from one version of the site pending on the user preference. On a totally unrelated note: Not to make any accusation on the security of the end-point tunnel network what-so-ever, but an entirely other issue is the tiny bit of a security conundrum that default tunnels create -- tunneling traffic to another network without notifying the user seems dangerous. If I were a tinfoil-hat security person (or a CSO of a bank for example) this would really freak me out. -Barrett
Apple Airport Extreme IPv6 problems?
Apple is nice enough to provide an automatic v6 tunnel from their new Airport Extreme units. They even get all the machines on the network to participate -- by default! At first this did not seem to be much of an issue, it was even pretty cool. However, I noticed as I roll out more v6 services to support native v6 users, I am impacting the network performance of almost all of the Apple airport population that has an inefficient tunnel configuration. The user obviously will take the v6 published IP over the v4 A record. Don't get me wrong v6 tunnels are great, when you opt-in and know what you are getting into. For example, my grandparents tunnel in California goes to Virginia. This impacts the user experience rather significantly with the first hop being nearly 100ms where their services to California are ~20ms. It's painful for a lot of users, especially when they don't even know what's going on. Has anyone else ran into this? It's not pretty for a CDN or anyone trying to provide a quality service over v6, shunting users over inefficiently tunneled routes does not sit well with me. I think Apple has made a mistake by enabling this by default. -Barrett
Re: Apple Airport Extreme IPv6 problems?
On Sep 15, 2007, at 11:01 AM, Rich Groves wrote: Are there any reliable stats on the number of 6in4 tunnel connects after the Extreme was released ? I'm just wondering if this is something that we as a community can easily track. Some DNS analysis at the provider I worked for in the past showed the bulk of requests (to my surprise) were for Nintendo Wii specific content (the weather app and news app) . When the Nintendo folk decide to do something more interesting and latency sensitive this could be a real problem I suppose. We removed on our production hosts shortly after we deployed it, our global v6 deployment goes production next week, at which time I may re-add the to limited production. If we do this, I publish a report of the stats once I have more accurate figures.
Re: Apple Airport Extreme IPv6 problems?
How did you do the naming? Matching or unique? Matched , I was thinking about doing a w6 or something more unique for now, but that somewhat defeats the point. The other thought that occurred to me, does FF/Safari/IE have any ability to default back to v4 if v6 is not working or behaving badly? This could be a helpful transition feature but may be more trouble than it's worth. -Barrett
ICANN registrar supporting v6 glue?
Apparently GoDaddy does not support v6 glue for their customers, who does? I don't think requiring dual-stack v6 users perform v4 queries to find records is all that great. Any input would be helpful, -Barrett
Re: ICANN registrar supporting v6 glue?
One note here is that even though you can get glue into com/net/org using this method, there is no IPv6 glue for the root yet, as such even if you manage to get the IPv6 glue in, it won't accomplish much (except sending all IPv6 capable resolvers over IPv6 transport :) as all Unless I did this query wrong, you are absolutely right: ;. IN NS A.ROOT-SERVERS.NET. 360 IN A 198.41.0.4 B.ROOT-SERVERS.NET. 360 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 360 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 360 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 360 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 360 IN A 192.5.5.241 G.ROOT-SERVERS.NET. 360 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 360 IN A 128.63.2.53 I.ROOT-SERVERS.NET. 360 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 360 IN A 192.58.128.30 K.ROOT-SERVERS.NET. 360 IN A 193.0.14.129 L.ROOT-SERVERS.NET. 360 IN A 198.32.64.12 M.ROOT-SERVERS.NET. 360 IN A 202.12.27.33 I don't see any v6 glue there... Rather than having conversations about transition to IPv6, maybe we should be sure it works natively first? It's rather ironic to think that for v6 DNS to work an incumbent legacy protocol is still required. The GTLD's appear to have somewhat better v6 services than root: A.GTLD-SERVERS.NET. 172800 IN 2001:503:a83e::2:30 B.GTLD-SERVERS.NET. 172800 IN 2001:503:231d::2:30 I'm pretty disappointed now, -Barrett
Re: ICANN registrar supporting v6 glue?
there are providers that have (in the US even if that matters) ipv6 connected auth servers, that could even help. I can't seem to make one of them want to be a registrar too :( but... maybe Ultra/Neustar could do that for you? Neustar/Ultra's .org gtld registration services apparently do not support v6, however, net and com do. Yet, .org does provide a v6 resolver: b0.org.afilias-nst.org. 86400 IN 2001:500:c::1 -B
Re: DNS deluge for x.p.ctrc.cc
I thought I would chime in quickly, one of my customers has been one of the targets of this attack. The x.p.ctrc.cc DNS server was shut down on the 15th, the response itself had a 36 TTL so that should be expired by now. On this end of it, the largest traffic spike we received was around 8 Gbps. The last time we saw this traffic was on the 21st around 2 GMT with traffic at about 2 Gbps, it has lost a lot of steam. If you see unusual DNS traffic to AS32787 or 72.52.0.0/18, chances are it is part of this attack or the attacker setup a new RR to query against. I've yet to see a copy of the malware that is doing the spoofed queries itself. If anyone has it, I would like to take a look. Thanks and I am really impressed with everyone's reaction to this attack. Especially Rob Thomas, he really has a grip on it. Cheers, -Barrett
