From fw at deneb.enyo.de Mon Oct 5 21:27:25 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 05 Oct 2009 19:27:25 +0000 Subject: Brekage due to Hurricane Electric/Internet2 Message-ID: <87tyydy736.fsf@mid.deneb.enyo.de> Debian has received a report about a partition affecting access to security.debian.org: According to , the BGP session to Hurricane Electric at Seattle is up, the prefixes are there, but packets are dropped. I wouldn't be surprised if this hists Internet2 downstreams pretty hard. From Brian_Tate at SyncGlobal.net Tue Oct 6 18:39:38 2009 From: Brian_Tate at SyncGlobal.net (Brian Tate) Date: Tue, 6 Oct 2009 12:39:38 -0400 Subject: IPv6 test set as operations tool? Message-ID: <00a801ca46a3$98364ef0$c8a2ecd0$@net> - Has anyone found useful a handheld Ethernet test set (e.g. Exfo AXS-850 or similar) with IPv6 testing capabilities? - Are they worth the cost for operational troubleshooting, or are other tools better? I am thinking of buying one... (Off-list replies are fine--this might be a better topic for a forum, rather than this list.) Thanks, Brian (an IPv6 Rookie) From fw at deneb.enyo.de Tue Oct 6 19:06:43 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 06 Oct 2009 17:06:43 +0000 Subject: Brekage due to Hurricane Electric/Internet2 In-Reply-To: <87tyydy736.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Mon, 05 Oct 2009 19:27:25 +0000") References: <87tyydy736.fsf@mid.deneb.enyo.de> Message-ID: <87skdwh2os.fsf@mid.deneb.enyo.de> * Florian Weimer: > Debian has received a report about a partition affecting access to > security.debian.org: > > > > According to , the BGP > session to Hurricane Electric at Seattle is up, the prefixes are > there, but packets are dropped. I've been told that the looking glass needs some knowledge about Internet2's routing architecture to use properly, and that I had misinterpreted its output. Sorry about that. The site in Brazil for which the problems were initially reported hasn't got global IPv6 transit, and it's likely that this is causing the reachability issue (d'oh). From wmaton at ryouko.imsb.nrc.ca Wed Oct 7 01:11:06 2009 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Tue, 6 Oct 2009 19:11:06 -0400 (EDT) Subject: Brekage due to Hurricane Electric/Internet2 In-Reply-To: <87tyydy736.fsf@mid.deneb.enyo.de> References: <87tyydy736.fsf@mid.deneb.enyo.de> Message-ID: On Mon, 5 Oct 2009, Florian Weimer wrote: > Debian has received a report about a partition affecting access to > security.debian.org: > > +1 here. Coming from CANARIE-assigned address space the site is unreachable. I suspect that global transit routes are being advertised to some research networks but the traffic is getting tanked. For example, security.debian.org resolves to 2001:4f8:8:36::6, but can't reach it: stats 1216# traceroute6 2001:4f8:8:36::6 traceroute to 2001:4f8:8:36::6 (2001:4f8:8:36::6), 30 hops max, 40 byte packets 1 olans.core.ottix.net (2001:410:90ff::1) 0.542 ms 0.745 ms 0.725 ms 2 border2.core.ottix.net (2001:478:235::7) 0.460 ms 0.562 ms 0.548 ms 3 canet5.gigafed.net (2001:478:149::13) 7.021 ms 7.756 ms 8.366 ms 4 2001:410:101:30::2 (2001:410:101:30::2) 71.428 ms 71.540 ms 71.772 ms 5 2001:320:1b00:1::1 (2001:320:1b00:1::1) 185.058 ms 185.172 ms 185.776 ms 6 * * * 7 * * * 8 * * * 9 * * * etc. > According to , the BGP > session to Hurricane Electric at Seattle is up, the prefixes are > there, but packets are dropped. > > I wouldn't be surprised if this hists Internet2 downstreams pretty > hard. It might, but CANARIE have identified the problem elsewhere but can't seem to pinpoint precisely where. wfms From jogi at mur.at Wed Oct 7 10:44:37 2009 From: jogi at mur.at (Jogi) Date: Wed, 07 Oct 2009 10:44:37 +0200 Subject: Brekage due to Hurricane Electric/Internet2 In-Reply-To: References: <87tyydy736.fsf@mid.deneb.enyo.de> Message-ID: <4ACC54F5.5060507@mur.at> Hi all, Our IPv6 upstream is the Austrian academic network. William F. Maton Sotomayor schrieb: > +1 here. Coming from CANARIE-assigned address space the site is > unreachable. I suspect that global transit routes are being advertised > to some research networks but the traffic is getting tanked. For > example, security.debian.org resolves to 2001:4f8:8:36::6, but can't > reach it: Here it resolves to: 2001:a78::1a 1?: [LOCALHOST] pmtu 1500 1: v200-fe2-r1ko.mur.at 0.995ms 2: wien6.v6.aco.net 6.454ms 3: 2001:7f8:30:0:2:1:0:286 6.536ms 4: mchn-s2-rou-1030.eurorings.net 14.831ms 5: mchn-s2-rou-1030.eurorings.net asymm 4 14.818ms pmtu 1476 5: v6-2-v4.01.spxs.net 31. 69ms 6: 2001:a78::1a 39.783ms reached Resume: pmtu 1476 hops 6 back 6 2001:8d8:2:1:6564:a62:0:2 1?: [LOCALHOST] pmtu 1500 1: v200-fe2-r1ko.mur.at 1. 41ms 2: wien6.v6.aco.net 6.772ms 3: wien6.v6.aco.net asymm 2 6.535ms pmtu 1480 3: tu-637.sar1.Amsterdam1.Level3.net 47.210ms 4: tu-637.sar1.Amsterdam1.Level3.net asymm 3 46.291ms pmtu 1450 4: tu-607.sar1.London1.Level3.net 54.438ms 5: 2001:7f8:4::cb9:1 asymm 6 55. 11ms 6: xe-4-1-0.lon11.ip6.tinet.net asymm 7 55.256ms 7: xe-8-2-0.ams10.ip6.tinet.net asymm 8 59.892ms 8: xe-2-2-0.ams20.ip.tinet.net asymm 9 59.219ms 9: schlund-gw.ip6.tinet.net asymm 14 193.410ms 10: te-4-1.bb-c.act.fra.de.oneandone.net asymm 15 201.553ms 11: te-1-3.bb-c.bs.kae.de.oneandone.net asymm 16 203.809ms 12: ae-1.gw-dists-a.bs.ka.oneandone.net asymm 17 203.263ms 13: wieck.debian.org asymm 18 204.294ms reached Resume: pmtu 1450 hops 13 back 18 2001:a78::16 1?: [LOCALHOST] pmtu 1500 1: v200-fe2-r1ko.mur.at 1. 60ms 2: wien6.v6.aco.net 7. 79ms 3: 2001:7f8:30:0:2:1:0:286 7.196ms 4: mchn-s2-rou-1030.eurorings.net 16.251ms 5: mchn-s2-rou-1030.eurorings.net asymm 4 14.200ms pmtu 1476 5: v6-2-v4.01.spxs.net 31.430ms 6: 2001:a78::16 38.966ms reached Resume: pmtu 1476 hops 6 back 6 The address you are getting is also reachable from our corner of the network: 1?: [LOCALHOST] pmtu 1500 1: v200-fe2-r1ko.mur.at 1.120ms 2: wien6.v6.aco.net 8.654ms 3: wien6.v6.aco.net asymm 2 7. 57ms pmtu 1480 3: tu-637.sar1.Amsterdam1.Level3.net 46.557ms 4: tu-637.sar1.Amsterdam1.Level3.net asymm 3 46.167ms pmtu 1450 4: tu-618.sar1.Dallas1.Level3.net 179.218ms 5: tu-636.sar1.SanJose1.Level3.net 222.971ms 6: ISC.tu-616.sar1.SanJose1.Level3.net asymm 7 224.300ms 7: gig-2-0-0.r1.pao1.isc.org 225.536ms 8: int-0-0-0.r1.sjc3.isc.org 228.184ms 9: schein.debian.org 225.243ms reached Resume: pmtu 1450 hops 9 back 9 Maybe this helps ... You might also check if you can see us (e.g. debian.mur.at @ 2a02:3e0::14:80). Cheers, j. -- NCC09 - Netart Community Convention 2009 What the net! 23.11.09 - 29.11.09 Graz/Austria https://wiki.mur.at/ncc09/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091007/02ec3504/attachment.bin From fw at deneb.enyo.de Wed Oct 7 12:36:40 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 07 Oct 2009 10:36:40 +0000 Subject: Brekage due to Hurricane Electric/Internet2 In-Reply-To: (William F. Maton Sotomayor's message of "Tue, 6 Oct 2009 19:11:06 -0400 (EDT)") References: <87tyydy736.fsf@mid.deneb.enyo.de> Message-ID: <87hbubebif.fsf@mid.deneb.enyo.de> * William F. Maton Sotomayor: > On Mon, 5 Oct 2009, Florian Weimer wrote: > >> Debian has received a report about a partition affecting access to >> security.debian.org: >> >> > > +1 here. Coming from CANARIE-assigned address space the site is > unreachable. What is your source address? Can you reach 2001:8d8:2:1:6564:a62:0:2, for instance? > I suspect that global transit routes are being advertised to some > research networks but the traffic is getting tanked. Yes, this could be a routing leak. CANARIE should be able to resolve it. From fw at deneb.enyo.de Wed Oct 7 12:40:49 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 07 Oct 2009 10:40:49 +0000 Subject: Breakage due to Hurricane Electric/Internet2 In-Reply-To: <4ACC54F5.5060507@mur.at> (jogi@mur.at's message of "Wed, 07 Oct 2009 10:44:37 +0200") References: <87tyydy736.fsf@mid.deneb.enyo.de> <4ACC54F5.5060507@mur.at> Message-ID: <87vdircwr2.fsf_-_@mid.deneb.enyo.de> > Here it resolves to: > > 2001:a78::1a > > 1?: [LOCALHOST] pmtu 1500 > 1: v200-fe2-r1ko.mur.at 0.995ms > 2: wien6.v6.aco.net 6.454ms Are you located at a G?ANT downstream? Can you reach 2001:12f0:840:4092:204:acff:fe25:f5fb? From wmaton at ryouko.imsb.nrc.ca Wed Oct 7 14:34:58 2009 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Wed, 7 Oct 2009 08:34:58 -0400 (EDT) Subject: Brekage due to Hurricane Electric/Internet2 In-Reply-To: <87hbubebif.fsf@mid.deneb.enyo.de> References: <87tyydy736.fsf@mid.deneb.enyo.de> <87hbubebif.fsf@mid.deneb.enyo.de> Message-ID: >>> >> >> +1 here. Coming from CANARIE-assigned address space the site is >> unreachable. > > What is your source address? Can you reach 2001:8d8:2:1:6564:a62:0:2, > for instance? We have address space from CAANRIE's network, so naturally it is the reasearch network. However, some blocks allocated under that space also have access to the global IPv6 network so those folks don't have a problem reaching things. The ones that don't get in trouble: stats 1219# traceroute 2001:8d8:2:1:6564:a62:0:2 traceroute to 2001:8d8:2:1:6564:a62:0:2 (2001:8d8:2:1:6564:a62:0:2), 30 hops max, 40 byte packets 1 olans.core.ottix.net (2001:410:90ff::1) 0.710 ms 0.788 ms 0.880 ms 2 border2.core.ottix.net (2001:478:235::7) 0.488 ms 0.482 ms 0.468 ms 3 canet5.gigafed.net (2001:478:149::13) 13.182 ms 13.664 ms 14.148 ms 4 2001:410:101:30::2 (2001:410:101:30::2) 70.721 ms 70.832 ms 71.430 ms 5 2001:320:1b00:1::1 (2001:320:1b00:1::1) 185.465 ms 185.575 ms 185.690 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 linx.bb-c.the.lon.gb.oneandone.net (2001:7f8:4::2170:1) 685.270 ms 689.004 ms 695.486 ms 13 te-1-2.bb-c.nkf.ams.nl.oneandone.net (2001:8d8:0:2::6) 699.094 ms 708.692 ms 711.432 ms 14 te-4-1.bb-c.act.fra.de.oneandone.net (2001:8d8:0:2::a) 719.148 ms 722.634 ms 725.365 ms 15 te-3-3.bb-c.bs.kae.de.oneandone.net (2001:8d8:0:2::2a) 1026.029 ms te-1-3.bb-c.bs.kae.de.oneandone.net (2001:8d8:0:2::12) 1016.646 ms te-3-3.bb-c.bs.kae.de.oneandone.net (2001:8d8:0:2::2a) 730.999 ms 16 ae-1.gw-dists-b.bs.ka.oneandone.net (2001:8d8:0:4::11) 731.097 ms ae-2.gw-dists-b.bs.ka.oneandone.net (2001:8d8:0:5::11) 731.451 ms ae-1.gw-dists-b.bs.ka.oneandone.net (2001:8d8:0:4::11) 731.185 ms 17 wieck.debian.org (2001:8d8:2:1:6564:a62:0:2) 727.989 ms 721.742 ms 718.61 9 ms Interesting. Today it's working. >> I suspect that global transit routes are being advertised to some >> research networks but the traffic is getting tanked. > > Yes, this could be a routing leak. CANARIE should be able to resolve > it. They are talking to KREONet who apparently is announcing those routes. The above traceroute might be a fix in progress. wfms From jogi at mur.at Wed Oct 7 15:01:34 2009 From: jogi at mur.at (Jogi) Date: Wed, 07 Oct 2009 15:01:34 +0200 Subject: Breakage due to Hurricane Electric/Internet2 In-Reply-To: <87vdircwr2.fsf_-_@mid.deneb.enyo.de> References: <87tyydy736.fsf@mid.deneb.enyo.de> <4ACC54F5.5060507@mur.at> <87vdircwr2.fsf_-_@mid.deneb.enyo.de> Message-ID: <4ACC912E.7040409@mur.at> Hi, Florian Weimer schrieb: > Are you located at a G?ANT downstream? Can you reach > 2001:12f0:840:4092:204:acff:fe25:f5fb? had to do a traceroute6 -I but: 1 v201-fe2-r1ko.mur.at (2a02:3e0:1::1) 0.364 ms 0.321 ms 0.331 ms 2 wien6.v6.aco.net (2001:628::1) 4.284 ms 4.434 ms 4.426 ms 3 aconet.rt1.vie.at.geant2.net (2001:798:10:10dd::1) 49.511 ms 59.531 ms 59.532 ms 4 so-3-0-0.rt1.mil.it.geant2.net (2001:798:cc:1001:1e01::2) 50.693 ms 50.853 ms 50.850 ms 5 so-6-3-0.rt1.gen.ch.geant2.net (2001:798:cc:1201:1e01::1) 57.507 ms 2001:798:cc:1201:1e01::5 (2001:798:cc:1201:1e01::5) 58.781 ms so-6-3-0.rt1.gen.ch.geant2.net (2001:798:cc:1201:1e01::1) 57.528 ms 6 so-7-0-0.rt1.mad.es.geant2.net (2001:798:cc:1201:1701::2) 80.994 ms 80.373 ms 80.587 ms 7 * * * 8 * * * 9 2001:1348:1::2 (2001:1348:1::2) 412.170 ms 412.209 ms 406.535 ms 10 2001:12f0:0:fc::16 (2001:12f0:0:fc::16) 406.512 ms 405.716 ms 404.130 ms 11 2001:12f0:0:fc::21 (2001:12f0:0:fc::21) 396.135 ms 381.061 ms 382.529 ms 12 2001:12f0:0:3020::2 (2001:12f0:0:3020::2) 382.290 ms 416.656 ms 416.944 ms 13 2001:12f0:840:169::2 (2001:12f0:840:169::2) 416.563 ms 416.929 ms 416.879 ms 14 2001:12f0:840:4092:204:acff:fe25:f5fb (2001:12f0:840:4092:204:acff:fe25:f5fb) 416.870 ms 417.169 ms 417.170 ms Cheers, j. -- NCC09 - Netart Community Convention 2009 What the net! 23.11.09 - 29.11.09 Graz/Austria https://wiki.mur.at/ncc09/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091007/f105408f/attachment.bin From jabley at hopcount.ca Thu Oct 8 18:47:34 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 8 Oct 2009 17:47:34 +0100 Subject: Brekage due to Hurricane Electric/Internet2 In-Reply-To: References: <87tyydy736.fsf@mid.deneb.enyo.de> Message-ID: On 2009-10-07, at 00:11, William F. Maton Sotomayor wrote: > On Mon, 5 Oct 2009, Florian Weimer wrote: > >> Debian has received a report about a partition affecting access to >> security.debian.org: >> >> > > +1 here. Coming from CANARIE-assigned address space the site is > unreachable. I suspect that global transit routes are being > advertised to some research networks but the traffic is getting > tanked. For example, security.debian.org resolves to > 2001:4f8:8:36::6, but can't reach it: Note that this debian server is hosted by ISC. If you're trying to debug, it may be easiest and best to contact their netops staff at noc at isc.org rather than trying to funnel the reports through debian volunteers. Joe From wouter at widexs.nl Thu Oct 15 12:32:53 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Thu, 15 Oct 2009 12:32:53 +0200 Subject: Hosting provider allocation advice Message-ID: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> Hi, We're a Hosting provider and basicly we have (for now) 3 different product-groups we want to launch IPv6 on. 1 - Shared Hosting These servers (Linux), are all in 1 vlan. Each server has 1 IPv4 address from the subnet that's configured on the vlan. Then we have an IPv4 /24 routed to each of the servers (each server has 1 /24 to host sites on). Here I'd assign a single /64 and use static addressing. And perhaps additionaly take this single /64 and divide it up like IPv4 : One subnet (/112?) for the 'main' server IPv6 addresses, and route a /112 per server to the main IPv6 address. 2 - Premium Managed & Unmanaged Hosting (Co-location). Each customer has one (or more) dedicated subnets and vlans. Here I'd assign a /64 per vlan. I'd do static addressing for Managed, but probably provide RA (EUI-64) for Unmanaged. 3 - Managed and Umanaged Hosting (Co-location). These servers are in 'shared' subnets, ranging from /23 to /26, and each customer get's assigned at least 1 IP from this subnet and more if they can justify. For customers needing 'large' subnets, we'd route a different subnet to their server of choice. Here, I'm not sure what to do... You should at least assign a /64 per customer, but how would one do that when they are in shared subnets/vlans... ? If for every server I'd need to assign a /64 secondary to our vlan interfaces, I'd trip the maximums (Nortel Passport 8600 used for these customers has quite some limitations on IPv6). It would be nice though, cause once IPv4 is no longer used (...) we could move customers to another/dedicated vlan. We've also fiddled with the idea of assigning one /48 to each of these vlans, and let each 'server' use a /64 out of it. This still seems a bit weird though... Also, since we do IP based billing here, we'd never know if one has 'hijacked' some IP space. Yes, we'd know for un-assigned addresses (not assigned but has traffic -> alert), but I don't expect a customer to use all addresses out of 'their' /64, so the not used addresses could be easily be abused. For IPv4, all addresses are usually really used and the customer who's IP's are hijacked, would almost definitely hang on the phone in no-time. Some advice would be very appreciated, cause I'm banging my head against the wall to find the best options and then we're ready to roll. We already provide it to some customers on a 'beta' request basis, but we would like to setup a good policy and then provide all customers with IPv6 by default as well. Many thanks & best regards, Wouter de Jong WideXS From gert at space.net Thu Oct 15 13:15:49 2009 From: gert at space.net (Gert Doering) Date: Thu, 15 Oct 2009 13:15:49 +0200 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> Message-ID: <20091015111549.GB32226@Space.Net> Hi, On Thu, Oct 15, 2009 at 12:32:53PM +0200, Wouter de Jong wrote: > You should at least assign a /64 per customer, but how would one do that > when they are in shared subnets/vlans... ? "unshare the VLAN"...? (Which might not be possible if the number of customers is too high...) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tedm at ipinc.net Thu Oct 15 15:57:54 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 15 Oct 2009 06:57:54 -0700 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> Message-ID: <4AD72A62.80806@ipinc.net> Wouter de Jong wrote: > Hi, > > We're a Hosting provider and basicly we have (for now) > 3 different product-groups we want to launch IPv6 on. > > > 1 - Shared Hosting > These servers (Linux), are all in 1 vlan. > Each server has 1 IPv4 address from the subnet that's configured on the > vlan. > Then we have an IPv4 /24 routed to each of the servers > (each server has 1 /24 to host sites on). > > Here I'd assign a single /64 and use static addressing. > And perhaps additionaly take this single /64 and divide it up like IPv4 > : > One subnet (/112?) for the 'main' server IPv6 addresses, > and route a /112 per server to the main IPv6 address. > > > 2 - Premium Managed & Unmanaged Hosting (Co-location). > Each customer has one (or more) dedicated subnets and vlans. > > Here I'd assign a /64 per vlan. > I'd do static addressing for Managed, but probably provide > RA (EUI-64) for Unmanaged. > > > 3 - Managed and Umanaged Hosting (Co-location). > These servers are in 'shared' subnets, ranging from /23 to /26, > and each customer get's assigned at least 1 IP from this subnet > and more if they can justify. For customers needing 'large' subnets, > we'd route a different subnet to their server of choice. > > Here, I'm not sure what to do... > > > You should at least assign a /64 per customer, but how would one do that > > when they are in shared subnets/vlans... ? > > If for every server I'd need to assign a /64 secondary to our vlan > interfaces, > I'd trip the maximums > (Nortel Passport 8600 used for these customers has quite some > limitations on IPv6). > It would be nice though, cause once IPv4 is no longer used (...) we > could > move customers to another/dedicated vlan. > > We've also fiddled with the idea of assigning one /48 to each of these > vlans, > and let each 'server' use a /64 out of it. This still seems a bit weird > though... > No it's not when you understand IPv6 You use DNS names, right? You can always renumber. > Also, since we do IP based billing here, > we'd never know if one has 'hijacked' some IP space. > "IP based billing" will be the first casualty of IPv6. There's a shortage of IPv4 which is why you can bill for each IPv4 number. There's no shortage of IPv6. Your competitors won't hesitate to spread around IPv6 numbers like peanut butter. Ted > Yes, we'd know for un-assigned addresses > (not assigned but has traffic -> alert), > but I don't expect a customer to use all addresses out of 'their' /64, > so the not used addresses could be easily be abused. > > For IPv4, all addresses are usually really used and the customer > who's IP's are hijacked, would almost definitely hang on the phone in > no-time. > > > Some advice would be very appreciated, cause I'm banging my head against > the > wall to find the best options and then we're ready to roll. > We already provide it to some customers on a 'beta' request basis, > but we would like to setup a good policy and then provide all customers > with IPv6 > by default as well. > > Many thanks & best regards, > > Wouter de Jong > WideXS > > From d.bay at rrbone-bb.net Thu Oct 15 16:04:12 2009 From: d.bay at rrbone-bb.net (Dominik Bay) Date: Thu, 15 Oct 2009 16:04:12 +0200 Subject: Hosting provider allocation advice In-Reply-To: <4AD72A62.80806@ipinc.net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> Message-ID: <4AD72BDC.90307@rrbone-bb.net> Ted Mittelstaedt schrieb: > Wouter de Jong wrote: [snip] >> Also, since we do IP based billing here, we'd never know if one has >> 'hijacked' some IP space. >> > > "IP based billing" will be the first casualty of IPv6. > > There's a shortage of IPv4 which is why you can bill for > each IPv4 number. > > There's no shortage of IPv6. Your competitors won't hesitate > to spread around IPv6 numbers like peanut butter. I read it like "We do IP-based Traffic Accounting" and not as "Our Customers pay per IP on their box". Kind regards, Dominik From wouter at widexs.nl Thu Oct 15 16:05:45 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Thu, 15 Oct 2009 16:05:45 +0200 Subject: Hosting provider allocation advice In-Reply-To: <20091015111549.GB32226@Space.Net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <20091015111549.GB32226@Space.Net> Message-ID: <87458E9581E41E4F8FFD60620074085604581123@mail01.widexs.local> Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert at space.net] > Sent: Thursday, October 15, 2009 13:16 > To: Wouter de Jong > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: Hosting provider allocation advice > > > You should at least assign a /64 per customer, but how would one do > that > > when they are in shared subnets/vlans... ? > > "unshare the VLAN"...? > > (Which might not be possible if the number of customers is too high...) Well, if each customer would have it's own subnet... yes, we would be able to do that. However, they don't... they share IP's out of the same /23 - /26's. It would also give us way more then 1024 vlan's, which could potentially lead to problems with our access-layer (max 255 vlans per stack). Private vlans might be an option to bypass that one, but I think that imposes a lot of other trouble, and I'm almost certain that our access-layer doesn't support it. > Gert Doering Thanks & regards, Wouter From michael.dillon at bt.com Thu Oct 15 16:11:53 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 15 Oct 2009 15:11:53 +0100 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> Message-ID: <28E139F46D45AF49A31950F88C497458039D566A@E03MVZ2-UKDY.domain1.systemhost.net> Rather than add IPv6 to existing services or convert each existing service to an IPv6 version, I would rethink it from the ground up. To start with, it seems that a shared service would be good enough for most people since very few are pumping enough traffic to require a dedicated server or dedicated VLAN. That could be done on one /64. You would never need any more addresses for this no matter how large your data center grows. Of course, you might want to offer different classes of shared service with separate /64s, i.e. one in which porn hosting is acceptable and one in which it is not. Also a class of shared hosting that allows email servers to use port 25. That way there will be less issues with shared fate from others using the same /64. When you get to the point where people want to do multiple website hosting on a single dedicated server, then perhaps a /64 per server would be right since it means that they do not share fate with the same subnet prefix as the spammer next door. This also fits the model of renting a dedicated server to someone who then runs VM software and builds an entire network of virtual machines on their server. For people who have multiple physical servers, again one /64 per customer VLAN. Please avoid ever using a prefix longer than /64 because a) you don't need to, b) nobody will ever thank you for saving a few addresses, c) it will cost you more in complexity, and d) any customers on such long prefixes will share fate with everyone else in the /64. The outside world will always assume that multiple addresses from the same /64 are the responsibility of one customer. For your own internal use (monitoring systems etc.) use a ULA block. And don't be afraid to allocate more /64s than you had planned, if it makes your life easier in some way. If you approach IPv6 as a new and separate service/network from the existing stuff, perhaps you can simplify things by wasting/spending some of those lovely addresses that you have received. --Michael Dillon From wouter at widexs.nl Thu Oct 15 16:12:27 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Thu, 15 Oct 2009 16:12:27 +0200 Subject: Hosting provider allocation advice In-Reply-To: <4AD72A62.80806@ipinc.net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> Message-ID: <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> Hi Ted, > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Thursday, October 15, 2009 15:58 > To: Wouter de Jong > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: Hosting provider allocation advice > > We've also fiddled with the idea of assigning one /48 to each of > these > > vlans, > > and let each 'server' use a /64 out of it. This still seems a bit > weird > > though... > > > > No it's not when you understand IPv6 > > You use DNS names, right? You can always renumber. I'm not really sure I understand what you mean, could you clarify a bit perhaps ? > > Also, since we do IP based billing here, > > we'd never know if one has 'hijacked' some IP space. > > > > "IP based billing" will be the first casualty of IPv6. > > There's a shortage of IPv4 which is why you can bill for > each IPv4 number. > > There's no shortage of IPv6. Your competitors won't hesitate > to spread around IPv6 numbers like peanut butter. I meant traffic billing based on IP number :) > > Ted Regards, Wouter From michael.dillon at bt.com Thu Oct 15 16:14:29 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 15 Oct 2009 15:14:29 +0100 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD60620074085604581123@mail01.widexs.local> Message-ID: <28E139F46D45AF49A31950F88C497458039D5684@E03MVZ2-UKDY.domain1.systemhost.net> > lead to problems with our access-layer (max 255 vlans per stack). > Private vlans might be an option to bypass that one, but I > think that imposes a lot of other trouble, and I'm almost > certain that our access-layer doesn't support it. It sounds like you need to look for opportunities to do aggregation at a higher level, i.e. one /60 block (or /56) to one area of the network. --Michael Dillon From wouter at widexs.nl Thu Oct 15 16:48:50 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Thu, 15 Oct 2009 16:48:50 +0200 Subject: Hosting provider allocation advice In-Reply-To: <4AD72BDC.90307@rrbone-bb.net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local><4AD72A62.80806@ipinc.net> <4AD72BDC.90307@rrbone-bb.net> Message-ID: <87458E9581E41E4F8FFD60620074085604581129@mail01.widexs.local> Hi Dominik, > -----Original Message----- > From: ipv6-ops-bounces+wouter=widexs.nl at lists.cluenet.de [mailto:ipv6- > ops-bounces+wouter=widexs.nl at lists.cluenet.de] On Behalf Of Dominik Bay > Sent: Thursday, October 15, 2009 16:04 > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: Hosting provider allocation advice > > I read it like "We do IP-based Traffic Accounting" and not as "Our > Customers pay per IP on their box". Exactly :) > Kind regards, > Dominik Regards, Wouter From wouter at widexs.nl Thu Oct 15 17:09:17 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Thu, 15 Oct 2009 17:09:17 +0200 Subject: Hosting provider allocation advice In-Reply-To: <28E139F46D45AF49A31950F88C497458039D5684@E03MVZ2-UKDY.domain1.systemhost.net> References: <87458E9581E41E4F8FFD60620074085604581123@mail01.widexs.local> <28E139F46D45AF49A31950F88C497458039D5684@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <87458E9581E41E4F8FFD6062007408560458112B@mail01.widexs.local> Hi Michael, > -----Original Message----- > From: ipv6-ops-bounces+wouter=widexs.nl at lists.cluenet.de [mailto:ipv6- > ops-bounces+wouter=widexs.nl at lists.cluenet.de] On Behalf Of > michael.dillon at bt.com > Sent: Thursday, October 15, 2009 16:14 > To: ipv6-ops at lists.cluenet.de > Subject: RE: Hosting provider allocation advice > > > lead to problems with our access-layer (max 255 vlans per stack). > > Private vlans might be an option to bypass that one, but I > > think that imposes a lot of other trouble, and I'm almost > > certain that our access-layer doesn't support it. > > It sounds like you need to look for opportunities to do aggregation at > a > higher level, i.e. one /60 block (or /56) to one area of the network. With access-layer switches I refer to the switches where our customers servers are directly connected to. Those are only L2 capable, so the L3 (per vlan) is done on the core-switch in this case. > --Michael Dillon Regards, Wouter From tedm at ipinc.net Thu Oct 15 17:16:08 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 15 Oct 2009 08:16:08 -0700 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> Message-ID: <4AD73CB8.3090600@ipinc.net> Wouter de Jong wrote: > Hi Ted, > >> -----Original Message----- >> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] >> Sent: Thursday, October 15, 2009 15:58 >> To: Wouter de Jong >> Cc: ipv6-ops at lists.cluenet.de >> Subject: Re: Hosting provider allocation advice > > >>> We've also fiddled with the idea of assigning one /48 to each of >> these >>> vlans, >>> and let each 'server' use a /64 out of it. This still seems a bit >> weird >>> though... >>> >> No it's not when you understand IPv6 >> >> You use DNS names, right? You can always renumber. > > I'm not really sure I understand what you mean, > could you clarify a bit perhaps ? > What I was meaning is don't be too hung up about making the wrong decision about allocating subnets right now. If you force reliance on DNS from the absolute beginning then if you need to renumber later to reallocate your subnets, it's no big deal. Buried in the fine print of our own shared web hosting contracts is language that states the customer's server is never guaranteed to keep a specific IP address. Granted, few customers READ the fine print, but we make every effort when setting them up to not mention IP addresses >>> Also, since we do IP based billing here, >>> we'd never know if one has 'hijacked' some IP space. >>> >> "IP based billing" will be the first casualty of IPv6. >> >> There's a shortage of IPv4 which is why you can bill for >> each IPv4 number. >> >> There's no shortage of IPv6. Your competitors won't hesitate >> to spread around IPv6 numbers like peanut butter. > > I meant traffic billing based on IP number :) > Doctor it hurts when I do this! Then don't do that! Seriously, you need to rethink your billing data collection. How difficult is it to go to your router that's feeding your network and setup a permit access list and count packets that pass through it? Construct the list with whatever granularity you want. Ted >> Ted > > Regards, > > Wouter > From wouter at widexs.nl Thu Oct 15 17:36:09 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Thu, 15 Oct 2009 17:36:09 +0200 Subject: Hosting provider allocation advice In-Reply-To: <4AD73CB8.3090600@ipinc.net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> <4AD73CB8.3090600@ipinc.net> Message-ID: <87458E9581E41E4F8FFD6062007408560458112E@mail01.widexs.local> Hi Ted, > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Thursday, October 15, 2009 17:16 > To: Wouter de Jong > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: Hosting provider allocation advice Thanks for explaning :) > What I was meaning is don't be too hung up about making the > wrong decision about allocating subnets right now. If you force > reliance on DNS from the absolute beginning then if you need to > renumber later to reallocate your subnets, it's no big deal. (most) Firewalls, ACL's, RBL's ... like IP's instead of hostnames. So that could be a bummer. Especially if a customer would manage a lot of remote networks from his server in our DC. > Buried in the fine print of our own shared web hosting contracts > is language that states the customer's server is never guaranteed > to keep a specific IP address. While this makes perfectly sense from 'our' side of the view, a lot of our customers would leave us instantly. They'd have to change IP's their anyway, but that won't stop them. We've done it in the past, and they we're not amused. I'd never get approval for it from $management, in these times they want to keep every client at all (reasonable) cost. > Granted, few customers READ the fine print, but we make every > effort when setting them up to not mention IP addresses > > >>> Also, since we do IP based billing here, > >>> we'd never know if one has 'hijacked' some IP space. > >>> > >> "IP based billing" will be the first casualty of IPv6. > >> > >> There's a shortage of IPv4 which is why you can bill for > >> each IPv4 number. > >> > >> There's no shortage of IPv6. Your competitors won't hesitate > >> to spread around IPv6 numbers like peanut butter. > > > > I meant traffic billing based on IP number :) > > > > Doctor it hurts when I do this! > > Then don't do that! > > Seriously, you need to rethink your billing data collection. How > difficult is it to go to your router that's feeding your network and > setup a permit access list and count packets that pass through it? > Construct the list with whatever granularity you want. It can be hard, cause your device must support it :)) We've put a fiber-tap between our fibers to our border routers, and run an accounting program that fills a database with src dst traffic insert-date. So internal traffic from vlan <-> vlan is for free, but traffic that goes to our Peerings/Transit, get's billed. Though with IPv6, it'll get a lot more records :) But I'm least worried about that. I'd rather implement a good policy, and solve my billing later on. The thing that frustrates me is that I just don't know how to give our our 3rd product group (the ones with shared vlan/subnet) IPv6 in a sane way. > Ted Regards, Wouter From jay at impulse.net Thu Oct 15 18:42:30 2009 From: jay at impulse.net (Jay Hennigan) Date: Thu, 15 Oct 2009 09:42:30 -0700 Subject: Hosting provider allocation advice In-Reply-To: <4AD72BDC.90307@rrbone-bb.net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <4AD72BDC.90307@rrbone-bb.net> Message-ID: <4AD750F6.6000407@impulse.net> Dominik Bay wrote: > I read it like "We do IP-based Traffic Accounting" and not as "Our > Customers pay per IP on their box". That's better than "Our Customers pay or IP on their box". -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From gert at space.net Thu Oct 15 19:56:44 2009 From: gert at space.net (Gert Doering) Date: Thu, 15 Oct 2009 19:56:44 +0200 Subject: Hosting provider allocation advice In-Reply-To: <28E139F46D45AF49A31950F88C497458039D566A@E03MVZ2-UKDY.domain1.systemhost.net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <28E139F46D45AF49A31950F88C497458039D566A@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20091015175644.GI32226@Space.Net> Hi, On Thu, Oct 15, 2009 at 03:11:53PM +0100, michael.dillon at bt.com wrote: > To start with, it seems that a shared service would be good enough for > most people since very few are pumping enough traffic to require a > dedicated server or dedicated VLAN. That could be done on one /64. The fundamental problem with shared service (as defined in: one shared layer 2 network, multiple machines, real or VM, admin'ned by different persons) is security. You see abuse coming from one specific IPv6 address - which machine is using it? (Worse: you get complaints about abuse that happened yesterday, from one specific IPv6 address, but that address is no longer visible anywhere and has never been officially assigned to any of these servers...) "One VLAN per customer" (+uRPF) nicely solves that part, but indeed brings up some other problems (number of VLANs, etc.). This is the way we decided to do that. "Static neighbour configuration plus lots of L2 security" also helps, but not all necessary gear is available yet. This is the way some of the big "WeHostMillions" providers need to take. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Thu Oct 15 19:59:20 2009 From: gert at space.net (Gert Doering) Date: Thu, 15 Oct 2009 19:59:20 +0200 Subject: Hosting provider allocation advice In-Reply-To: <4AD73CB8.3090600@ipinc.net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> <4AD73CB8.3090600@ipinc.net> Message-ID: <20091015175920.GJ32226@Space.Net> Hi, On Thu, Oct 15, 2009 at 08:16:08AM -0700, Ted Mittelstaedt wrote: > Seriously, you need to rethink your billing data collection. How > difficult is it to go to your router that's feeding your network and > setup a permit access list and count packets that pass through it? > Construct the list with whatever granularity you want. So this is not "ip based billing"? And how exactly does this protect against customer A bluntly using IPv6 addresses that belong to customer B, but are carried in the same layer 2 segment? (private VLANs + static MAC assignment + port security + static ND + L3 ACLs on L2 switch port can fix this to some extent, but it's messy) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From berni at birkenwald.de Thu Oct 15 20:04:13 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Thu, 15 Oct 2009 20:04:13 +0200 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> Message-ID: <20091015180413.GA18775@schleppi.birkenwald.de> On Thu, Oct 15, 2009 at 12:32:53PM +0200, Wouter de Jong wrote: Hi, > 3 - Managed and Umanaged Hosting (Co-location). > These servers are in 'shared' subnets, ranging from /23 to /26, > and each customer get's assigned at least 1 IP from this subnet > and more if they can justify. For customers needing 'large' subnets, > we'd route a different subnet to their server of choice. > > Here, I'm not sure what to do... > > You should at least assign a /64 per customer, but how would one do that > when they are in shared subnets/vlans... ? As Gert already said, "unshare that VLAN". If this is not possible, I (probably not the only one) thought of the following approach that at least one company is using already: a) do not use global addresses on the transport VLAN at all b) assign a /64 or /48 per customer, route it to their link-local address customer configuration won't change, they can still statically configure their own prefix on their ethernet port and learn the default gateway from RA (or set a static route, but that needs a link-local next-hop as well). c) (optional) set a static neighbor entry for the LL addr to their MAC d) (optional) set port security to only allow the MAC on their port e) (optional) enable private VLAN This solves a number of spoofing issues (attackers in the same VLAN cannot redirect traffic to the customer by spoofing ND and thus cannot spoof TCP) and is compatible with private VLAN. However, attackers can still send packets from the wrong source address, so any address based billing is suspectible to attack. Fixing that won't be possible without L2 infrastructure that can so some filtering (e.g. IPv6 ACL) per customer port. Bernhard From tedm at ipinc.net Thu Oct 15 21:01:57 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 15 Oct 2009 12:01:57 -0700 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD6062007408560458112E@mail01.widexs.local> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> <4AD73CB8.3090600@ipinc.net> <87458E9581E41E4F8FFD6062007408560458112E@mail01.widexs.local> Message-ID: <4AD771A5.7040908@ipinc.net> Wouter de Jong wrote: > Hi Ted, > >> -----Original Message----- >> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] >> Sent: Thursday, October 15, 2009 17:16 >> To: Wouter de Jong >> Cc: ipv6-ops at lists.cluenet.de >> Subject: Re: Hosting provider allocation advice > > Thanks for explaning :) > >> What I was meaning is don't be too hung up about making the >> wrong decision about allocating subnets right now. If you force >> reliance on DNS from the absolute beginning then if you need to >> renumber later to reallocate your subnets, it's no big deal. > > (most) Firewalls, ACL's, RBL's ... like IP's instead of hostnames. > So that could be a bummer. That's why you get paid the big bucks. Let me know when your mechanic starts complaining about how hard it is to fix cars. ;-) > Especially if a customer would manage a lot of remote networks > from his server in our DC. > If the customer is educated enough to know how to do that, they are educated enough to know that there's no IP permanence unless you request your numbers from an RIR. >> Buried in the fine print of our own shared web hosting contracts >> is language that states the customer's server is never guaranteed >> to keep a specific IP address. > > While this makes perfectly sense from 'our' side of the view, > a lot of our customers would leave us instantly. > They'd have to change IP's their anyway, but that won't stop them. > We've done it in the past, and they we're not amused. > I'd never get approval for it from $management, > in these times they want to keep every client at all (reasonable) cost. > Renumbering IPv4 is a lot more painful than renumbering IPv6. Your customers who want IPv6 from you aren't going to be among the subset of troglodyte customers you have that every ISP has to deal with. Keep in mind every other ISP offering IPv6 is going to be doing this initially. As long as you aren't renumbering the IPv4 they have from you, the few customers of yours who want IPv6 will be understanding. After all if they leave, where are they going to go to? Another hoster who doesn't even offer IPv6 at all? Or another hoster that only offers IPv6 with the same stipulations your offering - that IP#s may change? Highly unlikely. Think of how many IPv6 hosters out there aren't even running native, but using tunneled numbers from Hurricane or some such. You have time to play around with this stuff, don't cut yourself short. Ted >> Granted, few customers READ the fine print, but we make every >> effort when setting them up to not mention IP addresses >> >>>>> Also, since we do IP based billing here, >>>>> we'd never know if one has 'hijacked' some IP space. >>>>> >>>> "IP based billing" will be the first casualty of IPv6. >>>> >>>> There's a shortage of IPv4 which is why you can bill for >>>> each IPv4 number. >>>> >>>> There's no shortage of IPv6. Your competitors won't hesitate >>>> to spread around IPv6 numbers like peanut butter. >>> I meant traffic billing based on IP number :) >>> >> Doctor it hurts when I do this! >> >> Then don't do that! >> >> Seriously, you need to rethink your billing data collection. How >> difficult is it to go to your router that's feeding your network and >> setup a permit access list and count packets that pass through it? >> Construct the list with whatever granularity you want. > > It can be hard, cause your device must support it :)) > > We've put a fiber-tap between our fibers to our > border routers, and run an accounting program that fills a database with > > src dst traffic insert-date. So internal traffic from vlan <-> vlan is > for free, > but traffic that goes to our Peerings/Transit, get's billed. > > Though with IPv6, it'll get a lot more records :) > But I'm least worried about that. > I'd rather implement a good policy, and solve my billing later on. > > The thing that frustrates me is that I just don't know how to give our > our 3rd product group (the ones with shared vlan/subnet) IPv6 in a sane > way. > >> Ted > > Regards, > > Wouter > From tedm at ipinc.net Thu Oct 15 21:06:03 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 15 Oct 2009 12:06:03 -0700 Subject: Hosting provider allocation advice In-Reply-To: <20091015175920.GJ32226@Space.Net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> <4AD73CB8.3090600@ipinc.net> <20091015175920.GJ32226@Space.Net> Message-ID: <4AD7729B.5000805@ipinc.net> Gert Doering wrote: > Hi, > > On Thu, Oct 15, 2009 at 08:16:08AM -0700, Ted Mittelstaedt wrote: >> Seriously, you need to rethink your billing data collection. How >> difficult is it to go to your router that's feeding your network and >> setup a permit access list and count packets that pass through it? >> Construct the list with whatever granularity you want. > > So this is not "ip based billing"? > > And how exactly does this protect against customer A bluntly using > IPv6 addresses that belong to customer B, but are carried in the same > layer 2 segment? > He already said he's OK with that happening, because it causes customer B to call him, then he knows that this is happening. > (private VLANs + static MAC assignment + port security + static ND > + L3 ACLs on L2 switch port can fix this to some extent, but it's > messy) > I didn't want to launch into a discussion of how messed up I think his existing network was, for him to be using one customer stomping on another customer as a kind of early warning device. I just wanted to give him a possible bandaid to add to the bandaids he already has on the monster. At least he's looking at IPv6 - that's probably 1000% better than most of the hosters out there. Ted From alan.batie at peakinternet.com Thu Oct 15 21:07:13 2009 From: alan.batie at peakinternet.com (Alan Batie) Date: Thu, 15 Oct 2009 12:07:13 -0700 Subject: Hosting provider allocation advice In-Reply-To: <4AD771A5.7040908@ipinc.net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> <4AD73CB8.3090600@ipinc.net> <87458E9581E41E4F8FFD6062007408560458112E@mail01.widexs.local> <4AD771A5.7040908@ipinc.net> Message-ID: <4AD772E1.80709@peakinternet.com> Ted Mittelstaedt wrote: > Let me know when your mechanic starts complaining about how hard it > is to fix cars. ;-) Ask your mechanic about that sometime, particularly someone who's worked on 60's vintage cars vs post 70's cars... you'll likely get an earful :-) From tedm at ipinc.net Thu Oct 15 21:40:30 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 15 Oct 2009 12:40:30 -0700 Subject: Hosting provider allocation advice In-Reply-To: <4AD772E1.80709@peakinternet.com> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> <4AD73CB8.3090600@ipinc.net> <87458E9581E41E4F8FFD6062007408560458112E@mail01.widexs.local> <4AD771A5.7040908@ipinc.net> <4AD772E1.80709@peakinternet.com> Message-ID: <4AD77AAE.2060308@ipinc.net> Alan Batie wrote: > Ted Mittelstaedt wrote: > >> Let me know when your mechanic starts complaining about how hard it >> is to fix cars. ;-) > > Ask your mechanic about that sometime, particularly someone who's worked > on 60's vintage cars vs post 70's cars... you'll likely get an earful :-) Heh I do all my own wrenching on my own vehicles. The only thing I don't do is subassemby rebuilds since those take a lot of expensive specialized tools, and it's almost always cheaper to get a used engine/transmission/diff/ac compressor/etc. than rebuild one. I own a 68 Torino, and a couple 95 minivans with EFI and computer-controlled transmissions and engines. The minivans are no more difficult to work on. The only difference is the troubleshooting techniques and tools. It IS a lot harder to fix a modern vehicle with 60's era tools and techniques. But 90's techniques are not hard to learn and although the tooling is more expensive, it's still cheaper than paying someone to do it. (besides the fact that I know the procedure has been done properly, some of the stuff I've seen in used vehicles I've bought over the years would make you faint) Actually, though, the point I was making earlier is that most mechanics don't generally waste a lot of time complaining to customers - they are more than happy to get the newer vehicles because the repair times are so much longer on them (due to the tight quarters making it necessary to practically take the entire vehicle apart to get at what's broken) and the longer the repair time, the more profitable. Presumably, the OP is wanting to offer IPv6 so as to be able to charge extra for it, save money with it, or attract more customers with it (thus making money) - this is a business after all - thus he should welcome the added complexity (you can charge more money for it). Ted From gdolley at arpnetworks.com Fri Oct 16 01:35:25 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Thu, 15 Oct 2009 16:35:25 -0700 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD6062007408560458112E@mail01.widexs.local> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> <4AD73CB8.3090600@ipinc.net> <87458E9581E41E4F8FFD6062007408560458112E@mail01.widexs.local> Message-ID: <20091015233525.GD28658@garry-thinkpad.arpnetworks.com> On Thu, Oct 15, 2009 at 05:36:09PM +0200, Wouter de Jong wrote: > It can be hard, cause your device must support it :)) > > We've put a fiber-tap between our fibers to our > border routers, and run an accounting program that fills a database with > > src dst traffic insert-date. So internal traffic from vlan <-> vlan is > for free, > but traffic that goes to our Peerings/Transit, get's billed. Man, you guys are sure doing it the hard way ;) Why not just monitor customer interfaces, whether it be VLANs, physical ports on routers/switches, even *nix boxes, pop the data in Cacti / RRD, and write some scripts to report 95th percentile and/or total data transfer? Cacti already has templates for both of these methods. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From nuno.vieira at nfsi.pt Fri Oct 16 01:47:56 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi) Date: Fri, 16 Oct 2009 00:47:56 +0100 (WEST) Subject: Hosting provider allocation advice In-Reply-To: <20091015233525.GD28658@garry-thinkpad.arpnetworks.com> Message-ID: <429005223.12571255650476599.JavaMail.root@zimbra.nfsi.pt> Hi Garry, I'd love to do that on my XMR's ve interfaces, if i could. What solutions do you guys use out there to read ve / vlan counters on Foundry XMR switches ? cheers, --- Nuno Vieira nfsi telecom, lda. [Email] nuno.vieira at nfsi.pt [Phone] +351 21 114 2315 [Phone] +351 21 142 2300 [Mobile] +351 91 925 5561 [Fax] +351 21 114 2301 [Web] http://www.nfsi.pt/ ----- Original Message ----- From: "Garry Dolley" To: "Wouter de Jong" Cc: ipv6-ops at lists.cluenet.de Sent: Friday, 16 October, 2009 12:35:25 AM Subject: Re: Hosting provider allocation advice On Thu, Oct 15, 2009 at 05:36:09PM +0200, Wouter de Jong wrote: > It can be hard, cause your device must support it :)) > > We've put a fiber-tap between our fibers to our > border routers, and run an accounting program that fills a database with > > src dst traffic insert-date. So internal traffic from vlan <-> vlan is > for free, > but traffic that goes to our Peerings/Transit, get's billed. Man, you guys are sure doing it the hard way ;) Why not just monitor customer interfaces, whether it be VLANs, physical ports on routers/switches, even *nix boxes, pop the data in Cacti / RRD, and write some scripts to report 95th percentile and/or total data transfer? Cacti already has templates for both of these methods. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From wouter at widexs.nl Fri Oct 16 11:24:58 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Fri, 16 Oct 2009 11:24:58 +0200 Subject: Hosting provider allocation advice In-Reply-To: <4AD77AAE.2060308@ipinc.net> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> <4AD73CB8.3090600@ipinc.net> <87458E9581E41E4F8FFD6062007408560458112E@mail01.widexs.local> <4AD771A5.7040908@ipinc.net><4AD772E1.80709@peakinternet.com> <4AD77AAE.2060308@ipinc.net> Message-ID: <87458E9581E41E4F8FFD6062007408560458114F@mail01.widexs.local> Hi Ted, > -----Original Message----- > From: ipv6-ops-bounces+wouter=widexs.nl at lists.cluenet.de [mailto:ipv6- > ops-bounces+wouter=widexs.nl at lists.cluenet.de] On Behalf Of Ted > Mittelstaedt > Sent: Thursday, October 15, 2009 21:41 > To: Alan Batie > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: Hosting provider allocation advice > Presumably, the OP is wanting to offer IPv6 so as to be able to > charge extra for it, save money with it, or attract more customers > with it (thus making money) - this is a business after all - thus > he should welcome the added complexity (you can charge more money > for it). We won't charge extra for IPv6, the primary intention for rolling out IPv6 is to be ready for IPv6-only connectivity once that becomes common. And ofcourse, that also has a commercial twist. 'Yes, we can deliver you IPv6 so you are fully reachble over IPv4 and/or IPv6.' :) > Ted Regards, Wouter From wouter at widexs.nl Fri Oct 16 11:30:32 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Fri, 16 Oct 2009 11:30:32 +0200 Subject: Hosting provider allocation advice In-Reply-To: <20091015233525.GD28658@garry-thinkpad.arpnetworks.com> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> <4AD73CB8.3090600@ipinc.net> <87458E9581E41E4F8FFD6062007408560458112E@mail01.widexs.local> <20091015233525.GD28658@garry-thinkpad.arpnetworks.com> Message-ID: <87458E9581E41E4F8FFD60620074085604581150@mail01.widexs.local> Hi Garry, > -----Original Message----- > From: Garry Dolley [mailto:gdolley at arpnetworks.com] > Sent: Friday, October 16, 2009 01:35 > To: Wouter de Jong > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: Hosting provider allocation advice > > Man, you guys are sure doing it the hard way ;) > > Why not just monitor customer interfaces, whether it be VLANs, > physical ports on routers/switches, even *nix boxes, pop the data in > Cacti / RRD, and write some scripts to report 95th percentile and/or > total data transfer? Cacti already has templates for both of these > methods. The main reason for this, is that we don't charge backup traffic or traffic between servers from a customer, because these can be in different vlans. And some other reasons I don't know the details of. I would be very happy with 95% based billing myself though. Regards, Wouter From benny+usenet at amorsen.dk Fri Oct 16 12:15:41 2009 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Fri, 16 Oct 2009 12:15:41 +0200 Subject: Hosting provider allocation advice In-Reply-To: <28E139F46D45AF49A31950F88C497458039D566A@E03MVZ2-UKDY.domain1.systemhost.net> (michael dillon's message of "Thu, 15 Oct 2009 15:11:53 +0100") References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <28E139F46D45AF49A31950F88C497458039D566A@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: writes: > Rather than add IPv6 to existing services or convert each existing > service to an IPv6 version, I would rethink it from the ground up. This is actually one of the few large problems with dual-stack: With IPv4 you're often forced to put a lot of hosts into one subnet, because the waste of 3 addresses per subnet potentially quadruples your IP address requirements. To make that work you use switch-based firewalls which make sure that the hosts on each port can only use the assigned IP addresses and only access other ports according to the security policy. With IPv4 DHCP you can even dynamically assign static addresses based on switchport number. This model is completely unnecessary in IPv6, and it is probably difficult to get the fancy switch-based firewalls to work for IPv6 anyway. Even if you succeed, you still have to do all the static allocation and address management for IPv6, because automatic addressing (or just letting the customer handle it, within their subnet) just doesn't work in this model. The obvious way to do this in IPv6 is to route in the firewall instead of switching. However, I haven't seen any device other than a modern Unix box which can choose switching or routing based on whether a packet is v4 or v6... In summary, shared hosting centers now need to run a cable for IPv4 and a cable for IPv6, and double the number of ports in their switches/routers. /Benny From wouter at widexs.nl Fri Oct 16 13:11:45 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Fri, 16 Oct 2009 13:11:45 +0200 Subject: Hosting provider allocation advice In-Reply-To: <20091015180413.GA18775@schleppi.birkenwald.de> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <20091015180413.GA18775@schleppi.birkenwald.de> Message-ID: <87458E9581E41E4F8FFD6062007408560458115B@mail01.widexs.local> Hi Bernhard, > -----Original Message----- > From: Bernhard Schmidt [mailto:berni at birkenwald.de] > Sent: Thursday, October 15, 2009 20:04 > To: Wouter de Jong > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: Hosting provider allocation advice > As Gert already said, "unshare that VLAN". > > If this is not possible, I (probably not the only one) thought of the > following approach that at least one company is using already: > > a) do not use global addresses on the transport VLAN at all > b) assign a /64 or /48 per customer, route it to their link-local > address > > customer configuration won't change, they can still statically > configure > their own prefix on their ethernet port and learn the default gateway > from RA (or set a static route, but that needs a link-local next-hop as > well). > > c) (optional) set a static neighbor entry for the LL addr to their MAC > d) (optional) set port security to only allow the MAC on their port > e) (optional) enable private VLAN This sounds reasonable at first look :) Our current equipment (for the shared vlan/subnet part) can handle 250 IPv6 interfaces, so that leaves about 240 customers vlans (which is also about the limit for our access-switches). We currently are at ~ 150. It can also handle only 2000 IPv6 static routes, but that should be enough for now. What holds me a bit back though is the use of link-local. This would indeed mean that our customers need to manually specify the link-local address of our router, but if we'd swap interfaces, our link-local would change. So RA comes indeed into the picture. However.... just as with DHCP, you'd need to ensure that only _our_ equipment can send RA ? This can't be enforced I think, without heavy support in your access-switches ? So if a server receives 20 RA's, which one does it pick ? Also, we don't have support for private vlans in our access-switches at the moment. (Yes, we probably need new equipment :>) <..> Best regards, Wouter From wouter at widexs.nl Fri Oct 16 13:43:04 2009 From: wouter at widexs.nl (Wouter de Jong) Date: Fri, 16 Oct 2009 13:43:04 +0200 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD6062007408560458115B@mail01.widexs.local> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local><20091015180413.GA18775@schleppi.birkenwald.de> <87458E9581E41E4F8FFD6062007408560458115B@mail01.widexs.local> Message-ID: <87458E9581E41E4F8FFD6062007408560458115E@mail01.widexs.local> Hi, > -----Original Message----- > From: ipv6-ops-bounces+wouter=widexs.nl at lists.cluenet.de [mailto:ipv6- > ops-bounces+wouter=widexs.nl at lists.cluenet.de] On Behalf Of Wouter de > Jong > Sent: Friday, October 16, 2009 13:12 > To: Bernhard Schmidt > Cc: ipv6-ops at lists.cluenet.de > Subject: RE: Hosting provider allocation advice <..> > What holds me a bit back though is the use of link-local. > This would indeed mean that our customers need to manually specify the > link-local address > of our router, but if we'd swap interfaces, our link-local would > change. > So RA comes indeed into the picture. > However.... just as with DHCP, you'd need to ensure that only _our_ > equipment can send RA ? > This can't be enforced I think, without heavy support in your > access-switches ? > So if a server receives 20 RA's, which one does it pick ? What if we would still assign a /64 per vlan, and assign each server a single IPv6 address out of that /64, but ALSO would route a /64 to each server (to that single IPv6 address) ? Then if people would use source-address binding (is Exchange capable of something like that ?), they'd just needed to bind their SMTP apps to an IP out of the routed /64 to not get into trouble with RBL's that filter on /64. We'd then still have abusers who could add an un-used IPv6 address from the /64, but at least not from the routed /64's. The same story we'd have with IPv4 at present. Best regards, Wouter From berni at birkenwald.de Fri Oct 16 14:23:39 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Fri, 16 Oct 2009 14:23:39 +0200 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD6062007408560458115B@mail01.widexs.local> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <20091015180413.GA18775@schleppi.birkenwald.de> <87458E9581E41E4F8FFD6062007408560458115B@mail01.widexs.local> Message-ID: <4AD865CB.3030400@birkenwald.de> Hi Wouter, > What holds me a bit back though is the use of link-local. It is done because of two things: * systems that don't have a global IPv6 prefix routed do not have a global address at all, thus they cannot speak outside * if you use private VLANs your customer boxes can only speak to each other using the router. Since there is no transfer network they won't see any (global) address as directly connected, using the router all the time. > This would indeed mean that our customers need to manually specify the > link-local address of our router, but if we'd swap interfaces, our > link-local would change. You can usually set the link-local address of the router to be something like FE80::1. With HSRPv6 this is even a necessity. You have to differentiate between two things here: * Traffic routed to the customer is sent to his link-local address, which should not change without an equipment change (changing MAC), which you hopefully have to know/record anyway (port security). * Traffic sent by your customer to your link-local address, which should probably be set to be device-independent > So RA comes indeed into the picture. > However.... just as with DHCP, you'd need to ensure that only _our_ > equipment can send RA ? > This can't be enforced I think, without heavy support in your > access-switches ? > So if a server receives 20 RA's, which one does it pick ? A random one. There are tools that can snoop into a VLAN and react on rogue RA by spoofing a matching one with timers set to 0, but that is only a band-aid. Totally regardless of how you manage your routing (to link-local or not), if your customers can send RA to each other you are just screwed. But if they can send traffic to each other you are an easy target for spoofing attacks anyway. So you are just having the very same security problems you already have with IPv4 with IPv6 as well. > Also, we don't have support for private vlans in our access-switches at > the moment. It breaks my hard to say this, but doing native IPv6 in a shared VLAN without any security features is very likely a very bad idea. You should consider tunneling the last hop if you cannot solve that. Can your equipment do MAC ACLs? You might be able to filter IPv6 frames sent to 33:33:00:00:00:01. At least unsolicited RAs won't get through this way, you probably have to do something about solicited RAs as well. > (Yes, we probably need new equipment :>) I'd say so, yes, but also for IPv4. Bernhard From berni at birkenwald.de Fri Oct 16 14:27:45 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Fri, 16 Oct 2009 14:27:45 +0200 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD6062007408560458115E@mail01.widexs.local> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local><20091015180413.GA18775@schleppi.birkenwald.de> <87458E9581E41E4F8FFD6062007408560458115B@mail01.widexs.local> <87458E9581E41E4F8FFD6062007408560458115E@mail01.widexs.local> Message-ID: <4AD866C1.80004@birkenwald.de> Hi, > What if we would still assign a /64 per vlan, > and assign each server a single IPv6 address out of that /64, > but ALSO would route a /64 to each server (to that single IPv6 address) > ? The drawbacks are: * incompatible with PVLAN, should you decide to implement those later * people can configure unused addresses from that /64 * source-address-selection will prefer the address from the transfer network Bernhard From thedarkone at list.ru Sun Oct 25 23:04:21 2009 From: thedarkone at list.ru (The Dark One) Date: Mon, 26 Oct 2009 01:04:21 +0300 Subject: =?koi8-r?Q?Re[2]=3A_Hosting_provider_allocation_advice?= In-Reply-To: <4AD866C1.80004@birkenwald.de> References: <4AD866C1.80004@birkenwald.de> Message-ID: talking about hosting provider, anybody knows one that can provide IPv6 hosting in Italy? TheDarkOne -----Original Message----- From: Bernhard Schmidt To: ipv6-ops at lists.cluenet.de Date: Fri, 16 Oct 2009 14:27:45 +0200 Subject: Re: Hosting provider allocation advice > Hi, > > > What if we would still assign a /64 per vlan, > > and assign each server a single IPv6 address out of that /64, > > but ALSO would route a /64 to each server (to that single IPv6 address) > > ? > > The drawbacks are: > * incompatible with PVLAN, should you decide to implement those later > * people can configure unused addresses from that /64 > * source-address-selection will prefer the address from the transfer network > > Bernhard > From gdolley at arpnetworks.com Mon Oct 26 07:58:18 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Sun, 25 Oct 2009 23:58:18 -0700 Subject: Hosting provider allocation advice In-Reply-To: <429005223.12571255650476599.JavaMail.root@zimbra.nfsi.pt> References: <20091015233525.GD28658@garry-thinkpad.arpnetworks.com> <429005223.12571255650476599.JavaMail.root@zimbra.nfsi.pt> Message-ID: <20091026065818.GC32218@garry-thinkpad.arpnetworks.com> On Fri, Oct 16, 2009 at 12:47:56AM +0100, Nuno Vieira - nfsi wrote: > Hi Garry, > > I'd love to do that on my XMR's ve interfaces, if i could. > > What solutions do you guys use out there to read ve / vlan counters on Foundry XMR switches ? So the Foundry XMR switches don't report traffic of "ve" (vlan) interfaces over SNMP? -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Mon Oct 26 08:02:35 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Mon, 26 Oct 2009 00:02:35 -0700 Subject: Hosting provider allocation advice In-Reply-To: <87458E9581E41E4F8FFD6062007408560458114F@mail01.widexs.local> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <4AD72A62.80806@ipinc.net> <87458E9581E41E4F8FFD60620074085604581124@mail01.widexs.local> <4AD73CB8.3090600@ipinc.net> <87458E9581E41E4F8FFD6062007408560458112E@mail01.widexs.local> <4AD77AAE.2060308@ipinc.net> <87458E9581E41E4F8FFD6062007408560458114F@mail01.widexs.local> Message-ID: <20091026070235.GD32218@garry-thinkpad.arpnetworks.com> On Fri, Oct 16, 2009 at 11:24:58AM +0200, Wouter de Jong wrote: > Hi Ted, > > > -----Original Message----- > > From: ipv6-ops-bounces+wouter=widexs.nl at lists.cluenet.de [mailto:ipv6- > > ops-bounces+wouter=widexs.nl at lists.cluenet.de] On Behalf Of Ted > > Mittelstaedt > > Sent: Thursday, October 15, 2009 21:41 > > To: Alan Batie > > Cc: ipv6-ops at lists.cluenet.de > > Subject: Re: Hosting provider allocation advice > > > > Presumably, the OP is wanting to offer IPv6 so as to be able to > > charge extra for it, save money with it, or attract more customers > > with it (thus making money) - this is a business after all - thus > > he should welcome the added complexity (you can charge more money > > for it). > > We won't charge extra for IPv6, the primary intention for rolling > out IPv6 is to be ready for IPv6-only connectivity once that > becomes common. And ofcourse, that also has a commercial twist. > 'Yes, we can deliver you IPv6 so you are fully reachble over IPv4 and/or > IPv6.' At this point, my IPv6 is actually free. We don't graph the interfaces of our IPv6 router yet, and even if I did, I don't want the headache of separate IPv4 and IPv6 graphs (so I'd need to find a way to merge them somehow, which is probably not too hard with rrdtool, yet I have bigger fish to fry). Charging "extra" was never in my thinking, since I'd like to help IPv6 adoption. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From gdolley at arpnetworks.com Mon Oct 26 08:32:56 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Mon, 26 Oct 2009 00:32:56 -0700 Subject: Hosting provider allocation advice In-Reply-To: <4AD865CB.3030400@birkenwald.de> References: <87458E9581E41E4F8FFD606200740856045810FB@mail01.widexs.local> <20091015180413.GA18775@schleppi.birkenwald.de> <87458E9581E41E4F8FFD6062007408560458115B@mail01.widexs.local> <4AD865CB.3030400@birkenwald.de> Message-ID: <20091026073256.GE32218@garry-thinkpad.arpnetworks.com> On Fri, Oct 16, 2009 at 02:23:39PM +0200, Bernhard Schmidt wrote: > * if you use private VLANs your customer boxes can only speak to each other > using the router. Since there is no transfer network they won't see any > (global) address as directly connected, using the router all the time. If you route a prefix (say /48) to their LL, can't the customer then configure their own /56, /64, etc... on their equipment and then the equipment would talk to each other directly, not going through the router? If each piece of gear was on its own VLAN, then yes, I would see how they all have to talk through the router, but I don't think anyone would set up something like that ;) > You can usually set the link-local address of the router to be something > like FE80::1. With HSRPv6 this is even a necessity. This is interesting. I've started setting up some customer interfaces using LL and then routing their prefix to them, and it has worked out well. But I didn't think of making the LL on the router side of their VLAN simply FE80::1. I suppose that'd work :) Have you had any issues with this? It makes the router configuration a tad bit easier to manage. > Totally regardless of how you manage your routing (to link-local or not), > if your customers can send RA to each other you are just screwed. But if > they can send traffic to each other you are an easy target for spoofing > attacks anyway. So you are just having the very same security problems you > already have with IPv4 with IPv6 as well. Yup. If customer A can in any way see customer B traffic, you're going to always have some security issue there. My setup always puts different customers onto different VLANs. Issues of backups, intra-VLAN traffic and billing, max VLANs per switch, etc... are all easier to solve then the issues that would arise if I share customer traffic. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From kiwi at oav.net Mon Oct 26 09:09:50 2009 From: kiwi at oav.net (Xavier Beaudouin) Date: Mon, 26 Oct 2009 09:09:50 +0100 Subject: Hosting provider allocation advice In-Reply-To: <20091026065818.GC32218@garry-thinkpad.arpnetworks.com> References: <20091015233525.GD28658@garry-thinkpad.arpnetworks.com> <429005223.12571255650476599.JavaMail.root@zimbra.nfsi.pt> <20091026065818.GC32218@garry-thinkpad.arpnetworks.com> Message-ID: <08E08562-CADE-4C41-9D20-95346E1C8755@oav.net> Hello, Le 26 oct. 2009 ? 07:58, Garry Dolley a ?crit : > On Fri, Oct 16, 2009 at 12:47:56AM +0100, Nuno Vieira - nfsi wrote: >> Hi Garry, >> >> I'd love to do that on my XMR's ve interfaces, if i could. >> >> What solutions do you guys use out there to read ve / vlan counters >> on Foundry XMR switches ? > > So the Foundry XMR switches don't report traffic of "ve" (vlan) > interfaces over SNMP? No they don't (as every foundrys....), you'll have to use sflow (as foundry people says....)... This is really a shame ! Xavier -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3890 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091026/85dc37b5/attachment.bin From gdolley at arpnetworks.com Mon Oct 26 09:56:25 2009 From: gdolley at arpnetworks.com (Garry Dolley) Date: Mon, 26 Oct 2009 01:56:25 -0700 Subject: Hosting provider allocation advice In-Reply-To: <08E08562-CADE-4C41-9D20-95346E1C8755@oav.net> References: <20091015233525.GD28658@garry-thinkpad.arpnetworks.com> <429005223.12571255650476599.JavaMail.root@zimbra.nfsi.pt> <20091026065818.GC32218@garry-thinkpad.arpnetworks.com> <08E08562-CADE-4C41-9D20-95346E1C8755@oav.net> Message-ID: <20091026085625.GC15745@garry-thinkpad.arpnetworks.com> On Mon, Oct 26, 2009 at 09:09:50AM +0100, Xavier Beaudouin wrote: > Hello, > > Le 26 oct. 2009 ? 07:58, Garry Dolley a ?crit : > >> On Fri, Oct 16, 2009 at 12:47:56AM +0100, Nuno Vieira - nfsi wrote: >>> Hi Garry, >>> >>> I'd love to do that on my XMR's ve interfaces, if i could. >>> >>> What solutions do you guys use out there to read ve / vlan counters on >>> Foundry XMR switches ? >> >> So the Foundry XMR switches don't report traffic of "ve" (vlan) >> interfaces over SNMP? > > No they don't (as every foundrys....), you'll have to use sflow (as foundry > people says....)... Oh wow. Now I know what not to buy... ;) -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From kiwi at oav.net Mon Oct 26 10:06:54 2009 From: kiwi at oav.net (kiwi at oav.net) Date: Mon, 26 Oct 2009 10:06:54 +0100 Subject: Hosting provider allocation advice In-Reply-To: <20091026085625.GC15745@garry-thinkpad.arpnetworks.com> References: <20091015233525.GD28658@garry-thinkpad.arpnetworks.com> <429005223.12571255650476599.JavaMail.root@zimbra.nfsi.pt> <20091026065818.GC32218@garry-thinkpad.arpnetworks.com> <08E08562-CADE-4C41-9D20-95346E1C8755@oav.net> <20091026085625.GC15745@garry-thinkpad.arpnetworks.com> Message-ID: Hi again, >> No they don't (as every foundrys....), you'll have to use sflow (as >> foundry >> people says....)... > > Oh wow. Now I know what not to buy... ;) Except this thing, foundry works well... :p /Xavier From martin at airwire.ie Mon Oct 26 10:07:42 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Mon, 26 Oct 2009 09:07:42 +0000 Subject: Hosting provider allocation advice In-Reply-To: References: <4AD866C1.80004@birkenwald.de> Message-ID: <4AE566DE.8030801@airwire.ie> The Dark One wrote: > talking about hosting provider, anybody knows one that can provide IPv6 hosting in Italy? Talk to E4A, they might know, wo does do hosting, as they already have some IPv6 infrastructure in place. Kind Regards, Martin List-Petersen Airwire > -----Original Message----- > From: Bernhard Schmidt > To: ipv6-ops at lists.cluenet.de > Date: Fri, 16 Oct 2009 14:27:45 +0200 > Subject: Re: Hosting provider allocation advice > >> Hi, >> >>> What if we would still assign a /64 per vlan, >>> and assign each server a single IPv6 address out of that /64, >>> but ALSO would route a /64 to each server (to that single IPv6 address) >>> ? >> The drawbacks are: >> * incompatible with PVLAN, should you decide to implement those later >> * people can configure unused addresses from that /64 >> * source-address-selection will prefer the address from the transfer network >> >> Bernhard >> -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From nuno.vieira at nfsi.pt Mon Oct 26 13:49:37 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi) Date: Mon, 26 Oct 2009 12:49:37 +0000 (WET) Subject: Hosting provider allocation advice In-Reply-To: <20091026065818.GC32218@garry-thinkpad.arpnetworks.com> Message-ID: <1597726772.31551256561377566.JavaMail.root@zimbra.nfsi.pt> nope :( --- Nuno Vieira nfsi telecom, lda. [Email] nuno.vieira at nfsi.pt [Phone] +351 21 114 2315 [Phone] +351 21 142 2300 [Mobile] +351 91 925 5561 [Fax] +351 21 114 2301 [Web] http://www.nfsi.pt/ ----- Original Message ----- From: "Garry Dolley" To: "Nuno Vieira - nfsi" Cc: ipv6-ops at lists.cluenet.de, "Wouter de Jong" Sent: Monday, 26 October, 2009 6:58:18 AM Subject: Re: Hosting provider allocation advice On Fri, Oct 16, 2009 at 12:47:56AM +0100, Nuno Vieira - nfsi wrote: > Hi Garry, > > I'd love to do that on my XMR's ve interfaces, if i could. > > What solutions do you guys use out there to read ve / vlan counters on Foundry XMR switches ? So the Foundry XMR switches don't report traffic of "ve" (vlan) interfaces over SNMP? -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st From tore at linpro.no Tue Oct 27 12:29:32 2009 From: tore at linpro.no (Tore Anderson) Date: Tue, 27 Oct 2009 12:29:32 +0100 Subject: Dealing with filtered 6to4 clients Message-ID: <4AE6D99C.5090307@linpro.no> Hello list, I've been doing some testing in order to determine whether or not it would be ?dangerous? for our customers to dualstack their web sites. The largest problem I've found so far affects a very specific group of clients, which: 1) are using Windows Vista or newer, and 2) are using the Opera web browser, and 3) are assigned public IPv4 addresses, and 4) are on a network which filters inbound proto-41 traffic. In this case, the client will have a 6to4 tunnel interface automatically configured, and will prefer using it over native IPv4 for contacting dualstacked web sites. However the return traffic never makes it back to the client, which manifests itself on the server as unsucessful retransmits of the SYN+ACK TCP packet. On the client, it looks as if the site is down (or extremely slow, as it will eventually fall back on IPv4). There's two eyeball networks (of significant size) in Norway which does this kind of inbound proto-41 filtering at the moment, and it makes it hard for me to talk my customers into providing IPv6 content as they're terrified of client loss of any kind. The issue has been discussed with the networks in question and while at least one of them acknowledge the problem, they're reluctant to allow inbound proto-41 traffic as that will basically create a wide hole in their firewall filter (which I believe allows only inbound ?established-looking? packets at the moment). So, assuming that allowing 6to4/proto-41 (or deploying native v6) is out of the question: Does anyone have any suggestions on how I (or the eyeball networks) can handle this in a better way? I've tried filtering the 6to4 packets on the way out and returning a ICMPv4 type 3 code 13 (tried code 3 as well) to the client, hoping that it would prompt Opera to fall back on v4 immediately, but unfortunately it does not have any effect at all - it still hangs as if the site is down. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From martin at airwire.ie Tue Oct 27 12:33:40 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 27 Oct 2009 11:33:40 +0000 Subject: Dealing with filtered 6to4 clients In-Reply-To: <4AE6D99C.5090307@linpro.no> References: <4AE6D99C.5090307@linpro.no> Message-ID: <4AE6DA94.1090002@airwire.ie> Tore Anderson wrote: > Hello list, > > I've been doing some testing in order to determine whether or not it > would be ?dangerous? for our customers to dualstack their web sites. The > largest problem I've found so far affects a very specific group of > clients, which: > > 1) are using Windows Vista or newer, and > 2) are using the Opera web browser, and > 3) are assigned public IPv4 addresses, and > 4) are on a network which filters inbound proto-41 traffic. > > In this case, the client will have a 6to4 tunnel interface automatically > configured, and will prefer using it over native IPv4 for contacting > dualstacked web sites. Why would 6to4 be preferred over native IPv4 here ? That's not the behaviour intended. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From tore at linpro.no Tue Oct 27 12:36:32 2009 From: tore at linpro.no (Tore Anderson) Date: Tue, 27 Oct 2009 12:36:32 +0100 Subject: Dealing with filtered 6to4 clients In-Reply-To: <4AE6DA94.1090002@airwire.ie> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> Message-ID: <4AE6DB40.7000301@linpro.no> * Martin List-Petersen > Why would 6to4 be preferred over native IPv4 here ? That's not the > behaviour intended. It's a bug/feature of the Opera web browser. I believe it will prefer Teredo over IPv4, too. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From martin at airwire.ie Tue Oct 27 12:46:15 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 27 Oct 2009 11:46:15 +0000 Subject: Dealing with filtered 6to4 clients In-Reply-To: <4AE6DB40.7000301@linpro.no> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> Message-ID: <4AE6DD87.1000207@airwire.ie> Tore Anderson wrote: > * Martin List-Petersen > >> Why would 6to4 be preferred over native IPv4 here ? That's not the >> behaviour intended. > > It's a bug/feature of the Opera web browser. I believe it will prefer > Teredo over IPv4, too. First approach would be to get Opera to fix the bug/feature then, making them aware of the issues, they are causing. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From jeroen at unfix.org Tue Oct 27 12:48:20 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 27 Oct 2009 12:48:20 +0100 Subject: Dealing with filtered 6to4 clients In-Reply-To: <4AE6DB40.7000301@linpro.no> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> Message-ID: <4AE6DE04.8060003@spaghetti.zurich.ibm.com> Tore Anderson wrote: > * Martin List-Petersen > >> Why would 6to4 be preferred over native IPv4 here ? That's not the >> behaviour intended. > > It's a bug/feature of the Opera web browser. I believe it will prefer > Teredo over IPv4, too. Two possible fixes: - get Opera to stop deciding what the network should behave like and explain them that getaddrinfo() and more specifically RFC3484 exist for a reason and that the OS definitely know more than they do - get Microsoft to include a connectivity test inside their stacks. (which, partially, is there for Vista/Seven) Both require people to upgrade stuff, the first requires less people to upgrade, the latter would fix other issues. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091027/f2c5e1b3/attachment.bin From tore at linpro.no Tue Oct 27 13:01:52 2009 From: tore at linpro.no (Tore Anderson) Date: Tue, 27 Oct 2009 13:01:52 +0100 Subject: Dealing with filtered 6to4 clients In-Reply-To: <4AE6DD87.1000207@airwire.ie> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> <4AE6DD87.1000207@airwire.ie> Message-ID: <4AE6E130.6000304@linpro.no> * Martin List-Petersen > First approach would be to get Opera to fix the bug/feature then, making > them aware of the issues, they are causing. That has already been done. I don't know when (or if) they'll fix it, but in any case the broken implementation won't vanish overnight when the fixed version is released. I doubt this will be the last broken client-side implementation we'll see either... Maybe I shouldn't be too optimistic about it, but I'm hoping to find a solution that will solve the problem today (without requiring assistance from third parties like Opera or Microsoft), in a manner that allows me to convince my customers to start providing their content over IPv6. If I can get just that ball rolling and more and more v6-enabled sites show up here in Norway, the onus to not break v6 will shift to the eyeball networks (or so I hope). Thanks to you and Jeroen both for your input! Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From martin at airwire.ie Tue Oct 27 13:08:57 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 27 Oct 2009 12:08:57 +0000 Subject: Dealing with filtered 6to4 clients In-Reply-To: <4AE6E130.6000304@linpro.no> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> <4AE6DD87.1000207@airwire.ie> <4AE6E130.6000304@linpro.no> Message-ID: <4AE6E2D9.8040203@airwire.ie> Tore Anderson wrote: > Maybe I shouldn't be too optimistic about it, but I'm hoping to find a > solution that will solve the problem today (without requiring assistance > from third parties like Opera or Microsoft), in a manner that allows me > to convince my customers to start providing their content over IPv6. If > I can get just that ball rolling and more and more v6-enabled sites show > up here in Norway, the onus to not break v6 will shift to the eyeball > networks (or so I hope). The only other way of fixing this or ensuring no breaking is a DNS whitelist type of filter like what Google does. I wouldn't encourage that, but if your eyeball networks are that paranoid, that's a way, how they can be in control. They could then choose not to provide AAAA records to 6to4- and teredo- clients. Anyhow .. that's a hack and not to be encouraged, really. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From martin at airwire.ie Tue Oct 27 13:10:35 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 27 Oct 2009 12:10:35 +0000 Subject: Dealing with filtered 6to4 clients In-Reply-To: <4AE6E2D9.8040203@airwire.ie> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> <4AE6DD87.1000207@airwire.ie> <4AE6E130.6000304@linpro.no> <4AE6E2D9.8040203@airwire.ie> Message-ID: <4AE6E33B.6060702@airwire.ie> Martin List-Petersen wrote: > I wouldn't encourage that, but if your eyeball networks are that > paranoid, that's a way, how they can be in control. They could then > choose not to provide AAAA records to 6to4- and teredo- clients. > > Anyhow .. that's a hack and not to be encouraged, really. Arghh .. me not thinking today. Obviously they can't know, what the client has, but they could whitelist known good deployments then. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From tore at linpro.no Tue Oct 27 13:23:30 2009 From: tore at linpro.no (Tore Anderson) Date: Tue, 27 Oct 2009 13:23:30 +0100 Subject: Dealing with filtered 6to4 clients In-Reply-To: <20091027121555.GA3204@boris.ghen.be> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> <4AE6DD87.1000207@airwire.ie> <4AE6E130.6000304@linpro.no> <4AE6E2D9.8040203@airwire.ie> <4AE6E33B.6060702@airwire.ie> <20091027121555.GA3204@boris.ghen.be> Message-ID: <4AE6E642.6030203@linpro.no> * Geert Hendrickx > Or, on your side, you could not serve AAAA records to (the DNS > chaches of) the problematic network(s)? Hmm... That could work, at least for the customers who also have their DNS hosting from us. You'd need to create a separate view in BIND for the problematic networks using copies of the original zones sans the quad-A records, right? I'll look into it, thanks! Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From martin at airwire.ie Tue Oct 27 13:26:18 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 27 Oct 2009 12:26:18 +0000 Subject: Dealing with filtered 6to4 clients In-Reply-To: <20091027121555.GA3204@boris.ghen.be> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> <4AE6DD87.1000207@airwire.ie> <4AE6E130.6000304@linpro.no> <4AE6E2D9.8040203@airwire.ie> <4AE6E33B.6060702@airwire.ie> <20091027121555.GA3204@boris.ghen.be> Message-ID: <4AE6E6EA.6050309@airwire.ie> Geert Hendrickx wrote: > On Tue, Oct 27, 2009 at 12:10:35PM +0000, Martin List-Petersen wrote: >> Martin List-Petersen wrote: >>> I wouldn't encourage that, but if your eyeball networks are that >>> paranoid, that's a way, how they can be in control. They could then >>> choose not to provide AAAA records to 6to4- and teredo- clients. >>> >>> Anyhow .. that's a hack and not to be encouraged, really. >> Arghh .. me not thinking today. Obviously they can't know, what the >> client has, but they could whitelist known good deployments then. > > > Or, on your side, you could not serve AAAA records to (the DNS chaches of) > the problematic network(s)? That is the better approach alright. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From jeroen at unfix.org Tue Oct 27 13:39:42 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 27 Oct 2009 13:39:42 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <4AE6E6EA.6050309@airwire.ie> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> <4AE6DD87.1000207@airwire.ie> <4AE6E130.6000304@linpro.no> <4AE6E2D9.8040203@airwire.ie> <4AE6E33B.6060702@airwire.ie> <20091027121555.GA3204@boris.ghen.be> <4AE6E6EA.6050309@airwire.ie> Message-ID: <4AE6EA0E.6040600@spaghetti.zurich.ibm.com> Martin List-Petersen wrote: > Geert Hendrickx wrote: >> On Tue, Oct 27, 2009 at 12:10:35PM +0000, Martin List-Petersen wrote: >>> Martin List-Petersen wrote: >>>> I wouldn't encourage that, but if your eyeball networks are that >>>> paranoid, that's a way, how they can be in control. They could then >>>> choose not to provide AAAA records to 6to4- and teredo- clients. >>>> >>>> Anyhow .. that's a hack and not to be encouraged, really. >>> Arghh .. me not thinking today. Obviously they can't know, what the >>> client has, but they could whitelist known good deployments then. >> >> Or, on your side, you could not serve AAAA records to (the DNS chaches of) >> the problematic network(s)? > > That is the better approach alright. Which doesn't help you much. The problem with broken clients is that they are broken and that you do not have control over them (which is good from one point ;) As an excellent example look at: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/417757 In short: host has IPv6 enabled, application does a getaddrinfo(), which means it will ask for AAAA and then A from the resolvers. The DNS resolver though sees a DNS query for an AAAA record and does "eeehmm dunno, go away" and then just drops the request. The DNS client thus has to time out, as that is the only option it has. The client then send a request for an A record and gets a direct response. Users solution: disable IPv6 Real solution: fix/replace the broken DNS server (eg change to OpenDNS*) using the upstream DNS servers directly instead of the one in the DSL modem generally is already a good enough fix as you bypass the problem. Installing a local DNS recursor is another good option. Still... it is an end-user issue which the network admin has no control over and also can't easily check, nor does it actually require any IPv6 packets to flow over the network at all, just an active IPv6 stack, some OSs are a little 'smart' about this, but one can't be completely smart. Oh and yes, it also applies to Windows and every other OS... Greets, Jeroen * = also broken in various ways: https://lists.dns-oarc.net/pipermail/dns-operations/2009-July/004217.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091027/772286e0/attachment.bin From tore at linpro.no Tue Oct 27 14:01:32 2009 From: tore at linpro.no (Tore Anderson) Date: Tue, 27 Oct 2009 14:01:32 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <4AE6EA0E.6040600@spaghetti.zurich.ibm.com> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> <4AE6DD87.1000207@airwire.ie> <4AE6E130.6000304@linpro.no> <4AE6E2D9.8040203@airwire.ie> <4AE6E33B.6060702@airwire.ie> <20091027121555.GA3204@boris.ghen.be> <4AE6E6EA.6050309@airwire.ie> <4AE6EA0E.6040600@spaghetti.zurich.ibm.com> Message-ID: <4AE6EF2C.5070407@linpro.no> Hi, * Jeroen Massar > In short: host has IPv6 enabled, application does a getaddrinfo(), which > means it will ask for AAAA and then A from the resolvers. The DNS > resolver though sees a DNS query for an AAAA record and does "eeehmm > dunno, go away" and then just drops the request. The DNS client thus has > to time out, as that is the only option it has. The client then send a > request for an A record and gets a direct response. Well, this is a different problem than the one I've been describing. I'm sure this issue is causing its share of the client loss I see on the dualstack site too, but I believe it is smaller in scope than the problem I've been asking about. From what I can tell "my" problem is responsible for more than half of the client loss on the dualstack site. "Your" problem is incredibly hard to do anything about short of copying Google's approach, as the problem is probably in the users' SOHO routers most of the time and it would be impossible to contact them all and get them to do anything about it. Unless of course it is a common problem with a certain type of CPE device distributed by a certain ISP, of course, but that does not appear to be the case here. "My" problem is confined to two specific eyeball networks here in Norway which I think it is more likely to do be able to do something about somehow. If I can do that, and cut the client loss on the dualstack site in half (now it varies between 0.12% to 0.18% from day to day) it is more likely that my customers will be inclined to ignore the rest of the lost clients (inluding the ones caused by "your" problem) and proceed with dualstacking their content anyway. By the way - the sites that have been used for the IPv6 testing have a Norwegian reader mass (they're all in Norwegian). So my breakage numbers and reasons are probably very specific to Norway. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From jeroen at unfix.org Tue Oct 27 14:16:12 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 27 Oct 2009 14:16:12 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <4AE6EF2C.5070407@linpro.no> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> <4AE6DD87.1000207@airwire.ie> <4AE6E130.6000304@linpro.no> <4AE6E2D9.8040203@airwire.ie> <4AE6E33B.6060702@airwire.ie> <20091027121555.GA3204@boris.ghen.be> <4AE6E6EA.6050309@airwire.ie> <4AE6EA0E.6040600@spaghetti.zurich.ibm.com> <4AE6EF2C.5070407@linpro.no> Message-ID: <4AE6F29C.5040101@spaghetti.zurich.ibm.com> Tore Anderson wrote: > Hi, > > * Jeroen Massar > >> In short: host has IPv6 enabled, application does a getaddrinfo(), which >> means it will ask for AAAA and then A from the resolvers. The DNS >> resolver though sees a DNS query for an AAAA record and does "eeehmm >> dunno, go away" and then just drops the request. The DNS client thus has >> to time out, as that is the only option it has. The client then send a >> request for an A record and gets a direct response. > > Well, this is a different problem than the one I've been describing. Guess why I changed the subject ;) > I'm sure this issue is causing its share of the client loss I see on the > dualstack site too, but I believe it is smaller in scope than the > problem I've been asking about. From what I can tell "my" problem is > responsible for more than half of the client loss on the dualstack site. try googling for "ubuntu ipv6 disable", you'll get an idea :) or for that matter "disable ipv6" which also gives you the results for Windows. Googling here returns about 173.000 results along with: Searches related to: disable ipv6 disable ipv6 linux disable ipv6 ubuntu disable ipv6 xp disable ipv6 centos disable ipv6 fedora disable ipv6 debian disable ipv6 windows xp disable ipv6 redhat I guess that tells enough on how wide-spread this issue is. > "Your" problem is incredibly hard to do anything about short of copying > Google's approach, as the problem is probably in the users' SOHO routers Nope, that won't help. It does not matter if there are AAAA records in DNS, it is all about having the client query for them and the resolver (the one in the CPE) which drops the requests. > most of the time and it would be impossible to contact them all and get > them to do anything about it. Unless of course it is a common problem > with a certain type of CPE device distributed by a certain ISP, of > course, but that does not appear to be the case here. The problem there is that even older versions of dnsmasq had this issue and that is used in in a lot of CPEs. > "My" problem is confined to two specific eyeball networks here in Norway > which I think it is more likely to do be able to do something about > somehow. In that case not returning AAAA records for those would work and should not be too much overhead. Best solution in this case though is to convince the networks to fix their filtering issue, that is that they don't filter. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091027/bb3f4312/attachment.bin From tore at linpro.no Tue Oct 27 14:58:09 2009 From: tore at linpro.no (Tore Anderson) Date: Tue, 27 Oct 2009 14:58:09 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <4AE6F29C.5040101@spaghetti.zurich.ibm.com> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> <4AE6DD87.1000207@airwire.ie> <4AE6E130.6000304@linpro.no> <4AE6E2D9.8040203@airwire.ie> <4AE6E33B.6060702@airwire.ie> <20091027121555.GA3204@boris.ghen.be> <4AE6E6EA.6050309@airwire.ie> <4AE6EA0E.6040600@spaghetti.zurich.ibm.com> <4AE6EF2C.5070407@linpro.no> <4AE6F29C.5040101@spaghetti.zurich.ibm.com> Message-ID: <4AE6FC71.5040104@linpro.no> * Jeroen Massar > try googling for "ubuntu ipv6 disable", you'll get an idea :) Oh, by the way, googling for "Tore Anderson" returns 11.400 results. I'm pretty sure that does _not_ give me an idea of how many name brothers I have.... ;-) (Sorry, couldn't resist.) > Nope, that won't help. It does not matter if there are AAAA records in > DNS, it is all about having the client query for them and the resolver > (the one in the CPE) which drops the requests. In that case no additional breakage is introduced by dualstacking the sites in question, so it's not really something I (or my customers) care too much about really. My problem is that if dualstacking www.mycust.no makes it unavailable for a number of users (who will still be able access the singlestacked www.competitor-of-mycust.no just fine), then my customer is not likely to want any quad-A records anywhere near his site. Depending on how many users gets problems, of course. > In that case not returning AAAA records for those would work and should > not be too much overhead. Best solution in this case though is to > convince the networks to fix their filtering issue, that is that they > don't filter. Yup, blacklisting those operators would be the inverse of the Google approach, and I think it will work well enough - take out a large chunk of the brokenness while not being too conservative about it either (like Google). I think that is probably the best approach for now, at least I intend to have a chat with our hostmasters about how to go about implementing it. Convincing the problematic networks to allow proto-41 is of course a possibility, but I can understand their reluctance - I mean, they have probably a valid reason to want to filter inbound connections to, say, 1.2.3.4 port 22, 25, 80, 139, or whatever, but if they allow proto-41 then it will be embarrassingly easy for an external attacker to sidestep the filter by connecting to 2002:0102:0304::0102:0304 on the given port instead. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From remi at remlab.net Tue Oct 27 15:20:01 2009 From: remi at remlab.net (=?UTF-8?Q?R=C3=A9mi_Denis-Courmont?=) Date: Tue, 27 Oct 2009 15:20:01 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) Message-ID: <0f28925163d15916e7a009de3b3824cb@chewa.net> On Tue, 27 Oct 2009 13:39:42 +0100, Jeroen Massar wrote: > As an excellent example look at: > https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/417757 Hmm well, I suspect the problem is rather along the line of glibc depending on the little-known and hence under-used AI_ADDRCONFIG flag for correct RFC3484 operation. With that flag, it will only look quad-A records up if there is one (non-link-local) IPv6 address configured - in this case, it is reasonable to assume DNS works correctly, especially as Linux distros don't do "automatic" 6to4 setup by default. Whether it's a glibc or a many-applications bug is debatable. -- R?mi Denis-Courmont From jeroen at unfix.org Tue Oct 27 15:29:42 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 27 Oct 2009 15:29:42 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <0f28925163d15916e7a009de3b3824cb@chewa.net> References: <0f28925163d15916e7a009de3b3824cb@chewa.net> Message-ID: <4AE703D6.6020305@spaghetti.zurich.ibm.com> R?mi Denis-Courmont wrote: > On Tue, 27 Oct 2009 13:39:42 +0100, Jeroen Massar wrote: >> As an excellent example look at: >> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/417757 > > Hmm well, I suspect the problem is rather along the line of glibc depending > on the little-known and hence under-used AI_ADDRCONFIG flag for correct > RFC3484 operation. With that flag, it will only look quad-A records up if > there is one (non-link-local) IPv6 address configured - in this case, it is > reasonable to assume DNS works correctly, especially as Linux distros don't > do "automatic" 6to4 setup by default. > > Whether it's a glibc or a many-applications bug is debatable. *WHICH IS NOT THE ISSUE* (it is another one, but that generally doesn't hit anyone, as without an IPv6 default route your packets directly return anyway with an UNREACH when they are sent outbound thus it does not hurt in most cases) dig @ www.microsoft.com AAAA and the dns resolver will never ever reply that that query. This means that your resolver will time out. It is irrespective of having actualy IPv6 connectivity or not. It does depend on the OS making a decision if it needs to query an AAAA record or not which could indeed then be based on flags passed to getaddrinfo AI_ADDRCONFIG. Note though that AI_ADDRCONFIG stated per the man page on Debian: 8<----------- If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses are returned in the list pointed to by result only if the local system has at least one IPv4 address configured, and IPv6 addresses are only returned if the local system has at least one IPv6 address configured. ------------> In other words, 6to4, Teredo etc and you are bust. Also note that those are the defaults on Windows Vista and Seven... And even if you have proper IPv6 connectivity, this DNS querying bug can still hit you straight in the face. (Heck I had it at home with an old WRT box but I never noticed it till I once didn't have my VPN open and thus started using the local DNS server which was broken...) (And gee, see why so many other people are confused about this....) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091027/cd9f5bbd/attachment.bin From remi at remlab.net Tue Oct 27 16:03:05 2009 From: remi at remlab.net (=?UTF-8?Q?R=C3=A9mi_Denis-Courmont?=) Date: Tue, 27 Oct 2009 16:03:05 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <4AE703D6.6020305@spaghetti.zurich.ibm.com> References: <0f28925163d15916e7a009de3b3824cb@chewa.net> <4AE703D6.6020305@spaghetti.zurich.ibm.com> Message-ID: <5fd39f68abc665808d7ce0d365f35770@chewa.net> On Tue, 27 Oct 2009 15:29:42 +0100, Jeroen Massar wrote: >> Whether it's a glibc or a many-applications bug is debatable. > > *WHICH IS NOT THE ISSUE* It is the issue. (...) > In other words, 6to4, Teredo etc and you are bust. > Also note that those are the defaults on Windows Vista and Seven... To my knowledge, _none_ of the common Linux distros enable 6to4 or Teredo automatically by default. Of course, if they did, then they'd have to provide resolver hacks such as those done by Microsoft. _Then_ you can think of running the A and AAA queries in parallel, and timing out the AAAA query quickly after the A response. But it is currently a non-issue on _Linux_, which is the system the bug refers to. -- R?mi Denis-Courmont From tedm at ipinc.net Tue Oct 27 16:33:38 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 27 Oct 2009 08:33:38 -0700 Subject: Opera Browser problem Message-ID: <4AE712D2.1000008@ipinc.net> This came up on the SpamAssassin mailing list, I just thought people might be interested: Tore Anderson wrote: > Hello list, > > I've been doing some testing in order to determine whether or not it > would be ?dangerous? for our customers to dualstack their web sites. The > largest problem I've found so far affects a very specific group of > clients, which: > > 1) are using Windows Vista or newer, and > 2) are using the Opera web browser, and > 3) are assigned public IPv4 addresses, and > 4) are on a network which filters inbound proto-41 traffic. > > In this case, the client will have a 6to4 tunnel interface automatically > configured, and will prefer using it over native IPv4 for contacting > dualstacked web sites. Further discussion on the SA list about this indicates this is a known bug that was reported to Opera - but the broken browsers are out there, of course. Ted From jeroen at unfix.org Tue Oct 27 17:02:23 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 27 Oct 2009 17:02:23 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <5fd39f68abc665808d7ce0d365f35770@chewa.net> References: <0f28925163d15916e7a009de3b3824cb@chewa.net> <4AE703D6.6020305@spaghetti.zurich.ibm.com> <5fd39f68abc665808d7ce0d365f35770@chewa.net> Message-ID: <4AE7198F.1020709@spaghetti.zurich.ibm.com> R?mi Denis-Courmont wrote: > On Tue, 27 Oct 2009 15:29:42 +0100, Jeroen Massar wrote: >>> Whether it's a glibc or a many-applications bug is debatable. >> *WHICH IS NOT THE ISSUE* > > It is the issue. I would say, explain then to the Ubuntu folks how to properly resolve it, I am sure they will love you for it. (And it would save again some people on blocking IPv6 on their boxes, then again, their box, their problem) Yes, I can see that the ADDRCONF flag can be useful for this, as it avoids querying AAAA records in the first place, but that should not be done on a per-application level. That is a decision to be made by the resolver library which should be smart about that, link-local addresses can't be stuffed in a AAAA address anyway and if you don't have connectivity then there is not much to be done. > (...) >> In other words, 6to4, Teredo etc and you are bust. >> Also note that those are the defaults on Windows Vista and Seven... > > To my knowledge, _none_ of the common Linux distros enable 6to4 or Teredo > automatically by default. If you have IPv6 enabled in the kernel, which is the default, and somebody runs a "rogue" RA it gets enabled already (then you generally also get nice broken routes in addition ;) There are enough people who also magically tend to configure all kinds of things wrong or install magic tools they don't need, especially when they hear that "IPv6 will give them access to free warez". uTorrent is an example of that, which enables Teredo, but there are also other tools which do so. > Of course, if they did, then they'd have to > provide resolver hacks such as those done by Microsoft. _Then_ you can > think of running the A and AAA queries in parallel, and timing out the AAAA > query quickly after the A response. Which is what current glibc's (2.9 series) already do in most cases, but these also have some smarter algorithms to determine when and when not to do IPv6 queries. An application should not be forced to one or the other though, maybe the user wants to connect to that server on the link-local network, that was the whole point of the dentist-problem. As such, for instance Firefox should be able to do that too. (with for instance mDNS for resolving in that case, and yep, again something annoying called avahi is a semi-default, good that there are ways to block packages from ever installing) > But it is currently a non-issue on > _Linux_, which is the system the bug refers to. If it is such a "non-issue", why are there so many people complaining about it and then disabling IPv6? While if they specify eg the opendns nameservers in their resolv.conf everything works fine!? :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091027/a1495121/attachment.bin From swmike at swm.pp.se Tue Oct 27 17:12:04 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 27 Oct 2009 17:12:04 +0100 (CET) Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <4AE7198F.1020709@spaghetti.zurich.ibm.com> References: <0f28925163d15916e7a009de3b3824cb@chewa.net> <4AE703D6.6020305@spaghetti.zurich.ibm.com> <5fd39f68abc665808d7ce0d365f35770@chewa.net> <4AE7198F.1020709@spaghetti.zurich.ibm.com> Message-ID: On Tue, 27 Oct 2009, Jeroen Massar wrote: > I would say, explain then to the Ubuntu folks how to properly resolve > it, I am sure they will love you for it. There is a bug reported that when you disassociate/reassociate wlan, it doesn't drop the IPv6 address between (so after a few movements between wlan:s, you'll have a bunch of IPv6 addresses from different /64s), the response from the ubuntu people was that this needed a feature enhancement, it wasn't a bug. The writing from the person in question seemed to indicate that this wasn't seen as an issue. So no, there is very little IPv6 love from Ubuntu. -- Mikael Abrahamsson email: swmike at swm.pp.se From jeroen at unfix.org Tue Oct 27 17:28:05 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 27 Oct 2009 17:28:05 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: References: <0f28925163d15916e7a009de3b3824cb@chewa.net> <4AE703D6.6020305@spaghetti.zurich.ibm.com> <5fd39f68abc665808d7ce0d365f35770@chewa.net> <4AE7198F.1020709@spaghetti.zurich.ibm.com> Message-ID: <4AE71F95.90009@spaghetti.zurich.ibm.com> Mikael Abrahamsson wrote: > On Tue, 27 Oct 2009, Jeroen Massar wrote: > >> I would say, explain then to the Ubuntu folks how to properly resolve >> it, I am sure they will love you for it. > > There is a bug reported that when you disassociate/reassociate wlan, it > doesn't drop the IPv6 address between (so after a few movements between > wlan:s, you'll have a bunch of IPv6 addresses from different /64s), the > response from the ubuntu people was that this needed a feature > enhancement, it wasn't a bug. The writing from the person in question > seemed to indicate that this wasn't seen as an issue. Had not seen that one, but the below might be a work-around for it: In /etc/network/interfaces at the interfaces with the issues, add: pre-down ip -6 addr flush dev pre-down ip -6 ro flush dev (Maybe a post-down, but I guess that if the interface is marked 'down' one can't flush anymore, I noticed that once) Can't test it, as I don't use Linux on my laptop (Windows XP FTW! etc :) due to the crap wireless support on that platform. Oh and something with having already loads of Linux boxes to SSH/VNC/X into if I need a specific thing from such a box.... > So no, there is very little IPv6 love from Ubuntu. That was the impression I am getting too, that even while they are at least shipping IPv6-per-default-enabled, though I guess that might also be to match features with other distros. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091027/e4e6abc3/attachment.bin From remi at remlab.net Tue Oct 27 17:37:10 2009 From: remi at remlab.net (=?UTF-8?Q?R=C3=A9mi_Denis-Courmont?=) Date: Tue, 27 Oct 2009 17:37:10 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <4AE7198F.1020709@spaghetti.zurich.ibm.com> References: <0f28925163d15916e7a009de3b3824cb@chewa.net> <4AE703D6.6020305@spaghetti.zurich.ibm.com> <5fd39f68abc665808d7ce0d365f35770@chewa.net> <4AE7198F.1020709@spaghetti.zurich.ibm.com> Message-ID: <8e32b8a4c5d3df9d70567f862d36c4b2@chewa.net> On Tue, 27 Oct 2009 17:02:23 +0100, Jeroen Massar wrote: > Yes, I can see that the ADDRCONF flag can be useful for this, as it > avoids querying AAAA records in the first place, but that should not be > done on a per-application level. That is a decision to be made by the > resolver library which should be smart about that, link-local addresses > can't be stuffed in a AAAA address anyway and if you don't have > connectivity then there is not much to be done. I guess glibc does standard lawyering. There are cases where an application wantd to query AAAA regardless of the system configuration. Those cases are corner cases. glibc follows the standard to the letter and resolves everything by default. And so, glibc adds a (non-standard) flag if you want to use getaddrinfo for policy. In other words, even though this is the most common case, it is not the default. I am not going to get into a fight with Ulrich Drepper on this, as it would most likely get us nowhere. Ubuntu can force AI_ADDRCONFIG into their glibc if they see fit. > If you have IPv6 enabled in the kernel, which is the default, and > somebody runs a "rogue" RA it gets enabled already (then you generally > also get nice broken routes in addition ;) Well then you are really screwed anyway, just like if someone runs a rogue DHCPv4 at the moment you boot your computer. > There are enough people who also magically tend to configure all kinds > of things wrong or install magic tools they don't need, especially when > they hear that "IPv6 will give them access to free warez". uTorrent is > an example of that, which enables Teredo, but there are also other tools > which do so. AFAIK, that case is worked around in glibc 2.10: * DNS IPv4-IPv6 parallel lookup now deals better with broken DNS servers (the case, e.g., for some people using the built-in DNS server in ADSL modems/routers). There is a once-per-process timeout in case of a broken server. To avoid it, users can run nscd or put 'options single-request' in /etc/resolv.conf. Implemented by Ulrich Drepper. ...which builds on top of an earlier glibc 2.9 enhancement: * Unified lookup for getaddrinfo: IPv4 and IPv6 addresses are now looked up at the same time. Implemented by Ulrich Drepper. >> Of course, if they did, then they'd have to >> provide resolver hacks such as those done by Microsoft. _Then_ you can >> think of running the A and AAA queries in parallel, and timing out the >> AAAA query quickly after the A response. > > Which is what current glibc's (2.9 series) already do in most cases, but > these also have some smarter algorithms to determine when and when not > to do IPv6 queries. 2.9 is not current - anymore. Anyway, I fail to see what else can be done. There is no way to determine that AAAA are broken without trying. Worse, this hack might cause false positives. >> But it is currently a non-issue on >> _Linux_, which is the system the bug refers to. > > If it is such a "non-issue", why are there so many people complaining > about it and then disabling IPv6? While if they specify eg the opendns > nameservers in their resolv.conf everything works fine!? :) Automatically brought up 6to4 and Teredo are non-issues because there are NO SUCH THINGS on Linux. The point is, if glibc stops querying AAAA pointlessly, then the issue is solved. There is no need to hacks for automatic tunneling on a platform that does not have automatic tunneling. -- R?mi Denis-Courmont From spz at serpens.de Tue Oct 27 18:13:32 2009 From: spz at serpens.de (S.P.Zeidler) Date: Tue, 27 Oct 2009 18:13:32 +0100 Subject: Dealing with filtered 6to4 clients In-Reply-To: <4AE6D99C.5090307@linpro.no> References: <4AE6D99C.5090307@linpro.no> Message-ID: <20091027171331.GL843@serpens.de> Hi, Thus wrote Tore Anderson (tore at linpro.no): > 1) are using Windows Vista or newer, and > 2) are using the Opera web browser, and > 3) are assigned public IPv4 addresses, and > 4) are on a network which filters inbound proto-41 traffic. If the networks in question had their own "6to4 tunnel brokers" they could prevent loss of connectivity that their filtering generates by not actually brokering their clients but providing a kind of proxying instead. That'd be incredibly ugly but probably better than the current state. Getting IPv6 and actually brokering their customers of course also would help :) regards, spz -- spz at serpens.de (S.P.Zeidler) From charles at thewybles.com Tue Oct 27 18:51:09 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 27 Oct 2009 10:51:09 -0700 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <8e32b8a4c5d3df9d70567f862d36c4b2@chewa.net> References: <0f28925163d15916e7a009de3b3824cb@chewa.net> <4AE703D6.6020305@spaghetti.zurich.ibm.com> <5fd39f68abc665808d7ce0d365f35770@chewa.net> <4AE7198F.1020709@spaghetti.zurich.ibm.com> <8e32b8a4c5d3df9d70567f862d36c4b2@chewa.net> Message-ID: On Oct 27, 2009, at 9:37 AM, R?mi Denis-Courmont wrote: >> > > AFAIK, that case is worked around in glibc 2.10: > * DNS IPv4-IPv6 parallel lookup now deals better with broken DNS > servers (the case, e.g., for some people using the built-in DNS > server in ADSL modems/routers). There is a once-per-process timeout > in case of a broken server. To avoid it, users can run nscd or put > 'options single-request' in /etc/resolv.conf. > Implemented by Ulrich Drepper. I would recommend not running nscd. It causes all manner of issues and weirdness. Haven't played with the single-request in /etc/resolv.conf so can't comment on that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091027/abe244a7/attachment.html From tedm at ipinc.net Tue Oct 27 19:41:23 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 27 Oct 2009 11:41:23 -0700 Subject: Opera Browser problem In-Reply-To: <4AE712D2.1000008@ipinc.net> References: <4AE712D2.1000008@ipinc.net> Message-ID: <4AE73ED3.2090203@ipinc.net> Hi All, Just add me to the list of clueless users - I got the SpamAssassin mailing list mixed in with ipv6-ops when I sent this, this morning. Ted Ted Mittelstaedt wrote: > This came up on the SpamAssassin mailing list, > I just thought people might be interested: > > Tore Anderson wrote: >> Hello list, >> >> I've been doing some testing in order to determine whether or not it >> would be ?dangerous? for our customers to dualstack their web sites. The >> largest problem I've found so far affects a very specific group of >> clients, which: >> >> 1) are using Windows Vista or newer, and >> 2) are using the Opera web browser, and >> 3) are assigned public IPv4 addresses, and >> 4) are on a network which filters inbound proto-41 traffic. >> >> In this case, the client will have a 6to4 tunnel interface automatically >> configured, and will prefer using it over native IPv4 for contacting >> dualstacked web sites. > > Further discussion on the SA list about this indicates this is > a known bug that was reported to Opera - but the broken browsers > are out there, of course. > > Ted From alex at digriz.org.uk Tue Oct 27 18:45:56 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Tue, 27 Oct 2009 17:45:56 +0000 Subject: Opera Browser problem References: <4AE712D2.1000008@ipinc.net> Message-ID: Ted Mittelstaedt wrote: > > Tore Anderson wrote: >> >> I've been doing some testing in order to determine whether or not it >> would be ?dangerous? for our customers to dualstack their web sites. The >> largest problem I've found so far affects a very specific group of >> clients, which: >> >> 1) are using Windows Vista or newer, and >> 2) are using the Opera web browser, and >> 3) are assigned public IPv4 addresses, and >> 4) are on a network which filters inbound proto-41 traffic. >> >> In this case, the client will have a 6to4 tunnel interface automatically >> configured, and will prefer using it over native IPv4 for contacting >> dualstacked web sites. > > Further discussion on the SA list about this indicates this is > a known bug that was reported to Opera - but the broken browsers > are out there, of course. > Eugh, I have been reporting a stupid IPv6 bug for ages (about five years now) and they seem to ignore me; I was hoping by now they would have fixed it for version ten. Last time I even got a bug id, unsurprisingly it has probably been filed under "not important" like all the previous ones though. :-/ This was not so annoying (it only really ever affected my own sites) until my IPv6 enabled ISP got themselves whitelisted with Google and now using it is damn awkward :-/ The bug in detail, under Linux and Windows, it is very noticable that when you try to access a dual stacked site from an IPv4 only workstation, Opera will hang without sending a single packet till some internal timer expires (looks like about five seconds). It's crazy, you run tcpdump, you see the DNS query and response with an AAAA record...and then nothing. After a while, Opera decides maybe it should do something after all. Christ, even Firefox is not that braindead :-/ Time to move on I guess :) Cheers -- Alexander Clouter .sigmonster says: Even bytes get lonely for a little bit. From ghen at telenet.be Tue Oct 27 13:15:55 2009 From: ghen at telenet.be (Geert Hendrickx) Date: Tue, 27 Oct 2009 13:15:55 +0100 Subject: Dealing with filtered 6to4 clients In-Reply-To: <4AE6E33B.6060702@airwire.ie> References: <4AE6D99C.5090307@linpro.no> <4AE6DA94.1090002@airwire.ie> <4AE6DB40.7000301@linpro.no> <4AE6DD87.1000207@airwire.ie> <4AE6E130.6000304@linpro.no> <4AE6E2D9.8040203@airwire.ie> <4AE6E33B.6060702@airwire.ie> Message-ID: <20091027121555.GA3204@boris.ghen.be> On Tue, Oct 27, 2009 at 12:10:35PM +0000, Martin List-Petersen wrote: > Martin List-Petersen wrote: > > I wouldn't encourage that, but if your eyeball networks are that > > paranoid, that's a way, how they can be in control. They could then > > choose not to provide AAAA records to 6to4- and teredo- clients. > > > > Anyhow .. that's a hack and not to be encouraged, really. > > Arghh .. me not thinking today. Obviously they can't know, what the > client has, but they could whitelist known good deployments then. Or, on your side, you could not serve AAAA records to (the DNS chaches of) the problematic network(s)? Geert -- Geert Hendrickx -=- ghen at telenet.be -=- PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages! From he at uninett.no Wed Oct 7 13:44:40 2009 From: he at uninett.no (Havard Eidnes) Date: Wed, 07 Oct 2009 11:44:40 -0000 Subject: Breakage due to Hurricane Electric/Internet2 In-Reply-To: <87vdircwr2.fsf_-_@mid.deneb.enyo.de> References: <4ACC54F5.5060507@mur.at> <87vdircwr2.fsf_-_@mid.deneb.enyo.de> Message-ID: <20091007.134437.107323778.he@uninett.no> > > Here it resolves to: > > > > 2001:a78::1a > > > > 1?: [LOCALHOST] pmtu 1500 > > 1: v200-fe2-r1ko.mur.at 0.995ms > > 2: wien6.v6.aco.net 6.454ms > > Are you located at a G?ANT downstream? Can you reach > 2001:12f0:840:4092:204:acff:fe25:f5fb? Even though I'm not him, we're at a G?ANT downstream, and a traceroute6 to that address trails off somewhere in Brazil, (according to whois.lacnic.net): % traceroute6 2001:12f0:840:4092:204:acff:fe25:f5fb traceroute6 to 2001:12f0:840:4092:204:acff:fe25:f5fb (2001:12f0:840:4092:204:acff:fe25:f5fb) from 2001:700:1:0:21e:4fff:feed:ced, 64 hops max, 12 byte packets 1 uninett-gw 0.738 ms 0.777 ms 0.776 ms 2 teknobyen-gw2 4.375 ms 2.81 ms 2.018 ms 3 trd-gw1 0.778 ms 0.777 ms 6.827 ms 4 hovedbygget-gw1 2.432 ms 0.778 ms 0.777 ms 5 hovedbygget-gw4 0.777 ms 0.779 ms 0.777 ms 6 stolav-gw4 7.638 ms 7.563 ms 7.596 ms 7 stolav-gw1 7.813 ms 7.567 ms 7.617 ms 8 oslo-gw 10.824 ms 21.657 ms 7.787 ms 9 se-tug.nordu.net 15.616 ms 15.589 ms 15.493 ms 10 se-fre.nordu.net 15.982 ms 21.764 ms 15.939 ms 11 dk-ore.nordu.net 25.648 ms 25.612 ms 25.621 ms 12 nordunet.rt2.cop.dk.geant2.net 25.7 ms 25.692 ms 25.644 ms 13 so-7-3-0.rt1.fra.de.geant2.net 39.547 ms 39.693 ms 39.679 ms 14 so-6-2-0.rt1.gen.ch.geant2.net 47.857 ms 51.778 ms 47.776 ms 15 so-7-0-0.rt1.mad.es.geant2.net 69.869 ms 69.756 ms 69.889 ms 16 clara-gw.rt1.mad.es.geant2.net 184.347 ms 184.017 ms 184.216 ms 17 2001:1348::29 292.177 ms 292.174 ms 292.116 ms 18 2001:1348:1::2 300.53 ms 325.921 ms 292.639 ms 19 2001:12f0:0:fc::16 298.086 ms 298.917 ms 298.315 ms 20 2001:12f0:0:fc::21 318.522 ms 352.891 ms 318.153 ms 21 2001:12f0:0:3020::2 318.748 ms 318.556 ms 318.951 ms 22 2001:12f0:840:169::2 318.973 ms 318.866 ms 319.07 ms 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * ^C % Some folks obviously don't beleive in ip6.arpa :) Regards, - H?vard From ipv6-ops+phil at spodhuis.org Wed Oct 28 04:45:06 2009 From: ipv6-ops+phil at spodhuis.org (Phil Pennock) Date: Tue, 27 Oct 2009 20:45:06 -0700 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <8e32b8a4c5d3df9d70567f862d36c4b2@chewa.net> References: <0f28925163d15916e7a009de3b3824cb@chewa.net> <4AE703D6.6020305@spaghetti.zurich.ibm.com> <5fd39f68abc665808d7ce0d365f35770@chewa.net> <4AE7198F.1020709@spaghetti.zurich.ibm.com> <8e32b8a4c5d3df9d70567f862d36c4b2@chewa.net> Message-ID: <20091028034506.GA26148@redoubt.spodhuis.org> On 2009-10-27 at 17:37 +0100, R?mi Denis-Courmont wrote: > > On Tue, 27 Oct 2009 17:02:23 +0100, Jeroen Massar wrote: > > Yes, I can see that the ADDRCONF flag can be useful for this, as it > > avoids querying AAAA records in the first place, but that should not be > > done on a per-application level. That is a decision to be made by the > > resolver library which should be smart about that, link-local addresses > > can't be stuffed in a AAAA address anyway and if you don't have > > connectivity then there is not much to be done. > > I guess glibc does standard lawyering. There are cases where an application > wantd to query AAAA regardless of the system configuration. Those cases are > corner cases. glibc follows the standard to the letter and resolves > everything by default. > > And so, glibc adds a (non-standard) flag if you want to use getaddrinfo for > policy. In other words, even though this is the most common case, it is not > the default. I am not going to get into a fight with Ulrich Drepper on > this, as it would most likely get us nowhere. > > Ubuntu can force AI_ADDRCONFIG into their glibc if they see fit. Non-standard? Really? Well, it's true that the RFC for "Basic Socket Interface Extensions for IPv6" is non-standard, it's "Informational", but that's because it's a host API and more of a guideline of how to implement things. But AI_ADDRCONFIG is in RFC 3493 (from 2003). It was even in RFC 2553, from 1999. It was not in RFC 2133, from 1997. So AI_ADDRCONFIG was only introduced ten years ago, in an Informational RFC. Fortunately, we have the Single Unix Specification. SUSv3 includes AI_ADDRCONFIG. That makes it standard. SUSv2 did not include getaddrinfo(), AFAICT. So please, stop being rude about people who aren't here to defend themselves from such false statements. -Phil From remi at remlab.net Wed Oct 28 08:54:00 2009 From: remi at remlab.net (=?UTF-8?Q?R=C3=A9mi_Denis-Courmont?=) Date: Wed, 28 Oct 2009 08:54:00 +0100 Subject: Broken DNS client resolvers (Was: Dealing with filtered 6to4 clients) In-Reply-To: <20091028034506.GA26148@redoubt.spodhuis.org> References: <0f28925163d15916e7a009de3b3824cb@chewa.net> <4AE703D6.6020305@spaghetti.zurich.ibm.com> <5fd39f68abc665808d7ce0d365f35770@chewa.net> <4AE7198F.1020709@spaghetti.zurich.ibm.com> <8e32b8a4c5d3df9d70567f862d36c4b2@chewa.net> <20091028034506.GA26148@redoubt.spodhuis.org> Message-ID: <166c8f4df0f91534e51d90a572a026dd@chewa.net> On Tue, 27 Oct 2009 20:45:06 -0700, Phil Pennock wrote: >> Ubuntu can force AI_ADDRCONFIG into their glibc if they see fit. > > Non-standard? Really? > > Well, it's true that the RFC for "Basic Socket Interface Extensions for > IPv6" is non-standard, it's "Informational", but that's because it's a > host API and more of a guideline of how to implement things. But > AI_ADDRCONFIG is in RFC 3493 (from 2003). Well, then maybe it is standard. In that case, the blame is indeed on the applications rather than on glibc. But still most (not all) getaddrinfo-aware applications ignore this flag. This probably has something to do with the fact that it did not exist in original getaddrinfo spec, and that some major operating systems or older version thereof don't have it... -- R?mi Denis-Courmont From herlianto at gmail.com Wed Oct 28 10:10:53 2009 From: herlianto at gmail.com (Herlianto) Date: Wed, 28 Oct 2009 12:10:53 +0300 Subject: Translator / Broker IPV4 to IPV6 network Message-ID: Dear All, We will trial to interconnect from IPV4 network (1 ISP) to IPV6 cloud so from customer (IPV4) can access IPV6 content and vice versa. Is there any experience and reference using Cisco router as broker/translator ? Thanks for your kind attention and cooperation. -- _H e r l y_ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091028/d1949d90/attachment.html From bmanning at vacation.karoshi.com Wed Oct 28 12:55:19 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 28 Oct 2009 11:55:19 +0000 Subject: Translator / Broker IPV4 to IPV6 network In-Reply-To: References: Message-ID: <20091028115519.GE5181@vacation.karoshi.com.> can't speak to the use of a cisco box. the IVI code has been running rock soild for me for the past couple of years. kind of depends on how many folks are in the IPv4 cloud). On Wed, Oct 28, 2009 at 12:10:53PM +0300, Herlianto wrote: > Dear All, > > We will trial to interconnect from IPV4 network (1 ISP) to IPV6 cloud so > from customer (IPV4) can access IPV6 content and vice versa. > > Is there any experience and reference using Cisco router as > broker/translator ? > > Thanks for your kind attention and cooperation. > > -- > > > _H e r l y_ From ryanczak at arin.net Wed Oct 28 13:05:20 2009 From: ryanczak at arin.net (Matt Ryanczak) Date: Wed, 28 Oct 2009 08:05:20 -0400 Subject: Translator / Broker IPV4 to IPV6 network In-Reply-To: <20091028115519.GE5181@vacation.karoshi.com.> References: <20091028115519.GE5181@vacation.karoshi.com.> Message-ID: <1256731520.13852.23.camel@otto> Bill do you still need a /32 to use IVI effectively? Do you have links to a web site with more info? Last I check the documentation available on the web was pretty sparse. Thanks, ~Matt On Wed, 2009-10-28 at 07:55 -0400, bmanning at vacation.karoshi.com wrote: > can't speak to the use of a cisco box. the IVI code > has been running rock soild for me for the past couple of years. > kind of depends on how many folks are in the IPv4 cloud). > > > > On Wed, Oct 28, 2009 at 12:10:53PM +0300, Herlianto wrote: > > Dear All, > > > > We will trial to interconnect from IPV4 network (1 ISP) to IPV6 cloud so > > from customer (IPV4) can access IPV6 content and vice versa. > > > > Is there any experience and reference using Cisco router as > > broker/translator ? > > > > Thanks for your kind attention and cooperation. > > > > -- > > > > > > _H e r l y_ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091028/d23a19d7/attachment.bin From jogi at mur.at Wed Oct 28 22:20:54 2009 From: jogi at mur.at (Jogi Hofmueller) Date: Wed, 28 Oct 2009 22:20:54 +0100 Subject: Breakage due to Hurricane Electric/Internet2 In-Reply-To: <20091007.134437.107323778.he@uninett.no> References: <4ACC54F5.5060507@mur.at> <87vdircwr2.fsf_-_@mid.deneb.enyo.de> <20091007.134437.107323778.he@uninett.no> Message-ID: <4AE8B5B6.8070003@mur.at> Hey, Quite awkward. This mail was on route for >20 days! According to how I read the header, mail1.cluenet.de kept it for a while. Havard Eidnes schrieb: >>> Here it resolves to: >>> >>> 2001:a78::1a >>> >>> 1?: [LOCALHOST] pmtu 1500 >>> 1: v200-fe2-r1ko.mur.at 0.995ms >>> 2: wien6.v6.aco.net 6.454ms >> Are you located at a G?ANT downstream? Can you reach >> 2001:12f0:840:4092:204:acff:fe25:f5fb? > > Even though I'm not him, we're at a G?ANT downstream, and a > traceroute6 to that address trails off somewhere in Brazil, > (according to whois.lacnic.net): AFAIKS That's quite allright. We seem to have gotten the problems fixed, thanx to the help from ACOnet people. 1?: [LOCALHOST] pmtu 1500 1: v200-fe2-r1ko.mur.at 1. 8ms 2: wien6.v6.aco.net 11.916ms 3: wien6.v6.aco.net asymm 2 6.605ms pmtu 1476 3: aconet.rt1.vie.at.geant2.net asymm 4 7.173ms 4: so-3-0-0.rt1.mil.it.geant2.net asymm 5 19.389ms 5: so-6-3-0.rt1.gen.ch.geant2.net asymm 6 27.533ms 6: so-7-0-0.rt1.mad.es.geant2.net asymm 7 49.501ms 7: clara-gw.rt1.mad.es.geant2.net 194.930ms 8: 2001:1348::29 302.328ms 9: 2001:1348:1::2 asymm 10 304.115ms 10: 2001:12f0:0:fc::16 asymm 11 308.389ms 11: 2001:12f0:0:fc::21 asymm 12 329. 63ms !H Resume: pmtu 1476 The host seems to be unreachable at the moment, but it looks like I'm almost there. > % traceroute6 2001:12f0:840:4092:204:acff:fe25:f5fb > traceroute6 to 2001:12f0:840:4092:204:acff:fe25:f5fb (2001:12f0:840:4092:204:acff:fe25:f5fb) from 2001:700:1:0:21e:4fff:feed:ced, 64 hops max, 12 byte packets > 1 uninett-gw 0.738 ms 0.777 ms 0.776 ms > 2 teknobyen-gw2 4.375 ms 2.81 ms 2.018 ms > 3 trd-gw1 0.778 ms 0.777 ms 6.827 ms > 4 hovedbygget-gw1 2.432 ms 0.778 ms 0.777 ms > 5 hovedbygget-gw4 0.777 ms 0.779 ms 0.777 ms > 6 stolav-gw4 7.638 ms 7.563 ms 7.596 ms > 7 stolav-gw1 7.813 ms 7.567 ms 7.617 ms > 8 oslo-gw 10.824 ms 21.657 ms 7.787 ms > 9 se-tug.nordu.net 15.616 ms 15.589 ms 15.493 ms > 10 se-fre.nordu.net 15.982 ms 21.764 ms 15.939 ms > 11 dk-ore.nordu.net 25.648 ms 25.612 ms 25.621 ms > 12 nordunet.rt2.cop.dk.geant2.net 25.7 ms 25.692 ms 25.644 ms > 13 so-7-3-0.rt1.fra.de.geant2.net 39.547 ms 39.693 ms 39.679 ms > 14 so-6-2-0.rt1.gen.ch.geant2.net 47.857 ms 51.778 ms 47.776 ms > 15 so-7-0-0.rt1.mad.es.geant2.net 69.869 ms 69.756 ms 69.889 ms > 16 clara-gw.rt1.mad.es.geant2.net 184.347 ms 184.017 ms 184.216 ms > 17 2001:1348::29 292.177 ms 292.174 ms 292.116 ms > 18 2001:1348:1::2 300.53 ms 325.921 ms 292.639 ms > 19 2001:12f0:0:fc::16 298.086 ms 298.917 ms 298.315 ms > 20 2001:12f0:0:fc::21 318.522 ms 352.891 ms 318.153 ms > 21 2001:12f0:0:3020::2 318.748 ms 318.556 ms 318.951 ms > 22 2001:12f0:840:169::2 318.973 ms 318.866 ms 319.07 ms > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > ^C > % > > Some folks obviously don't beleive in ip6.arpa :) Well, all those 0.0.0... give me headaches too ;) Cheers, j. -- NCC09 - Netart Community Convention 2009 What the net! 23.11.09 - 29.11.09 Graz/Austria https://wiki.mur.at/ncc09/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20091028/3dd5b90f/attachment.bin From dr at cluenet.de Thu Oct 29 01:06:35 2009 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 29 Oct 2009 01:06:35 +0100 Subject: Breakage due to Hurricane Electric/Internet2 In-Reply-To: <4AE8B5B6.8070003@mur.at> References: <4ACC54F5.5060507@mur.at> <87vdircwr2.fsf_-_@mid.deneb.enyo.de> <20091007.134437.107323778.he@uninett.no> <4AE8B5B6.8070003@mur.at> Message-ID: <20091029000635.GA17822@srv03.cluenet.de> On Wed, Oct 28, 2009 at 10:20:54PM +0100, Jogi Hofmueller wrote: > Quite awkward. This mail was on route for >20 days! According to how I > read the header, mail1.cluenet.de kept it for a while. Yes, because the poster didn't post using his subscribed email address, so the posting got held for approval. And I don't have much time lately so it might take some (few) weeks until I get around to wade through a couple thousand of held-for-moderation mails in the queue. Will be fixed as soon as I have spam filtering in place at SMTP level. And then folks will start complaining about false positives. The spammers have won, they broke email. :-( Now back to ontopic stuff. :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From LLE at dk.ibm.com Thu Oct 29 16:02:45 2009 From: LLE at dk.ibm.com (Lasse Leegaard) Date: Thu, 29 Oct 2009 16:02:45 +0100 Subject: AUTO: Lasse Leegaard is out of the office. (returning 03-11-2009) Message-ID: I am out of the office until 03-11-2009. For changes, incidents and problems contact SDDK infrastructure (dm129core at dk.ibm.com) or Kim Lundsteen (kim5 at dk.ibm.com) For management escalations contact Michael Claus Hansen (hansenmi at dk.ibm.com) Note: This is an automated response to your message "ipv6-ops Digest, Vol 55, Issue 15" sent on 29/10/09 12:00:01. This is the only notification you will receive while this person is away.