From mohacsi at niif.hu Mon Mar 1 09:38:22 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 1 Mar 2010 09:38:22 +0100 (CET) Subject: D-Link to support DHCPv6-PD soon In-Reply-To: References: Message-ID: On Sat, 27 Feb 2010, Frank Bulk wrote: > Heard from a D-Link product manager that code that supports DHCPv6-PD will > be available in the next month or two. I had asked about the DIR-615 and > DIR-825, but he didn't mention which platform(s). Unfortunately the support and development at D-link did not match. I reported an IPv6 problem half year ago to D-link support. I got answer that next major release will fix the problem - expected release around November 2010. No major release since then (not even a bug fix release). Best Regards, Janos Mohacsi From tore.anderson at redpill-linpro.com Mon Mar 1 10:30:09 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 01 Mar 2010 10:30:09 +0100 Subject: IPv6 brokenness in Norway, February 2010 Message-ID: <4B8B8921.7060909@redpill-linpro.com> Hi list, find attached the brokenness reports for February. This time they're generated from the readers of www.vg.no, Norway's largest web site. The brokenness number is below 0.1% for the first time. Another thing worth mentioning is that Opera 10.50 is due to be released soon (RC3 was posted today). 10.50 will be RFC 3484 compliant (on Windows at least), so the majority of those 0.1% will likely go away once their users have upgraded. For the remaining 0.03% of brokenness not caused by Opera, I've been unable to pinpoint any major causes. Mac OS X-based clients seems to be over-represented, though. I'm also suspecting that some of the reported brokenness is in reality just an artifact caused by the average client-server latency being higher over IPv6 than over IPv4. In any case I'm optimistic that we'll see some major content being made available over IPv6 in Norway this month. BR, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 201002.txt Url: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100301/f763eda0/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 201002-noopera.txt Url: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100301/f763eda0/attachment-0001.txt From madams at netcologne.de Mon Mar 1 14:54:52 2010 From: madams at netcologne.de (Michael Adams) Date: Mon, 01 Mar 2010 14:54:52 +0100 Subject: D-Link to support DHCPv6-PD soon In-Reply-To: References: Message-ID: <4B8BC72C.16739.43BAB569@madams.netcologne.de> Frank Bulk, 27 Feb 2010 10:59: > Heard from a D-Link product manager that code that supports DHCPv6-PD will > be available in the next month or two. I had asked about the DIR-615 and > DIR-825, but he didn't mention which platform(s). I checked the 825 last december and ppp with v6 was not working. D-Link support offered a new firmware (2.02eub01) end of december. This one was far away from running smoothly but at least I could get a ppp session running. The 825 did ppp double session when using v4 and v6. IPv6 without ppp was running without problems. regards, Michael -- Michael Adams Tel: +49 221 2222 657 Network Engineering & Design Fax: +49 221 2222 7657 NetCologne Gesch?ftsf?hrer Gesellschaft f?r Telekommunikation mbH Werner Hanf Am Coloneum 9 Dipl.-Ing. Karl-Heinz Zankel 50829 K?ln HRB 25580, Amtsgericht K?ln From tedm at ipinc.net Tue Mar 2 07:10:10 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 01 Mar 2010 22:10:10 -0800 Subject: D-Link to support DHCPv6-PD soon In-Reply-To: <4B8BC72C.16739.43BAB569@madams.netcologne.de> References: <4B8BC72C.16739.43BAB569@madams.netcologne.de> Message-ID: <4B8CABC2.8020208@ipinc.net> I placed a new DIR-615 3 weeks ago at a customer, with the latest firmware. The customer reported the thing kept crashing about once a day. I replaced it with an Airlink 101 running dd-wrt firmware last week, no crashes since. The openwrt people reported they got openwrt running on a DIR-615, I wish you would tell your D-link product manager that if they really wanted to help the IPv6 community that they would dump that crap software they have on the 615 and start shipping them with openwrt. This reinventing the wheel stuff is bullshit when you can't do it better. Openwrt already has Ipv6 in it. Ted Michael Adams wrote: > Frank Bulk, 27 Feb 2010 10:59: > >> Heard from a D-Link product manager that code that supports DHCPv6-PD will >> be available in the next month or two. I had asked about the DIR-615 and >> DIR-825, but he didn't mention which platform(s). > > I checked the 825 last december and ppp with v6 was not working. D-Link support > offered a new firmware (2.02eub01) end of december. This one was far away from > running smoothly but at least I could get a ppp session running. The 825 did > ppp double session when using v4 and v6. IPv6 without ppp was running without > problems. > > regards, > Michael > From madams at netcologne.de Tue Mar 2 10:42:59 2010 From: madams at netcologne.de (Michael Adams) Date: Tue, 02 Mar 2010 10:42:59 +0100 Subject: D-Link to support DHCPv6-PD soon In-Reply-To: <4B8CABC2.8020208@ipinc.net> References: , <4B8BC72C.16739.43BAB569@madams.netcologne.de>, <4B8CABC2.8020208@ipinc.net> Message-ID: <4B8CDDA3.29940.47FA8842@madams.netcologne.de> Ted Mittelstaedt, 1 Mar 2010 22:10: > I wish you would tell your D-link product manager that if they really > wanted to help the IPv6 community that they would dump that crap > software they have on the 615 and start shipping them with openwrt. We don't have a D-Link product manager but if one pops up here trying to sell CPE's I'll surely ask for proper v6 functionality :) regards, Michael -- Michael Adams Tel: +49 221 2222 657 Network Engineering & Design Fax: +49 221 2222 7657 NetCologne Gesch?ftsf?hrer Gesellschaft f?r Telekommunikation mbH Werner Hanf Am Coloneum 9 Dipl.-Ing. Karl-Heinz Zankel 50829 K?ln HRB 25580, Amtsgericht K?ln From thomas at cis.uni-muenchen.de Tue Mar 2 11:07:45 2010 From: thomas at cis.uni-muenchen.de (=?UTF-8?B?VGhvbWFzIFNjaMOkZmVy?=) Date: Tue, 02 Mar 2010 11:07:45 +0100 Subject: AVM? In-Reply-To: <4B8CDDA3.29940.47FA8842@madams.netcologne.de> References: , <4B8BC72C.16739.43BAB569@madams.netcologne.de>, <4B8CABC2.8020208@ipinc.net> <4B8CDDA3.29940.47FA8842@madams.netcologne.de> Message-ID: <4B8CE371.7090303@cis.uni-muenchen.de> Hi, since weekend avm has released a new betafirmware for ipv6. Has somebody tried? I use it. But I am a little bit confused. E.g. I can configure the ipv6-Firewall only for one/(first?) device - it should be more. Release notes say: based on Interface-ID. Also every change of settings of the firewall cuts the external connection. A test for native ipv6 has also failed, possibly because of missing support by t-home/t-dsl. Sixxs-tunnel works as before(Version from 10/2009). Similar or different experiences? Regards, Thomas Sch?fer -- There?s no place like ::1 Thomas Sch?fer (Systemverwaltung) Ludwig-Maximilians-Universit?t Centrum f?r Informations- und Sprachverarbeitung Schellingstra?e 10 Raum J407A 80799 M?nchen ? +49/89/2180-9706 ? +49/89/2180-9701 From gert at space.net Tue Mar 2 11:19:27 2010 From: gert at space.net (Gert Doering) Date: Tue, 2 Mar 2010 11:19:27 +0100 Subject: D-Link to support DHCPv6-PD soon In-Reply-To: <4B8CABC2.8020208@ipinc.net> References: <4B8BC72C.16739.43BAB569@madams.netcologne.de> <4B8CABC2.8020208@ipinc.net> Message-ID: <20100302101927.GO1464@Space.Net> Hi, On Mon, Mar 01, 2010 at 10:10:10PM -0800, Ted Mittelstaedt wrote: > Openwrt already has Ipv6 in it. I haven't checked in a while - does OpenWRT have a DHCP-PD implementation? (As this is how this thread got started...) But anyway, I agree with you. Vendors that would just join forces with one of the OpenWRT/DD-WRT/... camps could save development effort while shipping a better product... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 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 mohacsi at niif.hu Tue Mar 2 12:23:27 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 2 Mar 2010 12:23:27 +0100 (CET) Subject: D-Link to support DHCPv6-PD soon In-Reply-To: <20100302101927.GO1464@Space.Net> References: <4B8BC72C.16739.43BAB569@madams.netcologne.de> <4B8CABC2.8020208@ipinc.net> <20100302101927.GO1464@Space.Net> Message-ID: On Tue, 2 Mar 2010, Gert Doering wrote: > Hi, > > On Mon, Mar 01, 2010 at 10:10:10PM -0800, Ted Mittelstaedt wrote: >> Openwrt already has Ipv6 in it. > > I haven't checked in a while - does OpenWRT have a DHCP-PD implementation? install wide-dhcpv6 client and configure for prefix delegation and write hotplug scripts. Or use native6 available at: http://www.andy.id.au/Home/openwrt/nativev6 > > (As this is how this thread got started...) > > But anyway, I agree with you. Vendors that would just join forces with > one of the OpenWRT/DD-WRT/... camps could save development effort while > shipping a better product... > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 144438 > > 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 swmike at swm.pp.se Tue Mar 2 12:45:25 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 2 Mar 2010 12:45:25 +0100 (CET) Subject: D-Link to support DHCPv6-PD soon In-Reply-To: <4B8CDDA3.29940.47FA8842@madams.netcologne.de> References: , <4B8BC72C.16739.43BAB569@madams.netcologne.de>, <4B8CABC2.8020208@ipinc.net> <4B8CDDA3.29940.47FA8842@madams.netcologne.de> Message-ID: On Tue, 2 Mar 2010, Michael Adams wrote: > We don't have a D-Link product manager but if one pops up here trying to > sell CPE's I'll surely ask for proper v6 functionality :) Also ask them about long term plans for the platform. I bought a DIR-855 over a year ago, and there has been a single software update for it without any new features and no IPv6 functionality at all. Since D-link makes all their money off of new box sales, I guess it'll never get it either. It seems like companies like Apple and Google who makes money off of services have much bigger incentive to keep their products updated with new features as opposed to companies that only sell products and then see no reason to supply updates or new functionality. I'd gladly pay 30 USD to get a software update for my DIR-855 with IPv6, but I guess handling money transfers and licenses eats up the profit from such a model... -- Mikael Abrahamsson email: swmike at swm.pp.se From tedm at ipinc.net Tue Mar 2 20:19:07 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 02 Mar 2010 11:19:07 -0800 Subject: D-Link to support DHCPv6-PD soon In-Reply-To: References: , <4B8BC72C.16739.43BAB569@madams.netcologne.de>, <4B8CABC2.8020208@ipinc.net> <4B8CDDA3.29940.47FA8842@madams.netcologne.de> Message-ID: <4B8D64AB.4010508@ipinc.net> Mikael Abrahamsson wrote: > On Tue, 2 Mar 2010, Michael Adams wrote: > >> We don't have a D-Link product manager but if one pops up here trying >> to sell CPE's I'll surely ask for proper v6 functionality :) > > Also ask them about long term plans for the platform. I bought a DIR-855 > over a year ago, and there has been a single software update for it > without any new features and no IPv6 functionality at all. > > Since D-link makes all their money off of new box sales, I guess it'll > never get it either. > > It seems like companies like Apple and Google who makes money off of > services have much bigger incentive to keep their products updated with > new features as opposed to companies that only sell products and then > see no reason to supply updates or new functionality. I'd gladly pay 30 > USD to get a software update for my DIR-855 with IPv6, but I guess The 855 uses the second generation Atheros AR9001AP-3NX2 chipset with a Ubicom processor. Much of D-links stuff is Ubicom-based. The problem with Ubicom CPU's is that Ubicom has not supplied docs about their CPU microcode and so until recently no backend existed for GCC that would allow you to compile code for it. This originally didn't matter (to them) but recently they have seen sales drop off as more and more router vendors have gone to Linux, and so they released this thing they call GNUPro which appears to be a proprietary IDE that is a mashup of GNU code and their own proprietary code. Since it's incompatible with the build environments used by both OpenWRT and DDwrt, it's sole purpose appears to be to allow Ubicom to run around claiming that their stuff is now "OpenWRT compliant" when in reality nobody has been willing yet to rewrite all of the build scripts and makefiles and such to actually compile openwrt or ddwrt on their stuff. > handling money transfers and licenses eats up the profit from such a > model... > It's not that at all, in my humble opinion. These D-links, Airlinks, Belkins, Linksyses and so on are all the same, they are just repackagings of someone else's chipsets to make a quick buck - they are aimed at the bargain-hunters. These companies use whatever the cheapest chipsets they can buy, in bulk. For example take the Cisco 160N. There's been 3 hardware revs of that router, rev 1 used an older Broadcom chipset with a bit slower CPU, rev 2 used a ralink chipset, rev 3 went back to a newer Broadcom chipset. From the outside the routers look identical - but inside they are very different. And the rev 2 units are utter garbage. The only reason Cisco deviated from the Broadcom chips for the 160N is because they got a great deal on a boatload of Ralink silicon. The bargain-hunters aren't gonna pay money for software updates, so for any of these companies to put in money transfers and licenses would be a waste of time, no customers would buy them. For the last 6 months of so I've been snagging used dd-wrt capabable routers at flea markets and suchlike, for testing, in an effort to find a device that is the best platform for dd-wrt. What I found is that there's NO difference between any of them. It makes absolutely no difference who's name is on the plastic, it could be Airlink, Belkin, SMC, Linksys, Motorola, Buffalo or Dell, every last one of them works identically under dd-wrt with the same high reliability dd-wrt, unlike open-wrt, runs on 2MB flash routers, and there's a lot more of those in the used market than of 4MB flash routers, that's why I concentrated on dd-wrt. And you see here this is the problem, from the manufacturers point of view. If these guys simply concentrated on releasing hardware, and let the openwrt development go along as it did, then all of the various reviews out there would concentrate SOLEY on the hardware and packaging. When you have a Motorola, a D-link, and a Linksys all using the same Broadcom chipset, same flash and ram, then the consumer is not going to care what device he buys, he's just going to buy the cheapest one, because he knows that all the devices are going to work the same. These router vendors don't want to be competing on price - not directly, at any rate. They want to go against each other in features. When magazines do reviews and router "bakeoffs" they NEVER subject the devices to uptime comparisons. To do so would mean they would have to spend months with 20-30 devices sitting on test benches running a test suite, it would greatly lengthen the amount of time to press, and tremendously increase the cost of writing the review. Thus the incentive for these manufacturers is to throw as many features into the code and long term reliability be damned. For example, the D-link DIR-655 firmware proudly proclaims itself "bittorrent certified" What the hell is that? Who but some gamer gives a fig about that? To me that merely means that the gamer running bittorrent only has to power-cycle his router every day instead of every hour - but he's still not going to blink an eye on having to power-cycle his router at all. Ted From nicholas.hatch at gmail.com Tue Mar 2 20:37:14 2010 From: nicholas.hatch at gmail.com (nick hatch) Date: Tue, 2 Mar 2010 11:37:14 -0800 Subject: D-Link to support DHCPv6-PD soon In-Reply-To: <4B8D64AB.4010508@ipinc.net> References: <4B8BC72C.16739.43BAB569@madams.netcologne.de> <4B8CABC2.8020208@ipinc.net> <4B8CDDA3.29940.47FA8842@madams.netcologne.de> <4B8D64AB.4010508@ipinc.net> Message-ID: On Tue, Mar 2, 2010 at 11:19 AM, Ted Mittelstaedt wrote: > > For example, the D-link DIR-655 firmware proudly proclaims itself > "bittorrent certified" > > What the hell is that? Who but some gamer gives a fig about that? > To me that merely means that the gamer running bittorrent only has > to power-cycle his router every day instead of every hour - but he's > still not going to blink an eye on having to power-cycle his router > at all. IIRC, the problem with Bittorrent on the first Linux based routers (Linksys WRT54G, for example), was that the timeout for a particular NAT table was set too high, and could be exhausted with a high rate of TCP connection turnover. DD-WRT et al provided better sane defaults, and gave users access to the right knobs to prevent this problem. If I were an engineer at D-link observing this situation, I'd be proud of fixing the problem in a stock configuration, and might even whisper to the marketing department too... Silly, yes. But it makes a bit of sense. Why you're conflating Bittorrent traffic with gamers, I don't know. However, having lived with gamers, I can tell you that they most certainly care about such things (latency, reliability) more than other users. If my torrent traffic impeded a marathon gaming session and caused connections to drop, I have no doubt that I'd soon know what an aluminum baseball bat sounds like bouncing off a steel computer case. ObIPv6 question: Anyone know if other third party firmwares have IPv6 plans in the works, eg the Tomato firmware? DD-WRT is great, but for "normal users", I find Tomato a great drop in replacement for situations where a friend needs a hand, and I never want to touch the equipment ever again. -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100302/b06f05b1/attachment.html From tedm at ipinc.net Tue Mar 2 21:41:16 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 02 Mar 2010 12:41:16 -0800 Subject: D-Link to support DHCPv6-PD soon In-Reply-To: References: <4B8BC72C.16739.43BAB569@madams.netcologne.de> <4B8CABC2.8020208@ipinc.net> <4B8CDDA3.29940.47FA8842@madams.netcologne.de> <4B8D64AB.4010508@ipinc.net> Message-ID: <4B8D77EC.1000604@ipinc.net> nick hatch wrote: > On Tue, Mar 2, 2010 at 11:19 AM, Ted Mittelstaedt wrote: > >> For example, the D-link DIR-655 firmware proudly proclaims itself >> "bittorrent certified" >> >> What the hell is that? Who but some gamer gives a fig about that? >> To me that merely means that the gamer running bittorrent only has >> to power-cycle his router every day instead of every hour - but he's >> still not going to blink an eye on having to power-cycle his router >> at all. > > > IIRC, the problem with Bittorrent on the first Linux based routers (Linksys > WRT54G, for example), was that the timeout for a particular NAT table was > set too high, and could be exhausted with a high rate of TCP connection > turnover. DD-WRT et al provided better sane defaults, and gave users access > to the right knobs to prevent this problem. > > If I were an engineer at D-link observing this situation, I'd be proud of > fixing the problem in a stock configuration, and might even whisper to the > marketing department too... Silly, yes. But it makes a bit of sense. > > Why you're conflating Bittorrent traffic with gamers, I don't know. Probably because since I have never found much use for Bittorrent, I don't know who runs it. (and yes I know all about it's uses for illegal stuff) > However, > having lived with gamers, I can tell you that they most certainly care about > such things (latency, reliability) more than other users. If my torrent > traffic impeded a marathon gaming session and caused connections to drop, I > have no doubt that I'd soon know what an aluminum baseball bat sounds like > bouncing off a steel computer case. > > ObIPv6 question: Anyone know if other third party firmwares have IPv6 plans > in the works, eg the Tomato firmware? DD-WRT is great, but for "normal > users", I find Tomato a great drop in replacement for situations where a > friend needs a hand, and I never want to touch the equipment ever again. > I have run Tomato and it's fine, but it's lack of support for a lot of hardware really limits it. I also think development effort on it has really died down - from their point, it's "finished" dd-wrt doesn't "officially" support IPv6. One of the developers on the forum has a custom build that he updates from time to time that contains all of the extra command line IPv6 goodies and that runs in 4MB. "Official" support really would require 8MB because the dd-wrt people haven't been that interested in releasing a version of dd-wrt without all the "turn your AP into a free wireless node with advertising" software stuffed into it. Openwrt is also a roll-your-own with IPv6 support but at least the base load contains all the tools. The problem is that none of the OpenWRT gui's have so far supported it. With both it, and the modded dd-wrt load, IPv6 support has to be configured from the command line of the router. None of the other 3rd party firmwares out there have any active development support and are pretty much restricted to old hardware versions of the Linksys WRT54G. Ted > -Nick > From coairetaletosa16743 at gmail.com Wed Mar 3 19:00:47 2010 From: coairetaletosa16743 at gmail.com (Katy Voshell) Date: Wed, 3 Mar 2010 21:00:47 +0300 Subject: preteen pics, preteen sex pics, preteen lolita pics Message-ID: <9cdb3f2c1003031000k38c8e00t3e0afcf906edc5d2@mail.gmail.com> // // // Robert, look at this, tube site with prete**ns http://doiop.com/secretpage // // preteen pics preteen sex pics preteen lolita pics preteen nude pics preteen model pics nude preteen pics free preteen pics preteen girl pics preteen panty pics free preteen lolita pics preteen porn pics lolita preteen pics preteen in undies pics preteen nudist pics preteen pussy pics preteen art pics naked preteen pics non nude preteen pics preteen boy pics preteen bikini pics free preteen sex pics preteen girls pics illegal preteen pics lolita underage preteen pics preteens incest pics incest preteen preteen pics free preteen 8 15 pics preteen pics preteens preteen models pics preteen incest pics From coairetaletosa16743 at gmail.com Wed Mar 3 19:01:47 2010 From: coairetaletosa16743 at gmail.com (Katy Voshell) Date: Wed, 3 Mar 2010 21:01:47 +0300 Subject: lolitas, lolita bbs, preteen lolita Message-ID: <9cdb3f2c1003031001tdc58b16p3d3effbd9d03dcc2@mail.gmail.com> // // // Robert, look at this, tube site with prete**ns http://doiop.com/secretpage // // lolitas lolita bbs preteen lolita preteen lolitas lolita sex lolita mpegs lolita models little lolita lolita porn little lolitas young lolita lolita nude lolita pics russian lolita young lolitas lolita preteen lolita art lolitas bbs lolita girls nude lolitas lolita portal nude lolita russian lolitas underage lolita magic lolita lolita tgp asian lolita underage lolitas preteen lolita sex lolita pussy From coairetaletosa16743 at gmail.com Wed Mar 3 19:02:16 2010 From: coairetaletosa16743 at gmail.com (Katy Voshell) Date: Wed, 3 Mar 2010 21:02:16 +0300 Subject: kids nude, hidden cams on nude kids, little kids nude Message-ID: <9cdb3f2c1003031002h68f33a8j38dea63f2f303d6c@mail.gmail.com> // // // Robert, look at this, tube site with prete**ns http://doiop.com/secretpage // // kids nude hidden cams on nude kids little kids nude young kids nude nude little kids kids nude tgp nude russian kids young nude kids nude beach kids nearly nude kids russian kids nude little nude kids nude kids gallery nude kids sex nude preteen kids kids nude pics kids playing nude non nude kids nude kids porn nude young kids russian nude kids underage kids nude gay kids nude kids nudes nude black kids japanese kids nude kids in the nude kids nude preteen nude kids preteen nude kids world From coairetaletosa16743 at gmail.com Wed Mar 3 19:02:42 2010 From: coairetaletosa16743 at gmail.com (Katy Voshell) Date: Wed, 3 Mar 2010 21:02:42 +0300 Subject: ls magazine, ls magazine bbs, ls magazine lolita Message-ID: <9cdb3f2c1003031002v1c2ad168qa361965fd90a61cf@mail.gmail.com> // // // Robert, look at this, tube site with prete**ns http://doiop.com/secretpage // // ls magazine ls magazine bbs ls magazine lolita ls magazine pics ls magazine preteen ls magazine torrent ls magazine video angels ls magazine forum ls magazine models ls magazine nude ls magazine lolitas ls magazine free ls magazine issue lolita ls magazine ls lolita magazine ls magazine free pics ls magazine portal ls magazines ls land magazine ls magazine girls ls magazine picture ls magazine pictures ls models magazine ls magazine issue 2 ls magazine gallery ls island magazine ls magazine defloration ls magazine preview ls magazine sex ls girls magazine From coairetaletosa16743 at gmail.com Wed Mar 3 19:03:00 2010 From: coairetaletosa16743 at gmail.com (Katy Voshell) Date: Wed, 3 Mar 2010 21:03:00 +0300 Subject: illegal sex, illegal preteen sex, preteen sex, illegal sex Message-ID: <9cdb3f2c1003031003p14e686c7i5571a05a013a2449@mail.gmail.com> // // // Robert, look at this, tube site with prete**ns http://doiop.com/secretpage // // illegal sex illegal preteen sex preteen sex, illegal sex illegal teen sex hardcore illegal sex illegal sex pics illegal underage sex illegal teenage sex pics illegal lolita sex illegal sex pictures illegal sex videos underage sex lolita illegal illegal child sex pics illegal pre teen sex illegal young sex illegal child sex illegal preteen lolita sex illegal sex sites preteen illegal sex illegal underage sex pics illegal web cam sex free illegal sex clips illegal sex search engine illegal teen sex pics preteen illegal boy sex pics illegal family sex illegal young pre teen lolita sex illegal little girl sex illegal preteen sex sites underage illegal sex From coairetaletosa16743 at gmail.com Wed Mar 3 19:03:20 2010 From: coairetaletosa16743 at gmail.com (Katy Voshell) Date: Wed, 3 Mar 2010 21:03:20 +0300 Subject: pre teen sex, lolita pre teen sex, free pre teen incest sex Message-ID: <9cdb3f2c1003031003w1bd734dbi7388feb81578266d@mail.gmail.com> // // // Robert, look at this, tube site with prete**ns http://doiop.com/secretpage // // pre teen sex lolita pre teen sex free pre teen incest sex boys pre teen sex pre teen sex pics pre teen stories sex girl pre teen sex pictures illegal pre teen sex p2p pre teen sex pre teen sex doll russian pre teen sex pregnant pre teen sex illegal young pre teen lolita sex pre teen sex videos naked pre teen model sex videos lolitas pre teen sex pre teen hardcore sex pre teen models having sex pre teen sex search pre teen taboo sex young pre teen sex pre teen gay sex pre teen sex stories pre teen girls having sex pre teen sex lolita fucking very young pre teen sex little pre teen lesbian sex pre teen extreme sex sites pre teen lolita sex pre teen sex chill From coairetaletosa16743 at gmail.com Wed Mar 3 19:03:42 2010 From: coairetaletosa16743 at gmail.com (Katy Voshell) Date: Wed, 3 Mar 2010 21:03:42 +0300 Subject: ranchi bbs, ranchi bbs gateway, loli ranchi bbs Message-ID: <9cdb3f2c1003031003kcd9cf39x5a3e75ca167b172a@mail.gmail.com> // // // Robert, look at this, tube site with prete**ns http://doiop.com/secretpage // // ranchi bbs ranchi bbs gateway loli ranchi bbs ranchi bbs list bbs and ranchi and lolita ranchi lolita bbs lolita bbs ranchi zeps guide ranchi bbs bbs ranchi zep bbs pthc ranchi board bbs lolita zep ranchi bbs bbs guide ranchi zeps bbs ranchi lolita bbs ranchi mummy ranchi gate bbs bbs mummy ranchi bbs pthc ranchi lolita ranchi bbs ranchi bbs board bbs guide ranchi zeps, pthc links, pthc bbs guide ranchi bbs ranchi board ranchi bbs guide ranchi bbs zeps guide ranchi gateway bbs where is ranchi bbs ranchi bbs pthc ranchi bbs gateway svens bbs dorki max sven ranchi bbs elweb freedom ranchi From coairetaletosa16743 at gmail.com Wed Mar 3 19:04:30 2010 From: coairetaletosa16743 at gmail.com (Katy Voshell) Date: Wed, 3 Mar 2010 21:04:30 +0300 Subject: underage nudity, legal underage nudity, illegal underage nudity Message-ID: <9cdb3f2c1003031004s63b19a0dj7893671c63943428@mail.gmail.com> // // // Robert, look at this, tube site with prete**ns http://doiop.com/secretpage // // underage nudity legal underage nudity illegal underage nudity where can i see underage nudity movies with underage female nudity underage nudity galleries underage nudity pics underage girl nudity underage nudity torrents celebrities who did underage nudity in film films with underage nudity keira knightly underage nudity in the hole underage child nudity underage nudity in legitimate film underage nudity in volver underage nudity pictures underage pre teen nudity watch free underage nudity asian adolesent porn From coairetaletosa16743 at gmail.com Wed Mar 3 19:04:50 2010 From: coairetaletosa16743 at gmail.com (Katy Voshell) Date: Wed, 3 Mar 2010 21:04:50 +0300 Subject: lolita preteen, preteen lolita sex, preteen lolita bbs Message-ID: <9cdb3f2c1003031004h7fa6aeyb7808dc2a3fb3ac@mail.gmail.com> // // // Robert, look at this, tube site with prete**ns http://doiop.com/secretpage // // lolita preteen preteen lolita sex preteen lolita bbs preteen lolita models free lolita preteen galleries preteen lolita pics lolita preteen galleries child lolita preteen child sex preteen lolita preteen lolita art photography lolita russian preteen preteen cp illegal lolita bbs lolita preteen preteen lolita dolls preteen lolita portals lolita preteen model lolita preteens preteen lolita links lolita underage preteen uncensored lolita preteen preteen lolita stories preteen panties young lolita tgp lolita preteen models preteen lolita galleries preteen lolita nude free preteen lolita pics russian preteen lolita nude preteen lolita lolita sex underage, preteen fuck lolita preteen sex From coairetaletosa16743 at gmail.com Wed Mar 3 19:05:26 2010 From: coairetaletosa16743 at gmail.com (Katy Voshell) Date: Wed, 3 Mar 2010 21:05:26 +0300 Subject: hot preteens, hot young girls preteens, hot young preteens Message-ID: <9cdb3f2c1003031005l51b02d08na60908ddcb5a9423@mail.gmail.com> // // // Robert, look at this, tube site with prete**ns http://doiop.com/secretpage // // hot preteens hot young girls preteens hot young preteens hot nude preteens hot naked preteens hot lesbian preteens hot little preteens hot pics of preteens hot preteens nude hot preteens gallery hot preteens in thongs hot preteens naked hot wet nude preteens preteens hot hot black preteens hot preteens pics hot young girls preteens pussy lolita underage hot latino preteens hot preteens having sex hot preteens modeling hot russian preteens hot young girls preteens pussy lolita hot young preteens nude preteens hot pics preteens in hot pants young hot preteens young hot sexy preteens hot hairstyles for preteens hot non nude pics of preteens hot preteens galliers From swmike at swm.pp.se Fri Mar 5 10:24:54 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 5 Mar 2010 10:24:54 +0100 (CET) Subject: disabling client use of SLAAC Message-ID: Hi. We're trying out deployment scenarios and the first one was to try to mimic our current model with DHCPv4 but move that to DHCPv6. We have successfully gotten a 1841 using IOS 15.0(1)M to do DHCPv6 relaying to a wide-dhcp6-server running on a linux machine and in this combination handing out IPv6 addresses statefully. On the cisco router we have: interface FastEthernet0/1 encapsulation dot1Q 11 ipv6 address YY:XX::1/64 ipv6 enable ipv6 nd autoconfig default-route ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 nd ra interval 10 ipv6 dhcp relay destination XX:YY::ZZ On a linux ubuntu 9.10 machine (2.6.31 kernel) the default when running wide-dhcpv6-client is that it will get stateful IPv6 address from the dhcp6s scope and successfully set /etc/resolv.conf with information received via DHCPv6. It will also successfully get the on-wire prefix from RAs, and everything is fine and dandy apart from that the client by default will still do SLAAC as well, and so it gets two IPv6 addresses, one with SLAAC and one from DHCP. Putting 0 into /proc/sys/net/ipv6/conf/eth0/autconf will stop SLAAC, so then it does what we want, but would like to avoid changing defaults in the OS. We haven't tested Win7. Looking at the RAs from the router, it has the "auto" flag set on the prefix info option, is this the flag that indicates if SLAAC is ok or not? I have not been able to find any information on this and if indeed that flag tells clients if SLAAC should be done or not, then how do I disable that flag in the router? The M and O flags says "get info via DHCP", but it seems they don't mean "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt correctly? So bottom line, how to make clients not use SLAAC with a Cisco router? -- Mikael Abrahamsson email: swmike at swm.pp.se From otroan at employees.org Fri Mar 5 10:40:42 2010 From: otroan at employees.org (Ole Troan) Date: Fri, 5 Mar 2010 10:40:42 +0100 Subject: disabling client use of SLAAC In-Reply-To: References: Message-ID: Mikael, > We're trying out deployment scenarios and the first one was to try to mimic our current model with DHCPv4 but move that to DHCPv6. > > We have successfully gotten a 1841 using IOS 15.0(1)M to do DHCPv6 relaying to a wide-dhcp6-server running on a linux machine and in this combination handing out IPv6 addresses statefully. > > On the cisco router we have: > > interface FastEthernet0/1 > encapsulation dot1Q 11 > ipv6 address YY:XX::1/64 > ipv6 enable > ipv6 nd autoconfig default-route > ipv6 nd managed-config-flag > ipv6 nd other-config-flag > ipv6 nd ra interval 10 > ipv6 dhcp relay destination XX:YY::ZZ > > On a linux ubuntu 9.10 machine (2.6.31 kernel) the default when running wide-dhcpv6-client is that it will get stateful IPv6 address from the dhcp6s scope and successfully set /etc/resolv.conf with information received via DHCPv6. It will also successfully get the on-wire prefix from RAs, and everything is fine and dandy apart from that the client by default will still do SLAAC as well, and so it gets two IPv6 addresses, one with SLAAC and one from DHCP. Putting 0 into /proc/sys/net/ipv6/conf/eth0/autconf will stop SLAAC, so then it does what we want, but would like to avoid changing defaults in the OS. We haven't tested Win7. > > Looking at the RAs from the router, it has the "auto" flag set on the prefix info option, is this the flag that indicates if SLAAC is ok or not? yes, you need to turn the A flag off for each prefix you are advertising. > I have not been able to find any information on this and if indeed that flag tells clients if SLAAC should be done or not, then how do I disable that flag in the router? > > The M and O flags says "get info via DHCP", but it seems they don't mean "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt correctly? that's correct. you can do both DHCPv6 address assignment and SLAAC at the same time. > So bottom line, how to make clients not use SLAAC with a Cisco router? ipv6 nd prefix YY:XX::/64 no-autoconfig cheers, Ole From evyncke at cisco.com Fri Mar 5 10:45:30 2010 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Fri, 5 Mar 2010 10:45:30 +0100 Subject: disabling client use of SLAAC In-Reply-To: References: Message-ID: <317616CE96204D49B5A1811098BA89500165D455@XMB-AMS-110.cisco.com> Mikael You need indeed to send the RA with the prefix marked as not to be used for autoconfig. ipv6 nd prefix 2001:db8::/64 no-autoconfig -?ric > -----Original Message----- > From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de [mailto:ipv6-ops- > bounces+evyncke=cisco.com at lists.cluenet.de] On Behalf Of Mikael Abrahamsson > Sent: vendredi 5 mars 2010 10:25 > To: ipv6-ops at lists.cluenet.de > Subject: disabling client use of SLAAC > > > Hi. > > We're trying out deployment scenarios and the first one was to try to > mimic our current model with DHCPv4 but move that to DHCPv6. > > We have successfully gotten a 1841 using IOS 15.0(1)M to do DHCPv6 > relaying to a wide-dhcp6-server running on a linux machine and in this > combination handing out IPv6 addresses statefully. > > On the cisco router we have: > > interface FastEthernet0/1 > encapsulation dot1Q 11 > ipv6 address YY:XX::1/64 > ipv6 enable > ipv6 nd autoconfig default-route > ipv6 nd managed-config-flag > ipv6 nd other-config-flag > ipv6 nd ra interval 10 > ipv6 dhcp relay destination XX:YY::ZZ > > On a linux ubuntu 9.10 machine (2.6.31 kernel) the default when running > wide-dhcpv6-client is that it will get stateful IPv6 address from the > dhcp6s scope and successfully set /etc/resolv.conf with information > received via DHCPv6. It will also successfully get the on-wire prefix from > RAs, and everything is fine and dandy apart from that the client by > default will still do SLAAC as well, and so it gets two IPv6 addresses, > one with SLAAC and one from DHCP. Putting 0 into > /proc/sys/net/ipv6/conf/eth0/autconf will stop SLAAC, so then it does what > we want, but would like to avoid changing defaults in the OS. We haven't > tested Win7. > > Looking at the RAs from the router, it has the "auto" flag set on the > prefix info option, is this the flag that indicates if SLAAC is ok or not? > > I have not been able to find any information on this and if indeed that > flag tells clients if SLAAC should be done or not, then how do I disable > that flag in the router? > > The M and O flags says "get info via DHCP", but it seems they don't mean > "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt > correctly? > > So bottom line, how to make clients not use SLAAC with a Cisco router? > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From brian.e.carpenter at gmail.com Fri Mar 5 21:24:49 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 06 Mar 2010 09:24:49 +1300 Subject: disabling client use of SLAAC In-Reply-To: References: Message-ID: <4B916891.6020309@gmail.com> On 2010-03-05 22:24, Mikael Abrahamsson wrote: ... > The M and O flags says "get info via DHCP", but it seems they don't mean > "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt correctly? > > So bottom line, how to make clients not use SLAAC with a Cisco router? > Note that this is known to be a tricky area in mutlti-vendor, multi-o/s situations. Quoting draft-carpenter-renum-needs-work-05: We should note a currently unresolved ambiguity in the interaction between DHCPv6 and SLAAC from the host's point of view. RA messages include a 'Managed Configuration' flag known as the M bit, which is supposed to indicate that DHCPv6 is in use. However, it is unspecified whether hosts must interpret this flag rigidly (i.e., may or must only start DHCPv6 if it is set, or if no RAs are received) or whether hosts are allowed or are recommended to start DHCPv6 by default. An added complexity is that DHCPv6 has a 'stateless' mode [RFC3736] in which SLAAC is used to obtain an address but DHCPv6 is used to obtain other parameters. Another flag in RA messages, the 'Other configuration' or O bit, indicates this. Until this ambiguous behaviour is clearly resolved by the IETF, operational problems are to be expected, since different host operating systems have taken different approaches. This makes it difficult for a site network manager to configure systems in such a way that all hosts boot in a consistent way. Hosts will start SLAAC if so directed by appropriately configured RA messages. However, if one operating system also starts a DHCPv6 client by default, and another one starts it only when it receives the M bit, systematic address management is impeded. Brian From marcoh at marcoh.net Fri Mar 5 21:32:00 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 5 Mar 2010 21:32:00 +0100 Subject: disabling client use of SLAAC In-Reply-To: <4B916891.6020309@gmail.com> References: <4B916891.6020309@gmail.com> Message-ID: <37A6B906-CEAD-408B-914B-CA5918997CC4@marcoh.net> On 5 mrt 2010, at 21:24, Brian E Carpenter wrote: > On 2010-03-05 22:24, Mikael Abrahamsson wrote: > ... >> The M and O flags says "get info via DHCP", but it seems they don't mean >> "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt correctly? >> >> So bottom line, how to make clients not use SLAAC with a Cisco router? >> > > Note that this is known to be a tricky area in mutlti-vendor, multi-o/s > situations. Can't agree more. In the meantime, what about extending the subnet mask a few bits (/80) on the lan ? MarcoH From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Mar 6 00:06:56 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 6 Mar 2010 09:36:56 +1030 Subject: disabling client use of SLAAC In-Reply-To: <37A6B906-CEAD-408B-914B-CA5918997CC4@marcoh.net> References: <4B916891.6020309@gmail.com> <37A6B906-CEAD-408B-914B-CA5918997CC4@marcoh.net> Message-ID: <20100306093656.5826ffc6@opy.nosense.org> On Fri, 5 Mar 2010 21:32:00 +0100 Marco Hogewoning wrote: > > On 5 mrt 2010, at 21:24, Brian E Carpenter wrote: > > > On 2010-03-05 22:24, Mikael Abrahamsson wrote: > > ... > >> The M and O flags says "get info via DHCP", but it seems they don't mean > >> "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt correctly? > >> > >> So bottom line, how to make clients not use SLAAC with a Cisco router? > >> > > > > Note that this is known to be a tricky area in mutlti-vendor, multi-o/s > > situations. > > > > > Can't agree more. In the meantime, what about extending the subnet mask a few bits (/80) on the lan ? > Why? > MarcoH > From otroan at employees.org Sat Mar 6 00:18:47 2010 From: otroan at employees.org (Ole Troan) Date: Sat, 6 Mar 2010 00:18:47 +0100 Subject: disabling client use of SLAAC In-Reply-To: <4B916891.6020309@gmail.com> References: <4B916891.6020309@gmail.com> Message-ID: <0274DDC8-069F-44AB-9E1B-B8353E5B1E9C@employees.org> Brian, >> The M and O flags says "get info via DHCP", but it seems they don't mean >> "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt correctly? >> >> So bottom line, how to make clients not use SLAAC with a Cisco router? >> > > Note that this is known to be a tricky area in mutlti-vendor, multi-o/s > situations. > > Quoting draft-carpenter-renum-needs-work-05: > > We should note a currently unresolved ambiguity in the interaction > between DHCPv6 and SLAAC from the host's point of view. RA messages > include a 'Managed Configuration' flag known as the M bit, which is > supposed to indicate that DHCPv6 is in use. However, it is > unspecified whether hosts must interpret this flag rigidly (i.e., may > or must only start DHCPv6 if it is set, or if no RAs are received) or > whether hosts are allowed or are recommended to start DHCPv6 by > default. An added complexity is that DHCPv6 has a 'stateless' mode > [RFC3736] in which SLAAC is used to obtain an address but DHCPv6 is > used to obtain other parameters. Another flag in RA messages, the > 'Other configuration' or O bit, indicates this. > > Until this ambiguous behaviour is clearly resolved by the IETF, > operational problems are to be expected, since different host > operating systems have taken different approaches. This makes it > difficult for a site network manager to configure systems in such a > way that all hosts boot in a consistent way. Hosts will start SLAAC > if so directed by appropriately configured RA messages. However, if > one operating system also starts a DHCPv6 client by default, and > another one starts it only when it receives the M bit, systematic > address management is impeded. I wouldn't say it is quite that indeterministic. a network manager is still in making the choice of what address assignment mechanism to use. I think you can reasonably safely assume that a host will use SLAAC if the A flag is set. it will not do SLAAC if the A flag is off. if it supports DHCPv6 it will most likely do DHCP if the M-flag is set and it may do it without, and especially in the case where the A flag is off. (;-)) if a host tries DHCP on a link which doesn't support it. no harm done. cheers, Ole From brian.e.carpenter at gmail.com Sat Mar 6 00:39:17 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 06 Mar 2010 12:39:17 +1300 Subject: disabling client use of SLAAC In-Reply-To: <0274DDC8-069F-44AB-9E1B-B8353E5B1E9C@employees.org> References: <4B916891.6020309@gmail.com> <0274DDC8-069F-44AB-9E1B-B8353E5B1E9C@employees.org> Message-ID: <4B919625.6050201@gmail.com> Ole, On 2010-03-06 12:18, Ole Troan wrote: > Brian, > >>> The M and O flags says "get info via DHCP", but it seems they don't mean >>> "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt correctly? >>> >>> So bottom line, how to make clients not use SLAAC with a Cisco router? >>> >> Note that this is known to be a tricky area in mutlti-vendor, multi-o/s >> situations. >> >> Quoting draft-carpenter-renum-needs-work-05: >> >> We should note a currently unresolved ambiguity in the interaction >> between DHCPv6 and SLAAC from the host's point of view. RA messages >> include a 'Managed Configuration' flag known as the M bit, which is >> supposed to indicate that DHCPv6 is in use. However, it is >> unspecified whether hosts must interpret this flag rigidly (i.e., may >> or must only start DHCPv6 if it is set, or if no RAs are received) or >> whether hosts are allowed or are recommended to start DHCPv6 by >> default. An added complexity is that DHCPv6 has a 'stateless' mode >> [RFC3736] in which SLAAC is used to obtain an address but DHCPv6 is >> used to obtain other parameters. Another flag in RA messages, the >> 'Other configuration' or O bit, indicates this. >> >> Until this ambiguous behaviour is clearly resolved by the IETF, >> operational problems are to be expected, since different host >> operating systems have taken different approaches. This makes it >> difficult for a site network manager to configure systems in such a >> way that all hosts boot in a consistent way. Hosts will start SLAAC >> if so directed by appropriately configured RA messages. However, if >> one operating system also starts a DHCPv6 client by default, and >> another one starts it only when it receives the M bit, systematic >> address management is impeded. > > I wouldn't say it is quite that indeterministic. > a network manager is still in making the choice of what address assignment mechanism to use. Well, the feedback we got on our renumbering draft definitely indicated operational uncertainty in real usage. > I think you can reasonably safely assume that a host will use SLAAC if the A flag is set. it will not do SLAAC if the A flag is off. if it supports DHCPv6 it will most likely do DHCP if the M-flag is set and it may do it without, and especially in the case where the A flag is off. (;-)) Thanks, I think we should think about adding that to our draft (except that it's already almost passed the IESG.) > if a host tries DHCP on a link which doesn't support it. no harm done. Agreed, apart from a little wasted time. Brian From swmike at swm.pp.se Sat Mar 6 06:41:57 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 6 Mar 2010 06:41:57 +0100 (CET) Subject: disabling client use of SLAAC In-Reply-To: <317616CE96204D49B5A1811098BA89500165D455@XMB-AMS-110.cisco.com> References: <317616CE96204D49B5A1811098BA89500165D455@XMB-AMS-110.cisco.com> Message-ID: On Fri, 5 Mar 2010, Eric Vyncke (evyncke) wrote: > You need indeed to send the RA with the prefix marked as not to be used for autoconfig. > > ipv6 nd prefix 2001:db8::/64 no-autoconfig Thanks everybody who replied, just want to say that: ipv6 nd prefix default 300 300 no-autoconfig did the trick. -- Mikael Abrahamsson email: swmike at swm.pp.se From prox at prolixium.com Sat Mar 6 17:56:34 2010 From: prox at prolixium.com (Mark Kamichoff) Date: Sat, 6 Mar 2010 11:56:34 -0500 Subject: disabling client use of SLAAC In-Reply-To: <20100306093656.5826ffc6@opy.nosense.org> References: <4B916891.6020309@gmail.com> <37A6B906-CEAD-408B-914B-CA5918997CC4@marcoh.net> <20100306093656.5826ffc6@opy.nosense.org> Message-ID: <20100306165634.GC9341@prolixium.com> On Sat, Mar 06, 2010 at 09:36:56AM +1030, Mark Smith wrote: > On Fri, 5 Mar 2010 21:32:00 +0100 > Marco Hogewoning wrote: > > > > > On 5 mrt 2010, at 21:24, Brian E Carpenter wrote: > > > > > On 2010-03-05 22:24, Mikael Abrahamsson wrote: > > > ... > > >> The M and O flags says "get info via DHCP", but it seems they don't mean > > >> "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt correctly? > > >> > > >> So bottom line, how to make clients not use SLAAC with a Cisco router? > > >> > > > > > > Note that this is known to be a tricky area in mutlti-vendor, multi-o/s > > > situations. > > > > > > > > > > Can't agree more. In the meantime, what about extending the subnet mask a few bits (/80) on the lan ? > > Why? Autoconf doesn't work for on >64 bit prefixes, so extending it to an 80 is a [interesting] way of disabling it completely. - Mark -- Mark Kamichoff prox at prolixium.com http://www.prolixium.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100306/74b89acf/attachment.bin From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Mar 6 22:41:02 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 7 Mar 2010 08:11:02 +1030 Subject: disabling client use of SLAAC In-Reply-To: <20100306165634.GC9341@prolixium.com> References: <4B916891.6020309@gmail.com> <37A6B906-CEAD-408B-914B-CA5918997CC4@marcoh.net> <20100306093656.5826ffc6@opy.nosense.org> <20100306165634.GC9341@prolixium.com> Message-ID: <20100307081102.6b43b08c@opy.nosense.org> On Sat, 6 Mar 2010 11:56:34 -0500 Mark Kamichoff wrote: > On Sat, Mar 06, 2010 at 09:36:56AM +1030, Mark Smith wrote: > > On Fri, 5 Mar 2010 21:32:00 +0100 > > Marco Hogewoning wrote: > > > > > > > > On 5 mrt 2010, at 21:24, Brian E Carpenter wrote: > > > > > > > On 2010-03-05 22:24, Mikael Abrahamsson wrote: > > > > ... > > > >> The M and O flags says "get info via DHCP", but it seems they don't mean > > > >> "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt correctly? > > > >> > > > >> So bottom line, how to make clients not use SLAAC with a Cisco router? > > > >> > > > > > > > > Note that this is known to be a tricky area in mutlti-vendor, multi-o/s > > > > situations. > > > > > > > > > > > > > > > Can't agree more. In the meantime, what about extending the subnet mask a few bits (/80) on the lan ? > > > > Why? > > Autoconf doesn't work for on >64 bit prefixes, so extending it to an 80 > is a [interesting] way of disabling it completely. > So is announcing RA Prefix Information options without the autonomous address-configuration flag set. I'd doubt anybody would be willing to standardise hack like that when there is already a proper way to stop nodes autoconfiguring addresses. Regards, Mark. From berni at birkenwald.de Sun Mar 7 00:42:51 2010 From: berni at birkenwald.de (Bernhard Schmidt) Date: Sun, 07 Mar 2010 00:42:51 +0100 Subject: disabling client use of SLAAC In-Reply-To: <20100307081102.6b43b08c@opy.nosense.org> References: <4B916891.6020309@gmail.com> <37A6B906-CEAD-408B-914B-CA5918997CC4@marcoh.net> <20100306093656.5826ffc6@opy.nosense.org> <20100306165634.GC9341@prolixium.com> <20100307081102.6b43b08c@opy.nosense.org> Message-ID: <4B92E87B.9090803@birkenwald.de> On 06.03.2010 22:41, Mark Smith wrote: Bernhard >> Autoconf doesn't work for on>64 bit prefixes, so extending it to an 80 >> is a [interesting] way of disabling it completely. > So is announcing RA Prefix Information options without the > autonomous address-configuration flag set. I'd doubt anybody > would be willing to standardise hack like that when there is already a > proper way to stop nodes autoconfiguring addresses. Except it doesn't work everywhere, for example it's not available in the most recent NX-OS 4.2 (Cisco Nexus 7000). You can either do "ipv6 nd suppress-ra" on that platform (which had (has?) the nasty problem of one RA being sent during software upgrade, hello SLAAC on >500 cluster hosts), or use a prefixlen != /64. Bernhard From otroan at employees.org Sun Mar 7 00:59:18 2010 From: otroan at employees.org (Ole Troan) Date: Sun, 7 Mar 2010 00:59:18 +0100 Subject: disabling client use of SLAAC In-Reply-To: <4B92E87B.9090803@birkenwald.de> References: <4B916891.6020309@gmail.com> <37A6B906-CEAD-408B-914B-CA5918997CC4@marcoh.net> <20100306093656.5826ffc6@opy.nosense.org> <20100306165634.GC9341@prolixium.com> <20100307081102.6b43b08c@opy.nosense.org> <4B92E87B.9090803@birkenwald.de> Message-ID: >>> Autoconf doesn't work for on>64 bit prefixes, so extending it to an 80 >>> is a [interesting] way of disabling it completely. >> So is announcing RA Prefix Information options without the >> autonomous address-configuration flag set. I'd doubt anybody >> would be willing to standardise hack like that when there is already a >> proper way to stop nodes autoconfiguring addresses. > > Except it doesn't work everywhere, for example it's not available in the most recent NX-OS 4.2 (Cisco Nexus 7000). You can either do "ipv6 nd suppress-ra" on that platform (which had (has?) the nasty problem of one RA being sent during software upgrade, hello SLAAC on >500 cluster hosts), or use a prefixlen != /64. this is obviously a bug. I'll speak to my colleagues in NX-OS land to get that fixed. another workaround may also be to not advertise any prefix on the link at all and just use the RA to advertise the default router. I presume you use manual addressing? cheers, Ole From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Mar 7 01:41:40 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 7 Mar 2010 11:11:40 +1030 Subject: disabling client use of SLAAC In-Reply-To: <4B92E87B.9090803@birkenwald.de> References: <4B916891.6020309@gmail.com> <37A6B906-CEAD-408B-914B-CA5918997CC4@marcoh.net> <20100306093656.5826ffc6@opy.nosense.org> <20100306165634.GC9341@prolixium.com> <20100307081102.6b43b08c@opy.nosense.org> <4B92E87B.9090803@birkenwald.de> Message-ID: <20100307111140.570bcb48@opy.nosense.org> On Sun, 07 Mar 2010 00:42:51 +0100 Bernhard Schmidt wrote: > On 06.03.2010 22:41, Mark Smith wrote: > > Bernhard > > >> Autoconf doesn't work for on>64 bit prefixes, so extending it to an 80 > >> is a [interesting] way of disabling it completely. > > So is announcing RA Prefix Information options without the > > autonomous address-configuration flag set. I'd doubt anybody > > would be willing to standardise hack like that when there is already a > > proper way to stop nodes autoconfiguring addresses. > > Except it doesn't work everywhere, for example it's not available in the > most recent NX-OS 4.2 (Cisco Nexus 7000). You can either do "ipv6 nd > suppress-ra" on that platform (which had (has?) the nasty problem of one > RA being sent during software upgrade, hello SLAAC on >500 cluster > hosts), or use a prefixlen != /64. > So the IETF should develop and standardise another mechanism to disable address autoconf, and then have all implementations of IPv6 (routers and end-nodes) be updated to support it, just because Cisco haven't got around to implementing the cli option to flip a bit in an RA option on one of their product lines? I think this is clearly a Cisco issue, not an IETF one, so Cisco are the ones who need to fix it. Lodge a fault with them. > Bernhard From john at sackheads.org Sun Mar 7 04:33:53 2010 From: john at sackheads.org (John Payne) Date: Sat, 6 Mar 2010 22:33:53 -0500 Subject: disabling client use of SLAAC In-Reply-To: <4B92E87B.9090803@birkenwald.de> References: <4B916891.6020309@gmail.com> <37A6B906-CEAD-408B-914B-CA5918997CC4@marcoh.net> <20100306093656.5826ffc6@opy.nosense.org> <20100306165634.GC9341@prolixium.com> <20100307081102.6b43b08c@opy.nosense.org> <4B92E87B.9090803@birkenwald.de> Message-ID: On Mar 6, 2010, at 6:42 PM, Bernhard Schmidt wrote: > On 06.03.2010 22:41, Mark Smith wrote: > > Bernhard > >>> Autoconf doesn't work for on>64 bit prefixes, so extending it to >>> an 80 >>> is a [interesting] way of disabling it completely. >> So is announcing RA Prefix Information options without the >> autonomous address-configuration flag set. I'd doubt anybody >> would be willing to standardise hack like that when there is >> already a >> proper way to stop nodes autoconfiguring addresses. > > Except it doesn't work everywhere, for example it's not available in > the most recent NX-OS 4.2 (Cisco Nexus 7000). You can either do > "ipv6 nd suppress-ra" on that platform (which had (has?) the nasty > problem of one RA being sent during software upgrade, hello SLAAC on > >500 cluster hosts), or use a prefixlen != /64. That also doesn't stop 6500s from responding to RS queries which is enough for some Linux boxes to auto configure, it seems.... From evyncke at cisco.com Sun Mar 7 09:09:21 2010 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Sun, 7 Mar 2010 09:09:21 +0100 Subject: disabling client use of SLAAC In-Reply-To: References: <4B916891.6020309@gmail.com> <37A6B906-CEAD-408B-914B-CA5918997CC4@marcoh.net> <20100306093656.5826ffc6@opy.nosense.org> <20100306165634.GC9341@prolixium.com><20100307081102.6b43b08c@opy.nosense.org><4B92E87B.9090803@birkenwald.de> Message-ID: <317616CE96204D49B5A1811098BA89500165D7AB@XMB-AMS-110.cisco.com> Indeed, the 'ipv6 nd suppress-ra' is only suppressing the periodic RA, it will not prevent the router to reply to RS. As written before 'ipv6 nd prefix default no-autoconfig' is probably what you want to do to disable SLAAC. It works for me for Mac & Windows XP/Vista > -----Original Message----- > From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de [mailto:ipv6-ops- > bounces+evyncke=cisco.com at lists.cluenet.de] On Behalf Of John Payne > Sent: dimanche 7 mars 2010 4:34 > To: Bernhard Schmidt > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: disabling client use of SLAAC > > > > On Mar 6, 2010, at 6:42 PM, Bernhard Schmidt > wrote: > > > On 06.03.2010 22:41, Mark Smith wrote: > > > > Bernhard > > > >>> Autoconf doesn't work for on>64 bit prefixes, so extending it to > >>> an 80 > >>> is a [interesting] way of disabling it completely. > >> So is announcing RA Prefix Information options without the > >> autonomous address-configuration flag set. I'd doubt anybody > >> would be willing to standardise hack like that when there is > >> already a > >> proper way to stop nodes autoconfiguring addresses. > > > > Except it doesn't work everywhere, for example it's not available in > > the most recent NX-OS 4.2 (Cisco Nexus 7000). You can either do > > "ipv6 nd suppress-ra" on that platform (which had (has?) the nasty > > problem of one RA being sent during software upgrade, hello SLAAC on > > >500 cluster hosts), or use a prefixlen != /64. > > That also doesn't stop 6500s from responding to RS queries which is > enough for some Linux boxes to auto configure, it seems.... From shane at time-travellers.org Tue Mar 9 14:41:03 2010 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 09 Mar 2010 14:41:03 +0100 Subject: IPv6 black lists? Message-ID: <4B964FEF.8070303@time-travellers.org> Hello, Does anybody know if there are IPv6 DNSBL available? Thanks, -- Shane From balla at staff.spin.it Tue Mar 9 14:46:13 2010 From: balla at staff.spin.it (Emanuele Balla) Date: Tue, 09 Mar 2010 14:46:13 +0100 Subject: IPv6 black lists? In-Reply-To: <4B964FEF.8070303@time-travellers.org> References: <4B964FEF.8070303@time-travellers.org> Message-ID: <4B965125.9020306@staff.spin.it> On 3/9/10 2:41 PM, Shane Kerr wrote: > Hello, > > Does anybody know if there are IPv6 DNSBL available? > > Thanks, http://virbl.bit.nl/index.php#ipv6 Mainly proofs of concept, since rbldnsd does not support ipv6 datasets yet. -- # Emanuele Balla # # # System & Network Engineer # Cell: +39 348 7747907 # # Spin s.r.l. # Phone: +39 040 9869090 # # Trieste # Email: balla at staff.spin.it # From brian.e.carpenter at gmail.com Tue Mar 9 21:47:13 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 10 Mar 2010 09:47:13 +1300 Subject: IPv6 black lists? In-Reply-To: <4B965125.9020306@staff.spin.it> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> Message-ID: <4B96B3D1.9030501@gmail.com> But is dnsbl a technique that should be encouraged for IPv6? It's already a blunt weapon for IPv4. As the virbl site notes, for IPv6 the only practical atom is a /64 and that is a *very* blunt weapon indeed. Its potential for false positives is extremely high. Brian On 2010-03-10 02:46, Emanuele Balla wrote: > On 3/9/10 2:41 PM, Shane Kerr wrote: >> Hello, >> >> Does anybody know if there are IPv6 DNSBL available? >> >> Thanks, > > http://virbl.bit.nl/index.php#ipv6 > > Mainly proofs of concept, since rbldnsd does not support ipv6 datasets yet. > From john at sackheads.org Tue Mar 9 21:52:51 2010 From: john at sackheads.org (John Payne) Date: Tue, 9 Mar 2010 15:52:51 -0500 Subject: IPv6 black lists? In-Reply-To: <4B96B3D1.9030501@gmail.com> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> Message-ID: <49BEEEA3-1634-4352-A2E6-3C4E40C8849E@sackheads.org> On Mar 9, 2010, at 3:47 PM, Brian E Carpenter wrote: > But is dnsbl a technique that should be encouraged for IPv6? > > It's already a blunt weapon for IPv4. As the virbl site notes, > for IPv6 the only practical atom is a /64 and that is a *very* > blunt weapon indeed. Its potential for false positives is > extremely high. I think that depends on the policies of the dnsbl maintainer and the dnsbl consumer. I personally wouldn't want to trust anything that shared a layer2 network with a virus laden machine even if it wasn't the same machine... so blocking at /64 is fine by me. Others may disagree. In the specific case of dnsbl's I do see /64 as an advantage - the false positives will be much lower than trying to block "same subnet" in IPv4. > > Brian > > > On 2010-03-10 02:46, Emanuele Balla wrote: >> On 3/9/10 2:41 PM, Shane Kerr wrote: >>> Hello, >>> >>> Does anybody know if there are IPv6 DNSBL available? >>> >>> Thanks, >> >> http://virbl.bit.nl/index.php#ipv6 >> >> Mainly proofs of concept, since rbldnsd does not support ipv6 datasets yet. >> > From brian.e.carpenter at gmail.com Tue Mar 9 21:57:57 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 10 Mar 2010 09:57:57 +1300 Subject: IPv6 black lists? In-Reply-To: <49BEEEA3-1634-4352-A2E6-3C4E40C8849E@sackheads.org> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <49BEEEA3-1634-4352-A2E6-3C4E40C8849E@sackheads.org> Message-ID: <4B96B655.1050607@gmail.com> On 2010-03-10 09:52, John Payne wrote: > On Mar 9, 2010, at 3:47 PM, Brian E Carpenter wrote: > >> But is dnsbl a technique that should be encouraged for IPv6? >> >> It's already a blunt weapon for IPv4. As the virbl site notes, >> for IPv6 the only practical atom is a /64 and that is a *very* >> blunt weapon indeed. Its potential for false positives is >> extremely high. > > I think that depends on the policies of the dnsbl maintainer and the dnsbl consumer. > > I personally wouldn't want to trust anything that shared a layer2 network with a virus laden machine even if it wasn't the same machine... so blocking at /64 is fine by me. Others may disagree. That makes sense in a small office or home network context. In a large institutional network it's much less clear. > In the specific case of dnsbl's I do see /64 as an advantage - the false positives will be much lower than trying to block "same subnet" in IPv4. In the sense that a /64 is by definition a subnet, that's true. Brian > > > >> Brian >> >> >> On 2010-03-10 02:46, Emanuele Balla wrote: >>> On 3/9/10 2:41 PM, Shane Kerr wrote: >>>> Hello, >>>> >>>> Does anybody know if there are IPv6 DNSBL available? >>>> >>>> Thanks, >>> http://virbl.bit.nl/index.php#ipv6 >>> >>> Mainly proofs of concept, since rbldnsd does not support ipv6 datasets yet. >>> > > From john at sackheads.org Tue Mar 9 22:01:23 2010 From: john at sackheads.org (John Payne) Date: Tue, 9 Mar 2010 16:01:23 -0500 Subject: IPv6 black lists? In-Reply-To: <4B96B655.1050607@gmail.com> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <49BEEEA3-1634-4352-A2E6-3C4E40C8849E@sackheads.org> <4B96B655.1050607@gmail.com> Message-ID: <284DC687-D881-4934-AE56-D153F6E447D7@sackheads.org> On Mar 9, 2010, at 3:57 PM, Brian E Carpenter wrote: > On 2010-03-10 09:52, John Payne wrote: >> On Mar 9, 2010, at 3:47 PM, Brian E Carpenter wrote: >> >>> But is dnsbl a technique that should be encouraged for IPv6? >>> >>> It's already a blunt weapon for IPv4. As the virbl site notes, >>> for IPv6 the only practical atom is a /64 and that is a *very* >>> blunt weapon indeed. Its potential for false positives is >>> extremely high. >> >> I think that depends on the policies of the dnsbl maintainer and the dnsbl consumer. >> >> I personally wouldn't want to trust anything that shared a layer2 network with a virus laden machine even if it wasn't the same machine... so blocking at /64 is fine by me. Others may disagree. > > That makes sense in a small office or home network context. In a large > institutional network it's much less clear. See my first point ;) > >> In the specific case of dnsbl's I do see /64 as an advantage - the false positives will be much lower than trying to block "same subnet" in IPv4. > > In the sense that a /64 is by definition a subnet, that's true. > > Brian >> >> >> >>> Brian >>> >>> >>> On 2010-03-10 02:46, Emanuele Balla wrote: >>>> On 3/9/10 2:41 PM, Shane Kerr wrote: >>>>> Hello, >>>>> >>>>> Does anybody know if there are IPv6 DNSBL available? >>>>> >>>>> Thanks, >>>> http://virbl.bit.nl/index.php#ipv6 >>>> >>>> Mainly proofs of concept, since rbldnsd does not support ipv6 datasets yet. >>>> >> >> > From berni at birkenwald.de Tue Mar 9 22:12:51 2010 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 09 Mar 2010 22:12:51 +0100 Subject: Sprint core contact Message-ID: <4B96B9D3.9050209@birkenwald.de> Hi, is anyone from Sprint on this list? You seem to be originating transfer networks/nexthops into global BGP (13105 and 8359 are just an example here, there are quite a few networks transporting them) * 2001:418:0:1000::f011/128 13105 8359 6175 1239 i same for * 2001:418:0:1000::f012/128 * 2001:418:0:4000::78/126 * 2001:418:0:4000::7c/126 * 2001:418:0:4000::80/126 * 2001:418:0:4000::84/126 * 2001:450:2008:1033::/64 * 2001:450:2008:1034::/64 * 2001:550:3::54/127 * 2001:550:4::8/128 * 2001:550:4::9/128 * 2001:550:4::a/128 * 2001:550:4::b/128 * 2001:550:4::c/128 * 2001:550:4::d/128 * 2001:5a0:d00::64/128 * 2001:5a0:1800:200::/64 * 2001:1900::3:71/128 * 2001:1900::3:74/128 * 2001:1900::3:81/128 * 2001:1900::3:ad/128 * 2001:1900:4:3::98/126 * 2001:1900:4:3::9c/126 * 2001:1900:4:3::a0/126 * 2001:2000:3080:7c::/64 * 2001:2000:3080:8f::/64 * 2600:802::16/128 * 2600:802:2::8/126 * 2600:803::19/128 Bernhard From sethm at rollernet.us Tue Mar 9 22:27:47 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 09 Mar 2010 13:27:47 -0800 Subject: Sprint core contact In-Reply-To: <4B96B9D3.9050209@birkenwald.de> References: <4B96B9D3.9050209@birkenwald.de> Message-ID: <4B96BD53.3050505@rollernet.us> On 3/9/10 1:12 PM, Bernhard Schmidt wrote: > Hi, > > is anyone from Sprint on this list? You seem to be originating transfer > networks/nexthops into global BGP (13105 and 8359 are just an example > here, there are quite a few networks transporting them) > Did you try Sprint first? Their IPv6 contact address has always been extremely responsive in my experience. ~Seth From marks at bit.nl Tue Mar 9 23:41:11 2010 From: marks at bit.nl (Mark Schouten) Date: Tue, 09 Mar 2010 23:41:11 +0100 Subject: IPv6 black lists? In-Reply-To: <4B96B3D1.9030501@gmail.com> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> Message-ID: <1268174471.2079.1.camel@maximus> On Wed, 2010-03-10 at 09:47 +1300, Brian E Carpenter wrote: > But is dnsbl a technique that should be encouraged for IPv6? > > It's already a blunt weapon for IPv4. As the virbl site notes, > for IPv6 the only practical atom is a /64 and that is a *very* > blunt weapon indeed. Its potential for false positives is > extremely high. That's not what we do. We list the /128 and if we find > 5 /128 in the same /64, we block the /64. That way, the false positives are limited, although not eliminated. But at least we can expect the admins attention on this subnet. :) -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 | KvK: 09090351 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 17FF From d at teklibre.org Wed Mar 10 00:57:38 2010 From: d at teklibre.org (Dave Taht) Date: Tue, 09 Mar 2010 17:57:38 -0600 Subject: IPv6 black lists? In-Reply-To: <1268174471.2079.1.camel@maximus> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> Message-ID: <4B96E072.2060008@teklibre.org> On 03/09/2010 04:41 PM, Mark Schouten wrote: > On Wed, 2010-03-10 at 09:47 +1300, Brian E Carpenter wrote: > >> But is dnsbl a technique that should be encouraged for IPv6? >> >> It's already a blunt weapon for IPv4. As the virbl site notes, >> for IPv6 the only practical atom is a /64 and that is a *very* >> blunt weapon indeed. Its potential for false positives is >> extremely high. >> > That's not what we do. We list the /128 and if we find> 5 /128 in the > same /64, we block the /64. That way, the false positives are limited, > although not eliminated. But at least we can expect the admins attention > on this subnet. :) > > > So this translates out to 2^16*5 = 327680 detected spams to get completely blocked for someone that gets a /48 allocation from some tunneling provider or another. While I suppose the virbl method will work for random zombie machines which can't change their ip addresses, it's not going to slow down a dedicated abuser all that much. I tend to think that changing the relevant RFC (sorry, can't remember which one) for exchanging email to require a valid certificate for email exchanged over ipv6 would be more effective in that case. From md at Linux.IT Wed Mar 10 01:37:12 2010 From: md at Linux.IT (Marco d'Itri) Date: Wed, 10 Mar 2010 01:37:12 +0100 Subject: IPv6 black lists? In-Reply-To: <4B96E072.2060008@teklibre.org> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> Message-ID: <20100310003712.GA6624@bongo.bofh.it> On Mar 10, Dave Taht wrote: > So this translates out to 2^16*5 = 327680 detected spams to get > completely blocked for someone that gets a /48 allocation from some > tunneling provider or another. While I suppose the virbl method will > work for random zombie machines which can't change their ip addresses, > it's not going to slow down a dedicated abuser all that much. Like it happens for IPv4, I expect that different DNSBLs (or their components) will adopt different approaches at complimentary upgrades of listings depending on what kind of sources they target. > I tend to think that changing the relevant RFC (sorry, can't remember > which one) for exchanging email to require a valid certificate for email > exchanged over ipv6 would be more effective in that case. This is clearly a FUSSP, one of the main botnets already uses TLS. -- ciao, Marco From d at teklibre.org Wed Mar 10 02:10:38 2010 From: d at teklibre.org (Dave Taht) Date: Tue, 09 Mar 2010 19:10:38 -0600 Subject: IPv6 black lists? In-Reply-To: <20100310003712.GA6624@bongo.bofh.it> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310003712.GA6624@bongo.bofh.it> Message-ID: <4B96F18E.6000002@teklibre.org> On 03/09/2010 06:37 PM, Marco d'Itri wrote: > On Mar 10, Dave Taht wrote: > > >> So this translates out to 2^16*5 = 327680 detected spams to get >> completely blocked for someone that gets a /48 allocation from some >> tunneling provider or another. While I suppose the virbl method will >> work for random zombie machines which can't change their ip addresses, >> it's not going to slow down a dedicated abuser all that much. >> > Like it happens for IPv4, I expect that different DNSBLs (or their > components) will adopt different approaches at complimentary upgrades > of listings depending on what kind of sources they target. > > >> I tend to think that changing the relevant RFC (sorry, can't remember >> which one) for exchanging email to require a valid certificate for email >> exchanged over ipv6 would be more effective in that case. >> > This is clearly a FUSSP, one of the main botnets already uses TLS TLS and "Valid Certificate" are separate animals. You can use TLS without a valid cert, you can also tell TLS to enforce that you accept only certificates created by a valid trust-chain, and various levels in-between. The human overhead required to create, software to distribute certs and revocations around is (possibly) an answer of some sort to some spam problems, which is why I threw the idea out there. In the case where invalid certs are still accepted, distributing the fingerprint of certs distributing spam might be more effective than blocking ipv6 addresses. A lot of this has been discussed over on the postfix mailing list. There is a large contingent of stressed out, overworked email admins over there vehemently opposed to distributing email, "as we know it" over ipv6, at all. That said, it too may well be yet another FUSSP. It's a hard problem. On my bad days I tend to think humanity's last role on this planet is to fully educate the spam-bots into sentience. From d at teklibre.org Wed Mar 10 02:32:45 2010 From: d at teklibre.org (Dave Taht) Date: Tue, 09 Mar 2010 19:32:45 -0600 Subject: IPv6 black lists? In-Reply-To: <4B96F18E.6000002@teklibre.org> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310003712.GA6624@bongo.bofh.it> <4B96F18E.6000002@teklibre.org> Message-ID: <4B96F6BD.8070101@teklibre.org> On 03/09/2010 07:10 PM, Dave Taht wrote: > On 03/09/2010 06:37 PM, Marco d'Itri wrote: >> On Mar 10, Dave Taht wrote: >> >>> So this translates out to 2^16*5 = 327680 detected spams to get >>> completely blocked for someone that gets a /48 allocation from some >>> tunneling provider or another. While I suppose the virbl method will >>> work for random zombie machines which can't change their ip addresses, >>> it's not going to slow down a dedicated abuser all that much. >> Like it happens for IPv4, I expect that different DNSBLs (or their >> components) will adopt different approaches at complimentary upgrades >> of listings depending on what kind of sources they target. >> >>> I tend to think that changing the relevant RFC (sorry, can't remember >>> which one) for exchanging email to require a valid certificate for >>> email >>> exchanged over ipv6 would be more effective in that case. >> This is clearly a FUSSP, one of the main botnets already uses TLS > > TLS and "Valid Certificate" are separate animals. You can use TLS > without a valid cert, you can also tell TLS to enforce that you accept > only certificates created by a valid trust-chain, and various levels > in-between. > > The human overhead required to create, software to distribute certs > and revocations around is (possibly) an answer of some sort to some > spam problems, which is why I threw the idea out there. > > In the case where invalid certs are still accepted, distributing the > fingerprint of certs distributing spam might be more effective than > blocking ipv6 addresses. > > A lot of this has been discussed over on the postfix mailing list. > There is a large contingent of stressed out, overworked email admins > over there vehemently opposed to distributing email, "as we know it" > over ipv6, at all. > > That said, it too may well be yet another FUSSP. It's a hard problem. > On my bad days I tend to think humanity's last role on this planet is > to fully educate the spam-bots into sentience. I just enjoyed re-reading http://www.rhyolite.com/anti-spam/you-might-be.html It seemed to be longer than I remembered. From marks at bit.nl Wed Mar 10 09:02:18 2010 From: marks at bit.nl (Mark Schouten) Date: Wed, 10 Mar 2010 09:02:18 +0100 Subject: IPv6 black lists? In-Reply-To: <4B96E072.2060008@teklibre.org> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> Message-ID: <1268208138.2660.3.camel@highway> On Tue, 2010-03-09 at 17:57 -0600, Dave Taht wrote: > > That's not what we do. We list the /128 and if we find> 5 /128 in the > > same /64, we block the /64. That way, the false positives are limited, > > although not eliminated. But at least we can expect the admins attention > > on this subnet. :) > > > > > > > So this translates out to 2^16*5 = 327680 detected spams to get > completely blocked for someone that gets a /48 allocation from some > tunneling provider or another. While I suppose the virbl method will > work for random zombie machines which can't change their ip addresses, > it's not going to slow down a dedicated abuser all that much. It's primarily based on the fact that Windows PC's often have privacy-extensions enabled. Please not that Virbl is a list to block virus-sending hosts, not spam. -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 | KvK: 09090351 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 17FF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100310/8e25afcc/attachment.bin From mohacsi at niif.hu Wed Mar 10 09:25:47 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 10 Mar 2010 09:25:47 +0100 (CET) Subject: IPv6 black lists? In-Reply-To: <4B96B3D1.9030501@gmail.com> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> Message-ID: On Wed, 10 Mar 2010, Brian E Carpenter wrote: > But is dnsbl a technique that should be encouraged for IPv6? > > It's already a blunt weapon for IPv4. As the virbl site notes, > for IPv6 the only practical atom is a /64 and that is a *very* > blunt weapon indeed. Its potential for false positives is > extremely high. I think dnsbl can be used for IPv6 - no difference in semantics from IPv4. The dnsbl filtering on /64 is very dangerous for making blackholes for ligitimate SMTP server. Consider e.g. malware infected desktop PC. Do you filter e.g. /24 for a IPv4? Same gradual approach should be taken. If more than predefined limit (defined clearly by dnsbl operator) reached then /128 filtering to /64 might be injected. Users of the particular dnsbl can decide whether the defined approach is acceptable for them..... Best Regards, Janos Mohacsi > > Brian > > > On 2010-03-10 02:46, Emanuele Balla wrote: >> On 3/9/10 2:41 PM, Shane Kerr wrote: >>> Hello, >>> >>> Does anybody know if there are IPv6 DNSBL available? >>> >>> Thanks, >> >> http://virbl.bit.nl/index.php#ipv6 >> >> Mainly proofs of concept, since rbldnsd does not support ipv6 datasets yet. >> > From marks at bit.nl Wed Mar 10 09:32:40 2010 From: marks at bit.nl (Mark Schouten) Date: Wed, 10 Mar 2010 09:32:40 +0100 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> Message-ID: <1268209960.2660.10.camel@highway> On Wed, 2010-03-10 at 09:25 +0100, Mohacsi Janos wrote: > > > On Wed, 10 Mar 2010, Brian E Carpenter wrote: > > > But is dnsbl a technique that should be encouraged for IPv6? > > > > It's already a blunt weapon for IPv4. As the virbl site notes, > > for IPv6 the only practical atom is a /64 and that is a *very* > > blunt weapon indeed. Its potential for false positives is > > extremely high. > > > I think dnsbl can be used for IPv6 - no difference in semantics from IPv4. > The dnsbl filtering on /64 is very dangerous for making blackholes for > ligitimate SMTP server. Consider e.g. malware infected desktop PC. Do you > filter e.g. /24 for a IPv4? Same gradual approach should be taken. If more > than predefined limit (defined clearly by dnsbl operator) reached then > /128 filtering to /64 might be injected. Users of the particular dnsbl can > decide whether the defined approach is acceptable for them..... No, you don't filter a /24 because a /24 can still be 256 different customers. With IPv6, a /64 is a site-network. So the chance that many customers reside in this /64 isn't that big. Router-advertisements only work in a /64, so you would be really dumb if you start chopping up /64's to different customers. Obviously, this is not a 100% solution; we have shared colocation networks that share a /64 so in that case we would have an issue. But the other solution, listing on a /128 is useless and you might just end up in listing 18446744073709551616 ip's per end-user... -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 | KvK: 09090351 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 17FF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100310/25ff1843/attachment.bin From mohacsi at niif.hu Wed Mar 10 09:41:52 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 10 Mar 2010 09:41:52 +0100 (CET) Subject: IPv6 black lists? In-Reply-To: <1268209960.2660.10.camel@highway> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268209960.2660.10.camel@highway> Message-ID: On Wed, 10 Mar 2010, Mark Schouten wrote: > On Wed, 2010-03-10 at 09:25 +0100, Mohacsi Janos wrote: >> >> >> On Wed, 10 Mar 2010, Brian E Carpenter wrote: >> >>> But is dnsbl a technique that should be encouraged for IPv6? >>> >>> It's already a blunt weapon for IPv4. As the virbl site notes, >>> for IPv6 the only practical atom is a /64 and that is a *very* >>> blunt weapon indeed. Its potential for false positives is >>> extremely high. >> >> >> I think dnsbl can be used for IPv6 - no difference in semantics from IPv4. >> The dnsbl filtering on /64 is very dangerous for making blackholes for >> ligitimate SMTP server. Consider e.g. malware infected desktop PC. Do you >> filter e.g. /24 for a IPv4? Same gradual approach should be taken. If more >> than predefined limit (defined clearly by dnsbl operator) reached then >> /128 filtering to /64 might be injected. Users of the particular dnsbl can >> decide whether the defined approach is acceptable for them..... > > No, you don't filter a /24 because a /24 can still be 256 different > customers. With IPv6, a /64 is a site-network. I think between 64 and 1. The common allocation is /30 or shorter for customers. > So the chance that many > customers reside in this /64 isn't that big. Router-advertisements only > work in a /64, so you would be really dumb if you start chopping > up /64's to different customers. In our case we are providing two types of hosting: 1. shared /64 - seperate (virtual) machines with some l2 protection 2. separate /64 > Obviously, this is not a 100% solution; we have shared colocation > networks that share a /64 so in that case we would have an issue. But > the other solution, listing on a /128 is useless and you might just end > up in listing 18446744073709551616 ip's per end-user... I think no, since the dnsbl operator should operate some limits where installs /64 as described in my e-mail. Best Regards, Janos Mohacsi From swmike at swm.pp.se Wed Mar 10 10:18:11 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Mar 2010 10:18:11 +0100 (CET) Subject: IPv6 black lists? In-Reply-To: <1268209960.2660.10.camel@highway> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268209960.2660.10.camel@highway> Message-ID: On Wed, 10 Mar 2010, Mark Schouten wrote: > customers. With IPv6, a /64 is a site-network. So the chance that many > customers reside in this /64 isn't that big. Router-advertisements only > work in a /64, so you would be really dumb if you start chopping > up /64's to different customers. I'd say it's going to be quite common that there are multiple customers in a single /64. There really should be some kind of mechanism so the ISP can indicate entity/subnet relationship, for instance if a /48 belongs to a single entity, or if multiple entities can reside within the same /64, and if these entities will have just a single IP per machine (strict DHCPv6 and no SLAAC), or if SLAAC is in effect and a box can have any IP. -- Mikael Abrahamsson email: swmike at swm.pp.se From jeroen at unfix.org Wed Mar 10 10:45:31 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 10 Mar 2010 10:45:31 +0100 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268209960.2660.10.camel@highway> Message-ID: <4B976A3B.2090105@spaghetti.zurich.ibm.com> [****************** Quick Sidenote: http://www.sixxs.net/tools/grh/dfp/ RIPE: "Thus 1049 (51.07%) networks are currently correctly announced." ARIN: "Thus 472 (37.97%) networks are currently correctly announced." APNIC: "Thus 327 (36.41%) networks are currently correctly announced." Come on US and Asia, you can do better than that!!! And that is just routing the thing, not even getting connectivity to any of your users, thus far from hard at all... I find it good to see that ISPs actually get a prefix, I find it very BAD that they are not even bothering announcing it, thus clearly they just reserve them and then maybe one day they'll turn it on. Better start doing that sooner than later folks! (most of the ARIN prefixes are /48s, while most of the RIPE prefixes are /32's btw) *****************] Mikael Abrahamsson wrote: > On Wed, 10 Mar 2010, Mark Schouten wrote: > >> customers. With IPv6, a /64 is a site-network. So the chance that many >> customers reside in this /64 isn't that big. Router-advertisements only >> work in a /64, so you would be really dumb if you start chopping >> up /64's to different customers. > > I'd say it's going to be quite common that there are multiple customers > in a single /64. Customers (eg sharing one host with one IP address) or hosts (eg sharing one host with multiple IPs) or different hosts (one host per customer). In the case of the middle one compromising one host would compromise all those IPs. What one has to see though is that a Black List should be used for *SCORING* as such. If you have a BL that lists a /64 (because it triggered virusses/spams/whatevermetric from 5 different /128s) then you know "the people operating this /64 is not cleaning up quick enough". Outright blocking/rejecting on that kind of information is of course silly. If you have a database which you 100% trust to have absolutely no false-positives then you might want to consider indeed directly rejecting. IMHO the metric of about /128, 8 of those -> /64, 16 of those -> /48, 128 of those /32 is a good one. Larger prefixes will be covered in the same way as they will just be hurt per /32 of their /13 (oh yeah, that is possible, to get a chunked up /13 from ARIN; they still haven't figured out this aggregation thing and seem to endorse de-aggregation already in the registry). Clearly if the ISP is not cleaning their mess up, then there is not much need to accept their nonsense. Still *SCORING* it is the keyword here. The Black List will then help a lot (maybe 50% of the score) to push the score into the 'reject' category. Of course in the case of SMTP, always do 'SMTP reject after DATA' and don't go accepting the email and then bounce it because you actually didn't like what you got. Sending a DSN then will just cause some innocent From: address to get flooded. > There really should be some kind of mechanism so the ISP can indicate > entity/subnet relationship There is whois.ripe.net ;) Maybe try and get the RIPE-DB folks to add an RPSL property stating what kind of usage the network has and hoping that BL providers use that information. Of course that requires people to actually fill in information there and people seem to be reluctant to do so. Additional note there: whois.ripe.net can ALSO be used for non-RIPE blocks. This is especially handy for people who want to let the rest of the world know about their routing policies in the form of IRR data. whois.ripe.net already has a large amount of data there thus don't hesitate to add your own! 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/20100310/105a664e/attachment-0001.bin From marcoh at marcoh.net Wed Mar 10 11:26:47 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 10 Mar 2010 11:26:47 +0100 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268209960.2660.10.camel@highway> Message-ID: <950600E5-56A0-412E-B44F-A3EF5F5A0B32@marcoh.net> On 10 mrt 2010, at 10:18, Mikael Abrahamsson wrote: > On Wed, 10 Mar 2010, Mark Schouten wrote: > >> customers. With IPv6, a /64 is a site-network. So the chance that many >> customers reside in this /64 isn't that big. Router-advertisements only >> work in a /64, so you would be really dumb if you start chopping >> up /64's to different customers. > > I'd say it's going to be quite common that there are multiple customers in a single /64. > > There really should be some kind of mechanism so the ISP can indicate entity/subnet relationship, for instance if a /48 belongs to a single entity, or if multiple entities can reside within the same /64, and if these entities will have just a single IP per machine (strict DHCPv6 and no SLAAC), or if SLAAC is in effect and a box can have any IP. Agreed, a first proposal was sent to the ripe IPv6-WG last year. I should be working on a follow-up of that, so if anybody is interested feel free to contact me :) Groet, MarcoH From me at benedikt-stockebrand.de Wed Mar 10 11:53:06 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Wed, 10 Mar 2010 10:53:06 +0000 Subject: IPv6 black lists? In-Reply-To: <4B96E072.2060008@teklibre.org> (Dave Taht's message of "Tue, 09 Mar 2010 17:57:38 -0600") References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> Message-ID: Hello List, Dave Taht writes: > So this translates out to 2^16*5 = 327680 detected spams to get > completely blocked for someone that gets a /48 allocation from some > tunneling provider or another. Dave is on the right track. If you work the numbers some more, this is what you get: With legacy IPv4, one can maintain a full host-specific IPv4 address blacklist in 512 MB of memory (using a bitmap with one bit per address), so this is obviously possible with today's standard hardware. Even if you filtered IPv6 by /48s, that would take 2^16 times as much memory, or 32 TB. Filtering at /64 we're at 2 EB (ExaBytes). Now how long do you expect it for spammers to figure out that once they take over a machine they should acquire a new address for every single spam mail they send out? Once they start to do this, any kind of address-based blacklist will blow up in your face. As soon as they hit a home router, they can use the entire /48 or whatever allocated to the victim by their ISP. We do have a problem here. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From gert at space.net Wed Mar 10 12:04:03 2010 From: gert at space.net (Gert Doering) Date: Wed, 10 Mar 2010 12:04:03 +0100 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> Message-ID: <20100310110403.GA1464@Space.Net> Hi, On Wed, Mar 10, 2010 at 10:53:06AM +0000, Benedikt Stockebrand wrote: > > So this translates out to 2^16*5 = 327680 detected spams to get > > completely blocked for someone that gets a /48 allocation from some > > tunneling provider or another. > > Dave is on the right track. If you work the numbers some more, this > is what you get: > > With legacy IPv4, one can maintain a full host-specific IPv4 address > blacklist in 512 MB of memory (using a bitmap with one bit per > address), so this is obviously possible with today's standard > hardware. > > Even if you filtered IPv6 by /48s, that would take 2^16 times as much > memory, or 32 TB. Filtering at /64 we're at 2 EB (ExaBytes). Not bitmap-based data structures exist... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 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 me at benedikt-stockebrand.de Wed Mar 10 12:13:20 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Wed, 10 Mar 2010 11:13:20 +0000 Subject: IPv6 black lists? In-Reply-To: <20100310110403.GA1464@Space.Net> (Gert Doering's message of "Wed, 10 Mar 2010 12:04:03 +0100") References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> Message-ID: Hi Gert and list, Gert Doering writes: > Not bitmap-based data structures exist... correct, but bitmaps are the best available data structure in a worst case scenario, so they define a lower bound. If spammers were seriously interested in disabling address-based blacklists by flooding them, then a bitmap is the most resilient data structure. With IPv4 that's feasible, with IPv6 it isn't. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From gert at space.net Wed Mar 10 12:16:17 2010 From: gert at space.net (Gert Doering) Date: Wed, 10 Mar 2010 12:16:17 +0100 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> Message-ID: <20100310111617.GC1464@Space.Net> Hi, On Wed, Mar 10, 2010 at 11:13:20AM +0000, Benedikt Stockebrand wrote: > Gert Doering writes: > > > Not bitmap-based data structures exist... > > correct, but bitmaps are the best available data structure in a worst > case scenario, so they define a lower bound. > > If spammers were seriously interested in disabling address-based > blacklists by flooding them, then a bitmap is the most resilient data > structure. With IPv4 that's feasible, with IPv6 it isn't. Sure. Which just emphasizes the point that you want to fall-up from "individual hosts in a /64" to "the whole /64" to "the whole /56" and so on, up to /32, as soon as a given threshold inside the /x is exceeded. Or make people and vendors liable for the damage they cause with their PCs. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 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 mohacsi at niif.hu Wed Mar 10 12:34:51 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 10 Mar 2010 12:34:51 +0100 (CET) Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> Message-ID: On Wed, 10 Mar 2010, Benedikt Stockebrand wrote: > Hello List, > > Dave Taht writes: > >> So this translates out to 2^16*5 = 327680 detected spams to get >> completely blocked for someone that gets a /48 allocation from some >> tunneling provider or another. > > Dave is on the right track. If you work the numbers some more, this > is what you get: > > With legacy IPv4, one can maintain a full host-specific IPv4 address > blacklist in 512 MB of memory (using a bitmap with one bit per > address), so this is obviously possible with today's standard > hardware. > > Even if you filtered IPv6 by /48s, that would take 2^16 times as much > memory, or 32 TB. Filtering at /64 we're at 2 EB (ExaBytes). > > Now how long do you expect it for spammers to figure out that once > they take over a machine they should acquire a new address for every > single spam mail they send out? Once they start to do this, any kind > of address-based blacklist will blow up in your face. What about stopping this happen at the end system: preventing changing IP addresses machines too often? Ther is already tool for monitoring such an activity..... Best Regards, Janos Mohacsi From jeroen at unfix.org Wed Mar 10 13:06:35 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 10 Mar 2010 13:06:35 +0100 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> Message-ID: <4B978B4B.6060103@spaghetti.zurich.ibm.com> Mohacsi Janos wrote: [..] > What about stopping this happen at the end system: preventing changing > IP addresses machines too often? Ther is already tool for monitoring > such an activity..... If you would control that network you would indeed not have that problem. If a /48 gets pushed to the user there is little (except for blocking/disabling) the upstream ISP can do. The method of raise the level after X hits from a certain prefix will solve this nicely. ISPs which respond to abuse and keep their networks clean won't get listed, ISPs who don't care will be listed. Simple. Simple solution: care and clean up and don't get listed ;) 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/20100310/23326973/attachment.bin From evyncke at cisco.com Wed Mar 10 14:17:49 2010 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Wed, 10 Mar 2010 14:17:49 +0100 Subject: IPv6 black lists? In-Reply-To: <950600E5-56A0-412E-B44F-A3EF5F5A0B32@marcoh.net> References: <4B964FEF.8070303@time-travellers.org><4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com><1268209960.2660.10.camel@highway> <950600E5-56A0-412E-B44F-A3EF5F5A0B32@marcoh.net> Message-ID: <317616CE96204D49B5A1811098BA8950016EAD03@XMB-AMS-110.cisco.com> Marco Any direct pointer to your proposal? A simple additional record in the WHOIS database containing the granularity of customer allocation would be nice indeed (of course there are other ways of making this information public) -?ric > > > > There really should be some kind of mechanism so the ISP can indicate > entity/subnet relationship, for instance if a /48 belongs to a single entity, > or if multiple entities can reside within the same /64, and if these entities > will have just a single IP per machine (strict DHCPv6 and no SLAAC), or if > SLAAC is in effect and a box can have any IP. > > > Agreed, a first proposal was sent to the ripe IPv6-WG last year. I should be > working on a follow-up of that, so if anybody is interested feel free to > contact me :) > > Groet, > > MarcoH From marcoh at marcoh.net Wed Mar 10 14:20:19 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 10 Mar 2010 14:20:19 +0100 Subject: IPv6 black lists? In-Reply-To: <317616CE96204D49B5A1811098BA8950016EAD03@XMB-AMS-110.cisco.com> References: <4B964FEF.8070303@time-travellers.org><4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com><1268209960.2660.10.camel@highway> <950600E5-56A0-412E-B44F-A3EF5F5A0B32@marcoh.net> <317616CE96204D49B5A1811098BA8950016EAD03@XMB-AMS-110.cisco.com> Message-ID: <0804C041-7F4B-45E9-886E-2D3377A0EB68@marcoh.net> On 10 mrt 2010, at 14:17, Eric Vyncke (evyncke) wrote: > Marco > > Any direct pointer to your proposal? http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2009/msg00142.html > A simple additional record in the WHOIS database containing the granularity of customer allocation would be nice indeed (of course there are other ways of making this information public) That's basically what I'm after Groet, MarcoH From me at benedikt-stockebrand.de Wed Mar 10 16:53:45 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Wed, 10 Mar 2010 15:53:45 +0000 Subject: IPv6 black lists? In-Reply-To: <20100310111617.GC1464@Space.Net> (Gert Doering's message of "Wed, 10 Mar 2010 12:16:17 +0100") References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> <20100310111617.GC1464@Space.Net> Message-ID: Hi Gert and list, Gert Doering writes: >> If spammers were seriously interested in disabling address-based >> blacklists by flooding them, then a bitmap is the most resilient data >> structure. With IPv4 that's feasible, with IPv6 it isn't. > > Sure. Which just emphasizes the point that you want to fall-up from > "individual hosts in a /64" to "the whole /64" to "the whole /56" > and so on, up to /32, as soon as a given threshold inside the /x > is exceeded. that's still too simple: If you are a hoster, then a single hijacked machine from a single customer will have all your other customers quickly blacklisted as well. IMHO blacklisting IPv6 addresses is pretty much a hopeless effort. > Or make people and vendors liable for the damage they cause with > their PCs. Make it a law -- and one internationally established and enforced:-) Until then: Stop offering flatrates (not Spacenet, but all ISPs). As soon as people have to pay for the spam their machines "accidentially" send out the'll be slightly more careful about securing their boxes. Not that I have too much confidence in any of these approaches... Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From me at benedikt-stockebrand.de Wed Mar 10 17:08:23 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Wed, 10 Mar 2010 16:08:23 +0000 Subject: IPv6 black lists? In-Reply-To: <4B978B4B.6060103@spaghetti.zurich.ibm.com> (Jeroen Massar's message of "Wed, 10 Mar 2010 13:06:35 +0100") References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <4B978B4B.6060103@spaghetti.zurich.ibm.com> Message-ID: Hi again, Jeroen Massar writes: > Mohacsi Janos wrote: > [..] >> What about stopping this happen at the end system: preventing changing >> IP addresses machines too often? Ther is already tool for monitoring >> such an activity..... How do you make everyone run such a tool? How do you make everyone understand its output? And how do you prevent a botnet operator from disabling it again afterwards? The key problem with botnets and therefore spam are end users who negligently provide bandwidth and CPU cycles. That's why Gert suggested to hold them liable for their (in)actions. > If a /48 gets pushed to the user there is little (except for > blocking/disabling) the upstream ISP can do. Even that is difficult at best for a large end user ISP. You have to be fast to be effective and you have to face lawsuits if your customers believe that you broke a contract as well as bad press. I'm not saying that ISPs shouldn't do it, but it's not as easy as it may appear. > The method of raise the level after X hits from a certain prefix will > solve this nicely. As soon as spammers figure this out (and they will as soon as it affects their "business") they'll strike back by flooding your blacklists. > ISPs which respond to abuse and keep their networks clean won't get > listed, ISPs who don't care will be listed. Simple. > > Simple solution: care and clean up and don't get listed ;) If there was a simple solution it would quite likely already be in place:-) Why should blacklisting work with IPv6 if it doesn't work with IPv4? By now I expect that the only way to really deal with this entire problem is to rethink the entire concept of e-mail from scratch. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From md at Linux.IT Wed Mar 10 17:24:06 2010 From: md at Linux.IT (Marco d'Itri) Date: Wed, 10 Mar 2010 17:24:06 +0100 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <4B978B4B.6060103@spaghetti.zurich.ibm.com> Message-ID: <20100310162406.GB13639@bongo.bofh.it> On Mar 10, Benedikt Stockebrand wrote: > Why should blacklisting work with IPv6 if it doesn't work with IPv4? Actually it tends to work fine for what it is designed to do. It's just not a FUSSP. I wish that the people interested in arguing about the various methods to stop spam would do it in a more appropriate forum, e.g. news.admin.net-abuse.email. -- ciao, Marco From js at yllq.net Wed Mar 10 17:11:59 2010 From: js at yllq.net (Mateusz Pawlowski) Date: Wed, 10 Mar 2010 16:11:59 +0000 Subject: IPv6 black =?UTF-8?Q?lists=3F?= In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <4B978B4B.6060103@spaghetti.zurich.ibm.com> Message-ID: On Wed, 10 Mar 2010 16:08:23 +0000, Benedikt Stockebrand wrote: > By now I expect that the only way to really deal with this entire > problem is to rethink the entire concept of e-mail from scratch. I've read that so many times about email since the Internet is public and what ? nothing like that materialised, so lets not go there as it's futile. -- Mateusz From gert at space.net Wed Mar 10 21:34:15 2010 From: gert at space.net (Gert Doering) Date: Wed, 10 Mar 2010 21:34:15 +0100 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> <20100310111617.GC1464@Space.Net> Message-ID: <20100310203415.GJ1464@Space.Net> Hi, On Wed, Mar 10, 2010 at 03:53:45PM +0000, Benedikt Stockebrand wrote: > >> If spammers were seriously interested in disabling address-based > >> blacklists by flooding them, then a bitmap is the most resilient data > >> structure. With IPv4 that's feasible, with IPv6 it isn't. > > > > Sure. Which just emphasizes the point that you want to fall-up from > > "individual hosts in a /64" to "the whole /64" to "the whole /56" > > and so on, up to /32, as soon as a given threshold inside the /x > > is exceeded. > > that's still too simple: If you are a hoster, then a single hijacked > machine from a single customer will have all your other customers > quickly blacklisted as well. No, why? If the customer spams from a single address, that address gets blocked. If the customer cycles through his /64, that /64 will get blocked. If you put multiple customers in the same /64, and one of them can use addresses out of that /64 at random, your setup is broken, and you deserve all the pain you can get. > Until then: Stop offering flatrates (not Spacenet, but all ISPs). As > soon as people have to pay for the spam their machines "accidentially" > send out the'll be slightly more careful about securing their boxes. The volume of a typical SPAM run is fairly low compared to the download of a single video. Won't work. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 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 brian.e.carpenter at gmail.com Wed Mar 10 22:14:52 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 11 Mar 2010 10:14:52 +1300 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268209960.2660.10.camel@highway> Message-ID: <4B980BCC.4040800@gmail.com> On 2010-03-10 21:41, Mohacsi Janos wrote: > > > > On Wed, 10 Mar 2010, Mark Schouten wrote: > >> On Wed, 2010-03-10 at 09:25 +0100, Mohacsi Janos wrote: >>> >>> >>> On Wed, 10 Mar 2010, Brian E Carpenter wrote: >>> >>>> But is dnsbl a technique that should be encouraged for IPv6? >>>> >>>> It's already a blunt weapon for IPv4. As the virbl site notes, >>>> for IPv6 the only practical atom is a /64 and that is a *very* >>>> blunt weapon indeed. Its potential for false positives is >>>> extremely high. >>> >>> >>> I think dnsbl can be used for IPv6 - no difference in semantics from >>> IPv4. >>> The dnsbl filtering on /64 is very dangerous for making blackholes for >>> ligitimate SMTP server. Consider e.g. malware infected desktop PC. Do >>> you >>> filter e.g. /24 for a IPv4? Same gradual approach should be taken. If >>> more >>> than predefined limit (defined clearly by dnsbl operator) reached then >>> /128 filtering to /64 might be injected. Users of the particular >>> dnsbl can >>> decide whether the defined approach is acceptable for them..... >> >> No, you don't filter a /24 because a /24 can still be 256 different >> customers. With IPv6, a /64 is a site-network. > > I think between 64 and 1. The common allocation is /30 or shorter for > customers. > >> So the chance that many >> customers reside in this /64 isn't that big. Router-advertisements only >> work in a /64, so you would be really dumb if you start chopping >> up /64's to different customers. > > In our case we are providing two types of hosting: > > 1. shared /64 - seperate (virtual) machines with some l2 protection > 2. separate /64 > > >> Obviously, this is not a 100% solution; we have shared colocation >> networks that share a /64 so in that case we would have an issue. But >> the other solution, listing on a /128 is useless and you might just end >> up in listing 18446744073709551616 ip's per end-user... > > I think no, since the dnsbl operator should operate some limits where > installs /64 as described in my e-mail. Yes. An ADSL subcriber with a single /64 might have any number of hosts - 3 or 4 for a domestic customer, hundreds for a business customer unwilling to pay extra for a /56 or /48. In the first case it's absolutely reasonable to assume that one infected PC means that all the hosts are infected. In the second case that is very unreasonable, and there's a strong risk of blocking quite legitimate servers. Would you want to block 2001:4860:b006::/64 for example, just because you saw malware from 2001:4860:b006::68 ? Brian From jeroen at unfix.org Wed Mar 10 22:23:15 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 10 Mar 2010 22:23:15 +0100 Subject: IPv6 black lists? In-Reply-To: <4B980BCC.4040800@gmail.com> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268209960.2660.10.camel@highway> <4B980BCC.4040800@gmail.com> Message-ID: <4B980DC3.9060102@spaghetti.zurich.ibm.com> Brian E Carpenter wrote: [..] > Would you want to block 2001:4860:b006::/64 for example, > just because you saw malware from 2001:4860:b006::68 ? Absolutely, as the 'block' will only be for SMTP, not for the webhosting that Google does there, which is what most people see. Outbound SMTP is also not affected, only inbound. Also note that Google has about 10 different prefixes (/32s and /48s) that might be used for outbound SMTP (or any other service) thus it won't be so strange if they have their SMTP boxes spread around and if you accidentally block one prefix you won't block others. Also note that those guys & gals (hi, Heather ;) are really good at cleaning up their networks, generally even pro-active. And that last point is what it is about: if you get listed as a /128, well, fine, but if your /64 or even /48 gets listed then you have too much badness. There is then of course also always the point of "Golden Networks" where one will explicitly white list certain prefixes. As I stated before: Blacklists should primarily used for scoring, not for outright blocking; unless of course the list is made for that, most are not. Like every tool on this planet: one can use it correctly or use it incorrectly, the latter though primarily affects ones own network, thus does it matter to the rest of the world? 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/20100310/99c4812d/attachment.bin From john at sackheads.org Wed Mar 10 23:51:22 2010 From: john at sackheads.org (John Payne) Date: Wed, 10 Mar 2010 17:51:22 -0500 Subject: IPv6 black lists? In-Reply-To: <4B980BCC.4040800@gmail.com> References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268209960.2660.10.camel@highway> <4B980BCC.4040800@gmail.com> Message-ID: <602A7DF9-C0EE-4B47-AF9F-BD0A3B3502CF@sackheads.org> On Mar 10, 2010, at 4:14 PM, Brian E Carpenter wrote: > Yes. An ADSL subcriber with a single /64 might have any number of > hosts - 3 or 4 for a domestic customer, hundreds for a business > customer unwilling to pay extra for a /56 or /48. In the first > case it's absolutely reasonable to assume that one infected PC means > that all the hosts are infected. In the second case that is very > unreasonable, and there's a strong risk of blocking quite legitimate > servers. I think you're overly optimistic about business customers :) I've seen infections spread across companies that haven't touched residential users. Residential users are also less likely to have company policies blocking them upgrading things as basic as web browsers. Plus, this is only for SMTP.... putting your mail server on the same layer 2 network as your end users is a recipe for fail. Especially in the IPv6 world where you can't claim address shortage :) From me at benedikt-stockebrand.de Thu Mar 11 00:11:02 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Wed, 10 Mar 2010 23:11:02 +0000 Subject: IPv6 black lists? In-Reply-To: <20100310203415.GJ1464@Space.Net> (Gert Doering's message of "Wed, 10 Mar 2010 21:34:15 +0100") References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> <20100310111617.GC1464@Space.Net> <20100310203415.GJ1464@Space.Net> Message-ID: Hi Gert and list, Gert Doering writes: >> that's still too simple: If you are a hoster, then a single hijacked >> machine from a single customer will have all your other customers >> quickly blacklisted as well. > > No, why? If the customer spams from a single address, that address > gets blocked. If the customer cycles through his /64, that /64 will > get blocked. that's the point: In doing so you block all other customers in that subnet as well. And keep in mind that with the RFC 3041 privacy extensions enabled by default on post-XP Windows boxes, the majority of them *will* cycle through the /64 anyway. > If you put multiple customers in the same /64, and one of them can > use addresses out of that /64 at random, your setup is broken, and you > deserve all the pain you can get. Tell that to people in the low cost end user hosting business. With business customers you are right, because they tend to be willing to pay a bit more for reliable service at least to some degree, but end users frequently think quite differently. >> Until then: Stop offering flatrates (not Spacenet, but all ISPs). >> [...] > > The volume of a typical SPAM run is fairly low compared to the download > of a single video. Won't work. Doesn't matter, it's more of a psychological aspect. I've heard too many Windows end users state that "as long as $game works I don't care, that's what I've got a flatrate for. And when $game breaks, I reinstall the machine." Just being able to tell them that their behaviour may turn rather expensive should help some. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From leo.vegoda at icann.org Thu Mar 11 00:30:50 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 10 Mar 2010 15:30:50 -0800 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> <20100310111617.GC1464@Space.Net> <20100310203415.GJ1464@Space.Net> Message-ID: <288DE16C-0113-4A1C-81E7-7963A9B7D33B@icann.org> On 10 Mar 2010, at 3:11, Benedikt Stockebrand wrote: [...] >> No, why? If the customer spams from a single address, that address >> gets blocked. If the customer cycles through his /64, that /64 will >> get blocked. > > that's the point: In doing so you block all other customers in that > subnet as well. > > And keep in mind that with the RFC 3041 privacy extensions enabled by > default on post-XP Windows boxes, the majority of them *will* cycle > through the /64 anyway. > >> If you put multiple customers in the same /64, and one of them can >> use addresses out of that /64 at random, your setup is broken, and you >> deserve all the pain you can get. > > Tell that to people in the low cost end user hosting business. With > business customers you are right, because they tend to be willing to > pay a bit more for reliable service at least to some degree, but end > users frequently think quite differently. Why would you want to deliver a level of reliability that has not been paid for? If the level of reliability for a shared service depends on the behavior of follow subscribers then as long as the customers know what they are (and are not) getting for their money then that sounds fine to me. Some customers will choose to upgrade to a dedicated service with their own /64 and others will either just grin and bear or or find a provider that doesn't host as many susceptible servers in shared subnets. Regards, Leo From gert at space.net Thu Mar 11 09:16:21 2010 From: gert at space.net (Gert Doering) Date: Thu, 11 Mar 2010 09:16:21 +0100 Subject: IPv6 black lists? In-Reply-To: References: <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> <20100310111617.GC1464@Space.Net> <20100310203415.GJ1464@Space.Net> Message-ID: <20100311081621.GP1464@Space.Net> Hi, On Wed, Mar 10, 2010 at 11:11:02PM +0000, Benedikt Stockebrand wrote: > Hi Gert and list, > > Gert Doering writes: > > >> that's still too simple: If you are a hoster, then a single hijacked > >> machine from a single customer will have all your other customers > >> quickly blacklisted as well. > > > > No, why? If the customer spams from a single address, that address > > gets blocked. If the customer cycles through his /64, that /64 will > > get blocked. > > that's the point: In doing so you block all other customers in that > subnet as well. There are no other customers in the same /64 subnet. Please repeat. There are no other customers in the same /64 subnet. > And keep in mind that with the RFC 3041 privacy extensions enabled by > default on post-XP Windows boxes, the majority of them *will* cycle > through the /64 anyway. This is the point: if they cycle through multiple addresses, block the subnet. So don't put other customers in the same subnet. > > If you put multiple customers in the same /64, and one of them can > > use addresses out of that /64 at random, your setup is broken, and you > > deserve all the pain you can get. > > Tell that to people in the low cost end user hosting business. With > business customers you are right, because they tend to be willing to > pay a bit more for reliable service at least to some degree, but end > users frequently think quite differently. What's so hard to understand about "... deserve all the pain you can get"? Companies like Strato that have multiple customers in the same /64 *have filters in place* to make sure that every customer will only use the set of addresses assigned to his server, and nothing else. This model of deployment is more complicated than "just slap a /64 on it, and every customer can run abuse from whatever address he wants to pick" - but it's the only way to be able to do any sort of abuse handling, not only SPAM. How are you going to trace back hacked machines etc. if you can't reliably associate a given IPv6 address with a given server? And if you can't do that, you shouldn't run an ISP. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 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 mohacsi at niif.hu Thu Mar 11 09:55:22 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 11 Mar 2010 09:55:22 +0100 (CET) Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> <20100310111617.GC1464@Space.Net> <20100310203415.GJ1464@Space.Net> Message-ID: On Wed, 10 Mar 2010, Benedikt Stockebrand wrote: > > And keep in mind that with the RFC 3041 privacy extensions enabled by > default on post-XP Windows boxes, the majority of them *will* cycle > through the /64 anyway. Then these systems are Not compliant to RFC 4941. http://tools.ietf.org/html/rfc4941 The updated privacy extension draft requires the default to be off. Regards, Janos Mohacsi From thomas at cis.uni-muenchen.de Thu Mar 11 09:58:16 2010 From: thomas at cis.uni-muenchen.de (=?UTF-8?B?VGhvbWFzIFNjaMOkZmVy?=) Date: Thu, 11 Mar 2010 09:58:16 +0100 Subject: different content Message-ID: <4B98B0A8.6040501@cis.uni-muenchen.de> Hello Operators, by feeding http://sixy.ch with sites I am confused about a lot of sites, where ipv6 is enabled, but wrong. e.g. www.charliechaplin.com I made a simple ticket to the hoster. www.charliechaplin.com has different content via ipv4--> ok via ipv6-->" Site en construction " Amen (the hoster) has answered: "Bonjour, nous ne supportons pas l'ipv6 pour l'instant Cordialement, Jean-louis" What can I do to convince him, that ipv6 enabled but not supported a very bad solution is? I am not able to write in charming french, and also my english is more broken than fluent. Regards, Thomas Sch?fer -- There?s no place like ::1 Thomas Sch?fer (Systemverwaltung) Ludwig-Maximilians-Universit?t Centrum f?r Informations- und Sprachverarbeitung Schellingstra?e 10 Raum J407A 80799 M?nchen ? +49/89/2180-9706 ? +49/89/2180-9701 From antoine.musso at laposte.fr Thu Mar 11 10:32:38 2010 From: antoine.musso at laposte.fr (Antoine Musso) Date: Thu, 11 Mar 2010 10:32:38 +0100 Subject: different content In-Reply-To: <4B98B0A8.6040501@cis.uni-muenchen.de> References: <4B98B0A8.6040501@cis.uni-muenchen.de> Message-ID: <4B98B8B6.4020509@laposte.fr> Le 11/03/2010 09:58, Thomas Sch?fer a ?crit : > www.charliechaplin.com > > has different content > > via ipv4--> ok > via ipv6-->" Site en construction" Hello Thomas, It looks like a configuration issue for this domain. Other entries such as www.charlie-chaplin.com and www.charliechaplin.fr points to the same A record but do not have any AAAA record. > Amen (the hoster) has answered: > "Bonjour, > nous ne supportons pas l'ipv6 pour l'instant > Cordialement, > Jean-louis" This roughly translate to : "We do not support IPv6 at the time" Amen issued some press releases in january 2009 about IPv6 support. They MIGHT only offer IPv6 connectivity at this time and do not offer support for managed hosting. I would go for a misconfiguration issue. -- Antoine MUSSO Architecte R?seau Groupe La Poste - DISIT/ETU/ARC/ART t?l. 02 44 76 77 27 Post-scriptum La Poste Ce message est confidentiel. Sous reserve de tout accord conclu par ecrit entre vous et La Poste, son contenu ne represente en aucun cas un engagement de la part de La Poste. Toute publication, utilisation ou diffusion, meme partielle, doit etre autorisee prealablement. Si vous n'etes pas destinataire de ce message, merci d'en avertir immediatement l'expediteur. From berni at birkenwald.de Thu Mar 11 11:19:33 2010 From: berni at birkenwald.de (Bernhard Schmidt) Date: Thu, 11 Mar 2010 11:19:33 +0100 Subject: different content In-Reply-To: <4B98B0A8.6040501@cis.uni-muenchen.de> References: <4B98B0A8.6040501@cis.uni-muenchen.de> Message-ID: <4B98C3B5.4020401@birkenwald.de> On 11.03.2010 09:58, Thomas Sch?fer wrote: Hi, > by feeding http://sixy.ch with sites I am confused about a lot of sites, > where ipv6 is enabled, but wrong. > > e.g. www.charliechaplin.com > > I made a simple ticket to the hoster. > > www.charliechaplin.com > > has different content > > via ipv4--> ok > via ipv6-->" Site en construction" This sounds vaguely familiar. http://www.apo-snow.com has the same problem since at least three months. I've never managed to get an answer from either AMEN or the customer itself. Does anyone know someone at AMEN? Bernhard From nuno.vieira at nfsi.pt Thu Mar 11 11:46:48 2010 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Thu, 11 Mar 2010 10:46:48 +0000 (WET) Subject: different content In-Reply-To: <4B98C3B5.4020401@birkenwald.de> Message-ID: <1944026229.1287.1268304408194.JavaMail.root@zimbra.nfsi.pt> ip route 2a02:2b8::/32 null0 ----- "Bernhard Schmidt" wrote: > On 11.03.2010 09:58, Thomas Sch?fer wrote: > > Hi, > > > by feeding http://sixy.ch with sites I am confused about a lot of > sites, > > where ipv6 is enabled, but wrong. > > > > e.g. www.charliechaplin.com > > > > I made a simple ticket to the hoster. > > > > www.charliechaplin.com > > > > has different content > > > > via ipv4--> ok > > via ipv6-->" Site en construction" > > This sounds vaguely familiar. http://www.apo-snow.com has the same > problem since at least three months. I've never managed to get an > answer > from either AMEN or the customer itself. > > Does anyone know someone at AMEN? > > Bernhard From martin at millnert.se Thu Mar 11 12:40:17 2010 From: martin at millnert.se (Martin Millnert) Date: Thu, 11 Mar 2010 12:40:17 +0100 Subject: On 6to4 gateway and recommended MTU setting Message-ID: <1268307617.2878.31.camel@hsa.vpn.anti> Hello list, was discussing best 6to4-relay interface MTU size with a friend and basically need more and wiser input. Apparently, Free BSD has a unmodifiable, static value of 1280 for the 6in4-interface. It could be argued that this follows 4213 3.2.1 ( http://tools.ietf.org/html/rfc4213#section-3.2.1 ). OSX also has a static value of 1280, unmodifiable (I try to stay away from OSX, could this be due to the kernel being the same?). XP reportedly also defaults to 1280, and I see my Windows 7-box does the same for 6to4, which appears once I deactivate native IPv6 on my LAN interface (netsh interface ipv6 show subinterfaces). Linux on the other hand defaults to 1480, but it is changeable. A working PMTUd will resolve MTU problems, both on underlying IPv4 node <-> 6to4-gateway, but this isn't the issue at the moment. The issue is what MTU value a single random 6to4-gateway today should have (purposefully not considering "the whole"), to maximize good interoperability and minimize problems. I'm not really concerned with the values of a end-node's 6to4 interface. I am not satisfied by the reasoning in 4213#3.2.1 in this regard, hence this mail. 3.2.1 to me doesn't seem to talk about a the MTU value of the interface on a globally announced relay gateway. Cheers, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/e11eec47/attachment.bin From ek at google.com Thu Mar 11 12:56:53 2010 From: ek at google.com (Erik Kline) Date: Thu, 11 Mar 2010 20:56:53 +0900 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <1268307617.2878.31.camel@hsa.vpn.anti> References: <1268307617.2878.31.camel@hsa.vpn.anti> Message-ID: <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> On 11 March 2010 20:40, Martin Millnert wrote: > Hello list, > > was discussing best 6to4-relay interface MTU size with a friend and > basically need more and wiser input. > > Apparently, Free BSD has a unmodifiable, static value of 1280 for the > 6in4-interface. It could be argued that this follows 4213 3.2.1 > ( http://tools.ietf.org/html/rfc4213#section-3.2.1 ). OSX also has a > static value of 1280, unmodifiable (I try to stay away from OSX, could > this be due to the kernel being the same?). XP reportedly also defaults > to 1280, and I see my Windows 7-box does the same for 6to4, which > appears once I deactivate native IPv6 on my LAN interface ?(netsh > interface ipv6 show subinterfaces). > > Linux on the other hand defaults to 1480, but it is changeable. > > A working PMTUd will resolve MTU problems, both on underlying IPv4 node > <-> 6to4-gateway, but this isn't the issue at the moment. > > The issue is what MTU value a single random 6to4-gateway today should > have (purposefully not considering "the whole"), to maximize good > interoperability and minimize problems. > > I'm not really concerned with the values of a end-node's 6to4 interface. > > I am not satisfied by the reasoning in 4213#3.2.1 in this regard, hence > this mail. 3.2.1 to me doesn't seem to talk about a the MTU value of the > interface on a globally announced relay gateway. > > Cheers, > Martin > Not to be too snarky, but how about 0? Just let 6to4 die. Please, please, please don't waste any time with 6to4. From nick-lists at netability.ie Thu Mar 11 12:58:13 2010 From: nick-lists at netability.ie (Nick Hilliard) Date: Thu, 11 Mar 2010 11:58:13 +0000 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> Message-ID: <4B98DAD5.9040607@netability.ie> On 11/03/2010 11:56, Erik Kline wrote: > Not to be too snarky, but how about 0? Just let 6to4 die. Please, > please, please don't waste any time with 6to4. +1 Nick From jeroen at unfix.org Thu Mar 11 12:58:38 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 12:58:38 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <1268307617.2878.31.camel@hsa.vpn.anti> References: <1268307617.2878.31.camel@hsa.vpn.anti> Message-ID: <4B98DAEE.2090400@spaghetti.zurich.ibm.com> Martin Millnert wrote: > Hello list, > > was discussing best 6to4-relay interface MTU size with a friend and > basically need more and wiser input. 1280. If you have anything else, you are being silly. [..] > A working PMTUd will resolve MTU problems, both on underlying IPv4 node > <-> 6to4-gateway, but this isn't the issue at the moment. Not in this case. PMTUd will resolve MTU problems on the layer that it is running, thus IPv6. But that won't affect the IPv4 layer. Remember, you are tunneling, thus both rules for IPv4 and IPv6 apply. The better question is actually: why bother with 6to4? Yes, it is a nice quick deployment strategy, but for anything long term, go native... (or at least native addresses using 6rd or something). 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/20100311/af7b4c2a/attachment.bin From martin at airwire.ie Thu Mar 11 13:05:13 2010 From: martin at airwire.ie (Martin List-Petersen) Date: Thu, 11 Mar 2010 12:05:13 +0000 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <1268307617.2878.31.camel@hsa.vpn.anti> References: <1268307617.2878.31.camel@hsa.vpn.anti> Message-ID: <4B98DC79.1040606@airwire.ie> Hi, Your underlying network is the factor, that limits you and that's the IPv4 network. Remember, 6to4 is tunneling, just like 6in4. So your MTU has to be smaller than 1500. EVERYONE is running 1280, why do you want to run something else and break things even further. Beyond that, fine if you run a gateway, but I'd focus my efforts to get people to go native and not use 6to4 or try to change 6to4. 6to4 is defined, it (sort of) works as it is and it will die eventually. Kind regards, Martin List-Petersen Airwire Martin Millnert wrote: > Hello list, > > was discussing best 6to4-relay interface MTU size with a friend and > basically need more and wiser input. > > Apparently, Free BSD has a unmodifiable, static value of 1280 for the > 6in4-interface. It could be argued that this follows 4213 3.2.1 > ( http://tools.ietf.org/html/rfc4213#section-3.2.1 ). OSX also has a > static value of 1280, unmodifiable (I try to stay away from OSX, could > this be due to the kernel being the same?). XP reportedly also defaults > to 1280, and I see my Windows 7-box does the same for 6to4, which > appears once I deactivate native IPv6 on my LAN interface (netsh > interface ipv6 show subinterfaces). > > Linux on the other hand defaults to 1480, but it is changeable. > > A working PMTUd will resolve MTU problems, both on underlying IPv4 node > <-> 6to4-gateway, but this isn't the issue at the moment. > > The issue is what MTU value a single random 6to4-gateway today should > have (purposefully not considering "the whole"), to maximize good > interoperability and minimize problems. > > I'm not really concerned with the values of a end-node's 6to4 interface. > > I am not satisfied by the reasoning in 4213#3.2.1 in this regard, hence > this mail. 3.2.1 to me doesn't seem to talk about a the MTU value of the > interface on a globally announced relay gateway. > > Cheers, > Martin From berni at birkenwald.de Thu Mar 11 13:12:58 2010 From: berni at birkenwald.de (Bernhard Schmidt) Date: Thu, 11 Mar 2010 13:12:58 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <1268307617.2878.31.camel@hsa.vpn.anti> References: <1268307617.2878.31.camel@hsa.vpn.anti> Message-ID: <4B98DE4A.3070303@birkenwald.de> On 11.03.2010 12:40, Martin Millnert wrote: Hi Martin, > Apparently, Free BSD has a unmodifiable, static value of 1280 for the > 6in4-interface. It could be argued that this follows 4213 3.2.1 > ( http://tools.ietf.org/html/rfc4213#section-3.2.1 ). OSX also has a > static value of 1280, unmodifiable (I try to stay away from OSX, could > this be due to the kernel being the same?). XP reportedly also defaults > to 1280, and I see my Windows 7-box does the same for 6to4, which > appears once I deactivate native IPv6 on my LAN interface (netsh > interface ipv6 show subinterfaces). > > Linux on the other hand defaults to 1480, but it is changeable. > > A working PMTUd will resolve MTU problems, both on underlying IPv4 node > <-> 6to4-gateway, but this isn't the issue at the moment. I suggest 1280 as well. RFC 3056 Section 4 (and most of the 6to4 proto41 traffic I see on the network) suggests that the DF bit is not to be set. Which means you won't have pMTU discovery, but slow and painful fragmentation in transit. Bernhard From martin at millnert.se Thu Mar 11 13:22:02 2010 From: martin at millnert.se (Martin Millnert) Date: Thu, 11 Mar 2010 13:22:02 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B98DAD5.9040607@netability.ie> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> Message-ID: <1268310122.2878.57.camel@hsa.vpn.anti> On Thu, 2010-03-11 at 11:58 +0000, Nick Hilliard wrote: > On 11/03/2010 11:56, Erik Kline wrote: > > Not to be too snarky, but how about 0? Just let 6to4 die. Please, > > please, please don't waste any time with 6to4. > > +1 > > Nick Well, if providing 6to4 relays for the gigabits upon gigabits of 6to4 IPv6 traffic there is on the Internet is actually harmful for the deployment of IPv6, we'd gladly stop to provide the service. Same for the Teredo relay we run, which considering your stance on providing 6to4 relays, I'm sure you are ten times as eager to kill off. :) However, let's be practical here for a while. If nobody provided neither 6to4 relays nor Teredo relays, 95% (statistics made up on the spot, but prove me wrong) of IPv6 traffic today would disappear, surely including breakage of ~all IPv6 hosted sites for end-users. So while I'm all for native v6 everywhere, the community has already made sure that current operating systems provide transition mechanisms, and even-more-so, activate them by default. Isn't it just a little late to retract operational support for them now since they're already there? If we do agree that Internet users are better off not having IPv6 at all unless it's native, then we should convince OS vendors to ship updates that disable these functions. Cheers, -- Martin Millnert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/8a5fac62/attachment.bin From martin at millnert.se Thu Mar 11 13:26:47 2010 From: martin at millnert.se (Martin Millnert) Date: Thu, 11 Mar 2010 13:26:47 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <4B98DAEE.2090400@spaghetti.zurich.ibm.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAEE.2090400@spaghetti.zurich.ibm.com> Message-ID: <1268310407.2878.63.camel@hsa.vpn.anti> On Thu, 2010-03-11 at 12:58 +0100, Jeroen Massar wrote: > The better question is actually: why bother with 6to4? I think you missed in what light I posed the question. I'm asking as a provider of a relay. We announce it to other networks and they use it. The "please kill 6to4"-thing is... within the other thread. > Yes, it is a nice quick deployment strategy, but for anything long term, > go native... (or at least native addresses using 6rd or something). As for our own end-users, barring crappy WLAN APs with built-in stupid NAT, nice and neat native IPv6 have been available for some 8 years now. Cheers, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/93e09742/attachment.bin From martin at millnert.se Thu Mar 11 13:30:40 2010 From: martin at millnert.se (Martin Millnert) Date: Thu, 11 Mar 2010 13:30:40 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <4B98DC79.1040606@airwire.ie> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DC79.1040606@airwire.ie> Message-ID: <1268310640.2878.67.camel@hsa.vpn.anti> On Thu, 2010-03-11 at 12:05 +0000, Martin List-Petersen wrote: > Hi, > > Your underlying network is the factor, that limits you and that's the > IPv4 network. Remember, 6to4 is tunneling, just like 6in4. > > So your MTU has to be smaller than 1500. EVERYONE is running 1280, why > do you want to run something else and break things even further. I've missed the memo saying that I should change it, if I run the gateway in Linux. :) I mean, that's why I'm asking. I'm missing a relevant section in a RFC stating that a global relay should be configured according to XYZ, due to ABC. Even after reading tens of RFCs multiple times, it can be hard to distill that XYZ. > Beyond that, fine if you run a gateway, but I'd focus my efforts to get > people to go native and not use 6to4 or try to change 6to4. 6to4 is > defined, it (sort of) works as it is and it will die eventually. See other thread. Cheers, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/11e83e4c/attachment-0001.bin From martin at airwire.ie Thu Mar 11 13:39:51 2010 From: martin at airwire.ie (Martin List-Petersen) Date: Thu, 11 Mar 2010 12:39:51 +0000 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <1268310640.2878.67.camel@hsa.vpn.anti> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DC79.1040606@airwire.ie> <1268310640.2878.67.camel@hsa.vpn.anti> Message-ID: <4B98E497.2000003@airwire.ie> Martin Millnert wrote: > On Thu, 2010-03-11 at 12:05 +0000, Martin List-Petersen wrote: >> Hi, >> >> Your underlying network is the factor, that limits you and that's the >> IPv4 network. Remember, 6to4 is tunneling, just like 6in4. >> >> So your MTU has to be smaller than 1500. EVERYONE is running 1280, why >> do you want to run something else and break things even further. > > I've missed the memo saying that I should change it, if I run the > gateway in Linux. :) I mean, that's why I'm asking. I'm missing a > relevant section in a RFC stating that a global relay should be > configured according to XYZ, due to ABC. Even after reading tens of RFCs > multiple times, it can be hard to distill that XYZ. I guess there has been no MTU specified in any RFC, because pMTU discovery should be taking care of it. My point really is, that you can't go beyond 1480 because you are tunneling over an unknown network, where you have to assume that a lot of it is no higher than 1500, if not less. The vast majority of end-users will be sitting behind a PPPoE or PPPoA tunnel, so they have less than 1500. 1280 has sort of been adapted for 6in4 tunneling and thus most 6to4 implementations follow that same setup. Kind regards, Martin List-Petersen Airwire From jeroen at unfix.org Thu Mar 11 13:52:58 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 13:52:58 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <1268310407.2878.63.camel@hsa.vpn.anti> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAEE.2090400@spaghetti.zurich.ibm.com> <1268310407.2878.63.camel@hsa.vpn.anti> Message-ID: <4B98E7AA.2060303@spaghetti.zurich.ibm.com> Martin Millnert wrote: > On Thu, 2010-03-11 at 12:58 +0100, Jeroen Massar wrote: >> The better question is actually: why bother with 6to4? > > I think you missed in what light I posed the question. I'm asking as a > provider of a relay. We announce it to other networks and they use it. If it is in another network then you do not know the MTU of the IPv4 link, thus then especially it just can be 1280. > The "please kill 6to4"-thing is... within the other thread. After you created that thread, maybe it belongs there. >> Yes, it is a nice quick deployment strategy, but for anything long term, >> go native... (or at least native addresses using 6rd or something). > > As for our own end-users, barring crappy WLAN APs with built-in stupid > NAT, nice and neat native IPv6 have been available for some 8 years now. Then why bother with a 6to4 relay that other networks are using? Then again, your money. 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/20100311/54a9ee67/attachment.bin From jeroen at unfix.org Thu Mar 11 13:56:47 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 13:56:47 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <1268310122.2878.57.camel@hsa.vpn.anti> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> Message-ID: <4B98E88F.1050009@spaghetti.zurich.ibm.com> Martin Millnert wrote: > On Thu, 2010-03-11 at 11:58 +0000, Nick Hilliard wrote: >> On 11/03/2010 11:56, Erik Kline wrote: >>> Not to be too snarky, but how about 0? Just let 6to4 die. Please, >>> please, please don't waste any time with 6to4. >> >> +1 >> >> Nick > > Well, if providing 6to4 relays for the gigabits upon gigabits of 6to4 > IPv6 traffic there is on the Internet is actually harmful for the > deployment of IPv6, we'd gladly stop to provide the service. Wow, please provide those statistics somewhere. I am sure lots of people would love to see this, especially with a small analysis of what the traffic most likely is (the answer is most very likely NNTP). > Same for > the Teredo relay we run, which considering your stance on providing 6to4 > relays, I'm sure you are ten times as eager to kill off. :) Teredo has the same issues as 6to4: anycast in both IPv4 and IPv6 thus you never know the path that the packets will follow, thus it is horribly hard to debug; unless you have access to every single hop in the path of course. THAT is the reason why 6to4 and Teredo are a bad thing: debugging. Over all these years there have been a lot of problems with those setups and people keep on complaining as it is causing brokeness. And no, there is no magic way to fix this, if you have it though, please illuminate the rest of the world with your awesome idea. 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/20100311/e0211bb3/attachment.bin From martin at millnert.se Thu Mar 11 14:04:18 2010 From: martin at millnert.se (Martin Millnert) Date: Thu, 11 Mar 2010 14:04:18 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <4B98E497.2000003@airwire.ie> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DC79.1040606@airwire.ie> <1268310640.2878.67.camel@hsa.vpn.anti> <4B98E497.2000003@airwire.ie> Message-ID: <1268312658.2878.86.camel@hsa.vpn.anti> On Thu, 2010-03-11 at 12:39 +0000, Martin List-Petersen wrote: > 1280 has sort of been adapted for 6in4 tunneling and thus most 6to4 > implementations follow that same setup. If ->all implementations configure 1280 (which they seem to do, except Linux), where will the hurt be in a relay having >1280? Not in 6to4-node -> relay -> v6 internet, at least. In the reverse path (v6 internet -> relay -> 6to4-node) there can obviously be problems on the IPv6 internet, but that's the general IPv6 internet case today and the MTU of my relay will not change this one way or another. On the v4 side of the reverse path however, there can be a difference and this is what I was originally wondering about. This sort of operational feedback is what I believe is missing from the relevant RFCs. Perhaps its obvious to most, it wasn't to me. While speaking about RFC:s, 3056 clearly states that anyone running a relay at 192.88.99.1 that is announced MUST also operate the gateway with a unicast address, for trouble shoot purposes. ~nobody does that. It helpfully leaves out *how* a end-user is supposed to find his equivalent unicast address though. :) [ http://tools.ietf.org/html/rfc3068#section-4.5 ] So RFC's only go so far. Operational feedback is strictly necessary and this is ipv6-ops after all. :) Me toying with 6to4 isn't that big of a problem, nor is any time that could be better used on other v6 things wasted, to the best of my knowledge; we already provide native v6 to our users since long ago, we dual-stack web servers, we operate v6 DNS and announce v6 resolvers to customers. We do everything short of knocking doors and talking with them about why they should spend 50?(?) on a WiFi router that handles native IPv6 while NAT:ing IPv4. Other suggestions for what we should do for IPv6 at this point are welcome. Thanks all who responded. I've configured our relay to 1280 now. Cheers, -- Martin Millnert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/4e9af4b1/attachment.bin From berni at birkenwald.de Thu Mar 11 14:06:20 2010 From: berni at birkenwald.de (Bernhard Schmidt) Date: Thu, 11 Mar 2010 14:06:20 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B98E88F.1050009@spaghetti.zurich.ibm.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <4B98E88F.1050009@spaghetti.zurich.ibm.com> Message-ID: <4B98EACC.6000509@birkenwald.de> Hi Jeroen, > Teredo has the same issues as 6to4: anycast in both IPv4 and IPv6 thus > you never know the path that the packets will follow, thus it is > horribly hard to debug; unless you have access to every single hop in > the path of course. Where exactly is there IPv4 anycast in Teredo? Teredo makes a few things a bit easier in debugging (since both directions go through the same relay), but makes it a lot harder as well (you need full end-to-end connectivity for connection setup/relay selection/trace, plus the dependency on (mostly third-party) Teredo servers, plus the statefulness on the relays). If there was an agreement to kill those services sooner than later I would be happy to be part of it, but at least for 6to4 this will be impossible. Bernhard From jeroen at unfix.org Thu Mar 11 14:17:30 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 14:17:30 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: References: Message-ID: <4B98ED6A.4070309@spaghetti.zurich.ibm.com> holger.zuleger at vodafone.com wrote: >> The better question is actually: why bother with 6to4? >> >> Yes, it is a nice quick deployment strategy, but for anything long term, >> go native... (or at least native addresses using 6rd or something). > But with 6rd you will end up in the same discussion. No you won't, as 6rd is a *LOCAL* solution and all the infrastructure involved is owned and operator by the ISP who runs it. As such, you won't have any debugging issues as one controls all the hops and there is no anycast pull on either IPv4 or IPv6. This is also one of the many reasons that 6rd exists: the address space routing is controlled by the entity that operates it (of course other ISPs can do whatever they want with it, but not in the way that one can with 6to4) just like their other native space. Of course, one should always plan to move your customers to native IPv6 over time, but that is why they call it a transition mechanism. (Think of the time where you can't get anymore IPv4 space to route that IPv6 space with, also the MTU is lower than 1500 thus suboptimal, especially combined with PPPOE and other tunnels which might lower it a bit more in some cases). 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/20100311/160f2afe/attachment.bin From jeroen at unfix.org Thu Mar 11 14:24:25 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 14:24:25 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B98EACC.6000509@birkenwald.de> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <4B98E88F.1050009@spaghetti.zurich.ibm.com> <4B98EACC.6000509@birkenwald.de> Message-ID: <4B98EF09.8070309@spaghetti.zurich.ibm.com> Bernhard Schmidt wrote: > Hi Jeroen, > >> Teredo has the same issues as 6to4: anycast in both IPv4 and IPv6 thus >> you never know the path that the packets will follow, thus it is >> horribly hard to debug; unless you have access to every single hop in >> the path of course. > > Where exactly is there IPv4 anycast in Teredo? Ah, meh, indeed, it is fortunately not on the IPv4 level ;) > Teredo makes a few things a bit easier in debugging (since both > directions go through the same relay), but makes it a lot harder as well > (you need full end-to-end connectivity for connection setup/relay > selection/trace, plus the dependency on (mostly third-party) Teredo > servers, plus the statefulness on the relays). Every tech has a side-effect... > If there was an agreement > to kill those services sooner than later I would be happy to be part of > it, but at least for 6to4 this will be impossible. The thing with 6to4 & Teredo (& Tunnel Brokers & 6rd etc etc) is that they should be of temporary nature. It seems some ISPs want to simply use them as their permanent plan "look folks we deploy IPv6" while they actually just use 6to4/Teredo actually operated by another ISP. And that is a good thing. I do also hope folks realize that one day or another they should be turning those services off, especially in the light of security and the abuse that can be done through them (spoofing ole). 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/20100311/6a20a673/attachment.bin From martin at millnert.se Thu Mar 11 14:29:14 2010 From: martin at millnert.se (Martin Millnert) Date: Thu, 11 Mar 2010 14:29:14 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B98E88F.1050009@spaghetti.zurich.ibm.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <4B98E88F.1050009@spaghetti.zurich.ibm.com> Message-ID: <1268314154.2878.104.camel@hsa.vpn.anti> On Thu, 2010-03-11 at 13:56 +0100, Jeroen Massar wrote: > > Well, if providing 6to4 relays for the gigabits upon gigabits of 6to4 > > IPv6 traffic there is on the Internet is actually harmful for the > > deployment of IPv6, we'd gladly stop to provide the service. > > Wow, please provide those statistics somewhere. I am sure lots of people > would love to see this, especially with a small analysis of what the > traffic most likely is (the answer is most very likely NNTP). We have our own stats at http://stats.csbnet.se/public/ipv6/ . Tele2 has some at http://ipv6.tele2.net/6to4_stats.php . Sweden is pretty much littered with 6to4 relays and I do not have access to a complete set of statistics. So I extrapolate. Our reach for our own 6to4-relay into other people's IPv4 networks is very limited. So I'm estimating something on the order of 1-5 gigabits at peak hour in Sweden. 3301 run their own relays. It is hard to get a good view of this. The best yield in result vs effort would probably be to measure SFlow stats on the Netnod IX's, I guess. > > Same for > > the Teredo relay we run, which considering your stance on providing 6to4 > > relays, I'm sure you are ten times as eager to kill off. :) > > Teredo has the same issues as 6to4: anycast in both IPv4 and IPv6 thus > you never know the path that the packets will follow, thus it is > horribly hard to debug; unless you have access to every single hop in > the path of course. Except Teredo isn't anycast in v4. See http://technet.microsoft.com/en-us/library/bb457011.aspx On v4 client-side, it's client-server, and client-relay, where both are unicast UDP connections. A v6 connection over Teredo is in that regard assymetric, but not in the same way as 6to4. A Teredo ipv6 connection settles down at the relay closest (in BGP terms) to the non-Teredo v6 side. Teredo-Teredo is a special case (see fig 15 and 16). That the teredo server used is encoded in the Teredo address unfortunately doesn't help that much in debugging network issues. This falls on operators. > THAT is the reason why 6to4 and Teredo are a bad thing: debugging. > Over all these years there have been a lot of problems with those setups > and people keep on complaining as it is causing brokeness. > And no, there is no magic way to fix this, if you have it though, please > illuminate the rest of the world with your awesome idea. I'm no magician, sadly. RFC3068 does require good monitoring in section 4.4, of the relay by its operating party. That's the best you can do :/ Same with Teredo. Cheers, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/7bafb7d0/attachment-0001.bin From thomas at cis.uni-muenchen.de Thu Mar 11 14:29:49 2010 From: thomas at cis.uni-muenchen.de (=?UTF-8?B?VGhvbWFzIFNjaMOkZmVy?=) Date: Thu, 11 Mar 2010 14:29:49 +0100 Subject: different content In-Reply-To: <4B98C3B5.4020401@birkenwald.de> References: <4B98B0A8.6040501@cis.uni-muenchen.de> <4B98C3B5.4020401@birkenwald.de> Message-ID: <4B98F04D.8090804@cis.uni-muenchen.de> Bernhard Schmidt schrieb: > On 11.03.2010 09:58, Thomas Sch?fer wrote: > > > This sounds vaguely familiar. http://www.apo-snow.com has the same > problem since at least three months. I've never managed to get an answer > from either AMEN or the customer itself. > I think the misconfiguration by amen concerns more than 50 active websites. Unfortunately I cannot provide a list anymore without extra effort. > Does anyone know someone at AMEN? No, I contacted them via http://www.amen.fr/support/contact/information.php I have got the answer (quoted in my first email regarding this issue) from AMEN.FR - Support Jean-louis Another popular problem are AAAA-Record like this: wesleyschool.org has IPv6 address :: or something like this: 007c.com has IPv6 address ::1 123china.co.kr has IPv6 address ::1 123sem.co.kr has IPv6 address ::1 1mp3.org has IPv6 address ::1 addlinkurl.com has IPv6 address ::1 articlemap.com has IPv6 address ::1 axisb.com has IPv6 address ::1 blinkingtextlive.com has IPv6 address ::1 central.net has IPv6 address ::1 channuoiheo.com has IPv6 address ::1 cl2000.com has IPv6 address ::1 clayhouseceramics.com has IPv6 address ::1 easygraffititext.com has IPv6 address ::1 easypichosting.com has IPv6 address ::1 gimp.com has IPv6 address ::1 glittertextgraphics.com has IPv6 address ::1 glittertextlive.com has IPv6 address ::1 kezet.com has IPv6 address ::1 look-inc.jp has IPv6 address ::1 marqueetextlive.com has IPv6 address ::1 metapack.com has IPv6 address ::1 millnicmedia.com has IPv6 address ::1 mobilereviewsonline.com has IPv6 address ::1 mypulau.com has IPv6 address ::1 mytextgraphics.com has IPv6 address ::1 nasmedia.co.kr has IPv6 address ::1 naturalseo.co.kr has IPv6 address ::1 nsmartad.com has IPv6 address ::1 oceanreefresorts.com has IPv6 address ::1 privatepilot.com has IPv6 address ::1 searchscout.com has IPv6 address ::1 shop-network.org has IPv6 address ::1 smfoogle.com has IPv6 address ::1 sparklee.com has IPv6 address ::1 talkzy.com has IPv6 address ::1 thearticlezone.com has IPv6 address ::1 thecw.com has IPv6 address ::1 topsitelists.com has IPv6 address ::1 www.clayhouseceramics.com has IPv6 address ::1 This list is not complete. Regards, Thomas Sch?fer From martin at millnert.se Thu Mar 11 14:37:01 2010 From: martin at millnert.se (Martin Millnert) Date: Thu, 11 Mar 2010 14:37:01 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B98EF09.8070309@spaghetti.zurich.ibm.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <4B98E88F.1050009@spaghetti.zurich.ibm.com> <4B98EACC.6000509@birkenwald.de> <4B98EF09.8070309@spaghetti.zurich.ibm.com> Message-ID: <1268314621.2878.107.camel@hsa.vpn.anti> On Thu, 2010-03-11 at 14:24 +0100, Jeroen Massar wrote: > The thing with 6to4 & Teredo (& Tunnel Brokers & 6rd etc etc) > I do also hope folks realize that one day or > another they should be turning those services off, especially in the > light of security and the abuse that can be done through them (spoofing > ole). Agreed. For the same reason, the RIR:s should make sure that 6rd allocations are transitional only, ie temporary. In other words, once the transition is complete, the space will be returned. This is another topic though and is probably more appropriate for $RIR-ipv6-wg-list. Cheers, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/df1d6779/attachment.bin From john at sackheads.org Thu Mar 11 14:40:33 2010 From: john at sackheads.org (John Payne) Date: Thu, 11 Mar 2010 08:40:33 -0500 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> <20100310111617.GC1464@Space.Net> <20100310203415.GJ1464@Space.Net> Message-ID: <467C1AD2-5257-4FD0-942A-48CA7738CA57@sackheads.org> On Mar 11, 2010, at 3:55 AM, Mohacsi Janos wrote: > > > > On Wed, 10 Mar 2010, Benedikt Stockebrand wrote: > >> >> And keep in mind that with the RFC 3041 privacy extensions enabled by >> default on post-XP Windows boxes, the majority of them *will* cycle >> through the /64 anyway. > > > Then these systems are Not compliant to RFC 4941. > http://tools.ietf.org/html/rfc4941 > > The updated privacy extension draft requires the default to be off. Windows 7 shipped with it on :( From jeroen at unfix.org Thu Mar 11 14:47:15 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 14:47:15 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <1268314621.2878.107.camel@hsa.vpn.anti> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <4B98E88F.1050009@spaghetti.zurich.ibm.com> <4B98EACC.6000509@birkenwald.de> <4B98EF09.8070309@spaghetti.zurich.ibm.com> <1268314621.2878.107.camel@hsa.vpn.anti> Message-ID: <4B98F463.3060106@spaghetti.zurich.ibm.com> Martin Millnert wrote: > On Thu, 2010-03-11 at 14:24 +0100, Jeroen Massar wrote: >> The thing with 6to4 & Teredo (& Tunnel Brokers & 6rd etc etc) > >> I do also hope folks realize that one day or >> another they should be turning those services off, especially in the >> light of security and the abuse that can be done through them (spoofing >> ole). > > Agreed. For the same reason, the RIR:s should make sure that 6rd > allocations are transitional only, ie temporary. In other words, once > the transition is complete, the space will be returned. This is another > topic though and is probably more appropriate for $RIR-ipv6-wg-list. That address space comes from the ISP's own /32 (or more), and thus, if they plan correctly they can easily stop doing 6rd at one point and then re-use that address space for something else. The RIRs are not involved in that part. 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/20100311/4f8cdfca/attachment.bin From tjc at ecs.soton.ac.uk Thu Mar 11 15:12:28 2010 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 11 Mar 2010 14:12:28 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B98F463.3060106@spaghetti.zurich.ibm.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <4B98E88F.1050009@spaghetti.zurich.ibm.com> <4B98EACC.6000509@birkenwald.de> <4B98EF09.8070309@spaghetti.zurich.ibm.com> <1268314621.2878.107.camel@hsa.vpn.anti> <4B98F463.3060106@spaghetti.zurich.ibm.com> <20100311141228.GT26334@login.ecs.soton.ac.uk> Message-ID: On Thu, Mar 11, 2010 at 02:47:15PM +0100, Jeroen Massar wrote: > Martin Millnert wrote: > > On Thu, 2010-03-11 at 14:24 +0100, Jeroen Massar wrote: > >> The thing with 6to4 & Teredo (& Tunnel Brokers & 6rd etc etc) > > > >> I do also hope folks realize that one day or > >> another they should be turning those services off, especially in the > >> light of security and the abuse that can be done through them (spoofing > >> ole). > > > > Agreed. For the same reason, the RIR:s should make sure that 6rd > > allocations are transitional only, ie temporary. In other words, once > > the transition is complete, the space will be returned. This is another > > topic though and is probably more appropriate for $RIR-ipv6-wg-list. > > That address space comes from the ISP's own /32 (or more), and thus, if > they plan correctly they can easily stop doing 6rd at one point and then > re-use that address space for something else. Agreed, that's one beauty of 6rd - the ISP can contain its transition within its own address space, at its own pace. I'm interested in what Nick's many gigabits of 6to4 traffic is - what are the apps people are running? For us, at least for website access, less than 1% of the IPv6 traffic we get is from 6to4 sources. -- Tim From martin at millnert.se Thu Mar 11 15:23:07 2010 From: martin at millnert.se (Martin Millnert) Date: Thu, 11 Mar 2010 15:23:07 +0100 Subject: On 6RD space address policy In-Reply-To: <4B98F463.3060106@spaghetti.zurich.ibm.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <4B98E88F.1050009@spaghetti.zurich.ibm.com> <4B98EACC.6000509@birkenwald.de> <4B98EF09.8070309@spaghetti.zurich.ibm.com> <1268314621.2878.107.camel@hsa.vpn.anti> <4B98F463.3060106@spaghetti.zurich.ibm.com> Message-ID: <1268317387.2878.126.camel@hsa.vpn.anti> (non-operational content) On Thu, 2010-03-11 at 14:47 +0100, Jeroen Massar wrote: > That address space comes from the ISP's own /32 (or more), and thus, if > they plan correctly they can easily stop doing 6rd at one point and then > re-use that address space for something else. Well, considering the amount of space 6RD require, it massively dwarfs any other equivalent IPv6 method known today (equivalent in terms of number of customers in non-theoretical, current, operational (v4-)networks). Hence, they'd do good, to avoid having to renumber once the 6RD transition is over and their need for the mostly 6RD space goes away, to have it allocated in a way that enables them to easily return this space. Having to renumber back from a /24 to a /32 for example, is not what I consider easy (for a ~large ISP) IMHO. > The RIRs are not involved in that part. There was a case where RIPE did not know how to consider a 6RD request, so the community was polled for feedback. That discussion on the ipv6-wg IIRC never reached consensus (more like, it died out). [ http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2009/msg00166.html ] I'll pose the question there as this is the second time in a not so long while that it has come up in my vicinity. Cheers, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/b42eb83a/attachment.bin From jeroen at unfix.org Thu Mar 11 15:29:59 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 15:29:59 +0100 Subject: On 6RD space address policy In-Reply-To: <1268317387.2878.126.camel@hsa.vpn.anti> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <4B98E88F.1050009@spaghetti.zurich.ibm.com> <4B98EACC.6000509@birkenwald.de> <4B98EF09.8070309@spaghetti.zurich.ibm.com> <1268314621.2878.107.camel@hsa.vpn.anti> <4B98F463.3060106@spaghetti.zurich.ibm.com> <1268317387.2878.126.camel@hsa.vpn.anti> Message-ID: <4B98FE67.7030604@spaghetti.zurich.ibm.com> Martin Millnert wrote: > (non-operational content) > > On Thu, 2010-03-11 at 14:47 +0100, Jeroen Massar wrote: >> That address space comes from the ISP's own /32 (or more), and thus, if >> they plan correctly they can easily stop doing 6rd at one point and then >> re-use that address space for something else. > > Well, considering the amount of space 6RD require, it massively dwarfs [..] > There was a case where RIPE did not know how to consider a 6RD request, > so the community was polled for feedback. That discussion on the ipv6-wg > IIRC never reached consensus (more like, it died out). > [ http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2009/msg00166.html ] And as Alex from RIPE NCC answered in the followup, paraphrased: Don't encode the full 32-bit address in there. If you have a /20 full of customers, then you only need 12bits to encode that. Give the user a /48, and you need 48-12 = /36 or for a /56 you would only need a 56-12 = /48. Sorry but I don't see a problem there. If you indeed have a /16 full of users, then you need 16 bits, thus 48-16 = /32 only one single /32 ;) For the ISPs who are much larger than that, well they can easily justify having more address space. 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/20100311/095e96fd/attachment.bin From mohacsi at niif.hu Thu Mar 11 15:35:38 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 11 Mar 2010 15:35:38 +0100 (CET) Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <4B98DAEE.2090400@spaghetti.zurich.ibm.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAEE.2090400@spaghetti.zurich.ibm.com> Message-ID: On Thu, 11 Mar 2010, Jeroen Massar wrote: > Martin Millnert wrote: >> Hello list, >> >> was discussing best 6to4-relay interface MTU size with a friend and >> basically need more and wiser input. > > 1280. > > If you have anything else, you are being silly. > > [..] >> A working PMTUd will resolve MTU problems, both on underlying IPv4 node >> <-> 6to4-gateway, but this isn't the issue at the moment. > > Not in this case. PMTUd will resolve MTU problems on the layer that it > is running, thus IPv6. But that won't affect the IPv4 layer. Remember, > you are tunneling, thus both rules for IPv4 and IPv6 apply. > > > The better question is actually: why bother with 6to4? > > Yes, it is a nice quick deployment strategy, but for anything long term, > go native... (or at least native addresses using 6rd or something). You know this not very easy is most of the situation. Let's suppose there are student and professors who are using IPv6 at the universities. They are using their own machines (laptops) to access IPv6 services, and they are getting to used some services in IPv6. But while they are at home they are using some broadband services (e.g. xDSL, cable, 3G-mobile etc.), where in most of cases no IPv6 service (and unfortunately no plan for it from telcos). How to access IPv6 service without IPv6 address: - use 6to4 since good number of soho routers has some form of 6to4 support. - user teredo if the host system support it. The research network is providing 6to4 relay and/or teredo relay announced via local IXs.... The tunnel broker might be another option..... Best Regards, Janos Mohacsi From gert at space.net Thu Mar 11 15:42:28 2010 From: gert at space.net (Gert Doering) Date: Thu, 11 Mar 2010 15:42:28 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAEE.2090400@spaghetti.zurich.ibm.com> Message-ID: <20100311144228.GH69383@Space.Net> Hi, On Thu, Mar 11, 2010 at 03:35:38PM +0100, Mohacsi Janos wrote: > You know this not very easy is most of the situation. Let's suppose there > are student and professors who are using IPv6 at the universities. They > are using their own machines (laptops) to access IPv6 services, and they > are getting to used some services in IPv6. [..] > The tunnel broker might be another option..... Tunnel broker at the university would be my favourite - it's well-defined and well-controlled, and the university personell would know whom to contact if it breaks. And at the same time complain to whoever is providing your IPv4-only access to the net... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 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 otroan at employees.org Thu Mar 11 15:44:10 2010 From: otroan at employees.org (Ole Troan) Date: Thu, 11 Mar 2010 15:44:10 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAEE.2090400@spaghetti.zurich.ibm.com> Message-ID: >>> Hello list, >>> >>> was discussing best 6to4-relay interface MTU size with a friend and >>> basically need more and wiser input. >> >> 1280. >> >> If you have anything else, you are being silly. >> >> [..] >>> A working PMTUd will resolve MTU problems, both on underlying IPv4 node >>> <-> 6to4-gateway, but this isn't the issue at the moment. >> >> Not in this case. PMTUd will resolve MTU problems on the layer that it >> is running, thus IPv6. But that won't affect the IPv4 layer. Remember, >> you are tunneling, thus both rules for IPv4 and IPv6 apply. >> >> >> The better question is actually: why bother with 6to4? >> >> Yes, it is a nice quick deployment strategy, but for anything long term, >> go native... (or at least native addresses using 6rd or something). > > > You know this not very easy is most of the situation. Let's suppose there are student and professors who are using IPv6 at the universities. They are using their own machines (laptops) to access IPv6 services, and they are getting to used some services in IPv6. > But while they are at home they are using some broadband services (e.g. xDSL, cable, 3G-mobile etc.), where in most of cases no IPv6 service (and unfortunately no plan for it from telcos). How to access IPv6 service without IPv6 address: > > - use 6to4 since good number of soho routers has some form of 6to4 support. > - user teredo if the host system support it. > > The research network is providing 6to4 relay and/or teredo relay announced via local IXs.... > > The tunnel broker might be another option..... my assertions would be that unless IPv6 is supported in the network you connect to, you should not bother. and in fact do more damage to IPv6 deployment than good. by providing 'broken' IPv6 hosts, prohibiting content providers from enabling IPv6 on their services, and end users to disable IPv6. see: http://www.google.com/trends?q=disable+ipv6%2C+enable+ipv6 (and no it is not scientific, and I'm sure you could make google trends show anything you want, but it is quite funny even so). ;-) cheers, Ole From mohacsi at niif.hu Thu Mar 11 15:47:42 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 11 Mar 2010 15:47:42 +0100 (CET) Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <20100311144228.GH69383@Space.Net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAEE.2090400@spaghetti.zurich.ibm.com> <20100311144228.GH69383@Space.Net> Message-ID: On Thu, 11 Mar 2010, Gert Doering wrote: > Hi, > > On Thu, Mar 11, 2010 at 03:35:38PM +0100, Mohacsi Janos wrote: >> You know this not very easy is most of the situation. Let's suppose there >> are student and professors who are using IPv6 at the universities. They >> are using their own machines (laptops) to access IPv6 services, and they >> are getting to used some services in IPv6. > [..] >> The tunnel broker might be another option..... > > Tunnel broker at the university would be my favourite - it's well-defined > and well-controlled, and the university personell would know whom to contact > if it breaks. Any usable tunnel broker available for free or cheaply? Best Regards, Janos Mohacsi From gert at space.net Thu Mar 11 15:54:35 2010 From: gert at space.net (Gert Doering) Date: Thu, 11 Mar 2010 15:54:35 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAEE.2090400@spaghetti.zurich.ibm.com> <20100311144228.GH69383@Space.Net> Message-ID: <20100311145435.GI69383@Space.Net> Hi, On Thu, Mar 11, 2010 at 03:47:42PM +0100, Mohacsi Janos wrote: > Any usable tunnel broker available for free or cheaply? I'm not 100% sure, but as far as I understood, the SIXXS stuff is available (and they will even operate the broker if you provide the hardware and IPv6 space, or something like that). Jeroen will tell us... Besides that, the university might provide a VPN solution for their user base, and might consider adding IPv6 to that (Cisco Anyconnect, OpenVPN come to mind). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/5579a991/attachment.bin From martin at millnert.se Thu Mar 11 15:55:40 2010 From: martin at millnert.se (Martin Millnert) Date: Thu, 11 Mar 2010 15:55:40 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAEE.2090400@spaghetti.zurich.ibm.com> <20100311144228.GH69383@Space.Net> Message-ID: <1268319340.2878.146.camel@hsa.vpn.anti> On Thu, 2010-03-11 at 15:47 +0100, Mohacsi Janos wrote: > Any usable tunnel broker available for free or cheaply? SixXS ( http://www.sixxs.net/main/ ) and HE ( http://tunnelbroker.net/ ) comes to mind. Cheers, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/5d3f2e80/attachment.bin From jeroen at unfix.org Thu Mar 11 16:21:54 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 16:21:54 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <20100311145435.GI69383@Space.Net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAEE.2090400@spaghetti.zurich.ibm.com> <20100311144228.GH69383@Space.Net> <20100311145435.GI69383@Space.Net> Message-ID: <4B990A92.60406@spaghetti.zurich.ibm.com> Gert Doering wrote: > Hi, > > On Thu, Mar 11, 2010 at 03:47:42PM +0100, Mohacsi Janos wrote: >> Any usable tunnel broker available for free or cheaply? > > I'm not 100% sure, but as far as I understood, the SIXXS stuff is available > (and they will even operate the broker if you provide the hardware and > IPv6 space, or something like that). Jeroen will tell us... Yep, very short edition: just install a minimum debian on a box or vm, install our root ssh key, route a /40 to the IPv6 address of the box, give it an IPv4 address, define the policy who can use the box etc and we'll do the rest. Free and for fun(tm). Of course, the true intention is that those boxes can go away at one point and it is primarily there to bridge a gap. > Besides that, the university might provide a VPN solution for their user > base, and might consider adding IPv6 to that (Cisco Anyconnect, OpenVPN > come to mind). That is another option, which is probably better for a closed user group. Also note that the folks at Hexago/Gogo6/$todaysname will happily sell you a GogoServer which is their Tunnelbroker in a box setup. 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/20100311/a3f6308f/attachment.bin From phrickman at upcbroadband.com Thu Mar 11 13:40:45 2010 From: phrickman at upcbroadband.com (Rickman, Phil) Date: Thu, 11 Mar 2010 13:40:45 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <4B98E497.2000003@airwire.ie> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DC79.1040606@airwire.ie> <1268310640.2878.67.camel@hsa.vpn.anti>,<4B98E497.2000003@airwire.ie> Message-ID: you need to consider the latency on pMTU in general with long paths as the negotiation needs to be distributed along each link - each negotiating locally and globally. Statics cannot be configured only at 1280 as anything higher on your network would cause drops from an originating MTU along the path higher than 1280. Phil Rickman NDA DD - +31 207 789 969 Mob: +31 610847604 ________________________________________ From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of Martin List-Petersen [martin at airwire.ie] Sent: 11 March 2010 13:39 To: Martin Millnert Cc: ipv6-ops at lists.cluenet.de Subject: Re: On 6to4 gateway and recommended MTU setting Martin Millnert wrote: > On Thu, 2010-03-11 at 12:05 +0000, Martin List-Petersen wrote: >> Hi, >> >> Your underlying network is the factor, that limits you and that's the >> IPv4 network. Remember, 6to4 is tunneling, just like 6in4. >> >> So your MTU has to be smaller than 1500. EVERYONE is running 1280, why >> do you want to run something else and break things even further. > > I've missed the memo saying that I should change it, if I run the > gateway in Linux. :) I mean, that's why I'm asking. I'm missing a > relevant section in a RFC stating that a global relay should be > configured according to XYZ, due to ABC. Even after reading tens of RFCs > multiple times, it can be hard to distill that XYZ. I guess there has been no MTU specified in any RFC, because pMTU discovery should be taking care of it. My point really is, that you can't go beyond 1480 because you are tunneling over an unknown network, where you have to assume that a lot of it is no higher than 1500, if not less. The vast majority of end-users will be sitting behind a PPPoE or PPPoA tunnel, so they have less than 1500. 1280 has sort of been adapted for 6in4 tunneling and thus most 6to4 implementations follow that same setup. Kind regards, Martin List-Petersen Airwire From holger.zuleger at vodafone.com Thu Mar 11 14:05:16 2010 From: holger.zuleger at vodafone.com (holger.zuleger at vodafone.com) Date: Thu, 11 Mar 2010 14:05:16 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <4B98DAEE.2090400@spaghetti.zurich.ibm.com> Message-ID: > The better question is actually: why bother with 6to4? > > Yes, it is a nice quick deployment strategy, but for anything long term, > go native... (or at least native addresses using 6rd or something). But with 6rd you will end up in the same discussion. Holger From phrickman at upcbroadband.com Thu Mar 11 18:48:55 2010 From: phrickman at upcbroadband.com (Rickman, Phil) Date: Thu, 11 Mar 2010 18:48:55 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: References: <4B98DAEE.2090400@spaghetti.zurich.ibm.com>, Message-ID: You cant go full native without massive application incompatibility Embedded IPv4 addresses etc ... with only 5% of "potential" content available for standard users let alone IP based VPN clients, RDP, the list is endless of what breaks when you leave dual stack. You also have issues with bi-directional routing, DR & LI, DNS64 preferences ..... And Holger is right 6rd has the same its own personal problems. Phil ________________________________________ From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of holger.zuleger at vodafone.com [holger.zuleger at vodafone.com] Sent: 11 March 2010 14:05 To: Jeroen Massar Cc: Martin Millnert; ipv6-ops at lists.cluenet.de; ipv6-ops-bounces+holger.zuleger=arcor.net at lists.cluenet.de Subject: Re: Re: On 6to4 gateway and recommended MTU setting > The better question is actually: why bother with 6to4? > > Yes, it is a nice quick deployment strategy, but for anything long term, > go native... (or at least native addresses using 6rd or something). But with 6rd you will end up in the same discussion. Holger From fstoyan at swapon.de Thu Mar 11 18:50:20 2010 From: fstoyan at swapon.de (Friedemann Stoyan) Date: Thu, 11 Mar 2010 18:50:20 +0100 Subject: different content In-Reply-To: <4B98C3B5.4020401@birkenwald.de> References: <4B98B0A8.6040501@cis.uni-muenchen.de> <4B98C3B5.4020401@birkenwald.de> Message-ID: <20100311175020.GA13322@reliant.lab.swapon.de> On 11.03.10 11:19, Bernhard Schmidt wrote: > > This sounds vaguely familiar. http://www.apo-snow.com has the same > problem since at least three months. I've never managed to get an answer > from either AMEN or the customer itself. > Same with: $ curl -v http://www.nic.it/ * About to connect() to www.nic.it port 80 (#0) * Trying 2a00:d40:1:1::239... connected * Connected to www.nic.it (2a00:d40:1:1::239) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.18.2 (x86_64-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g > zlib/1.2.3.3 libidn/1.8 libssh2/0.18 > Host: www.nic.it > Accept: */* > * Empty reply from server * Connection #0 to host www.nic.it left intact curl: (52) Empty reply from server * Closing connection #0 I have mailed the hostmaster but no answer too. Regards Friedemann From thomas at cis.uni-muenchen.de Thu Mar 11 19:20:27 2010 From: thomas at cis.uni-muenchen.de (Thomas =?utf-8?q?Sch=C3=A4fer?=) Date: Thu, 11 Mar 2010 19:20:27 +0100 Subject: different content In-Reply-To: <20100311175020.GA13322@reliant.lab.swapon.de> References: <4B98B0A8.6040501@cis.uni-muenchen.de> <4B98C3B5.4020401@birkenwald.de> <20100311175020.GA13322@reliant.lab.swapon.de> Message-ID: <201003111920.27917.thomas@cis.uni-muenchen.de> Am Donnerstag 11 M?rz 2010 schrieb Friedemann Stoyan: > On 11.03.10 11:19, Bernhard Schmidt wrote: > > This sounds vaguely familiar. http://www.apo-snow.com has the same > > problem since at least three months. I've never managed to get an answer > > from either AMEN or the customer itself. > > Same with: > > $ curl -v http://www.nic.it/ I cannot confirm this. It works with ipv4 and ipv6 in the same manner. curl -v -6 http://www.nic.it/ curl -v -4 http://www.nic.it/ I think, it was a temporary problem. "My" problem with "amen" and the wrong AAAA-Records are still there. Regards, Thomas From jeroen at unfix.org Thu Mar 11 19:34:35 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 19:34:35 +0100 Subject: Native IPv6 & 6rd (Was: On 6to4 gateway and recommended MTU setting) In-Reply-To: References: <4B98DAEE.2090400@spaghetti.zurich.ibm.com>, Message-ID: <4B9937BB.3010005@spaghetti.zurich.ibm.com> Rickman, Phil wrote: > You cant go full native without massive application incompatibility With 'native' most people mean dual-stack: native IPv4 + native IPv6. Where the 'native' means that if you have ethernet that both IPv4 and IPv6 are directly on top of that, without any extra secret magic layers in between. Apologies if you understood differently. Deploying IPv6-only is a silly thing, though there might be scenarious where people want that, then one will have to go the CGN/IVI etc road. > Embedded IPv4 addresses etc ... with only 5% of "potential" content > available for standard users let alone IP based VPN clients, RDP, > the list is endless of what breaks when you leave dual stack. RDP (Remote Desktop Protocol) actually works like a charm as Microsoft nicely upgraded all their important tools to understand IPv6. Also, see above, in the case of IPv6-only: one will have to do CGN/IVI alike tricks. > You > also have issues with bi-directional routing, DR & LI, DNS64 preferences ..... > > And Holger is right 6rd has the same its own personal problems. Please provide the list of issues to the writers of the 6rd RFC, I am sure they would love to know about them. Do realize that most transition mechanisms solve a specific issue as such they won't make everybody happy. 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/20100311/886bb9c6/attachment.bin From brian.e.carpenter at gmail.com Thu Mar 11 21:20:14 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 12 Mar 2010 09:20:14 +1300 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: References: Message-ID: <4B99507E.50806@gmail.com> On 2010-03-12 02:05, holger.zuleger at vodafone.com wrote: >> The better question is actually: why bother with 6to4? >> >> Yes, it is a nice quick deployment strategy, but for anything long term, >> go native... (or at least native addresses using 6rd or something). > But with 6rd you will end up in the same discussion. 6to4 and 6rd are *both* transitional solutions that will die in due time. Since we have plenty of running code experience that they work well with 1280 and sometimes hit PMTUD failures with 1480, any operator who wants to avoid unwanted phone calls will use 1280. Time enough to worry about an optimal value when you go native. By the way, we didn't know enough when RFC3056 was written to suggest a default, and we were too optimistic about PMTUD, so it didn't seem to matter. Brian From otroan at employees.org Thu Mar 11 21:25:41 2010 From: otroan at employees.org (Ole Troan) Date: Thu, 11 Mar 2010 21:25:41 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <4B99507E.50806@gmail.com> References: <4B99507E.50806@gmail.com> Message-ID: <7E8D6539-0EB1-40D3-9C14-0A75ECDB1ECC@employees.org> >>> The better question is actually: why bother with 6to4? >>> >>> Yes, it is a nice quick deployment strategy, but for anything long term, >>> go native... (or at least native addresses using 6rd or something). >> But with 6rd you will end up in the same discussion. > > 6to4 and 6rd are *both* transitional solutions that will die in due time. > > Since we have plenty of running code experience that they work well with > 1280 and sometimes hit PMTUD failures with 1480, any operator who wants to > avoid unwanted phone calls will use 1280. Time enough to worry about an > optimal value when you go native. > > By the way, we didn't know enough when RFC3056 was written to suggest a > default, and we were too optimistic about PMTUD, so it didn't seem to matter. I see no reason to suggest a default of 1280 for 6rd though, as one can expect the MTU to be well managed within the ISP. unless you also wanted to suggest that the default IPv6 MTU for _every_ independent of linktype must be 1280? if we do that, will we ever get away from it again? cheers, Ole From brian.e.carpenter at gmail.com Thu Mar 11 21:31:46 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 12 Mar 2010 09:31:46 +1300 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <4B98E88F.1050009@spaghetti.zurich.ibm.com> <4B98EACC.6000509@birkenwald.de> <4B98EF09.8070309@spaghetti.zurich.ibm.com> <1268314621.2878.107.camel@hsa.vpn.anti> <4B98F463.3060106@spaghetti.zurich.ibm.com> <20100311141228.GT26334@login.ecs.soton.ac.uk> Message-ID: <4B995332.1050508@gmail.com> On 2010-03-12 03:12, Tim Chown wrote: > On Thu, Mar 11, 2010 at 02:47:15PM +0100, Jeroen Massar wrote: >> Martin Millnert wrote: >>> On Thu, 2010-03-11 at 14:24 +0100, Jeroen Massar wrote: >>>> The thing with 6to4 & Teredo (& Tunnel Brokers & 6rd etc etc) >>> >>>> I do also hope folks realize that one day or >>>> another they should be turning those services off, especially in the >>>> light of security and the abuse that can be done through them (spoofing >>>> ole). >>> Agreed. For the same reason, the RIR:s should make sure that 6rd >>> allocations are transitional only, ie temporary. In other words, once >>> the transition is complete, the space will be returned. This is another >>> topic though and is probably more appropriate for $RIR-ipv6-wg-list. >> That address space comes from the ISP's own /32 (or more), and thus, if >> they plan correctly they can easily stop doing 6rd at one point and then >> re-use that address space for something else. > > Agreed, that's one beauty of 6rd - the ISP can contain its transition > within its own address space, at its own pace. > > I'm interested in what Nick's many gigabits of 6to4 traffic is - what > are the apps people are running? For us, at least for website access, > less than 1% of the IPv6 traffic we get is from 6to4 sources. But then, people likely to access your site are mainly in NRENs where there is native v6. I think the figures for Google v6 would be more interesting, but they aren't in Lorenzo's latest talk (http://www.apricot2010.net/__data/assets/pdf_file/0007/18997/IPv6-at-Google.pdf) However, he did say that their biggest contingent of users is from France, and that means 6rd. Brian From brian.e.carpenter at gmail.com Thu Mar 11 21:35:01 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 12 Mar 2010 09:35:01 +1300 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <7E8D6539-0EB1-40D3-9C14-0A75ECDB1ECC@employees.org> References: <4B99507E.50806@gmail.com> <7E8D6539-0EB1-40D3-9C14-0A75ECDB1ECC@employees.org> Message-ID: <4B9953F5.9050809@gmail.com> On 2010-03-12 09:25, Ole Troan wrote: >>>> The better question is actually: why bother with 6to4? >>>> >>>> Yes, it is a nice quick deployment strategy, but for anything long term, >>>> go native... (or at least native addresses using 6rd or something). >>> But with 6rd you will end up in the same discussion. >> 6to4 and 6rd are *both* transitional solutions that will die in due time. >> >> Since we have plenty of running code experience that they work well with >> 1280 and sometimes hit PMTUD failures with 1480, any operator who wants to >> avoid unwanted phone calls will use 1280. Time enough to worry about an >> optimal value when you go native. >> >> By the way, we didn't know enough when RFC3056 was written to suggest a >> default, and we were too optimistic about PMTUD, so it didn't seem to matter. > > I see no reason to suggest a default of 1280 for 6rd though, as one can expect the MTU to be well managed within the ISP. unless you also wanted to suggest that the default IPv6 MTU for _every_ independent of linktype must be 1280? if we do that, will we ever get away from it again? > I guess. But as I've said over in the IETF discussion, experience with broken PMTUD in IPv4 was that setting a low value was the least painful choice, until things got better in the network as a whole. Brian From otroan at employees.org Thu Mar 11 21:56:34 2010 From: otroan at employees.org (Ole Troan) Date: Thu, 11 Mar 2010 21:56:34 +0100 Subject: On 6to4 gateway and recommended MTU setting In-Reply-To: <4B9953F5.9050809@gmail.com> References: <4B99507E.50806@gmail.com> <7E8D6539-0EB1-40D3-9C14-0A75ECDB1ECC@employees.org> <4B9953F5.9050809@gmail.com> Message-ID: Brian, >>>>> The better question is actually: why bother with 6to4? >>>>> >>>>> Yes, it is a nice quick deployment strategy, but for anything long term, >>>>> go native... (or at least native addresses using 6rd or something). >>>> But with 6rd you will end up in the same discussion. >>> 6to4 and 6rd are *both* transitional solutions that will die in due time. >>> >>> Since we have plenty of running code experience that they work well with >>> 1280 and sometimes hit PMTUD failures with 1480, any operator who wants to >>> avoid unwanted phone calls will use 1280. Time enough to worry about an >>> optimal value when you go native. >>> >>> By the way, we didn't know enough when RFC3056 was written to suggest a >>> default, and we were too optimistic about PMTUD, so it didn't seem to matter. >> >> I see no reason to suggest a default of 1280 for 6rd though, as one can expect the MTU to be well managed within the ISP. unless you also wanted to suggest that the default IPv6 MTU for _every_ independent of linktype must be 1280? if we do that, will we ever get away from it again? >> > > I guess. But as I've said over in the IETF discussion, experience with > broken PMTUD in IPv4 was that setting a low value was the least painful > choice, until things got better in the network as a whole. aren't there two issues here. it is the issue of the tunnel MTU itself being smaller than the transport MTU to avoid fragmentation, and then there is the end to end IPv6 MTU. we could say in the IETF IPv6 CPE router requirement draft that the default MTU should be advertised as 1280 for example. but that's a pretty big change. Geoff Huston has an interesting blog post on the issue of MTU http://www.potaroo.net/ispcol/2009-02/mtu.html cheers, Ole From ek at google.com Thu Mar 11 23:41:53 2010 From: ek at google.com (Erik Kline) Date: Fri, 12 Mar 2010 07:41:53 +0900 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B995332.1050508@gmail.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <1268310122.2878.57.camel@hsa.vpn.anti> <4B98E88F.1050009@spaghetti.zurich.ibm.com> <4B98EACC.6000509@birkenwald.de> <4B98EF09.8070309@spaghetti.zurich.ibm.com> <1268314621.2878.107.camel@hsa.vpn.anti> <4B98F463.3060106@spaghetti.zurich.ibm.com> <20100311141228.GT26334@login.ecs.soton.ac.uk> <4B995332.1050508@gmail.com> Message-ID: <2e8c64261003111441o20523e4eg9e7003b280eec8ff@mail.gmail.com> >> I'm interested in what Nick's many gigabits of 6to4 traffic is - what >> are the apps people are running? ? For us, at least for website access, >> less than 1% of the IPv6 traffic we get is from 6to4 sources. > > But then, people likely to access your site are mainly in NRENs > where there is native v6. I think the figures for Google v6 would be > more interesting, but they aren't in Lorenzo's latest talk > (http://www.apricot2010.net/__data/assets/pdf_file/0007/18997/IPv6-at-Google.pdf) > However, he did say that their biggest contingent of users is > from France, and that means 6rd. Right now, about 0.325% of our users we detect as being IPv6 capable, 58% of which have 6to4. Those 6to4 users have, at varying times, experienced an /average/ of 50-150msec extra latency. This is why we have the whitelisting stuff. As Lorenzo has said, in response to the claim "There's nothing wrong with perfectly working 6to4!": "Yeah, but there's nothing right about it either." From phrickman at upcbroadband.com Fri Mar 12 01:13:51 2010 From: phrickman at upcbroadband.com (Rickman, Phil) Date: Fri, 12 Mar 2010 01:13:51 +0100 Subject: Native IPv6 & 6rd (Was: On 6to4 gateway and recommended MTU setting) In-Reply-To: <4B9937BB.3010005@spaghetti.zurich.ibm.com> References: <4B98DAEE.2090400@spaghetti.zurich.ibm.com>, , <4B9937BB.3010005@spaghetti.zurich.ibm.com> Message-ID: well that really deems no reply. Phil ________________________________________ From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of Jeroen Massar [jeroen at unfix.org] Sent: 11 March 2010 19:34 To: Rickman, Phil Cc: holger.zuleger at vodafone.com; ipv6-ops at lists.cluenet.de Subject: Native IPv6 & 6rd (Was: On 6to4 gateway and recommended MTU setting) Rickman, Phil wrote: > You cant go full native without massive application incompatibility With 'native' most people mean dual-stack: native IPv4 + native IPv6. Where the 'native' means that if you have ethernet that both IPv4 and IPv6 are directly on top of that, without any extra secret magic layers in between. Apologies if you understood differently. Deploying IPv6-only is a silly thing, though there might be scenarious where people want that, then one will have to go the CGN/IVI etc road. > Embedded IPv4 addresses etc ... with only 5% of "potential" content > available for standard users let alone IP based VPN clients, RDP, > the list is endless of what breaks when you leave dual stack. RDP (Remote Desktop Protocol) actually works like a charm as Microsoft nicely upgraded all their important tools to understand IPv6. Also, see above, in the case of IPv6-only: one will have to do CGN/IVI alike tricks. > You > also have issues with bi-directional routing, DR & LI, DNS64 preferences ..... > > And Holger is right 6rd has the same its own personal problems. Please provide the list of issues to the writers of the 6rd RFC, I am sure they would love to know about them. Do realize that most transition mechanisms solve a specific issue as such they won't make everybody happy. Greets, Jeroen From dougb at dougbarton.us Fri Mar 12 05:37:35 2010 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 11 Mar 2010 20:37:35 -0800 Subject: IPv6 black lists? In-Reply-To: References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> <20100310111617.GC1464@Space.Net> <20100310203415.GJ1464@Space.Net> Message-ID: <4B99C50F.2020500@dougbarton.us> On 3/11/2010 12:55 AM, Mohacsi Janos wrote: > > > > On Wed, 10 Mar 2010, Benedikt Stockebrand wrote: > >> >> And keep in mind that with the RFC 3041 privacy extensions enabled by >> default on post-XP Windows boxes, the majority of them *will* cycle >> through the /64 anyway. > > > Then these systems are Not compliant to RFC 4941. > http://tools.ietf.org/html/rfc4941 It's a SHOULD in 4941, not a MUST. > The updated privacy extension draft requires the default to be off. Is this a new draft different from 4941? If so, URL? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From me at benedikt-stockebrand.de Fri Mar 12 13:47:29 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Fri, 12 Mar 2010 12:47:29 +0000 Subject: IPv6 black lists? In-Reply-To: <20100311081621.GP1464@Space.Net> (Gert Doering's message of "Thu, 11 Mar 2010 09:16:21 +0100") References: <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> <20100310111617.GC1464@Space.Net> <20100310203415.GJ1464@Space.Net> <20100311081621.GP1464@Space.Net> Message-ID: Hi Gert and list, Gert Doering writes: > There are no other customers in the same /64 subnet. ok, so how do you do that as a mass web hoster with >60k machines (e.g. United Internet, last time I talked to them) if your customers expect both IPv4 and IPv6 to work? Put every machine in its own subnet? At Spacenet you might be able to do that, but in the low cost hosting business it doesn't necessarily work. (Neither does it when you are running the WLAN infrastructure at a large event---CeBIT immediatly comes to mind.) And don't discount the low cost business as irrelevant -- the Internet we have today was effectively funded by those pesky "I want it cheap" end users. BTW, there's a BSI (Federal Office for IT Security (in Germany)) project working on an IPv6 security guideline. Among other things we (I'm one of the authors) strongly suggest to use a network topology with "many small subnets" to get rid of a number of problems. The key drawback of such a topology is that means you can't deploy IPv6 that way along an existing ("NetBIOS-style") IPv4 topology with few large subnets. That implies that dual-stacked subnets are troublesome and should be used only for servers in "normal" (i.e. government and medium-to-large business) setups, but unfortunately that's exactly where hosters aren't "normal" and have to come up with a more elaborate solution. > Please repeat. > > There are no other customers in the same /64 subnet. Again, don't assume everybody on the Internet to have the same problems as you. One-size-fits-all approaches don't work well if the the user base is as diverse as on the Internet. And just repeating a mantra over and again doesn't make it right, it only makes you believe in it:-) >> Tell that to people in the low cost end user hosting business. With >> business customers you are right, because they tend to be willing to >> pay a bit more for reliable service at least to some degree, but end >> users frequently think quite differently. > > What's so hard to understand about "... deserve all the pain you can get"? Just because you can't hit the people causing the trouble that doesn't give you the right to wantonly hit arbitrary bystanders instead. Because your neighbor down the street bumped into my car doesn't give me the right to blow up yours. I am well aware that it is sometimes helpful to put some indirect pressure on the people providing the infrastructure for spammers and whatever, but doing so in this case and at this point will deter people from approaching IPv6. That's a Bad Thing. > Companies like Strato that have multiple customers in the same /64 > *have filters in place* to make sure that every customer will only > use the set of addresses assigned to his server, and nothing else. > > This model of deployment is more complicated than "just slap a /64 on > it, and every customer can run abuse from whatever address he wants to > pick" - but it's the only way to be able to do any sort of abuse handling, > not only SPAM. Let me repeat: "There are no other customers in the same /64 subnet." Sorry:-) I never said you should do this entire thing without some kind of filter mechanism. If you set up your filters to filter by /128, that's fine if your filters offer the functionality and performance, but as soon as people want multiple addresses (for virtual machines, zones, jails, or just multiple services) then these filters get even uglier than they are today. And to get back to the blacklisting topic: If you dish out prefixes anywhere from /$((128-$threshold)) to /65, that causes exactly the problem the IPv6 "movement" has the least possible use for: Eventually the entire /64 gets blacklisted and other people are affected in a way that drives them back to IPv4. > How are you going to trace back hacked machines etc. if you can't reliably > associate a given IPv6 address with a given server? Just to show that there are alternatives: One could do it the FC way, using static ARP (IPv4) and ND (IPv6), preferably together with a statically configured MAC-port mapping on your switches (if your switch vendor supports this and you find out how they call it). As far as I understand it, UI uses IPv4 "as is" and then tunnels IPv6 prefixes to individual customer machines (unfortunately, they only give out /56'es). When I first heard about that I thought they had been smoking some rather bad stuff, but that approach actually avoids the entire dual-stack topology issue even in their kind of business and even with virtual servers. Yet another solution would be to put every customer into their own subnet, giving them their own /64, and then set up IPv4 using point-to-point routes to preserve IPv4 addresses. And no, that's not a recommendation either, just to point out that there are alternatives. Whatever you do to deal with the dual-stack issue, it's going to be ugly one way or the other. You can only try to find the way that's the least ugly for your particular needs. > And if you can't do that, you shouldn't run an ISP. Now you're talking sense:-) Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From me at benedikt-stockebrand.de Fri Mar 12 14:04:24 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Fri, 12 Mar 2010 13:04:24 +0000 Subject: IPv6 black lists? In-Reply-To: (Mohacsi Janos's message of "Thu, 11 Mar 2010 09:55:22 +0100 (CET)") References: <4B964FEF.8070303@time-travellers.org> <4B965125.9020306@staff.spin.it> <4B96B3D1.9030501@gmail.com> <1268174471.2079.1.camel@maximus> <4B96E072.2060008@teklibre.org> <20100310110403.GA1464@Space.Net> <20100310111617.GC1464@Space.Net> <20100310203415.GJ1464@Space.Net> Message-ID: Hi again, Mohacsi Janos writes: > On Wed, 10 Mar 2010, Benedikt Stockebrand wrote: > >> >> And keep in mind that with the RFC 3041 privacy extensions enabled by >> default on post-XP Windows boxes, the majority of them *will* cycle >> through the /64 anyway. > > > Then these systems are Not compliant to RFC 4941. > http://tools.ietf.org/html/rfc4941 > > The updated privacy extension draft requires the default to be off. correct. Only since the original RFC 3041 didn't bother to provide an API for applications to choose between temporary and public addresses, most implementations provide a system-wide setting---BTW, do we have an API specification for that by now? Aside from that, I'm definitely not advocating the Microsoft approach here, my intention was only to point out a fact relevant to the blacklisting issue. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From ivan at main.uusia.org Sun Mar 14 08:15:14 2010 From: ivan at main.uusia.org (Ivan Shmakov) Date: Sun, 14 Mar 2010 13:15:14 +0600 Subject: On killing IPv6 transition mechanisms References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> Message-ID: <87634zwf0d.fsf@violet.siamics.net> >>>>> Martin Millnert writes: >>>>> Nick Hilliard wrote: >>>>> Erik Kline wrote: >>> Not to be too snarky, but how about 0? Just let 6to4 die. Please, >>> please, please don't waste any time with 6to4. >> +1 > Well, if providing 6to4 relays for the gigabits upon gigabits of 6to4 > IPv6 traffic there is on the Internet is actually harmful for the > deployment of IPv6, we'd gladly stop to provide the service. Same for > the Teredo relay we run, which considering your stance on providing > 6to4 relays, I'm sure you are ten times as eager to kill off. :) > However, let's be practical here for a while. > If nobody provided neither 6to4 relays nor Teredo relays, 95% > (statistics made up on the spot, but prove me wrong) of IPv6 traffic > today would disappear, surely including breakage of ~all IPv6 hosted > sites for end-users. Oh, guys, it seems to me that most of the better part of the world is surely ready to switch to native IPv6. However, what about the locations as distant as 83? E 53? W? There, I'm a customer of an ISP that offers a NAT-based service, so I, and their other customers, have no (Internet-routable) IPv4 address, let alone IPv6. Thanks to the brave old RFC 1918! Or, actually, they began to offer static Internet-routable IPv4 somewhat recently. Alas, this service is based on NAT, too, so neither 6to4, 6in4 or Teredo (unless relayed.) With regards to leaving this ISP and looking for another, the state of the local market seemed (the last time I've checked it) so bitter, that I've chosen to make a deal with an ISP in another city instead, connecting to them with OpenVPN. With that, and a few IPv4 I now have, I was able to get into IPv6, thanks to both HE.net and 6to4. And my coworkers are in the deal, too. Now, given the story above, are you sure that the world at large is ready for the transition mechanisms to be shut down? [...] -- FSF associate member #7257 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100314/286e9e4e/attachment.bin From gert at space.net Sun Mar 14 11:36:42 2010 From: gert at space.net (Gert Doering) Date: Sun, 14 Mar 2010 11:36:42 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <87634zwf0d.fsf@violet.siamics.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> Message-ID: <20100314103642.GF69383@Space.Net> Hi, On Sun, Mar 14, 2010 at 01:15:14PM +0600, Ivan Shmakov wrote: > With regards to leaving this ISP and looking for another, the > state of the local market seemed (the last time I've checked it) > so bitter, that I've chosen to make a deal with an ISP in > another city instead, connecting to them with OpenVPN. This is a cool workaround, and I'm sorry to hear about the sad state of IP networking in your area. (Actually this is why we *want* IPv6 - to get rid of NAT-based Internet offerings...) > With that, and a few IPv4 I now have, I was able to get into > IPv6, thanks to both HE.net and 6to4. And my coworkers are in > the deal, too. > > Now, given the story above, are you sure that the world at large > is ready for the transition mechanisms to be shut down? If you are using a configured tunnel from he.net, this is actually *not* 6to4 :-) - 6to4 is auto-tunneling, using 2002:xx addresses, relying on an unknown-to-you anycast relay somewhere in the world which is mostly impossible to troubleshoot. Some migration mechanisms are going to stay with us for a while, and "configured tunnels" (as he.net is offering) is one of them. Other migration mechanisms work well for some, and do not work at all for others, and you cannot fix it yourself because you rely on some unknown third party services - that's what 6to4 is, and which is why 6to4 (with anycast relays) is something prople consider potentially harmful today. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 ivan at main.uusia.org Sun Mar 14 12:57:54 2010 From: ivan at main.uusia.org (Ivan Shmakov) Date: Sun, 14 Mar 2010 17:57:54 +0600 Subject: On killing IPv6 transition mechanisms References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> Message-ID: <87wrxfunct.fsf@violet.siamics.net> >>>>> Gert Doering writes: >>>>> Ivan Shmakov wrote: >> With regards to leaving this ISP and looking for another, the state >> of the local market seemed (the last time I've checked it) so >> bitter, that I've chosen to make a deal with an ISP in another city >> instead, connecting to them with OpenVPN. > This is a cool workaround, and I'm sorry to hear about the sad state > of IP networking in your area. > (Actually this is why we *want* IPv6 - to get rid of NAT-based > Internet offerings...) The problem here is that most of the ISP here (at least those that offer services to private customers) just don't care. The other problems are, IIUC, that the staff isn't familiar of IPv6 (and it's a problem that needs a lot of care and time to resolve), and that the equipment is, most probably, was never tested to support IPv6. I'm trying my best to get the folks around here to familiarize themselves with IPv6 (including giving a talk at Software Freedom Day in 2009, and carrying over a course on computer networks, slightly biased towards IPv6, at the university I'm working at), but as one might guess, I have a plenty of other tasks to do. >> With that, and a few IPv4 I now have, I was able to get into IPv6, >> thanks to both HE.net and 6to4. And my coworkers are in the deal, >> too. >> Now, given the story above, are you sure that the world at large is >> ready for the transition mechanisms to be shut down? > If you are using a configured tunnel from he.net, this is actually > *not* 6to4 :-) - 6to4 is auto-tunneling, using 2002:xx addresses, I know the difference. The problem is that HE.net offers just a few /64, and I need somewhat larger address space. And they don't seem to offer reverse DNS, which is available for 6to4. Perhaps I should have tried SixXS.net instead, but it implied a slightly longer time to set-up. (OTOH, it works over NAT. And these folks operate a fancy HTTP proxy that allows IPv4 users to connect IPv6 HTTP servers and vice versa, too!) > relying on an unknown-to-you anycast relay somewhere in the world > which is mostly impossible to troubleshoot. Well, it seems that HE.net operates a 6to4 relay that's open for those subscribed to their 6in4 service. The anycast address doesn't seem to work from my ISP's network. > Some migration mechanisms are going to stay with us for a while, and > "configured tunnels" (as he.net is offering) is one of them. Given that it implies no automagic, I'd not be surprised. > Other migration mechanisms work well for some, and do not work at all > for others, and you cannot fix it yourself because you rely on some > unknown third party services - that's what 6to4 is, and which is why > 6to4 (with anycast relays) is something prople consider potentially > harmful today. I wonder, how no connectivity could be better than some? -- FSF associate member #7257 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100314/eb906a27/attachment.bin From gert at space.net Sun Mar 14 13:02:06 2010 From: gert at space.net (Gert Doering) Date: Sun, 14 Mar 2010 13:02:06 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <87wrxfunct.fsf@violet.siamics.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> Message-ID: <20100314120206.GH69383@Space.Net> Hi, On Sun, Mar 14, 2010 at 05:57:54PM +0600, Ivan Shmakov wrote: > > Other migration mechanisms work well for some, and do not work at all > > for others, and you cannot fix it yourself because you rely on some > > unknown third party services - that's what 6to4 is, and which is why > > 6to4 (with anycast relays) is something prople consider potentially > > harmful today. > > I wonder, how no connectivity could be better than some? That really depends. If you want to connect to an IPv6-only site, "crappy connectivity" might be better than no connectivity at all. If you connect to a dual-stack site, crappy IPv6 might actually make the connection a lot slower and painful than "no IPv6" - because with "no IPv6", the clients normally fall back to IPv4 pretty quickly. Of course this is assuming that you have halfway decent IPv4 :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 otroan at employees.org Sun Mar 14 13:20:04 2010 From: otroan at employees.org (Ole Troan) Date: Sun, 14 Mar 2010 13:20:04 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <87wrxfunct.fsf@violet.siamics.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> Message-ID: <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> > I wonder, how no connectivity could be better than some? because content providers measure the difference between IPv4 and IPv6 behaviour for dual stack hosts. if the number of hosts with broken IPv6 connectivity or with significantly worse latency than IPv4, they will not enable IPv6. to put it bluntly: if you don't get IPv6 from your SP, then don't bother. you are doing more harm to IPv6 deployment than good. cheers, Ole From ivan at main.uusia.org Sun Mar 14 13:23:13 2010 From: ivan at main.uusia.org (Ivan Shmakov) Date: Sun, 14 Mar 2010 18:23:13 +0600 Subject: On killing IPv6 transition mechanisms References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> Message-ID: <87sk83um6m.fsf@violet.siamics.net> >>>>> Ole Troan writes: >> I wonder, how no connectivity could be better than some? > because content providers measure the difference between IPv4 and > IPv6 behaviour for dual stack hosts. if the number of hosts with > broken IPv6 connectivity or with significantly worse latency than > IPv4, they will not enable IPv6. > to put it bluntly: if you don't get IPv6 from your SP, then don't > bother. you are doing more harm to IPv6 deployment than good. Would I bother not, who will? -- FSF associate member #7257 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100314/0b0abe67/attachment.bin From otroan at employees.org Sun Mar 14 13:57:47 2010 From: otroan at employees.org (Ole Troan) Date: Sun, 14 Mar 2010 13:57:47 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <87sk83um6m.fsf@violet.siamics.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <87sk83um6m.fsf@violet.siamics.net> Message-ID: >>> I wonder, how no connectivity could be better than some? > >> because content providers measure the difference between IPv4 and >> IPv6 behaviour for dual stack hosts. if the number of hosts with >> broken IPv6 connectivity or with significantly worse latency than >> IPv4, they will not enable IPv6. > >> to put it bluntly: if you don't get IPv6 from your SP, then don't >> bother. you are doing more harm to IPv6 deployment than good. > > Would I bother not, who will? there are lots of things you can do. make sure you're own network is IPv6 enabled, including hosts, applications, services, management..., nag your SP about IPv6. most of the SPs I talk with are thinking hard about IPv6 now, and I hope we'll start to see some big deployments during this year and next. that's a biased view though, since I'm only speak with people interested in IPv6. ;) cheers, Ole From ivan at main.uusia.org Sun Mar 14 14:22:36 2010 From: ivan at main.uusia.org (Ivan Shmakov) Date: Sun, 14 Mar 2010 19:22:36 +0600 Subject: On killing IPv6 transition mechanisms References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <87sk83um6m.fsf@violet.siamics.net> Message-ID: <87ocirujfn.fsf@violet.siamics.net> >>>>> Ole Troan writes: >>>> I wonder, how no connectivity could be better than some? >>> because content providers measure the difference between IPv4 and >>> IPv6 behaviour for dual stack hosts. if the number of hosts with >>> broken IPv6 connectivity or with significantly worse latency than >>> IPv4, they will not enable IPv6. To my mind this is only an issue when 6to4 is both used widely and cared for only superficially. >>> to put it bluntly: if you don't get IPv6 from your SP, then don't >>> bother. you are doing more harm to IPv6 deployment than good. And, BTW, I don't get IPv4 from my SP, either. Or does NAT count as ?IPv4 connectivity? nowadays? >> Would I bother not, who will? > there are lots of things you can do. make sure you're own network is > IPv6 enabled, including hosts, applications, services, management..., That's a great deal easier when there's both an address space assigned and the connectivity to the outer world, ain't it? > nag your SP about IPv6. With a single private customer demanding a service available to no one in the city, I'm in doubt that they are going to care. > most of the SPs I talk with are thinking hard about IPv6 now, and I > hope we'll start to see some big deployments during this year and > next. that's a biased view though, since I'm only speak with people > interested in IPv6. ;) And that view is, so to speak, is somewhat biased both ?geographically? and ?nationally?, isn't it? Some time ago I did a quick scan over some BGP data. In particular, it was easy to find that RUNNet, which claims to offer services to more than 400 universities and research institutes [1], has only a handful of IPv6 downlinks. The consequences are. [1] http://www.runnet.ru/ -- FSF associate member #7257 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100314/f21ed71e/attachment.bin From bjorn at mork.no Sun Mar 14 15:55:18 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sun, 14 Mar 2010 15:55:18 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <87wrxfunct.fsf@violet.siamics.net> (Ivan Shmakov's message of "Sun, 14 Mar 2010 17:57:54 +0600") References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> Message-ID: <87vdcz54x5.fsf@nemi.mork.no> Ivan Shmakov writes: > I know the difference. The problem is that HE.net offers just a > few /64, and I need somewhat larger address space. And they > don't seem to offer reverse DNS, which is available for 6to4. This is not correct. HE offer both routed /64s and /48s with delegated reverse DNS. They do not offer reverse DNS delegation for the tunnel prefixes. Neither do SIXXS. And that makes sense, IMHO. Bj?rn From ivan at main.uusia.org Sun Mar 14 19:22:58 2010 From: ivan at main.uusia.org (Ivan Shmakov) Date: Mon, 15 Mar 2010 00:22:58 +0600 Subject: On killing IPv6 transition mechanisms References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <87vdcz54x5.fsf@nemi.mork.no> Message-ID: <877hpevk3h.fsf@violet.siamics.net> >>>>> Bj?rn Mork writes: >>>>> Ivan Shmakov writes: >> I know the difference. The problem is that HE.net offers just a few >> /64, and I need somewhat larger address space. And they don't seem >> to offer reverse DNS, which is available for 6to4. > This is not correct. HE offer both routed /64s and /48s with > delegated reverse DNS. Nice to see they do it now; it wasn't the case when I began to explore IPv6 half a year ago. Okay, seemingly, that means that I need no 6to4 now. (What I need is some assistance in migrating a dozen of hosts or so, as well as a few DNS domains, to the new addresses.) > They do not offer reverse DNS delegation for the tunnel prefixes. > Neither do SIXXS. And that makes sense, IMHO. -- FSF associate member #7257 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100315/7361c0c6/attachment.bin From tony at lava.net Sun Mar 14 19:29:07 2010 From: tony at lava.net (Antonio Querubin) Date: Sun, 14 Mar 2010 08:29:07 -1000 (HST) Subject: On killing IPv6 transition mechanisms In-Reply-To: <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> Message-ID: On Sun, 14 Mar 2010, Ole Troan wrote: > to put it bluntly: if you don't get IPv6 from your SP, then don't > bother. you are doing more harm to IPv6 deployment than good. Extremism and exclusionary attitudes and practices have done and will do more harm to IPv6 deployment than good. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From broquea at he.net Sun Mar 14 19:39:14 2010 From: broquea at he.net (Alex Broque) Date: Sun, 14 Mar 2010 11:39:14 -0700 Subject: On killing IPv6 transition mechanisms In-Reply-To: <87wrxfunct.fsf@violet.siamics.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> Message-ID: <4B9D2D52.8040003@he.net> Ivan Shmakov wrote: > > I know the difference. The problem is that HE.net offers just a > few /64, and I need somewhat larger address space. And they > don't seem to offer reverse DNS, which is available for 6to4. > Just want to clarify some points. We've offered reverse DNS delegation for the /64 statically routed subnet since at least 2003, although it was a lot more manual configuration on our side back then. Then the /48 subnets since early 2008, which ushered in a more automated process for delegation for both /64 and /48 subnets. And yes, those are the only subnets that the user gets delegation control over. > Well, it seems that HE.net operates a 6to4 relay that's open for > those subscribed to their 6in4 service. > These are actually publicly available relays, and not limited to our tunnelbroker.net users. Those users obviously would be using static tunnels from that service, not tunnels based on the 6to4 well known anycasted ranges. Cheers, - Alex From ivan at main.uusia.org Sun Mar 14 20:09:37 2010 From: ivan at main.uusia.org (Ivan Shmakov) Date: Mon, 15 Mar 2010 01:09:37 +0600 Subject: On killing IPv6 transition mechanisms References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <4B9D2D52.8040003@he.net> Message-ID: <873a02vhxq.fsf@violet.siamics.net> >>>>> Alex Broque writes: >>>>> Ivan Shmakov wrote: >> I know the difference. The problem is that HE.net offers just a few >> /64, and I need somewhat larger address space. And they don't seem >> to offer reverse DNS, which is available for 6to4. > Just want to clarify some points. We've offered reverse DNS > delegation for the /64 statically routed subnet since at least 2003, > although it was a lot more manual configuration on our side back > then. Then the /48 subnets since early 2008, which ushered in a more > automated process for delegation for both /64 and /48 subnets. And > yes, those are the only subnets that the user gets delegation control > over. Perhaps I'm confusing the things up now, but I don't remember seeing reverse DNS being offered at https://tunnelbroker.net/, and I don't remember seeing /48 without ASN, either. Anyway, it's good to know that they are available now. Thanks. >> Well, it seems that HE.net operates a 6to4 relay that's open for >> those subscribed to their 6in4 service. > These are actually publicly available relays, and not limited to our > tunnelbroker.net users. Those users obviously would be using static > tunnels from that service, not tunnels based on the 6to4 well known > anycasted ranges. Well, it certainly makes sense. -- FSF associate member #7257 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100315/c79801e2/attachment.bin From otroan at employees.org Sun Mar 14 20:31:21 2010 From: otroan at employees.org (Ole Troan) Date: Sun, 14 Mar 2010 20:31:21 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> Message-ID: >> to put it bluntly: if you don't get IPv6 from your SP, then don't bother. you are doing more harm to IPv6 deployment than good. > > Extremism and exclusionary attitudes and practices have done and will do more harm to IPv6 deployment than good. obviously it isn't as simple as that. start off with the simple rule and make your exceptions as you see fit. in moving towards a production quality IPv6 Internet, you don't see any issues with 'unmanaged tunnels'? cheers, Ole From dougb at dougbarton.us Sun Mar 14 20:58:54 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 14 Mar 2010 12:58:54 -0700 Subject: On killing IPv6 transition mechanisms In-Reply-To: <873a02vhxq.fsf@violet.siamics.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <4B9D2D52.8040003@he.net> <873a02vhxq.fsf@violet.siamics.net> Message-ID: <4B9D3FFE.1050203@dougbarton.us> On 03/14/10 12:09, Ivan Shmakov wrote: >>>>>> Alex Broque writes: >>>>>> Ivan Shmakov wrote: > > >> I know the difference. The problem is that HE.net offers just a few > >> /64, and I need somewhat larger address space. And they don't seem > >> to offer reverse DNS, which is available for 6to4. > > > Just want to clarify some points. We've offered reverse DNS > > delegation for the /64 statically routed subnet since at least 2003, > > although it was a lot more manual configuration on our side back > > then. Then the /48 subnets since early 2008, which ushered in a more > > automated process for delegation for both /64 and /48 subnets. And > > yes, those are the only subnets that the user gets delegation control > > over. > > Perhaps I'm confusing the things up now, but I don't remember > seeing reverse DNS being offered at https://tunnelbroker.net/, > and I don't remember seeing /48 without ASN, either. Anyway, > it's good to know that they are available now. Thanks. I've had my tunnel since May 2008, and I can confirm that the /48 was offered at that time: http://www.tunnelbroker.net/forums/index.php?topic=106.0 Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From brian.e.carpenter at gmail.com Sun Mar 14 21:29:10 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 15 Mar 2010 09:29:10 +1300 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> Message-ID: <4B9D4716.8040403@gmail.com> On 2010-03-15 08:31, Ole Troan wrote: >>> to put it bluntly: if you don't get IPv6 from your SP, then don't bother. you are doing more harm to IPv6 deployment than good. >> Extremism and exclusionary attitudes and practices have done and will do more harm to IPv6 deployment than good. > > obviously it isn't as simple as that. start off with the simple rule and make your exceptions as you see fit. > > in moving towards a production quality IPv6 Internet, you don't see any issues with 'unmanaged tunnels'? As one of the authors of RFC 3056, it was my very conscious intention that 6to4 should be a subversive technology that could punch through, and quite possibly annoy or embarass, IPv4-only service providers. So it had two aims: give some kind of connectivity easily to early adopters stuck behind such service providers, and provide an incentive for those service providers to offer real IPv6 service instead. I can't speak for the author of RFC 3068 and RFC 4380, but I suspect a similar motivation. Judging by this thread, the plan is working ;-) But I don't see why we need a new plan to get rid of these mechanisms. They will go away spontaneously as ISPs add native support. Maybe in ten years it will be time to start picking off any IPv4-only ISPs that have survived, but I think most of them will have gone bust anyway. Brian From michael.dillon at bt.com Mon Mar 15 09:01:23 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 15 Mar 2010 08:01:23 -0000 Subject: IPv6 black lists? In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C4974580576EE3F@E03MVZ2-UKDY.domain1.systemhost.net> > > There are no other customers in the same /64 subnet. > > ok, so how do you do that as a mass web hoster with >60k > machines (e.g. United Internet, last time I talked to them) > if your customers expect both IPv4 and IPv6 to work? Put > every machine in its own subnet? Yes. Every machine could potentially be running some kind of virtualisation solution which means that what you see as 1 machine, is whole network of several virtual machines to the hosting customer. They should never get less than a /64. Making both IPv4 and IPv6 work is a transition question and the solution to that will not necesarily be the best practice after the transition period has passed. I think that hosters should implement the best IPv6 architecture right now, and apply transition mechanisms to make things work with two protocols. Also, note that it is only necessary to do this on new deployments. With existing hosting customers, whose machines will be depreciated and discarded before the end of IPv6 transition, you would have a different solution, probably some kind of v6 tunnel broker. --Michael Dillon From michael.dillon at bt.com Mon Mar 15 09:13:21 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 15 Mar 2010 08:13:21 -0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <87634zwf0d.fsf@violet.siamics.net> Message-ID: <28E139F46D45AF49A31950F88C4974580576EE55@E03MVZ2-UKDY.domain1.systemhost.net> > However, what about the locations as distant as 83? E 53? W? > There, I'm a customer of an ISP that offers a NAT-based service, > so I, and their other customers, have no (Internet-routable) > IPv4 address, let alone IPv6. Thanks to the brave old RFC 1918! This must be due to local economic conditions in Barnaul. > With regards to leaving this ISP and looking for another, the > state of the local market seemed (the last time I've checked it) > so bitter, that I've chosen to make a deal with an ISP in > another city instead, connecting to them with OpenVPN. Hopefully the other city is Novosibirsk, the 3rd largest in the Russian Federation. > With that, and a few IPv4 I now have, I was able to get into > IPv6, thanks to both HE.net and 6to4. And my coworkers are in > the deal, too. Using HE.net seems strange. Aren't their tunnel brokers all in California? You should look for a closer one such as SIXXS Also, lobby your government. The federal government in Russia has been taking several actions recently to improve the high tech economy. I believe that some of these actions involve IPv6. But one thing is certain, the federal government is ready to listen to people who have suggestions that can help grow the high tech economy in Russia. You shouldn't have to move to a city like Akademgorodok or Nizhniy Novgorod to participate. --Michael Dillon From michael.dillon at bt.com Mon Mar 15 09:19:31 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 15 Mar 2010 08:19:31 -0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> Message-ID: <28E139F46D45AF49A31950F88C4974580576EE5D@E03MVZ2-UKDY.domain1.systemhost.net> > to put it bluntly: if you don't get IPv6 from your SP, then > don't bother. you are doing more harm to IPv6 deployment than good. 15 years ago I was in the same position as Ivan, and did basically the same thing, i.e. get low grade connectivity using 56K frame relay for TCP/IP and UUNet over dialup. This soon evolved into the first ISP for my region. Weighing the pros and the cons, I think that it is better for Ivan to continue even if he does damage IPv6 deployment a little bit, because in the longer run he will have a new ISP running in Barnaul and perhaps even have a model that others can copy in other towns. The Russian Federation is a huge country and has the same Internet coverage problems that we still have in many parts of Canada, and in some rural areas of the USA. If these places can bootstrap IPv6 at the same time as they botstrap Internet connectivity, then it is better for all of us. --Michael Dillon From bjorn at mork.no Mon Mar 15 09:46:08 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Mon, 15 Mar 2010 09:46:08 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <28E139F46D45AF49A31950F88C4974580576EE55@E03MVZ2-UKDY.domain1.systemhost.net> (michael dillon's message of "Mon, 15 Mar 2010 08:13:21 -0000") References: <28E139F46D45AF49A31950F88C4974580576EE55@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <87iq8y3rcf.fsf@nemi.mork.no> writes: > Using HE.net seems strange. Aren't their tunnel brokers all in California? The fact checking skills are dropping fast on this list.... HE have tunnel servers all over Europe, and also in HK and CA. That's the country, not the state. Eh, well, they've got in the state as well but... Never mind, go look for yourself: http://www.tunnelbroker.net/usage/tunnels_by_latency.php Bj?rn (who have been enjoying a HE tunnel in London for quite some time, just to add to the weird locations where one might still need such hideous things) From tedm at ipinc.net Mon Mar 15 18:10:56 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 15 Mar 2010 10:10:56 -0700 Subject: On killing IPv6 transition mechanisms In-Reply-To: <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> Message-ID: <4B9E6A20.8020207@ipinc.net> Ole Troan wrote: >> I wonder, how no connectivity could be better than some? > > because content providers measure the difference between IPv4 and > IPv6 behaviour for dual stack hosts. if the number of hosts with > broken IPv6 connectivity or with significantly worse latency than > IPv4, they will not enable IPv6. > > to put it bluntly: if you don't get IPv6 from your SP, then don't > bother. you are doing more harm to IPv6 deployment than good. > Please quit FUDDing. Content providers only care that customers on the Internet are able to get at their offerings. Ebay, Craigslist and Amazon don't give a crap about latency of a connection if they get a credit card number over the connection for a valid order. And there are still a VERY LARGE minority of people on dialup-only IPv4, so quit being a connectivity snob - the worst IPv6 broadband connection out there is going to have lower latency than a 56k dialup modem!!! While the IPv6 deployment isn't served by "broken IPv6 connectivity" any content provider looking at IPv6 knows 2 things, first that most if not all IPv6 connections to their dual-stacked servers are "beta testing", (since IPv4 is still available from the RIR's) second that the more connectivity options they have to their servers the greater the chance that someone will be able to connect to them and get their content. You seem to assume the content providers on the Internet are idiots. They know that IPv6 right now is in it's infancy, and they are watching the usage of it. What is more important right now is GETTING the IPv6 connections from users, not how good they are. That's what they are paying attention to. Lastly, SP's aren't going to offer IPv6 unless they see monetary loss by not offering it. Obviously the best way is customer loss but there are others. Currently, Ivan's VPN solution essentially REWARDS his current non-IPv6-offering SP - however, Ivan can easily counteract that by calling into his SP, weekly if necessary, demanding IPv6. It costs a SP money to pay labor to answer the telephone, and if Ivan makes 2 phone calls a month and gets a live human being at his SP on the phone for at least 10 minutes, "filibustering" for IPv6, (ie: talking on and on an on touting his IPv6 VPN solution and how much better native IPv6 would be) then he will have eaten up all profit for the month for his SP on his account - and if enough people do this, then even SP's who are hostile to IPv6 will be forced to deploy it. Ted From otroan at employees.org Mon Mar 15 18:58:34 2010 From: otroan at employees.org (Ole Troan) Date: Mon, 15 Mar 2010 18:58:34 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9E6A20.8020207@ipinc.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> Message-ID: <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> Ted, >>> I wonder, how no connectivity could be better than some? >> because content providers measure the difference between IPv4 and >> IPv6 behaviour for dual stack hosts. if the number of hosts with >> broken IPv6 connectivity or with significantly worse latency than >> IPv4, they will not enable IPv6. >> to put it bluntly: if you don't get IPv6 from your SP, then don't >> bother. you are doing more harm to IPv6 deployment than good. > > Please quit FUDDing. Content providers only care that customers on > the Internet are able to get at their offerings. Ebay, Craigslist and Amazon don't give a crap about latency of a connection if they get a > credit card number over the connection for a valid order. And there > are still a VERY LARGE minority of people on dialup-only IPv4, so > quit being a connectivity snob - the worst IPv6 broadband connection > out there is going to have lower latency than a 56k dialup modem!!! see: https://sites.google.com/site/ipv6implementors/conference2009/agenda/10_Lees_Google_IPv6_User_Measurement.pdf?attredirects=0 which shows that a dual stack host is about 150ms slower using IPv6 than IPv4, and that ~0.08% of the hosts have broken IPv6. (please take notice in the presentation that there is quite a bit of statistical uncertainty because of few IPv6 clients). > While the IPv6 deployment isn't served by "broken IPv6 connectivity" any content provider looking at IPv6 knows 2 things, first that most if not all IPv6 connections to their dual-stacked servers are "beta testing", > (since IPv4 is still available from the RIR's) second that the more > connectivity options they have to their servers the greater the chance > that someone will be able to connect to them and get their content. > > You seem to assume the content providers on the Internet are idiots. > They know that IPv6 right now is in it's infancy, and they are watching > the usage of it. What is more important right now is GETTING the > IPv6 connections from users, not how good they are. That's what > they are paying attention to. if I was a content provider I would look hard at those numbers above to judge if I wanted to piss off 0.08% of my customers and slow down the web site for a quarter of a percent of the others. if we continue to push for mechanisms which have higher probability of delivering broken IPv6 connectivity and/or high latency then I'm afraid that content providers will be reluctant to enable IPv6. and users will disable it. see: http://www.google.com/trends?q=disable+ipv6%2C+enable+ipv6 (and no, not even I pretend that the above is scientific, but users shouldn't search for "disable ipv6" at all. ;-)) cheers, Ole > > Lastly, SP's aren't going to offer IPv6 unless they see monetary loss by not offering it. Obviously the best way is customer loss but there are others. Currently, Ivan's VPN solution essentially REWARDS his current non-IPv6-offering SP - however, Ivan can easily counteract that by calling into his SP, weekly if necessary, demanding IPv6. It costs > a SP money to pay labor to answer the telephone, and if Ivan makes 2 > phone calls a month and gets a live human being at his SP on the > phone for at least 10 minutes, "filibustering" for IPv6, (ie: > talking on and on an on touting his IPv6 VPN solution and how much > better native IPv6 would be) then he will have eaten up all profit for the month for his SP on his account - and if enough people do this, then even SP's who are hostile to IPv6 will be forced to deploy it. > > Ted From tedm at ipinc.net Mon Mar 15 19:53:12 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 15 Mar 2010 11:53:12 -0700 Subject: On killing IPv6 transition mechanisms In-Reply-To: <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> Message-ID: <4B9E8218.9030003@ipinc.net> Ole Troan wrote: > Ted, > >>>> I wonder, how no connectivity could be better than some? >>> because content providers measure the difference between IPv4 and >>> IPv6 behaviour for dual stack hosts. if the number of hosts with >>> broken IPv6 connectivity or with significantly worse latency >>> than IPv4, they will not enable IPv6. to put it bluntly: if you >>> don't get IPv6 from your SP, then don't bother. you are doing >>> more harm to IPv6 deployment than good. >> Please quit FUDDing. Content providers only care that customers on >> the Internet are able to get at their offerings. Ebay, Craigslist >> and Amazon don't give a crap about latency of a connection if they >> get a credit card number over the connection for a valid order. >> And there are still a VERY LARGE minority of people on dialup-only >> IPv4, so quit being a connectivity snob - the worst IPv6 broadband >> connection out there is going to have lower latency than a 56k >> dialup modem!!! > > see: > https://sites.google.com/site/ipv6implementors/conference2009/agenda/10_Lees_Google_IPv6_User_Measurement.pdf?attredirects=0 > > > which shows that a dual stack host is about 150ms slower using IPv6 > than IPv4, and that ~0.08% of the hosts have broken IPv6. (please > take notice in the presentation that there is quite a bit of > statistical uncertainty because of few IPv6 clients). > >> While the IPv6 deployment isn't served by "broken IPv6 >> connectivity" any content provider looking at IPv6 knows 2 things, >> first that most if not all IPv6 connections to their dual-stacked >> servers are "beta testing", (since IPv4 is still available from the >> RIR's) second that the more connectivity options they have to >> their servers the greater the chance that someone will be able to >> connect to them and get their content. >> >> You seem to assume the content providers on the Internet are >> idiots. They know that IPv6 right now is in it's infancy, and they >> are watching the usage of it. What is more important right now is >> GETTING the IPv6 connections from users, not how good they are. >> That's what they are paying attention to. > > if I was a content provider I would look hard at those numbers above > to judge if I wanted to piss off 0.08% of my customers and slow down > the web site for a quarter of a percent of the others. > Your thinking in terms of a garage operation ISP. "dual stack" to a content provider means "dual stack the SITE not the HOST" Most if not all the large content providers have multiple servers behind a load balancer. It's pretty obvious that devoting merely 1 of the servers out of their server pool to IPv6-only is the way to go, here. In fact you would just put it on the Internet directly, not behind the load-balancer. Once IPv6 traffic is large enough you would create a separate pool of IPv6 servers behind an IPv6 load-balancer. Dual-stacking the host is not needed to dual stack the site. Of course, I should not assume to tell content providers how to run their businesses, if they want to do it the bass-ackwards way that's their right. :-) > if we continue to push for mechanisms which have higher probability > of delivering broken IPv6 connectivity and/or high latency then I'm > afraid that content providers will be reluctant to enable IPv6. > > and users will disable it. see: > http://www.google.com/trends?q=disable+ipv6%2C+enable+ipv6 > > (and no, not even I pretend that the above is scientific, but users > shouldn't search for "disable ipv6" at all. ;-)) > Only the "power" users are going to bother digging that out and only in response to problems they perceive are happening with their machines. And these are the people who are probably going to be among the first and last groups on IPv6. And as long as their ISP's are running current nameserver code, they shouldn't be having problems, thus they will make the registry change, and nothing will happen, then 3 months later when they scotch their machine due to excessive tinkering with it and reinstall windows, they will not bother making the change Unfortunately this is all part of educating the consumer about what constitutes a decent ISP service and what doesn't. The fact of the matter though is that it really only matters to get the center of the bell-curve users on IPv6. Once that happens the power users will have to get on it also. Ted > cheers, Ole > > >> Lastly, SP's aren't going to offer IPv6 unless they see monetary >> loss by not offering it. Obviously the best way is customer loss >> but there are others. Currently, Ivan's VPN solution essentially >> REWARDS his current non-IPv6-offering SP - however, Ivan can easily >> counteract that by calling into his SP, weekly if necessary, >> demanding IPv6. It costs a SP money to pay labor to answer the >> telephone, and if Ivan makes 2 phone calls a month and gets a live >> human being at his SP on the phone for at least 10 minutes, >> "filibustering" for IPv6, (ie: talking on and on an on touting his >> IPv6 VPN solution and how much better native IPv6 would be) then he >> will have eaten up all profit for the month for his SP on his >> account - and if enough people do this, then even SP's who are >> hostile to IPv6 will be forced to deploy it. >> >> Ted > > From otroan at employees.org Mon Mar 15 20:09:39 2010 From: otroan at employees.org (Ole Troan) Date: Mon, 15 Mar 2010 20:09:39 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9E8218.9030003@ipinc.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <4B9E8218.9030003@ipinc.net> Message-ID: <4E188DAD-55F8-4343-83F5-DA72D5EACDE3@employees.org> >> if I was a content provider I would look hard at those numbers above >> to judge if I wanted to piss off 0.08% of my customers and slow down >> the web site for a quarter of a percent of the others. > > Your thinking in terms of a garage operation ISP. "dual stack" to a > content provider means "dual stack the SITE not the HOST" it is pretty evident that you don't know what terms I'm thinking in. ;-) the problem here isn't in the DC. the problem is that by adding an AAAA record to your site you will lose some fraction of your users. is that fraction small enough to ignore? hopefully. but let's not make it any larger. cheers, Ole From john at sackheads.org Mon Mar 15 20:21:00 2010 From: john at sackheads.org (John Payne) Date: Mon, 15 Mar 2010 15:21:00 -0400 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4E188DAD-55F8-4343-83F5-DA72D5EACDE3@employees.org> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <4B9E8218.9030003@ipinc.net> <4E188DAD-55F8-4343-83F5-DA72D5EACDE3@employees.org> Message-ID: <02D6A4E2-09A8-499A-92B1-3090BF5F0438@sackheads.org> On Mar 15, 2010, at 3:09 PM, Ole Troan wrote: >>> if I was a content provider I would look hard at those numbers above >>> to judge if I wanted to piss off 0.08% of my customers and slow down >>> the web site for a quarter of a percent of the others. >> >> Your thinking in terms of a garage operation ISP. "dual stack" to a >> content provider means "dual stack the SITE not the HOST" > > it is pretty evident that you don't know what terms I'm thinking in. ;-) > > the problem here isn't in the DC. the problem is that by adding an AAAA record to your site you will lose some fraction of your users. is that fraction small enough to ignore? hopefully. but let's not make it any larger. 0.1% (rounding up) is a HUGE number of users for many sites. That translates to lost revenue, so yeah, whilst it is measurable against "$RANDOM fluctuations" the fraction is too high. From tony at lava.net Mon Mar 15 20:21:13 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 15 Mar 2010 09:21:13 -1000 (HST) Subject: On killing IPv6 transition mechanisms In-Reply-To: <4E188DAD-55F8-4343-83F5-DA72D5EACDE3@employees.org> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <4B9E8218.9030003@ipinc.net> <4E188DAD-55F8-4343-83F5-DA72D5EACDE3@employees.org> Message-ID: On Mon, 15 Mar 2010, Ole Troan wrote: > the problem here isn't in the DC. the problem is that by adding an AAAA > record to your site you will lose some fraction of your users. is that > fraction small enough to ignore? hopefully. but let's not make it any > larger. High FUDD Alert! All prospective IPv6 deployers are advised to stay indoors and avoid any strenuous transition activity. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From jeroen at unfix.org Mon Mar 15 20:31:13 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 15 Mar 2010 20:31:13 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9E8218.9030003@ipinc.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <4B9E8218.9030003@ipinc.net> Message-ID: <4B9E8B01.1010807@spaghetti.zurich.ibm.com> Ted Mittelstaedt wrote: [..] > Most if not all the large content providers have multiple servers > behind a load balancer. The problem is that with 6to4 the user generally does not even come to that point. The google folks can tell you better what their motives are for not enabling IPv6 without the whitelist, but there For that matter F5's BIG-IP boxes have been doing IPv6 already for several years and quite happily, ask the www.bit.nl folks and various others of their customers ;) [..] > Dual-stacking the host is not needed to dual stack the site. The problem with upgrading a site is not so much stuff an IPv6 enabled proxy/loadbalancer in front of it, the problem generally is the fact that folks tend to store those nasty things called IP addresses and that suddenly you have very long ones. > Of course, I should not assume to tell content providers how to > run their businesses, if they want to do it the bass-ackwards way > that's their right. :-) Backwards would be dedicating a pool of boxes and connecting them directly to the Internet while you can just use the same methods you already use for IPv4 just for IPv6... [..] >> (and no, not even I pretend that the above is scientific, but users >> shouldn't search for "disable ipv6" at all. ;-)) > > Only the "power" users are going to bother digging that out Must be a lot of "power users" in this world then ;) Google/Bing/Yahoo! for it, there are lots of people who have problems with the fact that their OS of choice enables IPv6 per default and stuff start breaking due to either broken connectivity (6to4/Teredo) or even native being broken (though if the ISP turned it on, then heck they probably can fix it too ;) or broken DNS (which IHMO is a worse problem). If you earn say a million a day, and you loose 0.01% of that, well, then you know how much money you are missing every year. And money hurts. And do realize that Windows Vista/Seven come with IPv6 per default. XP can do it too. And more importantly: there are utilities (utorrent to name a famous one) who enable IPv6 per default et voila, you are broken. The user does not know, but they will notice. > Unfortunately this is all part of educating the consumer about > what constitutes a decent ISP service and what doesn't. Nothing to do with the consumer, they didn't do a thing. The ISP will get the complaints though that service X is unreachable. > The fact of the matter though is that it really only matters > to get the center of the bell-curve users on IPv6. Once that > happens the power users will have to get on it also. True power users know what they do, they don't have 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/20100315/2af14620/attachment-0001.bin From tedm at ipinc.net Mon Mar 15 21:44:06 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 15 Mar 2010 13:44:06 -0700 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9E8B01.1010807@spaghetti.zurich.ibm.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <4B9E8218.9030003@ipinc.net> <4B9E8B01.1010807@spaghetti.zurich.ibm.com> Message-ID: <4B9E9C16.9030709@ipinc.net> Jeroen Massar wrote: > Ted Mittelstaedt wrote: > [..] >> Most if not all the large content providers have multiple servers >> behind a load balancer. > > The problem is that with 6to4 the user generally does not even come to > that point. > > The google folks can tell you better what their motives are for not > enabling IPv6 without the whitelist, but there > > For that matter F5's BIG-IP boxes have been doing IPv6 already for > several years and quite happily, ask the www.bit.nl folks and various > others of their customers ;) > > [..] >> Dual-stacking the host is not needed to dual stack the site. > > The problem with upgrading a site is not so much stuff an IPv6 enabled > proxy/loadbalancer in front of it, the problem generally is the fact > that folks tend to store those nasty things called IP addresses and that > suddenly you have very long ones. > And this is our problem? As I said if a content provider wants to build their network ass-backwards with hard-coded IP addresses buried in config files all over their servers, that's their right. I doubt that such sites would ever be enabling IPv6, though. They will probably still be fighting it even with the entire Internet has switched. >> Of course, I should not assume to tell content providers how to >> run their businesses, if they want to do it the bass-ackwards way >> that's their right. :-) > > Backwards would be dedicating a pool of boxes and connecting them > directly to the Internet while you can just use the same methods you > already use for IPv4 just for IPv6... > So I take it then you disagree with the claim that dual-stacking melts down the latency? > [..] >>> (and no, not even I pretend that the above is scientific, but users >>> shouldn't search for "disable ipv6" at all. ;-)) >> Only the "power" users are going to bother digging that out > > Must be a lot of "power users" in this world then ;) > Google/Bing/Yahoo! for it, there are lots of people who have problems > with the fact that their OS of choice enables IPv6 per default and stuff > start breaking due to either broken connectivity (6to4/Teredo) or even > native being broken (though if the ISP turned it on, then heck they > probably can fix it too ;) or broken DNS (which IHMO is a worse problem). > > If you earn say a million a day, and you loose 0.01% of that, well, then > you know how much money you are missing every year. And money hurts. > > And do realize that Windows Vista/Seven come with IPv6 per default. XP > can do it too. And more importantly: there are utilities (utorrent to > name a famous one) who enable IPv6 per default et voila, you are broken. > The user does not know, but they will notice. > >> Unfortunately this is all part of educating the consumer about >> what constitutes a decent ISP service and what doesn't. > > Nothing to do with the consumer, they didn't do a thing. > The ISP will get the complaints though that service X is unreachable. > What it boils down to is laziness of the ISP. The ISP can educate their customers, fix their nameservers, and provide workarounds for other idiots on the Internet who have botched their IPv6 rollouts. Or they can be lazy-asses and find some quick hack to get their customer off the phone. (disable IPv6 on the workstation, perhaps?) >> The fact of the matter though is that it really only matters >> to get the center of the bell-curve users on IPv6. Once that >> happens the power users will have to get on it also. > > True power users know what they do, they don't have issues. > That's why I quoted "power users" :-) Ted > Greets, > Jeroen > From jeroen at unfix.org Mon Mar 15 22:14:11 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 15 Mar 2010 22:14:11 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9E9C16.9030709@ipinc.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <4B9E8218.9030003@ipinc.net> <4B9E8B01.1010807@spaghetti.zurich.ibm.com> <4B9E9C16.9030709@ipinc.net> Message-ID: <4B9EA323.3030905@spaghetti.zurich.ibm.com> Ted Mittelstaedt wrote: > Jeroen Massar wrote: [..] >> The problem with upgrading a site is not so much stuff an IPv6 enabled >> proxy/loadbalancer in front of it, the problem generally is the fact >> that folks tend to store those nasty things called IP addresses and that >> suddenly you have very long ones. >> > > And this is our problem? Depends on who 'our' is. I don't have any problems with it, as I don't earn my money with providing either content or access ;) > As I said if a content provider wants to build > their network ass-backwards with hard-coded IP addresses buried in > config files all over their servers, that's their right. Why is that a problem? I do that all the time, even in very large setups. That those configs are auto-generated solves all the problems. (Heck I even auto-generate m0n0wall configs) But I think you misunderstand something in what I wrote: there are these things called LOG FILES, they also contain IP addresses. Log files are used for all kind of things, amongst others user tracking and for security reasons. You'll find IP addresses all over the place. (Indeed there was already a site that was wide open when connecting over IPv6 because the 'security match' didn't properly work on that level; next to early postfix IPv6 patches having had an easy way to misconfigure IPv6 so that one become an open relay, and other such problems) Oh and then there is that little thing with training support personal, but that is outside the scope of the above problem. > I doubt that > such sites would ever be enabling IPv6, though. They will probably > still be fighting it even with the entire Internet has switched. As Randy Bush will say: I hope all my competitors do that So is that your, or my problem that they mismanage their stuff and can't upgrade... nope. >>> Of course, I should not assume to tell content providers how to >>> run their businesses, if they want to do it the bass-ackwards way >>> that's their right. :-) >> >> Backwards would be dedicating a pool of boxes and connecting them >> directly to the Internet while you can just use the same methods you >> already use for IPv4 just for IPv6... >> > > So I take it then you disagree with the claim that dual-stacking melts > down the latency? Depends on what kind of dual-stacking you are deploying and what the environment that is in. I love dual-stack and have been running so for pretty much 10 years already without many problems (the ones I had I kicked people really hard for :) Latency for IPv4 and IPv6 for me is generally the same, and sometimes lower in IPv6 (due to unused circuits etc). IPv6-Google has also been claimed to be faster on IPv6 (even through tunneled connections) than over IPv4 several times. If you have crap connectivity though (bad tunnel or bad upstream) or if you are going to tunnel twice around the world, well, you are peeped. I refer to: http://www.sixxs.net/news/2007/#grhlongestdistancerouting-0401 which has nice ones as: "2001:200:a000::/35 25441, 3257, 3549, 6939, 2516 7660, 22388 11537, 2500 at 40760 km flowing through Ireland, Germany, Netherlands, US, Japan, US and Japan. 2001:200:a000::/35 1836, 3549, 6939, 2516 7660, 22388 11537, 2500 at 39500 km flowing through Switzerland, Netherlands, US, Japan, US, and Japan." And if you are in some remote place where there is little to no incentive to have Internet (IPv4) in the first place, then most likely you won't find IPv6 either. But you most likely have no other choice if you want to get ready and already play with it. Fortunately the IPv6 routing world improved a lot since then, and the underlying tunnels are mostly gone or have become more aligned with the IPv4 network. As for to the end-site there are still lots of places where they will go quite a number of times around the world. [..] >> Nothing to do with the consumer, they didn't do a thing. >> The ISP will get the complaints though that service X is unreachable. >> > > What it boils down to is laziness of the ISP. Why is it lazyness of the ISP? The ISP is offering IPv4 connectivity. That is the job they are providing and generally they are doing that just fine. (They should start doing IPv6 soon though, but that is a different thing) > The ISP can educate their customers, I just have to assume that you clearly have no perception of cost. If you have a million customers, every dollar spent on 'educating' them, is way too much. Be happy that ISPs already handle abuse. > fix their nameservers, The ISPs nameservers are NOT broken. The problems lies in the CPE in which there is a broken DNS caching resolver. There are a couple of levels of brokenness but the most hopeless one is the one that only understands A records and drops everything else, without sending back a DNS packet stating that the request was refused. Sometimes these CPEs are owned by the ISP and thus theoretically they could upgrade them (but in some cases that means replacing them, times a million is well, lots of centavos lost revenue) but in a lot of cases the customer owns them. Thus it is the customer's problem which they have to fix. Oh and this little DNS issue is number #1 reason for 'turn off IPv6 and your Internet is fast again'.... > and provide workarounds for > other idiots on the Internet who have botched their IPv6 rollouts. Who "botched" exactly what here? I think you botched the part where you have to read ;) > Or they can be lazy-asses and find some quick hack to get their > customer off the phone. (disable IPv6 on the workstation, perhaps?) That unfortunately is the quickest and cheapest method. It solves the problem with minimal change. It doesn't present a long term solution though, but hey, that is not what people who care about their bread and their cash in their bank account care about now do they? Real solution would be replacing the CPE, but that is a costly thing. And why bother, over time people will replace that thing anyway and then they can get an IPv6 enabled edition, problem solved. >>> The fact of the matter though is that it really only matters >>> to get the center of the bell-curve users on IPv6. Once that >>> happens the power users will have to get on it also. >> >> True power users know what they do, they don't have issues. >> > > That's why I quoted "power users" :-) Are you one of them? 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/20100315/290e3261/attachment.bin From tedm at ipinc.net Mon Mar 15 23:13:23 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 15 Mar 2010 15:13:23 -0700 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9EA323.3030905@spaghetti.zurich.ibm.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <4B9E8218.9030003@ipinc.net> <4B9E8B01.1010807@spaghetti.zurich.ibm.com> <4B9E9C16.9030709@ipinc.net> <4B9EA323.3030905@spaghetti.zurich.ibm.com> Message-ID: <4B9EB103.6030005@ipinc.net> Jeroen Massar wrote: > Ted Mittelstaedt wrote: >> Jeroen Massar wrote: > [..] >>> The problem with upgrading a site is not so much stuff an IPv6 enabled >>> proxy/loadbalancer in front of it, the problem generally is the fact >>> that folks tend to store those nasty things called IP addresses and that >>> suddenly you have very long ones. >>> >> And this is our problem? > > Depends on who 'our' is. I don't have any problems with it, as I don't > earn my money with providing either content or access ;) > >> As I said if a content provider wants to build >> their network ass-backwards with hard-coded IP addresses buried in >> config files all over their servers, that's their right. > > Why is that a problem? I do that all the time, even in very large > setups. That those configs are auto-generated solves all the problems. > (Heck I even auto-generate m0n0wall configs) > > > But I think you misunderstand something in what I wrote: there are these > things called LOG FILES, they also contain IP addresses. > Log files are used for all kind of things, amongst others user tracking > and for security reasons. You'll find IP addresses all over the place. > (Indeed there was already a site that was wide open when connecting over > IPv6 because the 'security match' didn't properly work on that level; > next to early postfix IPv6 patches having had an easy way to > misconfigure IPv6 so that one become an open relay, and other such problems) > > Oh and then there is that little thing with training support personal, > but that is outside the scope of the above problem. > >> I doubt that >> such sites would ever be enabling IPv6, though. They will probably >> still be fighting it even with the entire Internet has switched. > > As Randy Bush will say: I hope all my competitors do that > > So is that your, or my problem that they mismanage their stuff and can't > upgrade... nope. > >>>> Of course, I should not assume to tell content providers how to >>>> run their businesses, if they want to do it the bass-ackwards way >>>> that's their right. :-) >>> Backwards would be dedicating a pool of boxes and connecting them >>> directly to the Internet while you can just use the same methods you >>> already use for IPv4 just for IPv6... >>> >> So I take it then you disagree with the claim that dual-stacking melts >> down the latency? > > Depends on what kind of dual-stacking you are deploying and what the > environment that is in. I love dual-stack and have been running so for > pretty much 10 years already without many problems (the ones I had I > kicked people really hard for :) Latency for IPv4 and IPv6 for me is > generally the same, and sometimes lower in IPv6 (due to unused circuits > etc). IPv6-Google has also been claimed to be faster on IPv6 (even > through tunneled connections) than over IPv4 several times. > > If you have crap connectivity though (bad tunnel or bad upstream) or if > you are going to tunnel twice around the world, well, you are peeped. > > I refer to: > http://www.sixxs.net/news/2007/#grhlongestdistancerouting-0401 > which has nice ones as: > "2001:200:a000::/35 25441, 3257, 3549, 6939, 2516 7660, 22388 11537, > 2500 at 40760 km > flowing through Ireland, Germany, Netherlands, US, Japan, US and Japan. > 2001:200:a000::/35 1836, 3549, 6939, 2516 7660, 22388 11537, 2500 at > 39500 km flowing through Switzerland, Netherlands, US, Japan, US, and > Japan." > > And if you are in some remote place where there is little to no > incentive to have Internet (IPv4) in the first place, then most likely > you won't find IPv6 either. But you most likely have no other choice if > you want to get ready and already play with it. > > Fortunately the IPv6 routing world improved a lot since then, and the > underlying tunnels are mostly gone or have become more aligned with the > IPv4 network. As for to the end-site there are still lots of places > where they will go quite a number of times around the world. > > [..] >>> Nothing to do with the consumer, they didn't do a thing. >>> The ISP will get the complaints though that service X is unreachable. >>> >> What it boils down to is laziness of the ISP. > > Why is it lazyness of the ISP? The ISP is offering IPv4 connectivity. They are offering INTERNET connectivity, that is why they are called INTERNET SERVICE PROVIDERS. When they start calling them INTERNET VERSION 4 SERVICE PROVIDERS then you would have a point. Many other things on the Internet are standards that have changed. IPv6 is no different and ISPs need to change on it, too. > That is the job they are providing and generally they are doing that > just fine. (They should start doing IPv6 soon though, but that is a > different thing) > >> The ISP can educate their customers, > > I just have to assume that you clearly have no perception of cost. > If you have a million customers, every dollar spent on 'educating' them, > is way too much. > Then don't educate them. You will make your millions as your customer base gets tired of you treating them like morons, and out grow you and go to other ISPs who are willing to help them. Then I guess you will retire on your golden parachute while your stockholders are left with nothing. You obviously learned American Business very well! :-) > Be happy that ISPs already handle abuse. > Since these large ISPs are the source of most of the abuse they are obligated to handle it. >> fix their nameservers, > > The ISPs nameservers are NOT broken. The problems lies in the CPE in > which there is a broken DNS caching resolver. a DNS caching resolver IS a nameserver. It's a caching-only nameserver. > There are a couple of > levels of brokenness but the most hopeless one is the one that only > understands A records and drops everything else, without sending back a > DNS packet stating that the request was refused. > > Sometimes these CPEs are owned by the ISP and thus theoretically they > could upgrade them (but in some cases that means replacing them, times a > million is well, lots of centavos lost revenue) but in a lot of cases > the customer owns them. Thus it is the customer's problem which they > have to fix. Oh and this little DNS issue is number #1 reason for 'turn > off IPv6 and your Internet is fast again'.... > >> and provide workarounds for >> other idiots on the Internet who have botched their IPv6 rollouts. > > Who "botched" exactly what here? Well, the CPE manufacturers for starters. The "linksys/netgear/whatever" small router manufacturers for another. A decent ISP will educate their user that their CPE is crap and needs to be replaced, or firmware-updated, or worked around with static DNS numbers in the OS config file or some such. A AOL/Comp$pend kind of ISP will do the "turn off IPv6 workaround" Both solutions will work to fix the immediate problem. A few years down the road when the customer figures things out, the second solution just cements their view that their ISP is incompetent. And on top of that the broken CPE's have other side effects as well, side effects that are often blamed on the ISP even when it isn't the ISP's fault. Here is a story for you. When the small Linksys BEFSR routers first came out we had a lot of DSL customers buy and use them. Then 6 months later we started getting a few disconnects from those customers on claims that the service was too slow. We investigated this rather aggressively (sent techs to homes and such) and discovered that the Linksys units were failing - but they weren't failing like a lightbulb and just stopping. They were getting slower and slower and slower. The customer of course blamed us until techs would pull out a brand new linksys of the same model, swap it, and speed went back to normal. If we had NOT had the focus on customer education that we have, we would have lost a large number of DSL customers. Instead we contacted all our customers using them (easy to do just read the MAC addresses to find the linksys units) and warned them about the problem. We got many comments thanking us as many customers by then were noticing problems. Needless to say we did NOT recommend Linksys units for many years after that. So, yeah, I do have a perception of cost. And yes I understand that when "stuff happens" that it is going to cost someone. But apparently I also understand that a dollar of preventative education now is worth 100 dollars of cure later on. I wonder if you have learned that? ISP's with millions of customers who begrudge the PENNIES spent upfront on educating their customers are very, very stupid. Yes they get a slight boost to their bottom line now. But that comes at a much higher cost down the road. And once the perception gets out there that the large ISP is a problem, it is extremely expensive to change. Sometimes it even cannot be changed at all, as AOL, AGIS, CompuServe have all found out, and Comcast is finding out. Just consider the millions of dollars Comcast is currently spending on television advertisements touting their new HD-TV service. All of those TV ads that are running on over-the-air broadcast digital TV are running with the vertical sidebars on HD-TV's because those adverts were filmed NTSC aspect ratio, not HD-TV aspect ratio, so that Comcast could make a very small short term financial gain (since TV stations charge more money for adverts in HD). Please consider the lunacy of a TV advert campaign for HDTV cable service that does not run in High Def on a HDTV set receiving High Def over the air. That ad campaign merely cements in the users minds who see it that Comcast is incompetent, and it is a perfect example of what happens when ISPs with "millions of customers" chintz upfront. > I think you botched the part where you > have to read ;) > >> Or they can be lazy-asses and find some quick hack to get their >> customer off the phone. (disable IPv6 on the workstation, perhaps?) > > That unfortunately is the quickest and cheapest method. > It solves the problem with minimal change. > > It doesn't present a long term solution though, but hey, that is not > what people who care about their bread and their cash in their bank > account care about now do they? > No, because most of them (in the US anyway) were educated at business schools where that kind of thinking was all the rage during the last decade. Those schools now have reversed 180 degrees but it will take many years before the young crop of MBAs takes the reins of power in business and starts thinking long-term. > Real solution would be replacing the CPE, but that is a costly thing. > And why bother, over time people will replace that thing anyway and then > they can get an IPv6 enabled edition, problem solved. > This is a pendulum in business thinking in the US. During the 80's most businesses were run short-term goals. Then Japan started kicking our ass and a lot of business schools and thinkers realized that long term planning had benefits and the short-term stuff fell out of favor, and companies started doing more long term planning. Then in the mid to late 90's short-term planning came back into favor as a result of the dot-com boom. That produced the 2008 financial crash and now it's back out of favor again. You know, there's nothing wrong with simply educating the user that they can use their existing junky CPE with a workaround, but that it really ought to be replaced. But I guess that sort of moderate centrist approach nobody likes nowadays. :-( >>>> The fact of the matter though is that it really only matters >>>> to get the center of the bell-curve users on IPv6. Once that >>>> happens the power users will have to get on it also. >>> True power users know what they do, they don't have issues. >>> >> That's why I quoted "power users" :-) > > Are you one of them? > It depends on the OS. :-) > Greets, > Jeroen > From ek at google.com Tue Mar 16 03:33:26 2010 From: ek at google.com (Erik Kline) Date: Tue, 16 Mar 2010 11:33:26 +0900 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9E8B01.1010807@spaghetti.zurich.ibm.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <4B9E8218.9030003@ipinc.net> <4B9E8B01.1010807@spaghetti.zurich.ibm.com> Message-ID: <2e8c64261003151933l307ffafl20978fca0d7cc9df@mail.gmail.com> > The google folks can tell you better what their motives are for not > enabling IPv6 without the whitelist, but there So the problem is actually two-fold (at least :). [1] First, and most obvious, is the impact of users not being able to reach us at all. There are many things that can go wrong between a web browser and a web server/service, it's true: DNS, weird CPE issues, misconfigured firewalls, et alia. /Most/ of these things, though, tend to affect all or most of the Internet traffic for affected user/host/network. As such, diagnosis (at some skill level) begins and may escalate to the ISP and so on. But IPv6-related breakage is not of the "all-or-nothing-so-I'd-better-get-it-figured-out" variety. It only affects the sites who advertise AAAAs. Maybe accessing the AAAA-advertising site will be important enough to folks that it will get resolved, and maybe it won't. 0.08% is still a lot folks who might needlessly have a bad experience trying to reach us, and we can do better than that. [2] Second, and perhaps less obvious, is the long-term adverse impact of latency. As you probably know right now we have this "Make the Web Faster" effort. If you search for comments made by Marissa Mayer in connection with latency you should find several stories about various latency experiments. A few miscellaneous links (since it obviously won't do any good to link to internal documents here): http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html http://www.bitcurrent.com/marissa-mayer-at-velocity09-and-googles-quest-for-speed/ The thing to note is that during experiments which added extra latency, searches were down, but restoring the performance of the site does not automatically restore the previous user behaviour. From the second link, "Even after turning off the [extra] latency, users continued to search less. That?s right: The perception of slowness had impacted the users? attitudes about the usefulness of the site." The long-term effect of extra latency is that people "learn" that your site is slow, and don't necessarily or automatically "unlearn" this when it gets faster. So clearly we're constantly working to make things faster. IPv6 is important for a variety of reasons, but it definitely shouldn't mean the web gets slower. Asymmetric/unmanaged/whatever-you-want-to-call-them transition mechanisms like 6to4 and Teredo tend to add latency which, for us dualstack sites, is of the "just plain unnecessary" variety. Hopefully this makes it a little more clear. -Erik From marcoh at marcoh.net Tue Mar 16 09:28:27 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 16 Mar 2010 09:28:27 +0100 Subject: Experiences with mobile devices ? Message-ID: Hi All, In an attempt to get a large and populair Dutch website available on IPv6 we get feedback that espcially mobile devices have trouble reaching their site. The problem itself is not new, neither is the solution. It's caused by clients thinking they have IPv6 but in fact they don't and people should either turn off IPv6 or fix their connection. But his is not what I'm after. What strikes me is that they list mobile as a specific problem area. I have seen a report in which the Samsung I600 running windows 5.0 causes problems while connected to wifi. Is there anybody who has such a phone who can confim it is broken by default ? Further I'm curious wether the 0.08% Google claims stays the same when you run into a a lot of mobile clients or does this grow bigger. Does anybody know wether there are figures available on this topic, or does anybody have a bright idea on how to measure this ? This site does weather forecasts so they are likely to have an above average number of mobile clients connecting, at the same time I'm not sure wether it really is a problem with mobile or it' just a combination of bad luck and statistics the complaints are about mobile. MarcoH From evyncke at cisco.com Tue Mar 16 09:37:13 2010 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Tue, 16 Mar 2010 09:37:13 +0100 Subject: Experiences with mobile devices ? In-Reply-To: References: Message-ID: <317616CE96204D49B5A1811098BA89500175F05D@XMB-AMS-110.cisco.com> Marco I am using a Samsung I600 and when using it on WiFi with IPv6, it works like a charm (or rather it works as usual with IPv4 as well -- quite slow). I have more problem with plain UMTS/GPRS as my mobile operator gives me a global IPv4 address, so, let's 6to4 start... and my mobile operator does not have any 6to4 relay in their network so it seems (traceroute to the anycast 6to4 relay) that all my 6to4 packets go from Brussels/Belgium to Amsterdam in the best case or to Switzerland in the worst case. Not optimum when you are in California and you want to reach a Californian IPv6 web server In short, I would not blame the stack (except to prefer 6to4 to IPv4) -?ric > -----Original Message----- > From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de [mailto:ipv6-ops- > bounces+evyncke=cisco.com at lists.cluenet.de] On Behalf Of Marco Hogewoning > Sent: mardi 16 mars 2010 9:28 > To: ipv6-ops at lists.cluenet.de > Subject: Experiences with mobile devices ? > > Hi All, > > In an attempt to get a large and populair Dutch website available on IPv6 we > get feedback that espcially mobile devices have trouble reaching their site. > The problem itself is not new, neither is the solution. It's caused by > clients thinking they have IPv6 but in fact they don't and people should > either turn off IPv6 or fix their connection. > > But his is not what I'm after. What strikes me is that they list mobile as a > specific problem area. I have seen a report in which the Samsung I600 running > windows 5.0 causes problems while connected to wifi. Is there anybody who has > such a phone who can confim it is broken by default ? > > Further I'm curious wether the 0.08% Google claims stays the same when you > run into a a lot of mobile clients or does this grow bigger. Does anybody > know wether there are figures available on this topic, or does anybody have a > bright idea on how to measure this ? > > This site does weather forecasts so they are likely to have an above average > number of mobile clients connecting, at the same time I'm not sure wether it > really is a problem with mobile or it' just a combination of bad luck and > statistics the complaints are about mobile. > > MarcoH From tore.anderson at redpill-linpro.com Tue Mar 16 10:13:18 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 16 Mar 2010 10:13:18 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9E6A20.8020207@ipinc.net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> Message-ID: <4B9F4BAE.1020207@redpill-linpro.com> * Ted Mittelstaedt > Please quit FUDDing. Content providers only care that customers on > the Internet are able to get at their offerings. Ebay, Craigslist > and Amazon don't give a crap about latency of a connection if they > get a credit card number over the connection for a valid order. And > there are still a VERY LARGE minority of people on dialup-only IPv4, > so quit being a connectivity snob - the worst IPv6 broadband > connection out there is going to have lower latency than a 56k dialup > modem!!! > > While the IPv6 deployment isn't served by "broken IPv6 connectivity" > any content provider looking at IPv6 knows 2 things, first that most > if not all IPv6 connections to their dual-stacked servers are "beta > testing", (since IPv4 is still available from the RIR's) second that > the more connectivity options they have to their servers the greater > the chance that someone will be able to connect to them and get their > content. > > You seem to assume the content providers on the Internet are idiots. > They know that IPv6 right now is in it's infancy, and they are > watching the usage of it. What is more important right now is > GETTING the IPv6 connections from users, not how good they are. > That's what they are paying attention to. Hello Ted, it might seem reasonable to assume that adding IPv6 capability to a web site will make it available for more eyeballs compared to running with IPv4-only. Unfortunately, the opposite is true. If you add AAAA-records to your web site, the total number of eyeballs able to access your content decreases - not by a big number, but a measurable one. As you correctly point out, this is something content providers care a great deal about. However, you're mistaken that content providers do not care about latency. Actually, what they do care about is providing the best browsing experience to their users - they will do other stuff to accomplish that too, such as creating light-weight web pages for mobile users, write HTML in a way that minimises browser rendering latency, use different TCP protocol parameters depending on the client are in a mobile network or not, selectively enable/disable compression in the application layer depending on the client's connectivity - the list goes on and on. Network latency is without question on that list. While nothing can be done about a user's high-latency connection, 150ms of additional client-server latency due to IPv6 being used will quickly add up to seconds in terms of overall page load time for a complex web site, and that's is certainly something users will notice, especially the broadband users who are expecting things to be snappy. So when considering dualstacking content, there's two arguments agaist at the moment: first that it will result in the site being unreachable for a small set of users, second that it will result in decreased connection quality for another small set of users. There are no real arguments for, except for ones like ?it's cool?. Sadly. However I think we're soon approaching the point where the number of users affected in a negative way are small enough that the coolness factor will trump the disadvantages, at least for content providers where the techies call the shots. I'm in the content hosting business, by the way. All of the things I point out above are real concerns from real content providers. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From gert at space.net Tue Mar 16 10:28:39 2010 From: gert at space.net (Gert Doering) Date: Tue, 16 Mar 2010 10:28:39 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9F4BAE.1020207@redpill-linpro.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> Message-ID: <20100316092839.GS69383@Space.Net> Hi, On Tue, Mar 16, 2010 at 10:13:18AM +0100, Tore Anderson wrote: > on and on. Network latency is without question on that list. While > nothing can be done about a user's high-latency connection, 150ms of > additional client-server latency due to IPv6 being used will quickly add > up to seconds in terms of overall page load time for a complex web site, I keep wondering about those 150ms. I seem to remember that Google saw *few users* that had a much higher IPv6 latency - but at the same time they also saw users with a *lower* latency via IPv6 (due to different network paths being taken). For me, the v4/v6 latency is very similar - I use v6 all day, many of the sites I connect to (including google) have v6, and I do not see any adverse effects (nor any positive effects - it's just IP, after all). So I'd like to see these 150ms qualified - in this discussion, it seems to be the assumption that "IPv6 will *always* be 150ms slower", which is most definitely not the case. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 jeroen at unfix.org Tue Mar 16 10:34:48 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 16 Mar 2010 10:34:48 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <2e8c64261003151933l307ffafl20978fca0d7cc9df@mail.gmail.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <4B9E8218.9030003@ipinc.net> <4B9E8B01.1010807@spaghetti.zurich.ibm.com> <2e8c64261003151933l307ffafl20978fca0d7cc9df@mail.gmail.com> Message-ID: <4B9F50B8.6060508@spaghetti.zurich.ibm.com> Erik Kline wrote: >> The google folks can tell you better what their motives are for not >> enabling IPv6 without the whitelist, but there [..] > But IPv6-related breakage is not of the > "all-or-nothing-so-I'd-better-get-it-figured-out" variety. It only > affects the sites who advertise AAAAs. I guess you will agree with me though that even if you don't publish AAAA records, that when the CPE's DNS is intercepting DNS packets or acting as a caching resolver and the user enables IPv6 in one form or another, and that DNS caching resolver drops requests for AAAA records that one is still broken. Same thing for retry-over-TCP for that matter as there are lots of setups that block port 53 TCP.... *sigh* (and then large TXT queries don't go through properly and also slow down everything). As such, the google-IPv6-whitelisting program does avoid the latency issue and the part where ISPs would get lots of customer complaints (which I think would be a good thing as they maybe would start enabling IPv6), it does not avoid people with broken (CPE) DNS which drop AAAA requests when their OS is IPv6 enabled (ubuntu has many very long "disable IPv6" threads :) 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/20100316/2d3d4b8c/attachment.bin From ek at google.com Tue Mar 16 10:38:24 2010 From: ek at google.com (Erik Kline) Date: Tue, 16 Mar 2010 18:38:24 +0900 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100316092839.GS69383@Space.Net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> Message-ID: <2e8c64261003160238g775e39dds5ec1f48aba54b0e6@mail.gmail.com> On 16 March 2010 18:28, Gert Doering wrote: > Hi, > > On Tue, Mar 16, 2010 at 10:13:18AM +0100, Tore Anderson wrote: >> on and on. ?Network latency is without question on that list. While >> nothing can be done about a user's high-latency connection, 150ms of >> additional client-server latency due to IPv6 being used will quickly add >> up to seconds in terms of overall page load time for a complex web site, > > I keep wondering about those 150ms. ?I seem to remember that Google saw > *few users* that had a much higher IPv6 latency - but at the same time > they also saw users with a *lower* latency via IPv6 (due to different > network paths being taken). > > For me, the v4/v6 latency is very similar - I use v6 all day, many of > the sites I connect to (including google) have v6, and I do not see any > adverse effects (nor any positive effects - it's just IP, after all). > > So I'd like to see these 150ms qualified - in this discussion, it seems > to be the assumption that "IPv6 will *always* be 150ms slower", which > is most definitely not the case. Things definitely improved a bit (brought the average extra latency down to between 50 and 100 msec) when we started getting a different 2002::/16 at one point, IIRC. There is indeed a list of caveats w.r.t. these latency numbers: they are only Google's observations based on the state of everyone else's 192.88.99.0/24 and whatever 2002::/16 we were being advertised during the measurement period. Clearly that means the observations were temporally relevant to mostly just ourselves. But that's not the point. The point is more the massive indeterminacy in the full pairwise mesh of ugliness and whether or not "polishing the turd" is worth one's time. Clearly that's going to be a decision each person will have to make for themselves. From tony at lava.net Tue Mar 16 10:49:32 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 15 Mar 2010 23:49:32 -1000 (HST) Subject: On killing IPv6 transition mechanisms In-Reply-To: <2e8c64261003160238g775e39dds5ec1f48aba54b0e6@mail.gmail.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <2e8c64261003160238g775e39dds5ec1f48aba54b0e6@mail.gmail.com> Message-ID: On Tue, 16 Mar 2010, Erik Kline wrote: > 2002::/16 at one point, IIRC. There is indeed a list of caveats > w.r.t. these latency numbers: they are only Google's observations > based on the state of everyone else's 192.88.99.0/24 and whatever > 2002::/16 we were being advertised during the measurement period. Are you saying Google doesn't run a 6to4 gateway of its own? That would at least eliminate some indeterminancy going in the Google IPv6 to user 6to4 host direction. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From tore.anderson at redpill-linpro.com Tue Mar 16 10:51:48 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 16 Mar 2010 10:51:48 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100316092839.GS69383@Space.Net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> Message-ID: <4B9F54B4.2000803@redpill-linpro.com> * Gert Doering > So I'd like to see these 150ms qualified - in this discussion, it > seems to be the assumption that "IPv6 will *always* be 150ms slower", > which is most definitely not the case. I did not mean to imply that IPv6 is inherently higher-latency than IPv4. I have not done any latency measurements myself, quite simply because my Apache logs timestamps have only second-precision. The 150ms figure comes from what I understand Google to have measured the average additional IPv6 latency to be for their users. I have no problems believing that latency with IPv6 will be on average higher than with IPv4 - there's fewer peering interconnections and stuff like 6to4 and Teredo will glady trampoline your packets off Timbuktu. If it's exactly 150ms, more, or less, for your users, I have no idea. I think that for mine it might be somewhat lower, but certainly not approaching the IPv4 standard. I suspect that the networks that have significantly better IPv6 connectivity than IPv4 is few and far between - most of the time IPv6 will be on par with, or worse than, IPv4. Improved latency is most certainly not a pro-IPv6 argument at this point. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From gert at space.net Tue Mar 16 11:05:17 2010 From: gert at space.net (Gert Doering) Date: Tue, 16 Mar 2010 11:05:17 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <2e8c64261003160238g775e39dds5ec1f48aba54b0e6@mail.gmail.com> References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <2e8c64261003160238g775e39dds5ec1f48aba54b0e6@mail.gmail.com> Message-ID: <20100316100517.GT69383@Space.Net> Hi, On Tue, Mar 16, 2010 at 06:38:24PM +0900, Erik Kline wrote: > > So I'd like to see these 150ms qualified - in this discussion, it seems > > to be the assumption that "IPv6 will *always* be 150ms slower", which > > is most definitely not the case. > > Things definitely improved a bit (brought the average extra latency > down to between 50 and 100 msec) when we started getting a different > 2002::/16 at one point, IIRC. So this extra latency is only for 6to4 clients? Now that doesn't me surprise at all :-) - but it's actually not that bad at the end. Operating systems with working policy tables[*] will not(!) use 6to4 if a target site is dual-stacked, and native IPv4 connectivity exists - so you only see the extra latency if you go to a v6-only site (or have v6-only testing pixels on your web site). [*] with the exception of broken clients that bypass OS policy tables, see the list archives for the affected Opera 10 versions Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100316/daf1cf16/attachment.bin From me at benedikt-stockebrand.de Tue Mar 16 13:01:38 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 16 Mar 2010 12:01:38 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100316092839.GS69383@Space.Net> (Gert Doering's message of "Tue, 16 Mar 2010 10:28:39 +0100") References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> Message-ID: Hi Gert and list, I really tried to stay out of this thread, but since things are cooling down to a reasonable level again: Gert Doering writes: > I keep wondering about those 150ms. I seem to remember that Google saw > *few users* that had a much higher IPv6 latency - but at the same time > they also saw users with a *lower* latency via IPv6 (due to different > network paths being taken). As I understand it they pick who they actually advertise AAAA's to, so their numbers are statistically biased. What would be interesting to know was what the latency looked like if they provided AAAA's to everybody. > For me, the v4/v6 latency is very similar - I use v6 all day, many of > the sites I connect to (including google) have v6, and I do not see any > adverse effects (nor any positive effects - it's just IP, after all). Sensible content providers won't offer AAAA's unless they can provide decent connectivity on their side. The big problem here is on the customer end of the line. Since you are quite likely better connected than many other people I'd suspect that your experience is also significantly biased. Do you get the same result when you connect to a statistically significant selection of IPv4-only ISPs using whatever 6to4 public relay? On another track: Much of the discussion in this thread makes an implicit assumption that there's a single DNS name for both IPv4 and IPv6 services, i.e. "www.example.com." has both an A and a AAAA record. That's fine if have the resources to do the Google approach and only serve AAAA's to whitelisted clients. If you can't do that, then there's the alternative approach of using "www6.example.com." for AAAA's---that requires conscious action on the client side. Doing so provides straightforward "workaround" by using the non-ipv6 name, only attracts those users who intentionally use IPv6 and allows you to show off with your IPv6 service. As usual, this is way from a one-size-fits-all solution, but it may be an alternative approach worth some thought. And finally, as far as some of the more heated part of the thread is concerned, please keep a few things in mind: - The "dumb unwashed masses" are those who actually fund most of the Internet. - Since they don't understand the difference between services they have a tendency to pick whatever they consider "best value" based on any criterium they think they understand---in our case that's usually bandwidth and money. - That doesn't stop them from complaining about bad service:-) - With this pressure on, the profit margin is rather small, so the difference between gross income and net profit is extremely significant; losing an "insignificant" fraction of .1% of your gross income *very* *seriously* hurts your net profit. - First level support in this business is a very significant contributor to your overall costs. - No matter if a problem is actually your fault or not, if your customer *perceives* it as your fault, you lose business. - When you have several million customers, "small" changes that involve some sort of cooperation turn into significant efforts---and if anything goes wrong and customers call your first level support this can quickly spell disaster. These points aren't only crucial to keep in mind if you do business with end users; they also apply to end user acceptance of IPv6 and as such the move towards IPv6. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From ryanczak at arin.net Tue Mar 16 13:15:29 2010 From: ryanczak at arin.net (Matt Ryanczak) Date: Tue, 16 Mar 2010 08:15:29 -0400 Subject: Latest Load Balancer IPv6 Support Message-ID: <4B9F7661.8010702@arin.net> I know this has been asked before but it has been quite some time so I thought it fair to bring this topic up again. What are peoples experiences with load balancers and IPv6? Does anyone know of a company whose load balancer product has feature parity between IPv4 and IPv6? Does anything out there support IPv6 in GSLB configurations? What works and what does not? -- Matt Ryanczak ARIN Network Operations Manager From jeroen at unfix.org Tue Mar 16 13:20:28 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 16 Mar 2010 13:20:28 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> Message-ID: <4B9F778C.8070207@spaghetti.zurich.ibm.com> Benedikt Stockebrand wrote: > Hi Gert and list, > > I really tried to stay out of this thread, but since things are > cooling down to a reasonable level again: > > Gert Doering writes: > >> I keep wondering about those 150ms. I seem to remember that Google saw >> *few users* that had a much higher IPv6 latency - but at the same time >> they also saw users with a *lower* latency via IPv6 (due to different >> network paths being taken). > > As I understand it they pick who they actually advertise AAAA's to, so > their numbers are statistically biased. What would be interesting to > know was what the latency looked like if they provided AAAA's to > everybody. From what I understood the Google test was that they randomly inserted some javascript/links which would do something IPv6'ish, this is thus over the base of 'everybody'. Google folks can of course confirm this what they did exactly (afaik it is detailed in the presentations at RIPE etc too). >> For me, the v4/v6 latency is very similar - I use v6 all day, many of >> the sites I connect to (including google) have v6, and I do not see any >> adverse effects (nor any positive effects - it's just IP, after all). > > Sensible content providers won't offer AAAA's unless they can provide > decent connectivity on their side. Always. > The big problem here is on the customer end of the line. Yep. Deploying IPv6 in the DC, getting peering etc is easy in most parts of the world. (There are places where connectivity in general is difficult, they will have it difficult with IPv6 too unfortunately). Getting it to the end-user is the tricky part, but solvable given some effort and some cash and some smart people. > Since you are quite likely better connected > than many other people I'd suspect that your experience is also > significantly biased. Having been around at least Europe and a bit of the US I have seen all kinds of connections and from a European point of view most US connections s.u.c.k..... heck even at a NANOG they where unable to provide proper connectivity as it was heavily overloaded (I can only assume that the fact that one of the main sponsors was providing free IPv6 usenet access had to do something with it, or just plain underprovisioned). Points of view are always points of view. Thus one will always have a bias of one sort or another. > Do you get the same result when you connect to a statistically > significant selection of IPv4-only ISPs using whatever 6to4 public > relay? AFAIK in western-Europe 6to4&teredo are pretty well deployed and generally just works, go outside of the stronger concentrations of IPv6 deployment, aka the places where people don't care enough yet and you will start running into trouble though. > On another track: Much of the discussion in this thread makes an > implicit assumption that there's a single DNS name for both IPv4 and > IPv6 services, i.e. "www.example.com." has both an A and a AAAA > record. That's fine if have the resources to do the Google approach > and only serve AAAA's to whitelisted clients. If you can't do that, > then there's the alternative approach of using "www6.example.com." for > AAAA's---that requires conscious action on the client side. Google does that partially too: http://ipv6.google.com has been live for quite a long time. A lot of folks also provide www.ipv4.XXXX + www.ipv6.XXXX variants. The trick question is: why would people even bother using those? Generally folks don't type hostnames any more anyway, you google for your query, click and presto. > Doing so provides straightforward "workaround" by using the non-ipv6 > name, only attracts those users who intentionally use IPv6 and allows > you to show off with your IPv6 service. You will have a pretty low volume of users I think. > As usual, this is way from a one-size-fits-all solution, but it may be > an alternative approach worth some thought. It is deployed, ask the big sites though how many people actually use it, not too many I would assume. > And finally, as far as some of the more heated part of the thread is > concerned, please keep a few things in mind: > > - The "dumb unwashed masses" are those who actually fund most of the > Internet. Yep ;) > - Since they don't understand the difference between services they > have a tendency to pick whatever they consider "best value" > based on any criterium they think they understand---in our case > that's usually bandwidth and money. Actually the factor of warez/money for one very large group, latency/money for the gaming group. > - That doesn't stop them from complaining about bad service:-) Depends on the type of user, if their download is low you'll get complaints from group one, if their latency is high from group two. I recall stories that AMS-IX NOC would get phone calls that the latency of Quake was up.... For that matter, having in your userbase a couple of gamers who whine about latency issues in the proper places can be one of the best active monitoring you'll ever get ;) > - With this pressure on, the profit margin is rather small, so the > difference between gross income and net profit is extremely > significant; losing an "insignificant" fraction of .1% of your gross > income *very* *seriously* hurts your net profit. Bingo. > - First level support in this business is a very significant > contributor to your overall costs. Definitely, and training them to even understand that IPv6 exists will be one of the bigger costs in deploying IPv6. > - No matter if a problem is actually your fault or not, if your > customer *perceives* it as your fault, you lose business. Yep. > - When you have several million customers, "small" changes that > involve some sort of cooperation turn into significant efforts---and > if anything goes wrong and customers call your first level support > this can quickly spell disaster. $$$ :) > These points aren't only crucial to keep in mind if you do business > with end users; they also apply to end user acceptance of IPv6 and as > such the move towards IPv6. Which is why companies that now suddenly realize that they need to do IPv6 will have to spend more money in one go than a company that have been playing with IPv6 already for ten years where everybody already has a moderate understanding of the pitfalls etc. For the folks who thus jump in now: You are too late! :) 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/20100316/25dc2cf4/attachment.bin From berni at birkenwald.de Tue Mar 16 13:21:54 2010 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 16 Mar 2010 13:21:54 +0100 Subject: Latest Load Balancer IPv6 Support In-Reply-To: <4B9F7661.8010702@arin.net> References: <4B9F7661.8010702@arin.net> Message-ID: <20100316122154.GA8113@schleppi.birkenwald.de> On Tue, Mar 16, 2010 at 08:15:29AM -0400, Matt Ryanczak wrote: Hi Matt, > I know this has been asked before but it has been quite some time so I > thought it fair to bring this topic up again. > > What are peoples experiences with load balancers and IPv6? Running v6 on our F5 BigIP since around 2006, and having quite a few systems behind it. Mostly Webservers (http://www.lrz-muenchen.de). Other than some weird traceroute6 output when tracing through the box it works like a charm. Bernhard From jeroen at unfix.org Tue Mar 16 13:27:00 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 16 Mar 2010 13:27:00 +0100 Subject: Latest Load Balancer IPv6 Support In-Reply-To: <20100316122154.GA8113@schleppi.birkenwald.de> References: <4B9F7661.8010702@arin.net> <20100316122154.GA8113@schleppi.birkenwald.de> Message-ID: <4B9F7914.2030602@spaghetti.zurich.ibm.com> Bernhard Schmidt wrote: > On Tue, Mar 16, 2010 at 08:15:29AM -0400, Matt Ryanczak wrote: > > Hi Matt, > >> I know this has been asked before but it has been quite some time so I >> thought it fair to bring this topic up again. >> >> What are peoples experiences with load balancers and IPv6? > > Running v6 on our F5 BigIP since around 2006, and having quite a few > systems behind it. Mostly Webservers (http://www.lrz-muenchen.de). Other > than some weird traceroute6 output when tracing through the box it works > like a charm. /me heard good things about F5's too from several locations and a nice detail: they are internally fully IPv6, IPv4 is just a side-effect in them. 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/20100316/7a295bfb/attachment.bin From ryanczak at arin.net Tue Mar 16 13:46:45 2010 From: ryanczak at arin.net (Matt Ryanczak) Date: Tue, 16 Mar 2010 08:46:45 -0400 Subject: Latest Load Balancer IPv6 Support In-Reply-To: <20100316122154.GA8113@schleppi.birkenwald.de> References: <4B9F7661.8010702@arin.net> <20100316122154.GA8113@schleppi.birkenwald.de> Message-ID: <4B9F7DB5.1070100@arin.net> Hi Bernhard, On 03/16/2010 08:21 AM, Bernhard Schmidt wrote: > Running v6 on our F5 BigIP since around 2006, and having quite a few > systems behind it. Mostly Webservers (http://www.lrz-muenchen.de). Other > than some weird traceroute6 output when tracing through the box it works > like a charm. Are you using gslb? Any chance you are using it for any DNS load balancing? -- Matt Ryanczak ARIN Network Operations Manager From mohacsi at niif.hu Tue Mar 16 14:01:22 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 16 Mar 2010 14:01:22 +0100 (CET) Subject: Latest Load Balancer IPv6 Support In-Reply-To: <4B9F7661.8010702@arin.net> References: <4B9F7661.8010702@arin.net> Message-ID: On Tue, 16 Mar 2010, Matt Ryanczak wrote: > I know this has been asked before but it has been quite some time so I > thought it fair to bring this topic up again. > > What are peoples experiences with load balancers and IPv6? We are using *BSD pf for loadbalancing or more exactly relayd http://spootnik.org/relayd/ This is working for more than 3-4 years now on FreeBSD. relayd is ip agnostic. We will switch to LVS since our operation team prefers linux. Best Regards, Janos Mohacsi > > Does anyone know of a company whose load balancer product has feature > parity between IPv4 and IPv6? Does anything out there support IPv6 in > GSLB configurations? What works and what does not? > > -- > Matt Ryanczak > ARIN Network Operations Manager > From phrickman at upcbroadband.com Tue Mar 16 14:02:26 2010 From: phrickman at upcbroadband.com (Rickman, Phil) Date: Tue, 16 Mar 2010 14:02:26 +0100 Subject: Latest Load Balancer IPv6 Support In-Reply-To: References: <4B9F7661.8010702@arin.net>, Message-ID: ADC or F5 are the main competitors and both have IPv6 implementations. Phil Rickman NDA DD - +31 207 789 969 Mob: +31 610847604 ________________________________________ From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of Mohacsi Janos [mohacsi at niif.hu] Sent: 16 March 2010 14:01 To: Matt Ryanczak Cc: ipv6-ops at lists.cluenet.de Subject: Re: Latest Load Balancer IPv6 Support On Tue, 16 Mar 2010, Matt Ryanczak wrote: > I know this has been asked before but it has been quite some time so I > thought it fair to bring this topic up again. > > What are peoples experiences with load balancers and IPv6? We are using *BSD pf for loadbalancing or more exactly relayd http://spootnik.org/relayd/ This is working for more than 3-4 years now on FreeBSD. relayd is ip agnostic. We will switch to LVS since our operation team prefers linux. Best Regards, Janos Mohacsi > > Does anyone know of a company whose load balancer product has feature > parity between IPv4 and IPv6? Does anything out there support IPv6 in > GSLB configurations? What works and what does not? > > -- > Matt Ryanczak > ARIN Network Operations Manager > From marcoh at marcoh.net Tue Mar 16 14:05:27 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 16 Mar 2010 14:05:27 +0100 Subject: Latest Load Balancer IPv6 Support In-Reply-To: <4B9F7661.8010702@arin.net> References: <4B9F7661.8010702@arin.net> Message-ID: On 16 mrt 2010, at 13:15, Matt Ryanczak wrote: > I know this has been asked before but it has been quite some time so I > thought it fair to bring this topic up again. > > What are peoples experiences with load balancers and IPv6? > > Does anyone know of a company whose load balancer product has feature > parity between IPv4 and IPv6? Does anything out there support IPv6 in > GSLB configurations? What works and what does not? We are running on Serveriron 11.0.x, it is missing a lot of features but it does the job. Unfortunately this whole platform is EOL so we are now looking into getting our hands on some ADX to at least test and possibly replace the current box. MarcoH From david.freedman at uk.clara.net Tue Mar 16 14:36:39 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 16 Mar 2010 13:36:39 +0000 Subject: Latest Load Balancer IPv6 Support In-Reply-To: <4B9F7661.8010702@arin.net> References: <4B9F7661.8010702@arin.net> Message-ID: <4B9F8967.2090701@uk.clara.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Ryanczak wrote: > I know this has been asked before but it has been quite some time so I > thought it fair to bring this topic up again. > > What are peoples experiences with load balancers and IPv6? Netscaler/Citrix has worked fine (both 6to6 and 6to4). Dave. - -- - ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkufiWcACgkQtFWeqpgEZrLX3ACeJpYmXKbXtx+5rWPIyZq3JUS5 CkwAnjk2FkJKcrUSoCXDZ/kzmo0AmBqh =Mq9g -----END PGP SIGNATURE----- From tjc at ecs.soton.ac.uk Tue Mar 16 14:54:00 2010 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 16 Mar 2010 13:54:00 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <20100316135400.GI11771@login.ecs.soton.ac.uk> Message-ID: On Mon, Mar 15, 2010 at 06:58:34PM +0100, Ole Troan wrote: > > see: https://sites.google.com/site/ipv6implementors/conference2009/agenda/10_Lees_Google_IPv6_User_Measurement.pdf?attredirects=0 > > which shows that a dual stack host is about 150ms slower using IPv6 than IPv4, and that ~0.08% of the hosts have broken IPv6. (please take notice in the presentation that there is quite a bit of statistical uncertainty because of few IPv6 clients). The key missing stat there is the difference in latency for native v6 clients that are dual-stacked. Since 66%(!) of the Google 'experiment' is 6to4 users, and the dual stack is thus resuambly IPv4 + 6to4, then the average 150ms delay difference isn't fair/representative. More of a reason to just throw 6to4 away. Interestingly free.fr is considered native although it uses 6rd tunneling, but I guess it counts as native as the tunneling is within free.fr :) Slide 18 shows MacOSX seems to be the big 6to4 offender, or rather the Airport Extreme is... and the slideset suggests ISPs deploy more 6to4 relays, not less use of 6to4. Is 6to4 enabled by default on the Airport Extreme? -- Tim From ford at isoc.org Tue Mar 16 14:57:15 2010 From: ford at isoc.org (Matthew Ford) Date: Tue, 16 Mar 2010 14:57:15 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <20100316135400.GI11771@login.ecs.soton.ac.uk> Message-ID: <4B9F8E3B.1070102@isoc.org> On 16/03/2010 14:54, Tim Chown wrote: > Is 6to4 enabled by default on the Airport Extreme? It's been a while since I set mine up, but from memory, no it's not. I've had it with 6to4, and should have native IPv6 later this week. Enough turd-polishing folks. Mat From mohacsi at niif.hu Tue Mar 16 15:19:56 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 16 Mar 2010 15:19:56 +0100 (CET) Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <20100316135400.GI11771@login.ecs.soton.ac.uk> Message-ID: On Tue, 16 Mar 2010, Tim Chown wrote: > > Slide 18 shows MacOSX seems to be the big 6to4 offender, or rather the > Airport Extreme is... and the slideset suggests ISPs deploy more 6to4 relays, > not less use of 6to4. Is 6to4 enabled by default on the Airport Extreme? Aiport Extreme supports 6to4 only if WAN interface is configured via DHCP or statically. 6to4 not enabled by default. From gert at space.net Tue Mar 16 15:38:57 2010 From: gert at space.net (Gert Doering) Date: Tue, 16 Mar 2010 15:38:57 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <20100316135400.GI11771@login.ecs.soton.ac.uk> Message-ID: <20100316143857.GB69383@Space.Net> Hi, On Tue, Mar 16, 2010 at 01:54:00PM +0000, Tim Chown wrote: > Slide 18 shows MacOSX seems to be the big 6to4 offender, or rather the > Airport Extreme is... and the slideset suggests ISPs deploy more 6to4 relays, > not less use of 6to4. Is 6to4 enabled by default on the Airport Extreme? Oh, good point. Yes, it seems to be enabled-by-default, and since the operating system on the client system does not *know* that it's 6to4 (for the client, it's just "IPv6 that someone announced a RA for on the local LAN"), it can't properly (de-)prioritize it... The Airport Extreme seems to do it automatically if you give it a public IP - I have one, it interfered with my native IPv6, so I turned it off. But it was on-by-default. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 Tue Mar 16 15:52:47 2010 From: gert at space.net (Gert Doering) Date: Tue, 16 Mar 2010 15:52:47 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> Message-ID: <20100316145247.GC69383@Space.Net> Hi, On Tue, Mar 16, 2010 at 12:01:38PM +0000, Benedikt Stockebrand wrote: > Gert Doering writes: > > > I keep wondering about those 150ms. I seem to remember that Google saw > > *few users* that had a much higher IPv6 latency - but at the same time > > they also saw users with a *lower* latency via IPv6 (due to different > > network paths being taken). > > As I understand it they pick who they actually advertise AAAA's to, so > their numbers are statistically biased. What would be interesting to > know was what the latency looked like if they provided AAAA's to > everybody. As far as I understand, these numbers are not for the "google over IPv6" service, but for a certain percentage of the "standard" search requests where they serve v4-only, v4+v6- and v6-only pixels on the HTML page, and then compare the resulting requests for these pixels. Or something like that. > > For me, the v4/v6 latency is very similar - I use v6 all day, many of > > the sites I connect to (including google) have v6, and I do not see any > > adverse effects (nor any positive effects - it's just IP, after all). [..] > Do you get the same result when you connect to a statistically > significant selection of IPv4-only ISPs using whatever 6to4 public > relay? I'm not exactly sure how a 6to4 public relay would enable me to connect to an IPv4-only ISP? (And I don't have a high enough number of servers on 2002:: addresses to make this a meaningful experiment). If I connect to an IPv4-only ISP, I use IPv4 on my end... > On another track: Much of the discussion in this thread makes an > implicit assumption that there's a single DNS name for both IPv4 and > IPv6 services, i.e. "www.example.com." has both an A and a AAAA > record. Which is the ONLY thing that makes sense in the long run. > That's fine if have the resources to do the Google approach > and only serve AAAA's to whitelisted clients. If you can't do that, > then there's the alternative approach of using "www6.example.com." for > AAAA's---that requires conscious action on the client side. Which was OK for testing IPv6 services in the last century, but this is completely useless as a way forward. Why should anybody (except somebody wanting to test this) type "www6" or "www.ipv6" or "www.six" into their web browser? [..] > These points aren't only crucial to keep in mind if you do business > with end users; they also apply to end user acceptance of IPv6 and as > such the move towards IPv6. There is no "end user acceptance of IPv6" - as the end users do not know what IPv4 or IPv6 is, they will use it if it is there, and not use it if it is not there. Which is why the argument "my customes are not asking for IPv6" is not very useful for this sort of customers either. The challenge for the large-scale providers is to roll out IPv6 to the end customers in a transparent way and without breaking anything in the process - and do this before the NAT4444 architecture is so cemented in all the heads that we're stuck with a completely no-more-end-to-end Internet for ever. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 ford at isoc.org Tue Mar 16 15:53:13 2010 From: ford at isoc.org (Matthew Ford) Date: Tue, 16 Mar 2010 15:53:13 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100316143857.GB69383@Space.Net> References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <20100316135400.GI11771@login.ecs.soton.ac.uk> <20100316143857.GB69383@Space.Net> Message-ID: <4B9F9B59.7070602@isoc.org> It was originally on-by-default. Hasn't been configured that way out of the box for quite some time. Mat On 16/03/2010 15:38, Gert Doering wrote: > Hi, > > On Tue, Mar 16, 2010 at 01:54:00PM +0000, Tim Chown wrote: >> Slide 18 shows MacOSX seems to be the big 6to4 offender, or rather the >> Airport Extreme is... and the slideset suggests ISPs deploy more 6to4 relays, >> not less use of 6to4. Is 6to4 enabled by default on the Airport Extreme? > > Oh, good point. Yes, it seems to be enabled-by-default, and since the > operating system on the client system does not *know* that it's 6to4 > (for the client, it's just "IPv6 that someone announced a RA for on the > local LAN"), it can't properly (de-)prioritize it... > > The Airport Extreme seems to do it automatically if you give it a public IP > - I have one, it interfered with my native IPv6, so I turned it off. But > it was on-by-default. > > Gert Doering > -- NetMaster From gert at space.net Tue Mar 16 15:55:42 2010 From: gert at space.net (Gert Doering) Date: Tue, 16 Mar 2010 15:55:42 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9F9B59.7070602@isoc.org> References: <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <20100316135400.GI11771@login.ecs.soton.ac.uk> <20100316143857.GB69383@Space.Net> <4B9F9B59.7070602@isoc.org> Message-ID: <20100316145542.GD69383@Space.Net> Hi, [ Airport Extreme, 6-to-4 relay ] On Tue, Mar 16, 2010 at 03:53:13PM +0100, Matthew Ford wrote: > It was originally on-by-default. Hasn't been configured that way out of > the box for quite some time. Which is a reasonable change, given the unreliability of 6to4 relays at the provider end. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 tore.anderson at redpill-linpro.com Tue Mar 16 16:03:20 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 16 Mar 2010 16:03:20 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100316143857.GB69383@Space.Net> References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <20100316135400.GI11771@login.ecs.soton.ac.uk> <20100316143857.GB69383@Space.Net> Message-ID: <4B9F9DB8.2010401@redpill-linpro.com> Hi Gert, > Oh, good point. Yes, it seems to be enabled-by-default, and since > the operating system on the client system does not *know* that it's > 6to4 (for the client, it's just "IPv6 that someone announced a RA for > on the local LAN"), it can't properly (de-)prioritize it... Actually, an RFC 3484-compliant getaddrinfo() implementation should be able to determine that, since it looks at its own source IP address used for the potential outgoing connection. If it's within 2002::/16, it's 6to4 and thus sorted below IPv4 alternatives in getaddrinfo()'s output. It should not matter if the actual proto-41 encapsulation is done by another device. However, there's still quite a bit of 6to4 traffic. Yesterday it was 30,281% of all IPv6 traffic for me, when ignoring Opera. Mac OS X seems _way_ overrepresented though: $ grep '^2002:' vg_log-20100315 | grep -v Opera | wc -l 1875 $ grep '^2002:.*Mac OS X' vg_log-20100315 | grep -v Opera | wc -l 1816 Hmmm... It seems Mac OS X isn't RFC 3484-compliant, or that Safari and Firefox don't use getaddrinfo() on that platform (of those 1816 hits, 1374 are Safari and 442 Firefox). Wonder how the hell I could have missed this earlier... Does anyone have a Mac OS X machine and a 6to4 LAN with SLAAC they can use to verify this with? I'd really appreciate more info on this! BR, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From pete at twisted.org.uk Tue Mar 16 16:33:15 2010 From: pete at twisted.org.uk (Pete French) Date: Tue, 16 Mar 2010 15:33:15 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9F9DB8.2010401@redpill-linpro.com> Message-ID: > Does anyone have a Mac OS X machine and a 6to4 LAN with SLAAC they can > use to verify this with? I'd really appreciate more info on this! I have a number of them here (the 6to4 is being provided by FreeBSD, not an airport, but all the clients are OSX). What would you like me to test ? BTW, I belive there is some kind of issue with how OSX resolves names with bot an A and an AAAA record. I have a feeling that it makes two requests, but only uses the one which comes back first or something along those lines... Certainly I use Ipv6 on OSx all the time for my work, and one of the annoyances is that an IPv6-only website which was previously accessible can suddenly vanish as far as Safari is concered. Quitting the app and disabling-the-reenabling wifi makes it appear again. -pete. From tjc at ecs.soton.ac.uk Tue Mar 16 16:37:57 2010 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 16 Mar 2010 15:37:57 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9F9DB8.2010401@redpill-linpro.com> References: <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> <20100316135400.GI11771@login.ecs.soton.ac.uk> <20100316143857.GB69383@Space.Net> <4B9F9DB8.2010401@redpill-linpro.com> <20100316153757.GP11771@login.ecs.soton.ac.uk> Message-ID: On Tue, Mar 16, 2010 at 04:03:20PM +0100, Tore Anderson wrote: > Hi Gert, > > > Oh, good point. Yes, it seems to be enabled-by-default, and since > > the operating system on the client system does not *know* that it's > > 6to4 (for the client, it's just "IPv6 that someone announced a RA for > > on the local LAN"), it can't properly (de-)prioritize it... > > Actually, an RFC 3484-compliant getaddrinfo() implementation should be > able to determine that, since it looks at its own source IP address used > ... > Hmmm... It seems Mac OS X isn't RFC 3484-compliant, or that Safari and > Firefox don't use getaddrinfo() on that platform (of those 1816 hits, > 1374 are Safari and 442 Firefox). Wonder how the hell I could have > missed this earlier... Indeed, using 6to4 behind an Airport box on a Mac is not good. Which is probably why the default changed. But Apple get on with 3484 please. Also Mac OSX still seems to have the DNS bug/feature whereby it asks for A and AAAA records but throws away responses after the first, so you may not ever see IPv6 used for some destinations. Then don't get started on DHCPv6 or SSM on Macs (and despite that I do use two at my place of work ;) -- Tim From tore.anderson at redpill-linpro.com Tue Mar 16 16:50:56 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 16 Mar 2010 16:50:56 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: Message-ID: <4B9FA8E0.3080102@redpill-linpro.com> * Pete French > I have a number of them here (the 6to4 is being provided by FreeBSD, > not an airport, but all the clients are OSX). What would you like me > to test ? > > BTW, I belive there is some kind of issue with how OSX resolves > names with bot an A and an AAAA record. I have a feeling that it > makes two requests, but only uses the one which comes back first or > something along those lines... Certainly I use Ipv6 on OSx all the > time for my work, and one of the annoyances is that an IPv6-only > website which was previously accessible can suddenly vanish as far as > Safari is concered. Quitting the app and disabling-the-reenabling > wifi makes it appear again. Basically to go to dualstacked destinations (www.ripe.net and www.ipv6.org are especially nice as they'll echo your source address back to you) and see if it'll connect by using IPv6/6to4 or IPv4. Or if it changes depending on which DNS response comes back first as you say, you should be able to determine that by tcpdumping your port 53/udp traffic. Also it would be interesting to hear if you're using the latest version of everything, especially if there's differences in behaviour between versions. If you're able to break 6to4 on purpose (e.g. dropping all proto-41 packets on the FreeBSD box), how does that change your browsing experience? Does dualstacked sites appear to be down or sluggish? You wouldn't happen to know what's the best way to get in touch with an Apple software engineer about this issue? Sigh.. here I thought I saw the end of the tunnel now that Opera have finally fixed their browser.. Thank you for your help! Best regards -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From ron at spawar.navy.mil Tue Mar 16 16:51:14 2010 From: ron at spawar.navy.mil (Ron Broersma) Date: Tue, 16 Mar 2010 08:51:14 -0700 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: Message-ID: <504E9FA0-2A28-4AD6-AED2-2ED60D5A3441@spawar.navy.mil> On Mar 16, 2010, at 8:33 AM, Pete French wrote: > BTW, I belive there is some kind of issue with how OSX resolves names > with bot an A and an AAAA record. I have a feeling that it makes two > requests, but only uses the one which comes back first or something > along those lines... Certainly I use Ipv6 on OSx all the time for my > work, and one of the annoyances is that an IPv6-only website which was > previously accessible can suddenly vanish as far as Safari is > concered. Quitting the app and disabling-the-reenabling wifi makes it > appear again. The brokenness you describe appeared in 10.6 (Snow Leopard). See http://openradar.appspot.com/7333104 for some details. --Ron -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4936 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100316/2de3793b/attachment.bin From dwmalone at maths.tcd.ie Tue Mar 16 16:55:47 2010 From: dwmalone at maths.tcd.ie (David Malone) Date: Tue, 16 Mar 2010 15:55:47 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <8C2D8352-F9FC-4A87-9080-4D835DF03038@employees.org> Message-ID: <20100316155547.GA19733@walton.maths.tcd.ie> On Mon, Mar 15, 2010 at 06:58:34PM +0100, Ole Troan wrote: > if I was a content provider I would look hard at those numbers > above to judge if I wanted to piss off 0.08% of my customers and > slow down the web site for a quarter of a percent of the others. FWIW, IPv6 has already provided evidence that many content providers do not care about small percentages of customers: when some DNS server devices were responding to AAAA requests incorrectly with NXDOMAIN/timeouts/..., most content providers didn't notice, let alone make any effort to fix it. The BBC and perl people did, but others (including doubleclick and HP) were slow to respond, on a time scale of years. As embeded doubleclick images were so common, this actually had an impact on many content providers, but it seems that it didn't provoke much of a push to have things fixed. Of course, I'm not sure what the percentage of people caught by this was. As long ago as 2004, Caida were reporting 1% AAAA queries at the DNS root, so I suspect that these problems were catching more than 0.08% of people. David. From tore.anderson at redpill-linpro.com Tue Mar 16 17:00:14 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 16 Mar 2010 17:00:14 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <504E9FA0-2A28-4AD6-AED2-2ED60D5A3441@spawar.navy.mil> References: <504E9FA0-2A28-4AD6-AED2-2ED60D5A3441@spawar.navy.mil> Message-ID: <4B9FAB0E.7050004@redpill-linpro.com> * Ron Broersma > The brokenness you describe appeared in 10.6 (Snow Leopard). See > http://openradar.appspot.com/7333104 for some details. Ugh... I do see significant amounts of 6to4 traffic from earlier versions of Mac OS X, too - hit counts from yesterday: 1 Mac OS X 10_5_4; 4 Mac OS X 10_6_3; 5 Mac OS X 10_5_6; 7 Mac OS X 10_6_1; 10 Mac OS X 10_6; 12 Mac OS X; 24 Mac OS X 10_5_7; 43 Mac OS X 10.4; 83 Mac OS X 10_4_11; 163 Mac OS X 10.6; 236 Mac OS X 10.5; 554 Mac OS X 10_5_8; 674 Mac OS X 10_6_2; ...so there might be two separate problems with Mac OS X and IPv6. :-( -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From pete at twisted.org.uk Tue Mar 16 17:47:28 2010 From: pete at twisted.org.uk (Pete French) Date: Tue, 16 Mar 2010 16:47:28 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4B9FA8E0.3080102@redpill-linpro.com> Message-ID: > Basically to go to dualstacked destinations (www.ripe.net and > www.ipv6.org are especially nice as they'll echo your source address > back to you) and see if it'll connect by using IPv6/6to4 or IPv4. Or if > it changes depending on which DNS response comes back first as you say, > you should be able to determine that by tcpdumping your port 53/udp traffic. Well, I can go ahead and do this, but it looks like it's been made somewhat iunnecessary by the subsequent posting of the link to the OSX brokenness, which does exactly that kind of tracing. I can still do it though if you want some confirmation ? > If you're able to break 6to4 on purpose (e.g. dropping all proto-41 > packets on the FreeBSD box), how does that change your browsing > experience? Does dualstacked sites appear to be down or sluggish? That I can do when I get home (similar setup to the work network, but I can turn stuff off with disrupting peoples work). -pete. From me at benedikt-stockebrand.de Tue Mar 16 19:15:54 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 16 Mar 2010 18:15:54 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100316145247.GC69383@Space.Net> (Gert Doering's message of "Tue, 16 Mar 2010 15:52:47 +0100") References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> Message-ID: Hi Gert and list, Gert Doering writes: >> Do you get the same result when you connect to a statistically >> significant selection of IPv4-only ISPs using whatever 6to4 public >> relay? > > I'm not exactly sure how a 6to4 public relay would enable me to connect > to an IPv4-only ISP? (And I don't have a high enough number of servers > on 2002:: addresses to make this a meaningful experiment). > > If I connect to an IPv4-only ISP, I use IPv4 on my end... ok, just to rephrase my original question: If you connect to the Internet via an IPv4-only ISP (rather than one that offers native IPv6) and then alternatively use native IPv4 and 6to4 to access a site serving both, do you still notice a difference in latency? >> On another track: Much of the discussion in this thread makes an >> implicit assumption that there's a single DNS name for both IPv4 and >> IPv6 services, i.e. "www.example.com." has both an A and a AAAA >> record. > > Which is the ONLY thing that makes sense in the long run. Yes, but we're talking transition mechanisms here. >> That's fine if have the resources to do the Google approach >> and only serve AAAA's to whitelisted clients. If you can't do that, >> then there's the alternative approach of using "www6.example.com." for >> AAAA's---that requires conscious action on the client side. > > Which was OK for testing IPv6 services in the last century, but this > is completely useless as a way forward. Why should anybody (except > somebody wanting to test this) type "www6" or "www.ipv6" or "www.six" > into their web browser? Because its "kewl" and/or they want to see if it actually works. Just because end users can be rather irrational doesn't mean that you can't sometimes make good use of it. Additionally, for internal purposes when you migrate a company or government agency network or such it lets you work around a number of problems during the transition period. > [..] >> These points aren't only crucial to keep in mind if you do business >> with end users; they also apply to end user acceptance of IPv6 and as >> such the move towards IPv6. > > There is no "end user acceptance of IPv6" - as the end users do not know > what IPv4 or IPv6 is, they will use it if it is there, and not use it > if it is not there. I was more thinking along the line End user: My Internet is broken. Help desk: What exactly do you want to do? End user: Connect to the Internet, with the funny colored letters. Help desk: Oh, you mean Google. Ok. What happens? End user: It doesn't work and says there is something wrong about some silly letters and colons there. Help desk: Ok, that should be an IPv6 address. I'll check with the network administrators if they did anything. End user: Whatever this "IPv6" is---turn it off, I want to work/play/whatever. If IPv6 disrupts a business customer's business or an end user's entertainment, there is a good chance they pick up "IPv6" as the keyword to blame. It doesn't take actually understanding what IPv6 is to do so. Neither do end users care that because of some reasonable change on your side the brokenness of their router (which "has been working fine as long as I had it") is actually causing them trouble now. > Which is why the argument "my customes are not asking for IPv6" is > not very useful for this sort of customers either. That's an entirely different discussion. As an ISP I wouldn't wait until people request IPv6 because by then it is too late to sort things out on the ISP side. By now I generally---including ISPs---tell people that IPv6 is somewhat like Y2K (except that it doesn't come at a fixed, and predictable, time): It doesn't have a "business case" but ignoring it will still cost significant money. As far as ISPs go: Since they are all equally affected the ones who deal best with it are likely to increase their market share. (Sorry about using one of the no-no words.) > The challenge for the large-scale providers is to roll out IPv6 to the > end customers in a transparent way and without breaking anything in the > process - and do this before the NAT4444 architecture is so cemented > in all the heads that we're stuck with a completely no-more-end-to-end > Internet for ever. With the large majority of people (including many professionals and wannabe professionals) that has already happened. ISPs are somewhat unusual with the IPv6 deployment because to them IPv6 is largely an all-or-nothing issue with no way to back out. To other customers I suggest to take a gradual approach with plenty of pre-planned rollback opportunities and/or use the upcoming move towards Windows 7 as a chance to do a reasonably painless move towards IPv6. This is admittedly unpractical to an ISP, but with the enterprises or government agency customers I am mostly concerned with right now, that's pretty much the way to go. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From gert at space.net Tue Mar 16 20:14:04 2010 From: gert at space.net (Gert Doering) Date: Tue, 16 Mar 2010 20:14:04 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> Message-ID: <20100316191404.GI69383@Space.Net> Hi, On Tue, Mar 16, 2010 at 06:14:54PM +0000, Benedikt Stockebrand wrote: > Gert Doering writes: > > >> Do you get the same result when you connect to a statistically > >> significant selection of IPv4-only ISPs using whatever 6to4 public > >> relay? > > > > I'm not exactly sure how a 6to4 public relay would enable me to connect > > to an IPv4-only ISP? (And I don't have a high enough number of servers > > on 2002:: addresses to make this a meaningful experiment). > > > > If I connect to an IPv4-only ISP, I use IPv4 on my end... > > ok, just to rephrase my original question: If you connect to the > Internet via an IPv4-only ISP (rather than one that offers native > IPv6) and then alternatively use native IPv4 and 6to4 to access a site > serving both, do you still notice a difference in latency? I'm pretty sure that I will. That was the initial starter for this thread - 6to4 is usually worse than native IPv4, and is causing real problems. Which is why it is fortunate that all the (recent?) Windows versions do the right thing, and prefer native IPv4 before 6to4 and Teredo - so for connecting to a dual-stacked hosts, 6to4 latency is irrelevant. [..] > >> That's fine if have the resources to do the Google approach > >> and only serve AAAA's to whitelisted clients. If you can't do that, > >> then there's the alternative approach of using "www6.example.com." for > >> AAAA's---that requires conscious action on the client side. > > > > Which was OK for testing IPv6 services in the last century, but this > > is completely useless as a way forward. Why should anybody (except > > somebody wanting to test this) type "www6" or "www.ipv6" or "www.six" > > into their web browser? > > Because its "kewl" and/or they want to see if it actually works. We know that IPv6 works. Since about 10 years. The time for testing in "kewl circles" is long over - now we need to do production tests, and then production *roll-out*. [..] > Additionally, for internal purposes when you migrate a company or > government agency network or such it lets you work around a number of > problems during the transition period. By replacing them with much larger problems, like "all of the absolute URLs that your sites might use for links will no longer work" - ask the heise people what fun they had with www.six.heise.de - they had to setup a special proxy that rewrites the HTML pages in-flight to get the URLs fixed. For small-scale testing, one can put the IPv6 address in the local machine's /etc/hosts file. For medium-scale testing, one can do split-DNS. This will get you *real* tests - with the right URL leading to the right site. With absolute links working, etc. [..] > > There is no "end user acceptance of IPv6" - as the end users do not know > > what IPv4 or IPv6 is, they will use it if it is there, and not use it > > if it is not there. > > I was more thinking along the line [..] > Help desk: Ok, that should be an IPv6 address. I'll check with > the network administrators if they did anything. > > End user: Whatever this "IPv6" is---turn it off, I want to > work/play/whatever. OK, I can see your point. And it has been mentioned before: the support people need to be trained. They must not be spooked by IPv6 addresses, and they need to know that they should not spook the customers. [..] > > The challenge for the large-scale providers is to roll out IPv6 to the > > end customers in a transparent way and without breaking anything in the > > process - and do this before the NAT4444 architecture is so cemented > > in all the heads that we're stuck with a completely no-more-end-to-end > > Internet for ever. > > With the large majority of people (including many professionals and > wannabe professionals) that has already happened. Well, fortunately, multiple layers of NAT are still the exception - so the deployer of the NAT is still in control regarding port forwardings and so on. With multiple layers of NAT, you will have to request port forwardings from your ISP (and likely charge a monthly fee per port...) - goodbye to anything that is not "consumer only". > ISPs are somewhat unusual with the IPv6 deployment because to them > IPv6 is largely an all-or-nothing issue with no way to back out. For the mass-market ISPs, certainly. If they roll out IPv6, and it doesn't work, game over. For the smaller ISPs, you can do it more gradually, and that way there already is some experience regarding IPv6 deployment out there... > To other customers I suggest to take a gradual approach with plenty of > pre-planned rollback opportunities and/or use the upcoming move > towards Windows 7 as a chance to do a reasonably painless move towards > IPv6. This is admittedly unpractical to an ISP, but with the > enterprises or government agency customers I am mostly concerned with > right now, that's pretty much the way to go. Smaller ISPs don't do this "we must not do a single change to our IT infrastructure thing!!!!" that large enterprises and govt. agencies are so good at :-) - so for us, IPv6 roll-out for our own infrastructure and servers goes hand in hand with the continuous change that we experience all the time anyway. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100316/451474c6/attachment.bin From leo.vegoda at icann.org Tue Mar 16 21:23:44 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 16 Mar 2010 13:23:44 -0700 Subject: Latest Load Balancer IPv6 Support In-Reply-To: <4B9F7661.8010702@arin.net> References: <4B9F7661.8010702@arin.net> Message-ID: On 16 Mar 2010, at 5:15, Matt Ryanczak wrote: > I know this has been asked before but it has been quite some time so I > thought it fair to bring this topic up again. > > What are peoples experiences with load balancers and IPv6? I checked with out IT department and they confirmed that we are very happy with F5 Networks. "There is excellent v6 support on the Local and Global traffic managers and DNSSEC support on the Global product as well." F5 seem to be getting a great big thumbs-up today. Leo From sethm at rollernet.us Tue Mar 16 21:28:54 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 16 Mar 2010 13:28:54 -0700 Subject: Latest Load Balancer IPv6 Support In-Reply-To: References: <4B9F7661.8010702@arin.net> Message-ID: <4B9FEA06.2010304@rollernet.us> On 3/16/2010 13:23, Leo Vegoda wrote: > On 16 Mar 2010, at 5:15, Matt Ryanczak wrote: > >> I know this has been asked before but it has been quite some time so I >> thought it fair to bring this topic up again. >> >> What are peoples experiences with load balancers and IPv6? > > I checked with out IT department and they confirmed that we are very happy with F5 Networks. > > "There is excellent v6 support on the Local and Global traffic managers and DNSSEC support on the Global product as well." > > F5 seem to be getting a great big thumbs-up today. > Is it still an add-on license for v6 support? Or am I thinking of someone else? ~Seth From tore.anderson at redpill-linpro.com Tue Mar 16 21:30:28 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 16 Mar 2010 21:30:28 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: Message-ID: <4B9FEA64.8060407@redpill-linpro.com> * Pete French > Well, I can go ahead and do this, but it looks like it's been made > somewhat iunnecessary by the subsequent posting of the link to the > OSX brokenness, which does exactly that kind of tracing. > > I can still do it though if you want some confirmation ? Unless you're able to test with OS X earlier than 10.6, I don't think there's any point. But if you have anything earlier than that, it would be nice to find out the reason why it seems to (sometimes?) prefer 6to4 over IPv4 - as I pointed out in another message there appears to be two distinct cases of IPv6 misbehavour in OS X, the link describes only one of them. >> If you're able to break 6to4 on purpose (e.g. dropping all >> proto-41 packets on the FreeBSD box), how does that change your >> browsing experience? Does dualstacked sites appear to be down or >> sluggish? > > That I can do when I get home (similar setup to the work network, but > I can turn stuff off with disrupting peoples work). Great! No rush. :-) Breaking IPv6/6to4 for OS X isn't really a problem for me/my customers if OS X able to gracefully fail back to IPv4 without the user noticing. Best regards, and thanks again, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From berni at birkenwald.de Tue Mar 16 21:30:51 2010 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 16 Mar 2010 21:30:51 +0100 Subject: Latest Load Balancer IPv6 Support In-Reply-To: <4B9F7DB5.1070100@arin.net> References: <4B9F7661.8010702@arin.net> <20100316122154.GA8113@schleppi.birkenwald.de> <4B9F7DB5.1070100@arin.net> Message-ID: <4B9FEA7B.6030504@birkenwald.de> On 16.03.2010 13:46, Matt Ryanczak wrote: Hi Matt, > On 03/16/2010 08:21 AM, Bernhard Schmidt wrote: >> Running v6 on our F5 BigIP since around 2006, and having quite a few >> systems behind it. Mostly Webservers (http://www.lrz-muenchen.de). Other >> than some weird traceroute6 output when tracing through the box it works >> like a charm. > Are you using gslb? Any chance you are using it for any DNS load balancing? No GSLB and no DNS load balancing on the F5, we use Anycast for that. For UDP traffic we do have our main Radius proxy behind the F5 though (IPv4 only). No big issues. Sometimes the box got confused on outgoing NAT (from the proxy nodes to some external department server) because the source port was the same on both. We changed our source port to be different. Bernhard From daniel at bit.nl Tue Mar 16 23:16:48 2010 From: daniel at bit.nl (Daniel Verlouw) Date: Tue, 16 Mar 2010 23:16:48 +0100 Subject: Latest Load Balancer IPv6 Support In-Reply-To: <4B9FEA06.2010304@rollernet.us> References: <4B9F7661.8010702@arin.net> <4B9FEA06.2010304@rollernet.us> Message-ID: <79C24AE8-4375-4EBC-A0AA-FF52B8EFD529@bit.nl> On Mar 16, 2010, at 9:28 PM, Seth Mattinen wrote: > On 3/16/2010 13:23, Leo Vegoda wrote: >> >> F5 seem to be getting a great big thumbs-up today. +1 although there are some minor annoyances, such as setting the netmask on interfaces. You have to enter as 'ffff:ffff:ffff:ffff::' instead of '/64', pretty lame if you ask me. Also note that IPv6 is not ASIC accelerated, so depending on your configuration and traffic profile you may want to performance test first. > Is it still an add-on license for v6 support? Or am I thinking of > someone else? on some models, it still is an add-on license. on others, it's included in the base price. Just tell your reseller you want it for free and you'll probably get it, the usual purchasing tactics apply ;-) --Daniel. From brian.e.carpenter at gmail.com Wed Mar 17 01:40:55 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 17 Mar 2010 13:40:55 +1300 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: <20100316092839.GS69383@Space.Net> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> Message-ID: <4BA02517.1030905@gmail.com> Gert, The problem is tunnels. The first example is from University of Auckland via Telstraclear and a HE tunnel. IPv6 penalty is about 390 ms round trip, crossing one ocean. The second is native all the way. *IPv4* penalty is 5 ms round trip, crossing two oceans. The problem is not 6to4 specifically, but I don't have the ability to compare 6to4 overhead with HE overhead. >ping www.ietf.org Pinging www.ietf.org [2001:1890:1112:1::20] with 32 bytes of data: Reply from 2001:1890:1112:1::20: time=667ms Reply from 2001:1890:1112:1::20: time=544ms Reply from 2001:1890:1112:1::20: time=575ms Reply from 2001:1890:1112:1::20: time=344ms Ping statistics for 2001:1890:1112:1::20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 344ms, Maximum = 667ms, Average = 532ms >ping -4 www.ietf.org Pinging www.ietf.org [64.170.98.32] with 32 bytes of data: Reply from 64.170.98.32: bytes=32 time=141ms TTL=66 Reply from 64.170.98.32: bytes=32 time=150ms TTL=66 Reply from 64.170.98.32: bytes=32 time=142ms TTL=66 Reply from 64.170.98.32: bytes=32 time=142ms TTL=66 Ping statistics for 64.170.98.32: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 141ms, Maximum = 150ms, Average = 143ms ---------------------------------------------------------- >ping www.surfnet.nl Pinging www.surfnet.nl [2001:610:1:80d0:194:171:26:201] with 32 bytes of data: Reply from 2001:610:1:80d0:194:171:26:201: time=311ms Reply from 2001:610:1:80d0:194:171:26:201: time=310ms Reply from 2001:610:1:80d0:194:171:26:201: time=311ms Reply from 2001:610:1:80d0:194:171:26:201: time=310ms Ping statistics for 2001:610:1:80d0:194:171:26:201: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 310ms, Maximum = 311ms, Average = 310ms >ping -4 www.surfnet.nl Pinging www.surfnet.nl [194.171.26.203] with 32 bytes of data: Reply from 194.171.26.203: bytes=32 time=322ms TTL=110 Reply from 194.171.26.203: bytes=32 time=313ms TTL=110 Reply from 194.171.26.203: bytes=32 time=313ms TTL=110 Reply from 194.171.26.203: bytes=32 time=313ms TTL=110 Ping statistics for 194.171.26.203: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 313ms, Maximum = 322ms, Average = 315ms Regards Brian Carpenter On 2010-03-16 22:28, Gert Doering wrote: > Hi, > > On Tue, Mar 16, 2010 at 10:13:18AM +0100, Tore Anderson wrote: >> on and on. Network latency is without question on that list. While >> nothing can be done about a user's high-latency connection, 150ms of >> additional client-server latency due to IPv6 being used will quickly add >> up to seconds in terms of overall page load time for a complex web site, > > I keep wondering about those 150ms. I seem to remember that Google saw > *few users* that had a much higher IPv6 latency - but at the same time > they also saw users with a *lower* latency via IPv6 (due to different > network paths being taken). > > For me, the v4/v6 latency is very similar - I use v6 all day, many of > the sites I connect to (including google) have v6, and I do not see any > adverse effects (nor any positive effects - it's just IP, after all). > > So I'd like to see these 150ms qualified - in this discussion, it seems > to be the assumption that "IPv6 will *always* be 150ms slower", which > is most definitely not the case. > > Gert Doering > -- NetMaster From gert at space.net Wed Mar 17 08:40:53 2010 From: gert at space.net (Gert Doering) Date: Wed, 17 Mar 2010 08:40:53 +0100 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: <4BA02517.1030905@gmail.com> References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <4BA02517.1030905@gmail.com> Message-ID: <20100317074053.GJ69383@Space.Net> Hi, On Wed, Mar 17, 2010 at 01:40:55PM +1300, Brian E Carpenter wrote: > The problem is tunnels. The first example is from University of Auckland > via Telstraclear and a HE tunnel. IPv6 penalty is about 390 ms round trip, > crossing one ocean. The second is native all the way. *IPv4* penalty is 5 ms > round trip, crossing two oceans. Sounds like something that can be easily identified and people should work to fix, no? From here: $ ping6 -c3 www.surfnet.nl PING6(56=40+8+8 bytes) 2001:608:2:2::250 --> 2001:610:1:80d0:194:171:26:201 16 bytes from 2001:610:1:80d0:194:171:26:201, icmp_seq=0 hlim=54 time=15.950 ms 16 bytes from 2001:610:1:80d0:194:171:26:201, icmp_seq=1 hlim=54 time=16.674 ms 16 bytes from 2001:610:1:80d0:194:171:26:201, icmp_seq=2 hlim=54 time=15.807 ms $ ping -c3 www.surfnet.nl PING www.surfnet.nl (194.171.26.203): 56 data bytes 64 bytes from 194.171.26.203: icmp_seq=0 ttl=118 time=32.051 ms 64 bytes from 194.171.26.203: icmp_seq=1 ttl=118 time=31.909 ms 64 bytes from 194.171.26.203: icmp_seq=2 ttl=118 time=31.905 ms (now that is cool, isn't it?) $ ping -c3 www.isc.org PING www.isc.org (149.20.64.42): 56 data bytes 64 bytes from 149.20.64.42: icmp_seq=0 ttl=57 time=168.623 ms 64 bytes from 149.20.64.42: icmp_seq=1 ttl=57 time=168.590 ms 64 bytes from 149.20.64.42: icmp_seq=2 ttl=57 time=168.420 ms $ ping6 -c3 www.isc.org PING6(56=40+8+8 bytes) 2001:608:2:2::250 --> 2001:4f8:0:2::d 16 bytes from 2001:4f8:0:2::d, icmp_seq=0 hlim=55 time=172.308 ms 16 bytes from 2001:4f8:0:2::d, icmp_seq=1 hlim=55 time=172.482 ms 16 bytes from 2001:4f8:0:2::d, icmp_seq=2 hlim=55 time=173.099 ms (not too bad - those 4ms shouldn't really affect anything) www.ietf.org sucks, tho (226 ms vs. 168 ms). So yes - we're back at the Subject: line - "on killing transition technologies". There's tunnels that don't impact performance (because they are on well-controlled infrastructure and just circumvent some local problem), and there's other tunnels that are obviously bad. These are local problems, though: someone has setup the tunnel, and this person can control working on the situation and improving it. 6to4 relays, on the other hand, are usually run by someone completely unknown to you, and if one of them is slow/unreliable, it's very hard to find out where it is. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100317/93844c0a/attachment-0001.bin From mohacsi at niif.hu Wed Mar 17 09:29:00 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 17 Mar 2010 09:29:00 +0100 (CET) Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> Message-ID: On Tue, 16 Mar 2010, Benedikt Stockebrand wrote: > > I was more thinking along the line > > End user: My Internet is broken. > > Help desk: What exactly do you want to do? > > End user: Connect to the Internet, with the funny colored letters. > > Help desk: Oh, you mean Google. Ok. What happens? > > End user: It doesn't work and says there is something wrong about > some silly letters and colons there. > > Help desk: Ok, that should be an IPv6 address. I'll check with > the network administrators if they did anything. > > End user: Whatever this "IPv6" is---turn it off, I want to > work/play/whatever. then this provider did his jobs badly. They did not test when they introduced ipv6. Plan, Train, Test in small, learn, train, pilot, test, train, test, introduce. Phased introduction this is the key! This takes time! Therefore many ISPs are already late. > > If IPv6 disrupts a business customer's business or an end user's > entertainment, there is a good chance they pick up "IPv6" as the > keyword to blame. It doesn't take actually understanding what IPv6 is > to do so. They should blame the provider! Probably change to another ISP. As they would change if IPv4 service is badly provided. Best Regards, Janos Mohacsi From tore.anderson at redpill-linpro.com Wed Mar 17 10:07:09 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 17 Mar 2010 10:07:09 +0100 Subject: IPv6 brokenness in Norway, February 2010 In-Reply-To: <4B8B8921.7060909@redpill-linpro.com> References: <4B8B8921.7060909@redpill-linpro.com> Message-ID: <4BA09BBD.5000308@redpill-linpro.com> * Tore Anderson > find attached the brokenness reports for February. This time they're > generated from the readers of www.vg.no, Norway's largest web site. I've just generated a new report for February, this time excluding both all clients using Opera and Mac OS X. The result is essentially that almost no brokenness remains (0.004% total) - some of the individual days actually give me a negative score so I think we're easily within the statistical error margin of 0%. Opera has already fixed their browser. I wonder how to best get in touch with Apple... The issue seems to be the same there, namely that it prefers 6to4 over IPv4 when it shouldn't. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 201002-noopera-noosx.txt Url: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100317/274bda88/attachment.txt From tme at americafree.tv Wed Mar 17 10:11:57 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 17 Mar 2010 05:11:57 -0400 Subject: IPv6 brokenness in Norway, February 2010 In-Reply-To: <4BA09BBD.5000308@redpill-linpro.com> References: <4B8B8921.7060909@redpill-linpro.com> <4BA09BBD.5000308@redpill-linpro.com> Message-ID: <85C54636-094B-4650-B26F-CBF7B96862B2@americafree.tv> On Mar 17, 2010, at 5:07 AM, Tore Anderson wrote: > * Tore Anderson > >> find attached the brokenness reports for February. This time they're >> generated from the readers of www.vg.no, Norway's largest web site. > > I've just generated a new report for February, this time excluding > both > all clients using Opera and Mac OS X. The result is essentially that > almost no brokenness remains (0.004% total) - some of the individual > days actually give me a negative score so I think we're easily within > the statistical error margin of 0%. > > Opera has already fixed their browser. I wonder how to best get in > touch with Apple... I would suggest starting with the Apple employee on the IAB. Regards Marshall > The issue seems to be the same there, namely that > it prefers 6to4 over IPv4 when it shouldn't. > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > Tel: +47 21 54 41 27 > <201002-noopera-noosx.txt> From evyncke at cisco.com Wed Mar 17 19:02:54 2010 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Wed, 17 Mar 2010 19:02:54 +0100 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] Message-ID: <317616CE96204D49B5A1811098BA89500113466F@XMB-AMS-110.cisco.com> Brian Ping ietf with Ttl=66 waouw, I have never seen this value! I wonder which was the hop limit value at ietf web site :-) Sent on my mobile with a micro keyboard. Please accept my apologies for typos... -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter at gmail.com] Sent: Wednesday, March 17, 2010 01:41 AM W. Europe Standard Time To: Gert Doering Cc: ipv6-ops at lists.cluenet.de Subject: Tunnel overhead [On killing IPv6 transition mechanisms] Gert, The problem is tunnels. The first example is from University of Auckland via Telstraclear and a HE tunnel. IPv6 penalty is about 390 ms round trip, crossing one ocean. The second is native all the way. *IPv4* penalty is 5 ms round trip, crossing two oceans. The problem is not 6to4 specifically, but I don't have the ability to compare 6to4 overhead with HE overhead. >ping www.ietf.org Pinging www.ietf.org [2001:1890:1112:1::20] with 32 bytes of data: Reply from 2001:1890:1112:1::20: time=667ms Reply from 2001:1890:1112:1::20: time=544ms Reply from 2001:1890:1112:1::20: time=575ms Reply from 2001:1890:1112:1::20: time=344ms Ping statistics for 2001:1890:1112:1::20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 344ms, Maximum = 667ms, Average = 532ms >ping -4 www.ietf.org Pinging www.ietf.org [64.170.98.32] with 32 bytes of data: Reply from 64.170.98.32: bytes=32 time=141ms TTL=66 Reply from 64.170.98.32: bytes=32 time=150ms TTL=66 Reply from 64.170.98.32: bytes=32 time=142ms TTL=66 Reply from 64.170.98.32: bytes=32 time=142ms TTL=66 Ping statistics for 64.170.98.32: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 141ms, Maximum = 150ms, Average = 143ms ---------------------------------------------------------- >ping www.surfnet.nl Pinging www.surfnet.nl [2001:610:1:80d0:194:171:26:201] with 32 bytes of data: Reply from 2001:610:1:80d0:194:171:26:201: time=311ms Reply from 2001:610:1:80d0:194:171:26:201: time=310ms Reply from 2001:610:1:80d0:194:171:26:201: time=311ms Reply from 2001:610:1:80d0:194:171:26:201: time=310ms Ping statistics for 2001:610:1:80d0:194:171:26:201: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 310ms, Maximum = 311ms, Average = 310ms >ping -4 www.surfnet.nl Pinging www.surfnet.nl [194.171.26.203] with 32 bytes of data: Reply from 194.171.26.203: bytes=32 time=322ms TTL=110 Reply from 194.171.26.203: bytes=32 time=313ms TTL=110 Reply from 194.171.26.203: bytes=32 time=313ms TTL=110 Reply from 194.171.26.203: bytes=32 time=313ms TTL=110 Ping statistics for 194.171.26.203: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 313ms, Maximum = 322ms, Average = 315ms Regards Brian Carpenter On 2010-03-16 22:28, Gert Doering wrote: > Hi, > > On Tue, Mar 16, 2010 at 10:13:18AM +0100, Tore Anderson wrote: >> on and on. Network latency is without question on that list. While >> nothing can be done about a user's high-latency connection, 150ms of >> additional client-server latency due to IPv6 being used will quickly add >> up to seconds in terms of overall page load time for a complex web site, > > I keep wondering about those 150ms. I seem to remember that Google saw > *few users* that had a much higher IPv6 latency - but at the same time > they also saw users with a *lower* latency via IPv6 (due to different > network paths being taken). > > For me, the v4/v6 latency is very similar - I use v6 all day, many of > the sites I connect to (including google) have v6, and I do not see any > adverse effects (nor any positive effects - it's just IP, after all). > > So I'd like to see these 150ms qualified - in this discussion, it seems > to be the assumption that "IPv6 will *always* be 150ms slower", which > is most definitely not the case. > > Gert Doering > -- NetMaster -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100317/1d90460a/attachment.html From stig at venaas.com Wed Mar 17 19:17:43 2010 From: stig at venaas.com (Stig Venaas) Date: Wed, 17 Mar 2010 11:17:43 -0700 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: <317616CE96204D49B5A1811098BA89500113466F@XMB-AMS-110.cisco.com> References: <317616CE96204D49B5A1811098BA89500113466F@XMB-AMS-110.cisco.com> Message-ID: <4BA11CC7.4000107@venaas.com> Eric Vyncke (evyncke) wrote: > Brian > > Ping ietf with Ttl=66 waouw, I have never seen this value! I wonder > which was the hop limit value at ietf web site :-) > Almost certainly 128 I would say. But I'm getting 68 for IPv4 and I am 15 hops away (if IPv4 path is symmetric). But I've never heard of any OS using 83 or whatever for initial TTL. AFAIK there are OSes using 64 and 128, but I'm not aware of any in between. Stig From tedm at ipinc.net Wed Mar 17 19:55:46 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 17 Mar 2010 11:55:46 -0700 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: <4BA11CC7.4000107@venaas.com> References: <317616CE96204D49B5A1811098BA89500113466F@XMB-AMS-110.cisco.com> <4BA11CC7.4000107@venaas.com> Message-ID: <4BA125B2.3010809@ipinc.net> I am pretty sure I recall reading that the larger routers have the ability to lower priority of ICMP echo replies and that most of them do. Have you confirmed these ping numbers agree with traceroutes, particularly ones NOT using standard trace protocols? Also, one point on Tore Andersons comment that I'm not going to let slide: "...Network latency is without question on that list....additional client-server latency due to IPv6 being used will quickly add up to seconds in terms of overall page load time for a complex web site..." That is factually incorrect. TCP/IP uses sliding windows. As long as the overall latency falls within the window setting, (and 150ms definitely does) then the IP transmission WILL NOT fall back into the "send-a-pack-wait-for-an-ack" mode and bandwidth will NOT be affected, thus it does not result in any increase in page load delay for larger pages. In any case, content providers are idiots if they don't understand that complex web pages take longer to render in the web browser than simpler pages. There is a reason that Ebay, Craigslist, Google, etc. use text-output for their browse listings - they aren't run by idiots. That's why I don't use bing.com for example, and never will. Ted Stig Venaas wrote: > Eric Vyncke (evyncke) wrote: >> Brian >> >> Ping ietf with Ttl=66 waouw, I have never seen this value! I wonder >> which was the hop limit value at ietf web site :-) >> > > Almost certainly 128 I would say. But I'm getting 68 for IPv4 and I am > 15 hops away (if IPv4 path is symmetric). But I've never heard of any OS > using 83 or whatever for initial TTL. AFAIK there are OSes using 64 and > 128, but I'm not aware of any in between. > > Stig From gert at space.net Wed Mar 17 20:10:14 2010 From: gert at space.net (Gert Doering) Date: Wed, 17 Mar 2010 20:10:14 +0100 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: <4BA125B2.3010809@ipinc.net> References: <317616CE96204D49B5A1811098BA89500113466F@XMB-AMS-110.cisco.com> <4BA11CC7.4000107@venaas.com> <4BA125B2.3010809@ipinc.net> Message-ID: <20100317191014.GV69383@Space.Net> Hi, On Wed, Mar 17, 2010 at 11:55:46AM -0700, Ted Mittelstaedt wrote: > I am pretty sure I recall reading that the larger routers have the > ability to lower priority of ICMP echo replies and that most of them > do. They do, which is why we ping servers, not routers :-) [..] > "...Network latency is without question on that list....additional > client-server latency due to IPv6 being used will quickly add > up to seconds in terms of overall page load time for a complex web site..." > > That is factually incorrect. TCP/IP uses sliding windows. As long > as the overall latency falls within the window setting, (and 150ms > definitely does) then the IP transmission WILL NOT fall back into > the "send-a-pack-wait-for-an-ack" mode and bandwidth will NOT be > affected, thus it does not result in any increase in page load > delay for larger pages. A web page consists of manymanymany round-trips for manymanymany small page elements. 150ms adds up. It's worse with HTTP persistant connections, less bad with multiple parallel connections. Web is not "FTP download a single big file in a continuous mostly unidirectional stream". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100317/adab4360/attachment.bin From ipv6-ops at c0mplx.org Wed Mar 17 20:36:03 2010 From: ipv6-ops at c0mplx.org (Kurt Jaeger) Date: Wed, 17 Mar 2010 20:36:03 +0100 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: <4BA125B2.3010809@ipinc.net> References: <317616CE96204D49B5A1811098BA89500113466F@XMB-AMS-110.cisco.com> <4BA11CC7.4000107@venaas.com> <4BA125B2.3010809@ipinc.net> Message-ID: <20100317193603.GQ2911@home.opsec.eu> Hi! > "...Network latency is without question on that list....additional > client-server latency due to IPv6 being used will quickly add > up to seconds in terms of overall page load time for a complex web site..." > > That is factually incorrect. TCP/IP uses sliding windows. http://oreilly.com/catalog/9780596529307/ describes the problem: Websites do not provide one large tcp stream, but many small ones, many of them with multiple tcp connection setups and teardowns. Those are eating up the latency budget for a snappy website. There's a cute tool which allowes one to test it: http://www.alphaworks.ibm.com/tech/pagedetailer "A graphical tool that enables Web content providers to rapidly and accurately measure client side performance of Web pages." -- pi at opsec.eu +49 171 3101372 10 years to go ! From tedm at ipinc.net Wed Mar 17 21:27:02 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 17 Mar 2010 13:27:02 -0700 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: <20100317193603.GQ2911@home.opsec.eu> References: <317616CE96204D49B5A1811098BA89500113466F@XMB-AMS-110.cisco.com> <4BA11CC7.4000107@venaas.com> <4BA125B2.3010809@ipinc.net> <20100317193603.GQ2911@home.opsec.eu> Message-ID: <4BA13B16.8030307@ipinc.net> Kurt Jaeger wrote: > Hi! > >> "...Network latency is without question on that list....additional >> client-server latency due to IPv6 being used will quickly add >> up to seconds in terms of overall page load time for a complex web site..." >> >> That is factually incorrect. TCP/IP uses sliding windows. > > http://oreilly.com/catalog/9780596529307/ > > describes the problem: Websites do not provide one large tcp stream, > but many small ones, many of them with multiple tcp connection setups > and teardowns. Those are eating up the latency budget for a snappy > website. > OK, I see, however from a users perspective I actually like this, because it discourages content providers from sticking in a bunch of extra advertisements and such that crap up their site. I still maintain, though, that for 90% of the machines out there, the browser rendering engine is a far larger contributor to "unsnappy" websites. Based on our customer feedback most people have older systems or newer systems that are crapped-up with adware. The google toolbar alone ads an extra 2-3 seconds for most systems, and I've had people call in with yahoo, google, aol, avg, bing, and msn toolbars loaded in. It's a wonder there was any room to display the page at all. Years ago I worked for a software developer and what your illustrating is "developer myopia" Website developers and software developers always get the very fastest and latest PCs handed to them by their companies for free - so they develop these pigs of websites and software then think they are "snappy" for everyone on the Internet, because they can't see how they work firsthand. If they wanna blame IPv6 then let them - you cannot educate people who have rose-colored glasses on and think everyone on the Internet has a 4Ghz CPU system with 8GB of ram and a $200 video card, on a 10Mbt cable line to do their surfing. The users with the fastest systems on the Internet typically buy them for watching video, and that IS "one large tcp stream", or they buy them for gaming and that's a whole different issue. > There's a cute tool which allowes one to test it: > > http://www.alphaworks.ibm.com/tech/pagedetailer > > "A graphical tool that enables Web content providers to rapidly and > accurately measure client side performance of Web pages." > Cute too, I wonder how many content providers actually read the advice in the help to put their sites on a diet. Ted From nicholas.hatch at gmail.com Wed Mar 17 22:31:08 2010 From: nicholas.hatch at gmail.com (nick hatch) Date: Wed, 17 Mar 2010 14:31:08 -0700 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: <4BA13B16.8030307@ipinc.net> References: <317616CE96204D49B5A1811098BA89500113466F@XMB-AMS-110.cisco.com> <4BA11CC7.4000107@venaas.com> <4BA125B2.3010809@ipinc.net> <20100317193603.GQ2911@home.opsec.eu> <4BA13B16.8030307@ipinc.net> Message-ID: On Wed, Mar 17, 2010 at 1:27 PM, Ted Mittelstaedt wrote: > OK, I see, however from a users perspective I actually like this, because it discourages content providers from sticking in a bunch of > extra advertisements and such that crap up their site. > > I still maintain, though, that for 90% of the machines out there, the browser rendering engine is a far larger contributor to "unsnappy" > websites. ?Based on our customer feedback most people have older systems or newer systems that are crapped-up with adware. Yes, the rendering engine can be a bottleneck in performance. However, this bottleneck is influenced by how the website is authored: Download latency, for example, can affect the DOM, which affects the rendering engine, which affects speed. The Webkit blog has a great post with more details [1]: "Introducing just 50ms of additional latency doubled the page loading time in the high bandwidth case (from ~3200ms to ~6300ms)." I strongly disagree that junky PCs are the limiting factor for 90% of people, but don't have empirical data to back it up. In any case, what you're describing is the lower-bound for website performance. Website designers can't change several of those factors, and "advertisements and such that crap up their site" isn't the biggest problem. Designers are focused on the upper-bound of performance, which improves things for everyone. Yahoo has a great introduction to the topic [2]. Note they don't say "reduce complexity" or "don't use ads", or "code for crap computers!" but rather, "reduce the number of http requests". > The google toolbar alone ads an extra 2-3 seconds for most systems, I've never seen performance issues like this with the Google toolbar, ever. As stated earlier, Google hates the slow web, and has data to back up why. [3] Does it really make sense to you that Google would release a tool that slows down the web that much? >> There's a cute tool which allowes one to test it: >> >> http://www.alphaworks.ibm.com/tech/pagedetailer >> >> "A graphical tool that enables Web content providers to rapidly and >> accurately measure client side performance of Web pages." >> > > Cute too, I wonder how many content providers actually read the > advice in the help to put their sites on a diet. These tools aren't cute, they're very useful, and common: http://code.google.com/speed/page-speed/ http://developer.yahoo.com/yslow/ Good web developers don't talk about "putting sites on diets", they talk about progressive enhancement, caching, compression, CSS sprites, Javascript include order, etc. This topic is well studied from just about every angle, and is empirical for obvious reasons. Getting back to IPv6: Poorly performing transition mechanisms can affect user experience in serious ways. -Nick [1] http://webkit.org/blog/166/optimizing-page-loading-in-web-browser/ [2] http://developer.yahoo.com/performance/rules.html [3] http://code.google.com/speed/ From ipv6-ops+phil at spodhuis.org Thu Mar 18 06:49:40 2010 From: ipv6-ops+phil at spodhuis.org (Phil Pennock) Date: Wed, 17 Mar 2010 22:49:40 -0700 Subject: VM systems and IPv6? Message-ID: <20100318054939.GA16423@redoubt.spodhuis.org> Folks, How common is it these days to have people using Windows under VMs? How common is it for VM virtual bridges to somehow be breaking IPv6? I see another source of some of the broken machines in the stats that various people have published ... I've not previously played with VMs (I'm a latecomer). Playing with Parallels 5 on a Mac, I couldn't get FreeBSD able to route out, looks like NDP announcements weren't making it out, so packets weren't returning so the router wasn't able to send packets back to the VM dom. I could only ping the dom0 and vice-versa. So I brought up a Debian VM, same problem. Interface configures up, gets a default route pointing to the router (Apple Airport) on link-local. I ping ipv6.google.com, see neighbour solicitations for the gateway address but no response. This is from { tcpdump -vvvnpi eth0 -s1500 ip6 } (after ssh'ing back in on explicitly IPv4 to avoid the loop of output-generating-packets, oops). If I ping the fe80:: address of the router itself then: from dom0 I get a response, so the gateway isn't filtering and in the VM; when I try from the VM, I again see neighbour solicitation go out, this time I also see neighbour solicitations from the router for the VM's address (progress!) , then I see the VM send a solicited neighbour advertisement but then nothing. VM eth0 (Debian 5.0): 2001:470:1f05:456:24a:5bff:fe9b:355c fe80::24a:5bff:fe9b:355c dom0 IF is en1: 2001:470:1f05:456:5ab0:35ff:fe60:52b6 fe80::5ab0:35ff:fe60:52b6 Gateway is: 2001:470:1f05:456:fa1e:dfff:fef7:86a0 fe80::fa1e:dfff:fef7:86a0 [ set as default route on hosts ] ----------------------------8< cut here >8------------------------------ 22:06:05.560193 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) fe80::24a:5bff:fe9b:355c > fe80::fa1e:dfff:fef7:86a0: [icmp6 sum ok] ICMP6, echo request, length 64, seq 1 22:06:05.565442 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::fa1e:dfff:fef7:86a0 > ff02::1:ff9b:355c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::24a:5bff:fe9b:355c source link-address option (1), length 8 (1): f8:1e:df:f7:86:a0 0x0000: f81e dff7 86a0 22:06:05.565514 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::24a:5bff:fe9b:355c > fe80::fa1e:dfff:fef7:86a0: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::24a:5bff:fe9b:355c, Flags [solicited, override] destination link-address option (2), length 8 (1): 00:4a:5b:9b:35:5c 0x0000: 004a 5b9b 355c 22:06:06.573865 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) fe80::24a:5bff:fe9b:355c > fe80::fa1e:dfff:fef7:86a0: [icmp6 sum ok] ICMP6, echo request, length 64, seq 2 ----------------------------8< cut here >8------------------------------ tcpdump from the dom0 is not more informative. It really looks as though neighbour solicitations are not making it across, which begs the question of how did the VM get its address configured up in the first place. Anyone have any better thoughts? Am I going to say "doh"? Which returns to my second question. Are there VM environments that do work with IPv6? Thanks, -Phil From tony at lava.net Thu Mar 18 06:53:17 2010 From: tony at lava.net (Antonio Querubin) Date: Wed, 17 Mar 2010 19:53:17 -1000 (HST) Subject: VM systems and IPv6? In-Reply-To: <20100318054939.GA16423@redoubt.spodhuis.org> References: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: On Wed, 17 Mar 2010, Phil Pennock wrote: > How common is it these days to have people using Windows under VMs? > > How common is it for VM virtual bridges to somehow be breaking IPv6? OpenVZ containers using the veth device for bridging between host and containers works fine with IPv6. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From s.ewing at aussiehq.com.au Thu Mar 18 07:06:39 2010 From: s.ewing at aussiehq.com.au (Shaun Ewing) Date: Thu, 18 Mar 2010 17:06:39 +1100 Subject: VM systems and IPv6? In-Reply-To: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: On 18/03/10 4:49 PM, "Phil Pennock" wrote: > How common is it these days to have people using Windows under VMs? We have an extensive Vmware Vsphere setup, with a native IPv6 network and a substantial number of Windows VMs running IPv6. No issues there (and we've been doing this since our network core went v6 native in Feb 2008). > How common is it for VM virtual bridges to somehow be breaking IPv6? On enterprise kit I'm yet to see it. You did however mention Parallels. Most Mac users in our company (including myself) have Parallels running with a Windows VM to access some Windows only apps. I have one running Windows XP, which works fine with IPv6 (albeit on Parallels 4), eg: http://snaps.se.id.au/1/20100318-winxpv6.png The only thing I would suggest - make sure you're using "Bridged Ethernet". Shared Networking does not work. -Shaun -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3285 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100318/100744d8/attachment.bin From ipv6-ops+phil at spodhuis.org Thu Mar 18 07:39:15 2010 From: ipv6-ops+phil at spodhuis.org (Phil Pennock) Date: Wed, 17 Mar 2010 23:39:15 -0700 Subject: VM systems and IPv6? In-Reply-To: References: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: <20100318063915.GA17960@redoubt.spodhuis.org> On 2010-03-18 at 17:06 +1100, Shaun Ewing wrote: > You did however mention Parallels. Most Mac users in our company (including > myself) have Parallels running with a Windows VM to access some Windows only > apps. > > I have one running Windows XP, which works fine with IPv6 (albeit on > Parallels 4), eg: > http://snaps.se.id.au/1/20100318-winxpv6.png Hrm. That suggests I'm being stupid in a way I've yet to spot. I shall keep pondering. Thanks. > The only thing I would suggest - make sure you're using "Bridged Ethernet". > Shared Networking does not work. Yup, I'm Bridged. And disabling the firewall on the Mac doesn't help either. So, probably not a source of significant bias in the percentage of hosts that are broken on IPv6 and thus perhaps OT for the ops list. Thanks, -Phil From yoshfuji at linux-ipv6.org Thu Mar 18 08:12:40 2010 From: yoshfuji at linux-ipv6.org (YOSHIFUJI Hideaki) Date: Thu, 18 Mar 2010 16:12:40 +0900 Subject: VM systems and IPv6? In-Reply-To: <20100318054939.GA16423@redoubt.spodhuis.org> References: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: <1268896360.10592.15.camel@cirrhata.linux-ipv6.org> Phil Pennock wrote: > How common is it these days to have people using Windows under VMs? > > How common is it for VM virtual bridges to somehow be breaking IPv6? : > It really looks as though neighbour solicitations are not making it > across, which begs the question of how did the VM get its address > configured up in the first place. > > Anyone have any better thoughts? Am I going to say "doh"? > > Which returns to my second question. Are there VM environments that do > work with IPv6? Well, I guess you're using wireless NIC in your host machine. If so, I'd say that bridging is not friendly with wireless NIC. - source address cannot be "forged"; you cannot use another source MAC address, e.g. one assigned on your VM's interface. - you cannot set "promiscuous" mode on your Wireless card; you cannot get unicast traffic for your guests. Even with these restrictions, multicast traffic (e.g. unsolicited RAs etc.) can reach your VMs, so VM can have global address. Too bad. To solve these issues, host machine needs to have ND Proxy (RFC4389) or similar. Or, as a workaround, disable IPv6 on your VMs. (sigh...) Regards, --yoshfuji From gert at space.net Thu Mar 18 08:19:04 2010 From: gert at space.net (Gert Doering) Date: Thu, 18 Mar 2010 08:19:04 +0100 Subject: VM systems and IPv6? In-Reply-To: <20100318054939.GA16423@redoubt.spodhuis.org> References: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: <20100318071904.GZ69383@Space.Net> Hi, On Wed, Mar 17, 2010 at 10:49:40PM -0700, Phil Pennock wrote: > Which returns to my second question. Are there VM environments that do > work with IPv6? Vmware ESX works well for us with IPv6. There's a caveat: if you enable TCP offloading in Linux VMs, the IPv6 TCP performance will be abysmal. So don't. But besides this, it works as expected. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 jogi at mur.at Thu Mar 18 09:03:39 2010 From: jogi at mur.at (Jogi =?utf-8?Q?Hofm=C3=BCller?=) Date: Thu, 18 Mar 2010 09:03:39 +0100 Subject: VM systems and IPv6? In-Reply-To: <20100318054939.GA16423@redoubt.spodhuis.org> References: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: <20100318080339.GB5509@kathy> On Wed, Mar 17, 2010 at 10:49:40PM -0700, Phil Pennock wrote: > Folks, > > How common is it these days to have people using Windows under VMs? > > How common is it for VM virtual bridges to somehow be breaking IPv6? We have a Debian based kvm environment here and so far no issues with native IPv6. But I can only say that for Debian/Linux guests since we don't have any other OSes. Cheers, j. -- j.hofm?ller http://users.mur.at/thesix/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100318/342f1d30/attachment.bin From phrickman at upcbroadband.com Thu Mar 18 10:02:58 2010 From: phrickman at upcbroadband.com (Rickman, Phil) Date: Thu, 18 Mar 2010 10:02:58 +0100 Subject: VM systems and IPv6? In-Reply-To: <20100318054939.GA16423@redoubt.spodhuis.org> References: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: Phil, we use it in testing on VMware and have no problems with it so far for customer simulation. Phil ________________________________________ From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of Phil Pennock [ipv6-ops+phil at spodhuis.org] Sent: 18 March 2010 06:49 To: ipv6-ops at lists.cluenet.de Subject: VM systems and IPv6? Folks, How common is it these days to have people using Windows under VMs? How common is it for VM virtual bridges to somehow be breaking IPv6? I see another source of some of the broken machines in the stats that various people have published ... I've not previously played with VMs (I'm a latecomer). Playing with Parallels 5 on a Mac, I couldn't get FreeBSD able to route out, looks like NDP announcements weren't making it out, so packets weren't returning so the router wasn't able to send packets back to the VM dom. I could only ping the dom0 and vice-versa. So I brought up a Debian VM, same problem. Interface configures up, gets a default route pointing to the router (Apple Airport) on link-local. I ping ipv6.google.com, see neighbour solicitations for the gateway address but no response. This is from { tcpdump -vvvnpi eth0 -s1500 ip6 } (after ssh'ing back in on explicitly IPv4 to avoid the loop of output-generating-packets, oops). If I ping the fe80:: address of the router itself then: from dom0 I get a response, so the gateway isn't filtering and in the VM; when I try from the VM, I again see neighbour solicitation go out, this time I also see neighbour solicitations from the router for the VM's address (progress!) , then I see the VM send a solicited neighbour advertisement but then nothing. VM eth0 (Debian 5.0): 2001:470:1f05:456:24a:5bff:fe9b:355c fe80::24a:5bff:fe9b:355c dom0 IF is en1: 2001:470:1f05:456:5ab0:35ff:fe60:52b6 fe80::5ab0:35ff:fe60:52b6 Gateway is: 2001:470:1f05:456:fa1e:dfff:fef7:86a0 fe80::fa1e:dfff:fef7:86a0 [ set as default route on hosts ] ----------------------------8< cut here >8------------------------------ 22:06:05.560193 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) fe80::24a:5bff:fe9b:355c > fe80::fa1e:dfff:fef7:86a0: [icmp6 sum ok] ICMP6, echo request, length 64, seq 1 22:06:05.565442 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::fa1e:dfff:fef7:86a0 > ff02::1:ff9b:355c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::24a:5bff:fe9b:355c source link-address option (1), length 8 (1): f8:1e:df:f7:86:a0 0x0000: f81e dff7 86a0 22:06:05.565514 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::24a:5bff:fe9b:355c > fe80::fa1e:dfff:fef7:86a0: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::24a:5bff:fe9b:355c, Flags [solicited, override] destination link-address option (2), length 8 (1): 00:4a:5b:9b:35:5c 0x0000: 004a 5b9b 355c 22:06:06.573865 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) fe80::24a:5bff:fe9b:355c > fe80::fa1e:dfff:fef7:86a0: [icmp6 sum ok] ICMP6, echo request, length 64, seq 2 ----------------------------8< cut here >8------------------------------ tcpdump from the dom0 is not more informative. It really looks as though neighbour solicitations are not making it across, which begs the question of how did the VM get its address configured up in the first place. Anyone have any better thoughts? Am I going to say "doh"? Which returns to my second question. Are there VM environments that do work with IPv6? Thanks, -Phil From hahn at berkom.de Thu Mar 18 10:39:51 2010 From: hahn at berkom.de (Christian Hahn) Date: Thu, 18 Mar 2010 10:39:51 +0100 Subject: VM systems and IPv6? In-Reply-To: References: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: <4BA1F4E7.3000509@berkom.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 18.03.2010 06:53, schrieb Antonio Querubin: > On Wed, 17 Mar 2010, Phil Pennock wrote: > >> How common is it these days to have people using Windows under VMs? >> >> How common is it for VM virtual bridges to somehow be breaking IPv6? > > OpenVZ containers using the veth device for bridging between host and > containers works fine with IPv6. I can confirm this, although I only have experiences with Debian VMs on a Debian Host. What also works are Xen VMs (CentOS) with vifs and xenbr interfaces. cheers, Christian > > Antonio Querubin > 808-545-5282 x3003 > e-mail/xmpp: tony at lava.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuh9OYACgkQ6kMW7HW86223ogCeOjx/yDqqf4UGilFMFdKh8d+b L4kAniswwPH3AsAC6qWgQNSexfAGuwaA =+16R -----END PGP SIGNATURE----- From mohacsi at niif.hu Thu Mar 18 11:07:31 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 18 Mar 2010 11:07:31 +0100 (CET) Subject: VM systems and IPv6? In-Reply-To: <20100318054939.GA16423@redoubt.spodhuis.org> References: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: On Wed, 17 Mar 2010, Phil Pennock wrote: > Folks, > > How common is it these days to have people using Windows under VMs? > > How common is it for VM virtual bridges to somehow be breaking IPv6? > > I see another source of some of the broken machines in the stats that > various people have published ... > > I've not previously played with VMs (I'm a latecomer). Playing with > Parallels 5 on a Mac, I couldn't get FreeBSD able to route out, looks > like NDP announcements weren't making it out, so packets weren't > returning so the router wasn't able to send packets back to the VM dom. > I could only ping the dom0 and vice-versa. > > So I brought up a Debian VM, same problem. Probably it a Parallels specific problem. We are using Xen and VMWare VM with IPv6 without the problem (VMware 2 had similar problem 5 years ago) Report to Parallels. Best Regards, Janos From garry at nethinks.com Thu Mar 18 11:48:37 2010 From: garry at nethinks.com (Garry Glendown) Date: Thu, 18 Mar 2010 11:48:37 +0100 Subject: VM systems and IPv6? In-Reply-To: <20100318054939.GA16423@redoubt.spodhuis.org> References: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: <4BA20505.3060108@nethinks.com> On 18.03.2010 06:49, Phil Pennock wrote: > Which returns to my second question. Are there VM environments that do > work with IPv6? > v6 works fine for me with Xen Server ... running Debian in the VMs ... built a combined v4/v6 gateway/firewall VM that controls traffic flows, and multiple VMs on the inside... -garry From pete at twisted.org.uk Thu Mar 18 12:02:33 2010 From: pete at twisted.org.uk (Pete French) Date: Thu, 18 Mar 2010 11:02:33 +0000 Subject: VM systems and IPv6? In-Reply-To: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: > Which returns to my second question. Are there VM environments that do > work with IPv6? I'm successfully using VirtualBox running on FreeBSD to support a number of virtual Windows platforms, all with work IPv6 (main XP64, but one XP32 machine, and we have also tried Windows 7). As other people have said, however, bridged mode is required for all these things. -pete. From me at benedikt-stockebrand.de Thu Mar 18 12:02:43 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Thu, 18 Mar 2010 11:02:43 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100316191404.GI69383@Space.Net> (Gert Doering's message of "Tue, 16 Mar 2010 20:14:04 +0100") References: <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> Message-ID: Hi Gert and list, Gert Doering writes: >> ok, just to rephrase my original question: If you connect to the >> Internet via an IPv4-only ISP (rather than one that offers native >> IPv6) and then alternatively use native IPv4 and 6to4 to access a site >> serving both, do you still notice a difference in latency? > > I'm pretty sure that I will. That was the initial starter for this > thread - 6to4 is usually worse than native IPv4, and is causing real > problems. > > Which is why it is fortunate that all the (recent?) Windows versions do > the right thing, and prefer native IPv4 before 6to4 and Teredo - so > for connecting to a dual-stacked hosts, 6to4 latency is irrelevant. we're still talking different things here: If you are on the *customer* side and connecting to a dual-stacked host when you are using 6to4 yourself, then you do see the difference. >> Because its "kewl" and/or they want to see if it actually works. > > We know that IPv6 works. Since about 10 years. Well, six or seven years ago I first had to tell people how to recompile a kernel on Linux, download some extra software for XP or update their IOS. Then it was time to recompile Ssh with the proper compile time options, the then-standard Apache 1 didn't support IPv6 except through patches, you had to use a beta version of the UDel(?) NTPD and the Linux people were stuck without an IPv6-capable syslogd. As far as the network layer goes, yes, IPv6 worked then. But it has only become usable with Vista (which was unusable in many other ways) or Win7, with more up-to-date Linux distributions and whatever else on the client side. And considering the problems relating to RFC 3484 alone there is still some way to go. > The time for testing in "kewl circles" is long over - now we need to > do production tests, and then production *roll-out*. The "kewl" people are not the ones who do testing but the ones who believe and tell everybody that they understand computers:-) What we need are those enthusiasts spending 500Euro for a new graphics card, tinker with absolutely everything they find and are generally a major pain in the rear side for everybody else---but are still asked for computer-related by their friends and family. We don't need them for testing but for marketing IPv6. I don't like this situation either, but we better face it. >> Additionally, for internal purposes when you migrate a company or >> government agency network or such it lets you work around a number of >> problems during the transition period. > > By replacing them with much larger problems, like "all of the absolute > URLs that your sites might use for links will no longer work" - ask the > heise people what fun they had with www.six.heise.de - they had to > setup a special proxy that rewrites the HTML pages in-flight to get > the URLs fixed. Agreed, when we're talking web servers and URIs that's not the very best move. But I was actually thinking more along the lines of DNS, NTP, CIFS/SMB, NFS, SMTP, POP3/IMAP and such. >> I was more thinking along the line > [..] >> Help desk: Ok, that should be an IPv6 address. I'll check with >> the network administrators if they did anything. >> >> End user: Whatever this "IPv6" is---turn it off, I want to >> work/play/whatever. > > OK, I can see your point. I'm afraid you don't: > And it has been mentioned before: the support people need to be > trained. They must not be spooked by IPv6 addresses, and they need > to know that they should not spook the customers. As I pointed out a few minutes ago in reply to Janos, the key point is that IPv6 will expose hidden problems with existing setups and as such will be *perceived* as the actual problem. It is not what factually *is* the problem, but what is *perceived* by the customer as the problem that matters when it comes to accepting IPv6. ISPs who have already provided their customers with IPv6 for some time don't have that problem because the actual root causes never had a chance to develop, but that doesn't help those who only now start to get into IPv6 deployment right now. > Well, fortunately, multiple layers of NAT are still the exception - > so the deployer of the NAT is still in control regarding port > forwardings and so on. As far as I can tell that largely depends on which part of the world you're living in. It's a shame you haven't been in Potsdam two years ago, there was a Korean colleague there who could tell you more about the problems running large NAT gateways at the ISP side than you wanted to hear about. And we're facing pretty much the same situation with 3G/UMTS even here. > With multiple layers of NAT, you will have to request port forwardings > from your ISP (and likely charge a monthly fee per port...) - goodbye > to anything that is not "consumer only". This is a bit of a tangent, but: You can already run into this kind of limitation with the "right" kind of CPE router. > For the smaller ISPs, you can do it more gradually, and that way there > already is some experience regarding IPv6 deployment out there... If I was still with a larger ISP I'd spend some really serious thinking on how to do a gradual rollout, too. As far as I can tell it is possible even at a larger scale, but you can't do it on short notice. > Smaller ISPs don't do this "we must not do a single change to our IT > infrastructure thing!!!!" that large enterprises and govt. agencies > are so good at :-) - so for us, IPv6 roll-out for our own infrastructure > and servers goes hand in hand with the continuous change that we > experience all the time anyway. Larger ISPs at least used to work much like that internally, but as soon as customers are affected this becomes rather troublesome. Still, my point was on IPv6 deployment in an enterprise. Just recently I got a training request from a customer with such an enterprise. Just to give an idea of the numbers: 3 data centers, 150 locations, 40 000 employees. I don't have the number of desktop and notebook PCs, but you may well assume in that case that just about every employee has at least one computer. In another case I had participants in a training who were dealing with 8000 locations. And these are still small compared to the major banks here in Frankfurt. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From md at Linux.IT Thu Mar 18 12:28:40 2010 From: md at Linux.IT (Marco d'Itri) Date: Thu, 18 Mar 2010 12:28:40 +0100 Subject: VM systems and IPv6? In-Reply-To: <20100318071904.GZ69383@Space.Net> References: <20100318054939.GA16423@redoubt.spodhuis.org> <20100318071904.GZ69383@Space.Net> Message-ID: <20100318112840.GA5509@bongo.bofh.it> On Mar 18, Gert Doering wrote: > There's a caveat: if you enable TCP offloading in Linux VMs, the IPv6 > TCP performance will be abysmal. Can you tell us more? Which virtualization solution are you talking about, and which kind of network setup? Is this a documented bug? -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100318/4d5dda58/attachment.bin From ipv6-ops at c0mplx.org Thu Mar 18 12:29:03 2010 From: ipv6-ops at c0mplx.org (Kurt Jaeger) Date: Thu, 18 Mar 2010 12:29:03 +0100 Subject: VM systems and IPv6? In-Reply-To: References: <20100318054939.GA16423@redoubt.spodhuis.org> Message-ID: <20100318112903.GS2911@home.opsec.eu> Hi! > > Which returns to my second question. Are there VM environments that do > > work with IPv6? FreeBSD Jails work with IPv6. -- pi at opsec.eu +49 171 3101372 10 years to go ! From gert at space.net Thu Mar 18 12:30:10 2010 From: gert at space.net (Gert Doering) Date: Thu, 18 Mar 2010 12:30:10 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> Message-ID: <20100318113010.GL69383@Space.Net> Hi, On Thu, Mar 18, 2010 at 11:02:43AM +0000, Benedikt Stockebrand wrote: > >> ok, just to rephrase my original question: If you connect to the > >> Internet via an IPv4-only ISP (rather than one that offers native > >> IPv6) and then alternatively use native IPv4 and 6to4 to access a site > >> serving both, do you still notice a difference in latency? > > > > I'm pretty sure that I will. That was the initial starter for this > > thread - 6to4 is usually worse than native IPv4, and is causing real > > problems. > > > > Which is why it is fortunate that all the (recent?) Windows versions do > > the right thing, and prefer native IPv4 before 6to4 and Teredo - so > > for connecting to a dual-stacked hosts, 6to4 latency is irrelevant. > > we're still talking different things here: If you are on the > *customer* side and connecting to a dual-stacked host when you are > using 6to4 yourself, then you do see the difference. If you connect to a dual-stacked host, and your operating system is behaving as Windows does (prefer native IPv6, but if that is not available, prefer IPv4 before 6to4 and Teredo), your client will not use 6to4. So where should the difference come from? (If you connect to an IPv6-*only* host, of course it will have to use 6to4, and that might be lots slower than the IPv4 path, but then, there for an IPv6-only host there is no v4 path to start with). We are talking about the same thing, but you are ignoring the default precedence tables in current Windows versions :-) > >> Because its "kewl" and/or they want to see if it actually works. > > > > We know that IPv6 works. Since about 10 years. > > Well, six or seven years ago I first had to tell people how to > recompile a kernel on Linux, download some extra software for XP or [..] Yes, I agree. The client and application side has become much less painful, and much more automatic in regard to IPv6. And of course, things still break - which why it is so important to start now (well, "to have started 5 years ago") to be ready in time. [..] > What we need are those enthusiasts spending 500Euro for a new graphics > card, tinker with absolutely everything they find and are generally a > major pain in the rear side for everybody else---but are still asked > for computer-related by their friends and family. > > We don't need them for testing but for marketing IPv6. "Roll out IPv6, make 'the ping' slower for IPv4 than for IPv6, that will get their attention" :-) Latency *does* matter! [..] > > By replacing them with much larger problems, like "all of the absolute > > URLs that your sites might use for links will no longer work" - ask the > > heise people what fun they had with www.six.heise.de - they had to > > setup a special proxy that rewrites the HTML pages in-flight to get > > the URLs fixed. > > Agreed, when we're talking web servers and URIs that's not the very > best move. But I was actually thinking more along the lines of DNS, > NTP, CIFS/SMB, NFS, SMTP, POP3/IMAP and such. I've run my machines dual-stacked with a single DNS name for dunno how many years, and all these services just work in a mixed v4/v6 environment - older clients generally use v4-only, newer clients try both and fall back to v4 if v6 doesn't work. Of course there are broken clients, and broken servers, but if you do things like "ntp.ipv6.my.domain" and then don't advertise it, you're just hiding the problem - it won't go away, just by pretending to the broken client that IPv6 doesn't exist. [ Alternatives to IPv6 ] > > Well, fortunately, multiple layers of NAT are still the exception - > > so the deployer of the NAT is still in control regarding port > > forwardings and so on. > > As far as I can tell that largely depends on which part of the world > you're living in. > > It's a shame you haven't been in Potsdam two years ago, there was a > Korean colleague there who could tell you more about the problems > running large NAT gateways at the ISP side than you wanted to hear > about. I've seen the newly-presented Cisco NAT Services card, and have a vague idea what the list price might be for something that holds 20 million nat table entries... > And we're facing pretty much the same situation with 3G/UMTS even > here. Yes. But if you remember last year's IPv6 conference, at least Vodafone has seen the light regarding UMTS and packet clients. [..] > Still, my point was on IPv6 deployment in an enterprise. Just > recently I got a training request from a customer with such an > enterprise. Just to give an idea of the numbers: 3 data centers, 150 > locations, 40 000 employees. I don't have the number of desktop and > notebook PCs, but you may well assume in that case that just about > every employee has at least one computer. In another case I had > participants in a training who were dealing with 8000 locations. These enterprises are the ones that will be in for a nasty surprise when they roll out Win7 or Server2008R2, and all of a sudden they have uncontrolled IPv6 all over the place. So it's quite important that they understand what is coming up, and get prepared. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100318/2a74e440/attachment.bin From gert at space.net Thu Mar 18 12:43:57 2010 From: gert at space.net (Gert Doering) Date: Thu, 18 Mar 2010 12:43:57 +0100 Subject: VM systems and IPv6? In-Reply-To: <20100318112840.GA5509@bongo.bofh.it> References: <20100318054939.GA16423@redoubt.spodhuis.org> <20100318071904.GZ69383@Space.Net> <20100318112840.GA5509@bongo.bofh.it> Message-ID: <20100318114357.GP69383@Space.Net> Hi, On Thu, Mar 18, 2010 at 12:28:40PM +0100, Marco d'Itri wrote: > On Mar 18, Gert Doering wrote: > > > There's a caveat: if you enable TCP offloading in Linux VMs, the IPv6 > > TCP performance will be abysmal. > Can you tell us more? Which virtualization solution are you talking > about, and which kind of network setup? >From the part that you didn't quote: VMware ESX. I'm not sure ESX can do anything but "virtual switches" - so that's what we using: external links to the host are tagged, and the ESX switch distributes the "right" VLAN to each VM. > Is this a documented bug? It is at least a known bug - googling finds lots of hits for "slow performance with IPv6 in VMware". The recommended solution is usually "do not install VMware-tools" - and that works, but that's just side effect. Installing VMware-tools will install a RC startup script that will always turn on TCP offloading, and *that* is the root-cause, not the vmware-tools itself. So "with VMware-tools, but without TCP offloading, things work" We have not reported it to VMware, as their official stance on IPv6 was "we do not support it yet" and we found a workaround. (Also it was not clear whether this is a VMware bug, or a Linux kernel bug in the driver for the virtual e1000). The virtual NIC we use on the system where I had the problem is: $ lspci -v ... 00:11.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: VMware Inc Abstract PRO/1000 MT Single Port Adapter Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 177 Memory at f4820000 (64-bit, non-prefetchable) [size=128K] Memory at f4800000 (64-bit, non-prefetchable) [size=64K] I/O ports at 1400 [size=64] [virtual] Expansion ROM at 88000000 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device As I said - we found a workaround, and had other things to break & fix... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 bjorn at mork.no Thu Mar 18 14:13:01 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 18 Mar 2010 14:13:01 +0100 Subject: VM systems and IPv6? In-Reply-To: <20100318080339.GB5509@kathy> ("Jogi =?utf-8?Q?Hofm=C3=BCller?= =?utf-8?Q?=22's?= message of "Thu, 18 Mar 2010 09:03:39 +0100") References: <20100318054939.GA16423@redoubt.spodhuis.org> <20100318080339.GB5509@kathy> Message-ID: <87ljdp6aea.fsf@nemi.mork.no> Jogi Hofm?ller writes: > On Wed, Mar 17, 2010 at 10:49:40PM -0700, Phil Pennock wrote: >> Folks, >> >> How common is it these days to have people using Windows under VMs? >> >> How common is it for VM virtual bridges to somehow be breaking IPv6? > > We have a Debian based kvm environment here and so far no issues with > native IPv6. But I can only say that for Debian/Linux guests since we > don't have any other OSes. I've been running Olive's (no they don't exist :-), Debian (both Linux and kFreeBSD based), Juniper SRC (yes, I know that's an appliance - but it's also a Centos-based OS) and assorted Windows versions, all of which have been doing IPv6 just fine on KVM using VDE as a bridge. Under Debian as host system, not that I see how that matters. What probably does matter is: - which virtualisation tech (kvm, vmware, xen, other)? - how do you brigde between them (VDE, Linux bridged tun/tap, openvswitch, other) - guest OS As I said, I have good experience using VDE, including bridging tap connected VDE ports with real ethernet ports. But I haven't explored the more fancy IPv6 related switch features like MLD snooping etc. I assume that is not supported. For the future, Open vSwitch (http://openvswitch.org/) is probably the way to go But anyway, I cannot see any reason to expect virtual switches to be more broken than hardware. Go look at low end consumer hardware, like the switches which are thrown into every CPE, wireless router or whatever, and you'll find a new dimension of brokenness... *That's* what breaks most clients, not virtual switches. Bj?rn From tedm at ipinc.net Thu Mar 18 19:48:11 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 18 Mar 2010 11:48:11 -0700 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: References: <317616CE96204D49B5A1811098BA89500113466F@XMB-AMS-110.cisco.com> <4BA11CC7.4000107@venaas.com> <4BA125B2.3010809@ipinc.net> <20100317193603.GQ2911@home.opsec.eu> <4BA13B16.8030307@ipinc.net> Message-ID: <4BA2756B.1050809@ipinc.net> nick hatch wrote: > On Wed, Mar 17, 2010 at 1:27 PM, Ted Mittelstaedt wrote: >> OK, I see, however from a users perspective I actually like this, because it discourages content providers from sticking in a bunch of >> extra advertisements and such that crap up their site. >> >> I still maintain, though, that for 90% of the machines out there, the browser rendering engine is a far larger contributor to "unsnappy" >> websites. Based on our customer feedback most people have older systems or newer systems that are crapped-up with adware. > > Yes, the rendering engine can be a bottleneck in performance. However, > this bottleneck is influenced by how the website is authored: Download > latency, for example, can affect the DOM, which affects the rendering > engine, which affects speed. The Webkit blog has a great post with > more details [1]: > > "Introducing just 50ms of additional latency doubled the page loading > time in the high bandwidth case (from ~3200ms to ~6300ms)." > > I strongly disagree that junky PCs are the limiting factor for 90% of > people, but don't have empirical data to back it up. In any case, what > you're describing is the lower-bound for website performance. > Most of the PCs people buy out there (for personal use) are cheap and the manufacturers make them cheap by reducing disk space and ram. > Website designers can't change several of those factors, and > "advertisements and such that crap up their site" isn't the biggest > problem. Hello? You just lost a lot of your credibility there. How have many of the viruses spread lately? Not by infecting the primary sites - by infecting the advertising providers webservers. Many times I've had to deal with advertisements that will throw popups up that cover the primary site, or that cause the browser to crash or act really slow. It sounds to me like you don't do a lot of web surfing if your going to minimize the role that advertisements play in degrading the web experience of a site. > Designers are focused on the upper-bound of performance, > which improves things for everyone. > SOME are. The vast majority are not - they are focused on producing slick-looking sites to justify the money they are charging their clients - most of whom don't understand what good web design is, and just want something that "looks cool" I agree the designers on staff of the large content providers - employees that is - are probably more focused on the upper bound of performance. But that is not the majority of sites on the Internet nor the majority of web designers who have created them. > Yahoo has a great introduction to the topic [2]. Note they don't say > "reduce complexity" or "don't use ads", or "code for crap computers!" > but rather, "reduce the number of http requests". > Since the adverts are served from different servers each one of them you put on a site creates more http requests from the client, so it's pretty obvious what they are recommending. And more and more adverts now have multiple elements in them. When a site carries adverts it's basically handing off a lot of screen realestate to some other web designer, who is probably NOT going to be following good design practices. >> The google toolbar alone ads an extra 2-3 seconds for most systems, > I've never seen performance issues like this with the Google toolbar, It takes ram and on a machine that's ram-shy, and swapping already, and running a winmodem, then yes it does worsen the performance. It's only been in the last 2 years that systems were regularly sold with more than a gig of ram. Walk into a computer store sometime and chat them up. Ram and disk upgrades are the most popular sellers - those are going to at least the clueful people. But many are not clueful and just live with it. I still regularly see people running XP & IE8 on 512MB ram systems. I'm typing this message on a 1GB of ram system, as a matter of fact. > ever. As stated earlier, Google hates the slow web, and has data to > back up why. [3] Does it really make sense to you that Google would > release a tool that slows down the web that much? > Google is making the assumption I talked about earlier which is that everyone has a reasonably fast machine with lots of ram. >>> There's a cute tool which allowes one to test it: >>> >>> http://www.alphaworks.ibm.com/tech/pagedetailer >>> >>> "A graphical tool that enables Web content providers to rapidly and >>> accurately measure client side performance of Web pages." >>> >> Cute too, I wonder how many content providers actually read the >> advice in the help to put their sites on a diet. > > These tools aren't cute, they're very useful, and common: > I was meaning cute as in pretty, not as in toy-like. I thought it was a neat piece of software. > http://code.google.com/speed/page-speed/ > http://developer.yahoo.com/yslow/ > > Good web developers don't talk about "putting sites on diets", they > talk about progressive enhancement, caching, compression, CSS sprites, > Javascript include order, etc. This topic is well studied from just > about every angle, and is empirical for obvious reasons. > Most of those things are just palliatives to try to get a too-fat site with a bunch of worthless eye candy that does not convey information to run acceptably. And they only work when the system the site is being displayed on is running modern software and a fast CPU and has a decent amount of ram since they push more of the processing onto the browser. And yet meanwhile, technologies like scalable vector graphics which would be really useful, are put on the back burner and keep getting delayed. That ought to tell you plenty as to what's important to the content community. The state today of current web design is to continue to make sites appear slicker and slicker with more and more eye-catching candy that does nothing to add to the usable information content being transmitted. It's a consequence of letting all the commercial entities on the web who are competing with each other, and putting a lot of inexperienced users who don't have a lot of surfing under their belt. And yet when you go to the forums that collect experienced web surfers and read them, they are full of posts on how to obtain different bits of software to BLOCK the eye candy. If that does not adequately illustrate the disconnect between most web designers and most experienced web surfers, I don't know what does. > Getting back to IPv6: Poorly performing transition mechanisms can > affect user experience in serious ways. > If the content providers are that concerned with this they need to be pressuring the ISP's they buy service from for native IPv6, simple as that. Those ISPs are the same ISPs supplying connectivity to those end users. Rather than taking the retrograde tack and arguing that since an IPv6 transition mechanism is slow that it should be scrapped and go back to IPv4, they need to be applauding and encouraging the transition mechanisms and if users complain, then point them to the real culprits - the ISPs they are buying service from who are NOT running native IPv6. Ted > -Nick > > [1] http://webkit.org/blog/166/optimizing-page-loading-in-web-browser/ > [2] http://developer.yahoo.com/performance/rules.html > [3] http://code.google.com/speed/ > From ipv6-ops at netsecs.us Thu Mar 18 20:29:57 2010 From: ipv6-ops at netsecs.us (Mia Sechez) Date: Thu, 18 Mar 2010 14:29:57 -0500 (EST) Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: <4BA2756B.1050809@ipinc.net> References: <317616CE96204D49B5A1811098BA89500113466F@XMB-AMS-110.cisco.com> <4BA11CC7.4000107@venaas.com> <4BA125B2.3010809@ipinc.net> <20100317193603.GQ2911@home.opsec.eu> <4BA13B16.8030307@ipinc.net> <4BA2756B.1050809@ipinc.net> Message-ID: On Thu, 18 Mar 2010, Ted Mittelstaedt wrote: > Hello? You just lost a lot of your credibility there. How have many > of the viruses spread lately? Not by infecting the primary sites - > by infecting the advertising providers webservers. Many times I've > had to deal with advertisements that will throw popups up that cover > the primary site, or that cause the browser to crash or act really slow. > > It sounds to me like you don't do a lot of web surfing if your going to > minimize the role that advertisements play in degrading the web experience of > a site. I never have this problem. Firefox with No-Script and Ad-Block extensions solved the problem neatly. Before denigrating someone's credibility, maybe you should evaluate your own configurations. From tedm at ipinc.net Thu Mar 18 20:02:47 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 18 Mar 2010 12:02:47 -0700 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100318113010.GL69383@Space.Net> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> Message-ID: <4BA278D7.40206@ipinc.net> Gert Doering wrote: > Hi, > > On Thu, Mar 18, 2010 at 11:02:43AM +0000, Benedikt Stockebrand wrote: >>>> ok, just to rephrase my original question: If you connect to the >>>> Internet via an IPv4-only ISP (rather than one that offers native >>>> IPv6) and then alternatively use native IPv4 and 6to4 to access a site >>>> serving both, do you still notice a difference in latency? >>> I'm pretty sure that I will. That was the initial starter for this >>> thread - 6to4 is usually worse than native IPv4, and is causing real >>> problems. >>> >>> Which is why it is fortunate that all the (recent?) Windows versions do >>> the right thing, and prefer native IPv4 before 6to4 and Teredo - so >>> for connecting to a dual-stacked hosts, 6to4 latency is irrelevant. >> we're still talking different things here: If you are on the >> *customer* side and connecting to a dual-stacked host when you are >> using 6to4 yourself, then you do see the difference. > > If you connect to a dual-stacked host, and your operating system is > behaving as Windows does (prefer native IPv6, but if that is not available, > prefer IPv4 before 6to4 and Teredo), your client will not use 6to4. > > So where should the difference come from? > > (If you connect to an IPv6-*only* host, of course it will have to use > 6to4, and that might be lots slower than the IPv4 path, but then, there > for an IPv6-only host there is no v4 path to start with). > > We are talking about the same thing, but you are ignoring the default > precedence tables in current Windows versions :-) > > >>>> Because its "kewl" and/or they want to see if it actually works. >>> We know that IPv6 works. Since about 10 years. >> Well, six or seven years ago I first had to tell people how to >> recompile a kernel on Linux, download some extra software for XP or > [..] > > Yes, I agree. The client and application side has become much less > painful, and much more automatic in regard to IPv6. > > And of course, things still break - which why it is so important to > start now (well, "to have started 5 years ago") to be ready in time. > > [..] >> What we need are those enthusiasts spending 500Euro for a new graphics >> card, tinker with absolutely everything they find and are generally a >> major pain in the rear side for everybody else---but are still asked >> for computer-related by their friends and family. >> >> We don't need them for testing but for marketing IPv6. > > "Roll out IPv6, make 'the ping' slower for IPv4 than for IPv6, that > will get their attention" :-) > > Latency *does* matter! > > [..] >>> By replacing them with much larger problems, like "all of the absolute >>> URLs that your sites might use for links will no longer work" - ask the >>> heise people what fun they had with www.six.heise.de - they had to >>> setup a special proxy that rewrites the HTML pages in-flight to get >>> the URLs fixed. >> Agreed, when we're talking web servers and URIs that's not the very >> best move. But I was actually thinking more along the lines of DNS, >> NTP, CIFS/SMB, NFS, SMTP, POP3/IMAP and such. > > I've run my machines dual-stacked with a single DNS name for dunno > how many years, and all these services just work in a mixed v4/v6 > environment - older clients generally use v4-only, newer clients try > both and fall back to v4 if v6 doesn't work. > > Of course there are broken clients, and broken servers, but if you > do things like "ntp.ipv6.my.domain" and then don't advertise it, you're > just hiding the problem - it won't go away, just by pretending to the > broken client that IPv6 doesn't exist. > > [ Alternatives to IPv6 ] > >>> Well, fortunately, multiple layers of NAT are still the exception - >>> so the deployer of the NAT is still in control regarding port >>> forwardings and so on. >> As far as I can tell that largely depends on which part of the world >> you're living in. >> >> It's a shame you haven't been in Potsdam two years ago, there was a >> Korean colleague there who could tell you more about the problems >> running large NAT gateways at the ISP side than you wanted to hear >> about. > > I've seen the newly-presented Cisco NAT Services card, and have a vague > idea what the list price might be for something that holds 20 million > nat table entries... > > >> And we're facing pretty much the same situation with 3G/UMTS even >> here. > > Yes. But if you remember last year's IPv6 conference, at least Vodafone > has seen the light regarding UMTS and packet clients. > > > [..] >> Still, my point was on IPv6 deployment in an enterprise. Just >> recently I got a training request from a customer with such an >> enterprise. Just to give an idea of the numbers: 3 data centers, 150 >> locations, 40 000 employees. I don't have the number of desktop and >> notebook PCs, but you may well assume in that case that just about >> every employee has at least one computer. In another case I had >> participants in a training who were dealing with 8000 locations. > > These enterprises are the ones that will be in for a nasty surprise > when they roll out Win7 or Server2008R2, and all of a sudden they have > uncontrolled IPv6 all over the place. So it's quite important that they > understand what is coming up, and get prepared. > Since those orgs use prebuilt images when rolling that stuff out, they always have the ability to disable IPv6 in the image then roll it out and that is likely what they will be doing. It's really going to be the midsize orgs not enterprise who will be most affected because they tend to not do forklift rollouts of machines across the enterprise, but instead move machines around between people and buy the machines one at a time as they need them and do not use prebuilt images, they just use the load that comes on the system. They are bringing win7 into the network now and mixing it with XP and some small amount of Vista. Ted From me at benedikt-stockebrand.de Thu Mar 18 21:49:23 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Thu, 18 Mar 2010 20:49:23 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100318113010.GL69383@Space.Net> (Gert Doering's message of "Thu, 18 Mar 2010 12:30:10 +0100") References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> Message-ID: Hi Gert and list, Gert Doering writes: > If you connect to a dual-stacked host, and your operating system is > behaving as Windows does (prefer native IPv6, but if that is not available, > prefer IPv4 before 6to4 and Teredo), your client will not use 6to4. ok, you know I'm more of a Unixer. This approach appears quite reasonable but either I misinterpret RFC 3484 or it is a Windows-specific arrangement. >> What we need are those enthusiasts spending 500Euro for a new graphics >> card, tinker with absolutely everything they find and are generally a >> major pain in the rear side for everybody else---but are still asked >> for computer-related by their friends and family. >> >> We don't need them for testing but for marketing IPv6. > > "Roll out IPv6, make 'the ping' slower for IPv4 than for IPv6, that > will get their attention" :-) > > Latency *does* matter! Sure does:-) Just don't overdo it: Forcing things this way may actually open another can of worms, concerning net neutrality (in whatever broad definition of the term) and whatever else. From a business perspective, artificially lowering the quality of your service doesn't sound too good either, simply because you give an advantage to those of competitors who don't do this. In the long run the extra latency caused by bloated routing tables and NAT in a low-power CPE router should generally make this happen anyway. > I've run my machines dual-stacked with a single DNS name for dunno > how many years, and all these services just work in a mixed v4/v6 > environment - older clients generally use v4-only, newer clients try > both and fall back to v4 if v6 doesn't work. > > Of course there are broken clients, and broken servers, but if you > do things like "ntp.ipv6.my.domain" and then don't advertise it, you're > just hiding the problem - it won't go away, just by pretending to the > broken client that IPv6 doesn't exist. I'm by no means suggesting this as a permanent approach. It is an intermediate setup during migration/deployment in scenarios where everything is currently v4only and v6 is about to get deployed one way or another. Using this temporary naming scheme helps to do a finely controlled gradual move. In the long run, if there are any legacy systems too broken to be fixed, too unique to be replaced by anything else and too important to be kicked out, using the same approach the other way round can also be helpful, using e.g. A+AAAA for nfs0.example.com. and A-only for nfs0.v4.example.com. And another one for migration scenarios: Especially if you have significant numbers of dual-stacked machines and system/network admins who haven't had much chance to gather experience with IPv6, I found it quite helpful to have the PTR records return a name that uniquely identifies if the address is IPv4 or IPv6. This is particularly helpful with applications that log that name to their log files rather than the IP address, but also helps people new to IPv6 when troubleshooting. Just make sure that you don't mess up the "authentication" mechanisms that use the reverse DNS entry of the address they see (like Solaris NFS). > I've seen the newly-presented Cisco NAT Services card, and have a vague > idea what the list price might be for something that holds 20 million > nat table entries... And they don't even tell you the cost to keep that sort of equipment up and running, or the "opportunity costs" these boxes generate when they cause problems noticeable to the user base. >> And we're facing pretty much the same situation with 3G/UMTS even >> here. > > Yes. But if you remember last year's IPv6 conference, at least Vodafone > has seen the light regarding UMTS and packet clients. Must have been while I held the tutorial. And the 3G/UMTS providers actually have a huge advantage over Korean ISPs: You can't really do 100 Mbit/s over 3G/UMTS, so the amount of traffic going through the NAT gateways of 3G/UMTS providers is way less than what the Koreans experience in their fiber networks. To my understanding, just rebooting a large, non-redundant NAT gateway is simply disastrous from an economical point of view---it'll cause an immediate meltdown in your call center. Setting up these boxes fully redundantly is the only option, but but then the synchronization traffic between them can be rather troublesome by itself. No matter what, these "solutions" are ugly at best. > These enterprises are the ones that will be in for a nasty surprise > when they roll out Win7 or Server2008R2, and all of a sudden they have > uncontrolled IPv6 all over the place. So it's quite important that they > understand what is coming up, and get prepared. Right. But what could they have done so far? With Vista being generally considered unfit for enterprise use, they have been stuck with XP until Win7 was released. Using IPv6 with XP is infeasible at least at a larger scale, so they were effectively stuck with IPv4, too. Now that Win7 is available they have to get all the software they use to work with Win7, and possibly even get it certified one way or another, before they can move on to Win7---and they have to do so before Microsoft stops providing security fixes for XP. That's their primary concern. Deploying IPv6 in "empty" networks that are then populated with Win7 in the next step adds some extra work that must be done before the XP deadline, so this is a risky (in the risk management sense) approach but also the one most rewarding if it succeeds. First deploying Win7 in an IPv4 environment, next setting up IPv6 and then finally moving Win7 to IPv6 on the other hand is a sure way to spend significant extra money, both on immediate expenses as well as those "opportunity costs" because of extra downtimes, but it is fairly low risk. Moving to Win7/IPv4 first, then setting up IPv6 and afterwards deferring the deployment of Windows to the IPv6 setup until the successor of Win7 becomes available is another alternative---quite likely the one a number of companies will choose. This is rather risky because they effectively bet their IT-related "competitiveness" (sorry about all those buzzwords, but they actually mean something in a business context, and these are arguments from the business perspective) on the hope that the successor of Win7 is both usable and available early enough they can get it up and running before IPv6 becomes relevant. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From tore.anderson at redpill-linpro.com Thu Mar 18 22:46:49 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 18 Mar 2010 22:46:49 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> Message-ID: <4BA29F49.6040307@redpill-linpro.com> Hi, * Benedikt Stockebrand > Gert Doering writes: > >> If you connect to a dual-stacked host, and your operating system is >> behaving as Windows does (prefer native IPv6, but if that is not >> available, prefer IPv4 before 6to4 and Teredo), your client will >> not use 6to4. > > ok, you know I'm more of a Unixer. This approach appears quite > reasonable but either I misinterpret RFC 3484 or it is a > Windows-specific arrangement. It is not a Windows-specific arrangement, it's implemented in getaddrinfo() at least in GNU libc, probably most other modern variants as well. This is because rule 4 of the destination address selection (chapter 6) comes into play, which says to prefer matching labels. A normal IPv6 address has a different label than a 6to4 address (the table is in chapter 2.1), so communication between two normal IPv4 addresses are preferred. However, if both the client and the server were to have 6to4-addresses, a 6to4-to-6to4 connection will be preferred over IPv4-to-IPv4, since now both the options have matching labels, but the 6to4 one wins because it has a higher sorting precedence. In my opinion, this is a bug in the RFC, but I don't think it has any significant operational impact. Another far more serious shortcoming of the RFC is that it does not take into account the prevalence of IPv4 NAT. RFC 1918 addresses are given the site-local scope, and rule 2 of the destination address selection algorithm says to prefer addresses with a matching scope. A 6to4 address is globally scoped like any other IPv6 address, so this means that 6to4 connections will be preferred over NAT-ed IPv4 connections from RFC 1918 prefix. This becomes a real problem if you for instance have a SOHO router that can do 6to4 tunneling from its WAN address and also send regular router advertisements on the LAN side, in addition to regular IPv4 NAT. The Apple Airport Extreme is one well-known example of such a device. I see quite a bit of breakage (lost clients that's using Mac OS X) towards my dualstack testing host due to this. Even though the behaviour is clearly problematic, it is a completely correct implementation of the RFC, as far as I can tell. Unfortunately. I've not really seen this behaviour from other operating systems though, perhaps other implementers have decided not to follow the RFC to the letter to avoid the problem, or it could simply be that it's really only Mac users that buy the Airport Extreme. I would have to look more into it to say for certain. BR, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From me at benedikt-stockebrand.de Thu Mar 18 22:48:56 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Thu, 18 Mar 2010 21:48:56 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA278D7.40206@ipinc.net> (Ted Mittelstaedt's message of "Thu, 18 Mar 2010 12:02:47 -0700") References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA278D7.40206@ipinc.net> Message-ID: Hi Ted and list, Ted Mittelstaedt writes: > Gert Doering wrote: >>[............................................................] >> These enterprises are the ones that will be in for a nasty surprise >> when they roll out Win7 or Server2008R2, and all of a sudden they have >> uncontrolled IPv6 all over the place. So it's quite important that they >> understand what is coming up, and get prepared. > > Since those orgs use prebuilt images when rolling that stuff out, they > always have the ability to disable IPv6 in the image then roll it out > and that is likely what they will be doing. First of all, they still have to know why and how to disable IPv6 reliably when they build these images. And "always" is a word always to be used with particular consideration:-) Enterprise wide deployment isn't as easy as you seem to think, at least with those enterprises I've seen so far. Have you ever been involved in such a project? We are easily talking about a time scale of two years here. Those two years are the key reason why these enterprises have to make up their mind about IPv6 right now: If they miss the rollout window created by Win7, doing a separate rollout for IPv6 involves really significant money, while waiting for Win8 plus the two years that rollout preparation takes may be disastrous---not to mention the chance that Win8 proves as troublesome as Vista. > It's really going to be the midsize orgs not enterprise who will be most > affected because they tend to not do forklift rollouts of machines > across the enterprise, but instead move machines around between people > and buy the machines one at a time as they need them and do not use > prebuilt images, they just use the load that comes on the system. > They are bringing win7 into the network now and mixing it with XP and > some small amount of Vista. While smaller companies do have a number of the problems you point out, in this case they have a rather significant advantage: When machines are replaced by a new one or re-installed with a new OS and/or application software one at a time, you can test them on the spot and fix problems one at a time rather than bringing major parts of your company to a grinding halt. Aside from that, even some of the "midsize" organizations I have encountered so far have long since learned to buy machines from vendors that provide proper end-of-life schedules and install them using an imaging tool. After all, they also go through that Windows upgrade routine every few years. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From me at benedikt-stockebrand.de Thu Mar 18 22:51:46 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Thu, 18 Mar 2010 21:51:46 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: (Mohacsi Janos's message of "Wed, 17 Mar 2010 09:29:00 +0100 (CET)") References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> Message-ID: Hi Janos (I suppose that's your first name?) and list, > then this provider did his jobs badly. They did not test when they > introduced ipv6. Plan, Train, Test in small, learn, train, pilot, > test, train, test, introduce. that doesn't solve the problem. Consider this example: A company has set up and installed a web server connected behind a dual-stack uplink. Between the web server and the CPE router towards their ISP they installed a packet filter configured to silently discard all IPv6 traffic from the Internet. The web server has both A and AAAA records in the DNS, possibly because it is accessible internally via IPv6 as well. The point here is that this setup is broken in a number of ways, but as long as the "road warriors" only have IPv4 access it still works fine. Now bring in your own reasoning: >> If IPv6 disrupts a business customer's business or an end user's >> entertainment, there is a good chance they pick up "IPv6" as the >> keyword to blame. It doesn't take actually understanding what IPv6 is >> to do so. > > They should blame the provider! Probably change to another ISP. As > they would change if IPv4 service is badly provided. As soon as you, as the ISP, enable IPv6 for your customers, from the customer's point of view you "break" that web server. If you think of this at a scale of serveral million users, quite likely generating significant press coverage along the way, this can get rather disastrous for the ISP as well as for the entire move towards IPv6. It doesn't really matter at this point what actually caused the problem but what people *perceive* as the cause of the problem. The majority will behave pretty much the way you reasoned yourself; they either lack the necessary knowledge to understand what happened or they need a scapegoat for one reason or another. You did something, then something undesirable happened, so you're "responsible". > Phased introduction this is the key! Agreed. In some cases this may get difficult because it leads to ugly discussions with the marketing people. They may want to make the IPv6 deployment a major event---that's difficult if you do it in small steps. There is another trick along that line: Make the customers enable IPv6 themselves. If they have to connect to a web front end, log in and enable IPv6 for their particular hookup, then you get a somewhat phased introduction, largely avoid the blame for the broken web server above, and provide them with a rollback option if things break. On the ISP side you have to provide that web interface, somehow convince your access router infrastructure to deal with this level of user-specific configuration, notify your customer base, find a way how to estimate and deal with the extra workload in your call centers and eventually deal with the (quite likely large number of) people who never bothered to even try. So it's still a big job. > This takes time! Therefore many ISPs are already late. Agreed again. Which means that many ISPs will have to deploy IPv6 in a rather chaotic way at some point. The good news here is that the more competent ISPs are likely to gain from this. The bad news is that there will be less ISPs afterwards than right now, because at least some of them will go out of business; that's bad as far as competition and alternatives for customers go. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From brian.e.carpenter at gmail.com Thu Mar 18 23:14:54 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 19 Mar 2010 11:14:54 +1300 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA29F49.6040307@redpill-linpro.com> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> Message-ID: <4BA2A5DE.80105@gmail.com> On 2010-03-19 10:46, Tore Anderson wrote: > Hi, > > * Benedikt Stockebrand > >> Gert Doering writes: >> >>> If you connect to a dual-stacked host, and your operating system is >>> behaving as Windows does (prefer native IPv6, but if that is not >>> available, prefer IPv4 before 6to4 and Teredo), your client will >>> not use 6to4. >> ok, you know I'm more of a Unixer. This approach appears quite >> reasonable but either I misinterpret RFC 3484 or it is a >> Windows-specific arrangement. > > It is not a Windows-specific arrangement, it's implemented in > getaddrinfo() at least in GNU libc, probably most other modern variants > as well. This is because rule 4 of the destination address selection > (chapter 6) comes into play, which says to prefer matching labels. A > normal IPv6 address has a different label than a 6to4 address (the table > is in chapter 2.1), so communication between two normal IPv4 addresses > are preferred. > > However, if both the client and the server were to have 6to4-addresses, > a 6to4-to-6to4 connection will be preferred over IPv4-to-IPv4, since now > both the options have matching labels, but the 6to4 one wins because it > has a higher sorting precedence. In my opinion, this is a bug in the > RFC, but I don't think it has any significant operational impact. I believe this was intentional, since the philosophy was 'prefer IPv6 connectivity if it exists'. I also agree that reversing this in the policy table would be very reasonable; 3484 only provides a *default* policy table. > > Another far more serious shortcoming of the RFC is that it does not take > into account the prevalence of IPv4 NAT. RFC 1918 addresses are given > the site-local scope, and rule 2 of the destination address selection > algorithm says to prefer addresses with a matching scope. A 6to4 > address is globally scoped like any other IPv6 address, so this means > that 6to4 connections will be preferred over NAT-ed IPv4 connections > from RFC 1918 prefix. Again, intentional, for the same reason. This becomes a real problem if you for instance > have a SOHO router that can do 6to4 tunneling from its WAN address and > also send regular router advertisements on the LAN side, in addition to > regular IPv4 NAT. The Apple Airport Extreme is one well-known example > of such a device. > > I see quite a bit of breakage (lost clients that's using Mac OS X) > towards my dualstack testing host due to this. You mean, I assume, that it turns out that there is no 6to4 relay in the outbound or return path? That is (IMHO) the problem with RFC 3068. The assumption of RFC 3056 was that the placement of 6to4 relays would be a managed process, for savvy early-adopter sites. The addition of the anycast relay model in RFC 3068 broke that assumption and brought about unmanaged deployment. Nathan Ward has suggested a way to fix this (and the equivalent problem with Vista/Teredo) but it does need sites or ISPs to install a box to catch the anycasts. Brian Even though the > behaviour is clearly problematic, it is a completely correct > implementation of the RFC, as far as I can tell. Unfortunately. I've > not really seen this behaviour from other operating systems though, > perhaps other implementers have decided not to follow the RFC to the > letter to avoid the problem, or it could simply be that it's really only > Mac users that buy the Airport Extreme. I would have to look more into > it to say for certain. > > BR, From paul at paulstewart.org Thu Mar 18 23:27:43 2010 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 18 Mar 2010 18:27:43 -0400 Subject: DNS Behaviour - Dual Stack Clients In-Reply-To: <4BA2A5DE.80105@gmail.com> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> Message-ID: <002801cac6ea$3a57cd00$af076700$@org> Hi folks.. Pardon me if this is a "basic" question but trying to see if I understand DNS for IPv6.... we have dual-stack running in our core and distribution networks. Unfortunately our DNS servers are behind load balancers that do not support IPv6 yet ;( If I load the reverse IPv6 zone and put forward AAA entries into BIND it answers fine locally - what happens with a dual-stack client when they want to do a IPv6 authoritive lookup? Will the dual-stack client connect on IPv4 and be able to still receive *and use* IPv6 records (via IPv4)? Or is this client dependant on how it's configured? Hope this makes sense - we're 6-8 months away from having our load balancers replaced with hardware that supports IPv6 directly... Paul From dougb at dougbarton.us Thu Mar 18 23:37:44 2010 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 18 Mar 2010 15:37:44 -0700 Subject: DNS Behaviour - Dual Stack Clients In-Reply-To: <002801cac6ea$3a57cd00$af076700$@org> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <002801cac6ea$3a57cd00$af076700$@org> Message-ID: <4BA2AB38.5000307@dougbarton.us> On 03/18/10 15:27, Paul Stewart wrote: > Hi folks.. > > Pardon me if this is a "basic" question but trying to see if I > understand DNS for IPv6.... we have dual-stack running in our core > and distribution networks. Yay! > Unfortunately our DNS servers are behind load balancers that do not > support IPv6 yet ;( Boo! > If I load the reverse IPv6 zone and put forward AAA entries into BIND > it answers fine locally - what happens with a dual-stack client when > they want to do a IPv6 authoritive lookup? Will the dual-stack > client connect on IPv4 and be able to still receive *and use* IPv6 > records (via IPv4)? Or is this client dependant on how it's > configured? ... but seriously folks, the client and their resolving name server are almost always completely independent entities. If YOUR name server only has IPv4 address entries (which it should from what you describe) the other name servers in the world will only try to connect to it via IPv4. The fact that you return AAAAs for your dual-stacked hosts has nothing to do with how the remote nameservers get the answers. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From paul at paulstewart.org Thu Mar 18 23:55:45 2010 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 18 Mar 2010 18:55:45 -0400 Subject: DNS Behaviour - Dual Stack Clients In-Reply-To: <4BA2AB38.5000307@dougbarton.us> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <002801cac6ea$3a57cd00$af076700$@org> <4BA2AB38.5000307@dougbarton.us> Message-ID: <002b01cac6ee$24ac53f0$6e04fbd0$@org> Thank you for the reply... so just to clarify further... A remote client or name server queries our nameserver (which is only reachable via IPv4). Our name server replies with A and AAAA records in the lookup. If the remote client is IPv6 capable will it ignore the AAAA information because it was only able to get the query answered via IPv4? I believe this is what you're saying - again, just looking to clarify ;) Appreciate it, Paul -----Original Message----- From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf Of Doug Barton Sent: March-18-10 6:38 PM To: ipv6-ops at lists.cluenet.de Subject: Re: DNS Behaviour - Dual Stack Clients On 03/18/10 15:27, Paul Stewart wrote: > Hi folks.. > > Pardon me if this is a "basic" question but trying to see if I > understand DNS for IPv6.... we have dual-stack running in our core > and distribution networks. Yay! > Unfortunately our DNS servers are behind load balancers that do not > support IPv6 yet ;( Boo! > If I load the reverse IPv6 zone and put forward AAA entries into BIND > it answers fine locally - what happens with a dual-stack client when > they want to do a IPv6 authoritive lookup? Will the dual-stack > client connect on IPv4 and be able to still receive *and use* IPv6 > records (via IPv4)? Or is this client dependant on how it's > configured? ... but seriously folks, the client and their resolving name server are almost always completely independent entities. If YOUR name server only has IPv4 address entries (which it should from what you describe) the other name servers in the world will only try to connect to it via IPv4. The fact that you return AAAAs for your dual-stacked hosts has nothing to do with how the remote nameservers get the answers. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From tore.anderson at redpill-linpro.com Thu Mar 18 23:58:16 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 18 Mar 2010 23:58:16 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA2A5DE.80105@gmail.com> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> Message-ID: <4BA2B008.2060508@redpill-linpro.com> Hi, * Brian E Carpenter > I believe this was intentional, since the philosophy was 'prefer IPv6 > connectivity if it exists'. I also agree that reversing this in > the policy table would be very reasonable; 3484 only provides a > *default* policy table. I should probably have said "shortcoming" instead of "bug". However, the RFC does special-case 6to4 and makes 6to4-to-!6to4 connectivity less preferred than IPv4-to-IPv4. If the point was to prefer IPv6 unconditionally, they would not have had to mention the 6to4 prefix at all. But they did, and I cannot imagine any other reason that they recognized that 6to4-based connectivity would be inherently less reliable than the IPv4 connectivity that 6to4 was tunneled on top of. So I don't quite understand why they didn't make 6to4-to-6to4 less preferred than IPv4-to-IPv4 too. I don't think 6to4-to-6to4 is used for much production traffic though, so it's not really a problem. > You mean, I assume, that it turns out that there is no 6to4 relay > in the outbound or return path? That is (IMHO) the problem > with RFC 3068. The assumption of RFC 3056 was that the placement > of 6to4 relays would be a managed process, for savvy early-adopter > sites. The addition of the anycast relay model in RFC 3068 broke that > assumption and brought about unmanaged deployment. Yes, that there is no 6to4 relay in the outbound path (I can easily make sure there's return relays for 2002::/16 within my own network so that part isn't easily handled), or that proto-41 traffic is filtered, or that the relay doesn't work, or is very far away latency-wise, and so on and so on. Broken 6to4/Teredo connectivity is the single largest cause for web sites to appear unreachable/down for regular eyeballs after introducing AAAA records. It's responsible for almost all of it, I cannot really point out any other single cause of significance, of the 0.094% of total brokenness I measured in February, 0.090 percentage points is due to 6to4/Teredo.... Had it not been for 6to4 I doubt I would have had an problems convincing my customers to dualstack their content. But now they're understandably concerned about losing visitors and thus revenue. Probably most content providers wants everyone else to go first and take the pain, so that the problematic users hopefully will be mostly fixed by the time they add IPv6 capability themselves. > Nathan Ward has suggested a way to fix this (and the equivalent > problem with Vista/Teredo) but it does need sites or ISPs to install > a box to catch the anycasts. Do you have a pointer to his suggested solution? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From dougb at dougbarton.us Thu Mar 18 23:58:37 2010 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 18 Mar 2010 15:58:37 -0700 Subject: Tunnel overhead [On killing IPv6 transition mechanisms] In-Reply-To: <4BA02517.1030905@gmail.com> References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <4BA02517.1030905@gmail.com> Message-ID: <4BA2B01D.9030103@dougbarton.us> On 03/16/10 17:40, Brian E Carpenter wrote: > Gert, > > The problem is tunnels. The first example is from University of Auckland > via Telstraclear and a HE tunnel. IPv6 penalty is about 390 ms round trip, > crossing one ocean. Here is another data point, from my home in Southern California, to the ARIN web servers on the East coast (Ashburn if I'm reading the traces correctly). IPv4: ping -c 20 -s 1024 www.arin.net --- www.arin.net ping statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 82.205/84.069/100.077/3.739 ms IPv6 (through the HE.net tunnel in Fremont, CA): ping6 -c 20 -s 1024 www.arin.net --- www.arin.net ping6 statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 107.004/114.436/183.481/18.180 ms That's a 30 ms penalty for the tunnel, which I have never found to be unduly burdensome. With the same ping options I get even better results for some sites: --- ipv6.l.google.com ping6 statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 47.204/48.537/50.859/0.926 ms For certain things the tunnel is actually _faster_ than IPv4, but that's because I picked a tunnel endpoint that's co-located with the stuff I want to access. :) To make sure we're comparing apples to apples, this is a proto 41 tunnel set up on my home router, providing "native" IPv6 to my laptop. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dougb at dougbarton.us Fri Mar 19 00:02:13 2010 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 18 Mar 2010 16:02:13 -0700 Subject: DNS Behaviour - Dual Stack Clients In-Reply-To: <002b01cac6ee$24ac53f0$6e04fbd0$@org> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <002801cac6ea$3a57cd00$af076700$@org> <4BA2AB38.5000307@dougbarton.us> <002b01cac6ee$24ac53f0$6e04fbd0$@org> Message-ID: <4BA2B0F5.10306@dougbarton.us> On 03/18/10 15:55, Paul Stewart wrote: > Thank you for the reply... so just to clarify further... > > A remote client or name server queries our nameserver (which is only reachable via IPv4). Our name server replies with A and AAAA records in the lookup. If the remote client is IPv6 capable will it ignore the AAAA information because it was only able to get the query answered via IPv4? I believe this is what you're saying - again, just looking to clarify ;) Um, no, what I'm saying is actually the opposite. How the client receives the address records has nothing to do with what it does with them. If the client is IPv6-capable, and receives AAAAs, it will use them. The client does not even know how the resolving nameserver retrieved the records, nor could it find out. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From paul at paulstewart.org Fri Mar 19 00:05:41 2010 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 18 Mar 2010 19:05:41 -0400 Subject: DNS Behaviour - Dual Stack Clients In-Reply-To: <4BA2B0F5.10306@dougbarton.us> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <002801cac6ea$3a57cd00$af076700$@org> <4BA2AB38.5000307@dougbarton.us> <002b01cac6ee$24ac53f0$6e04fbd0$@org> <4BA2B0F5.10306@dougbarton.us> Message-ID: <002c01cac6ef$880d3210$98279630$@org> Ahhh... good then in our case (at least interm)... Thank you for the clarification..;) Paul -----Original Message----- From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf Of Doug Barton Sent: March-18-10 7:02 PM To: Paul Stewart Cc: ipv6-ops at lists.cluenet.de Subject: Re: DNS Behaviour - Dual Stack Clients On 03/18/10 15:55, Paul Stewart wrote: > Thank you for the reply... so just to clarify further... > > A remote client or name server queries our nameserver (which is only reachable via IPv4). Our name server replies with A and AAAA records in the lookup. If the remote client is IPv6 capable will it ignore the AAAA information because it was only able to get the query answered via IPv4? I believe this is what you're saying - again, just looking to clarify ;) Um, no, what I'm saying is actually the opposite. How the client receives the address records has nothing to do with what it does with them. If the client is IPv6-capable, and receives AAAAs, it will use them. The client does not even know how the resolving nameserver retrieved the records, nor could it find out. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From tedm at ipinc.net Fri Mar 19 00:31:33 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 18 Mar 2010 16:31:33 -0700 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> Message-ID: <4BA2B7D5.2000407@ipinc.net> Benedikt Stockebrand wrote: > Hi Gert and list, > > >> These enterprises are the ones that will be in for a nasty surprise >> when they roll out Win7 or Server2008R2, and all of a sudden they have >> uncontrolled IPv6 all over the place. So it's quite important that they >> understand what is coming up, and get prepared. > > Right. But what could they have done so far? With Vista being > generally considered unfit for enterprise use, Vista's downfall was that it did not have that good application support for old XP apps - some would run, some wouldn't - and too late Microsoft realized the importance of a 128MB 3D card and 4GB of ram for decent performance, and did not adequately communicate that to the OEM PC makers. Enterprises that attempted Vista rollouts on P4's with 1GB and slow graphics cards got burned and spread a lot of lies around. But many enterprises did not have any of the problematical XP apps, and deployed Vista by buying brand new business-class desktops that DID have the requisite hardware, and THEY had no problem. You just didn't hear about their stories in the PC ragazines since it didn't make for good press. But admins that did their homework found the popular press was sensationalizing the issue and went ahead and deployed. Windows 7 is really just Vista with the "Win 7 Service Pack" applied. The entire Win 7 launch was a huge marketing campaign, fundamentally there is no difference between Vista and Win 7 except for the XP compatability box, which took care of enough of the older problematical XP apps that MS can now afford to ignore the remaining troublemakers. The notion that no enterprises deployed Vista is a myth that is being helped along by MS since they want everyone to pay them more money for Win 7 upgrades on their Vista desktops. > they have been stuck > with XP until Win7 was released. Using IPv6 with XP is infeasible > at least at a larger scale, so they were effectively stuck with IPv4, > too. > > Now that Win7 is available they have to get all the software they use > to work with Win7, Something that the XP compatibility in win7 makes really easy now. > and possibly even get it certified one way or > another, Large enterprises have the money club that makes this happen really fast before they can move on to Win7---and they have to do so > before Microsoft stops providing security fixes for XP. That's their > primary concern. > excuses, excuses. There's no reason most enterprises couldn't have deployed IPv6 once Vista came out other than sheer mental inertia. Only the ones with stale apps that they would have to sit on the vendor to update might have had an excuse, and by the time the first Vista SP came out they could have gotten it done. Ted From brian.e.carpenter at gmail.com Fri Mar 19 02:24:16 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 19 Mar 2010 14:24:16 +1300 Subject: DNS Behaviour - Dual Stack Clients In-Reply-To: <4BA2B0F5.10306@dougbarton.us> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <002801cac6ea$3a57cd00$af076700$@org> <4BA2AB38.5000307@dougbarton.us> <002b01cac6ee$24ac53f0$6e04fbd0$@org> <4BA2B0F5.10306@dougbarton.us> Message-ID: <4BA2D240.2020502@gmail.com> Paul, On 2010-03-19 12:02, Doug Barton wrote: > On 03/18/10 15:55, Paul Stewart wrote: >> Thank you for the reply... so just to clarify further... >> >> A remote client or name server queries our nameserver (which is only reachable via IPv4). Our name server replies with A and AAAA records in the lookup. If the remote client is IPv6 capable will it ignore the AAAA information because it was only able to get the query answered via IPv4? I believe this is what you're saying - again, just looking to clarify ;) > > Um, no, what I'm saying is actually the opposite. How the client > receives the address records has nothing to do with what it does with > them. If the client is IPv6-capable, and receives AAAAs, it will use > them. The client does not even know how the resolving nameserver > retrieved the records, nor could it find out. To be even more explicit, clients that can only resolve FQDNs by DNS-over-IPv4, but that speak IPv6 and make use of AAAA records, are common; I'm using one right now (XP, to give it a name). My home ISP only provides DNS-over-IPv4 but happily serves up AAAA records: brian>nslookup Default Server: dns1.orcon.net.nz Address: 60.234.1.1 > set type=AAAA > www.ietf.org Server: dns1.orcon.net.nz Address: 60.234.1.1 Non-authoritative answer: www.ietf.org AAAA IPv6 address = 2001:1890:1112:1::20 (I get my home v6 connectivity by a tunnel, but exactly the same thing happens on an XP client with native v6.) Brian From brian.e.carpenter at gmail.com Fri Mar 19 02:28:47 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 19 Mar 2010 14:28:47 +1300 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA2B008.2060508@redpill-linpro.com> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <4BA2B008.2060508@redpill-linpro.com> Message-ID: <4BA2D34F.8010308@gmail.com> The link for Nathan Ward's work: http://www.braintrust.co.nz/tui/ Regards Brian Carpenter On 2010-03-19 11:58, Tore Anderson wrote: > Hi, > > * Brian E Carpenter > >> I believe this was intentional, since the philosophy was 'prefer IPv6 >> connectivity if it exists'. I also agree that reversing this in >> the policy table would be very reasonable; 3484 only provides a >> *default* policy table. > > I should probably have said "shortcoming" instead of "bug". However, > the RFC does special-case 6to4 and makes 6to4-to-!6to4 connectivity less > preferred than IPv4-to-IPv4. If the point was to prefer IPv6 > unconditionally, they would not have had to mention the 6to4 prefix at all. > > But they did, and I cannot imagine any other reason that they recognized > that 6to4-based connectivity would be inherently less reliable than the > IPv4 connectivity that 6to4 was tunneled on top of. So I don't quite > understand why they didn't make 6to4-to-6to4 less preferred than > IPv4-to-IPv4 too. I don't think 6to4-to-6to4 is used for much > production traffic though, so it's not really a problem. > >> You mean, I assume, that it turns out that there is no 6to4 relay >> in the outbound or return path? That is (IMHO) the problem >> with RFC 3068. The assumption of RFC 3056 was that the placement >> of 6to4 relays would be a managed process, for savvy early-adopter >> sites. The addition of the anycast relay model in RFC 3068 broke that >> assumption and brought about unmanaged deployment. > > Yes, that there is no 6to4 relay in the outbound path (I can easily make > sure there's return relays for 2002::/16 within my own network so that > part isn't easily handled), or that proto-41 traffic is filtered, or > that the relay doesn't work, or is very far away latency-wise, and so on > and so on. > > Broken 6to4/Teredo connectivity is the single largest cause for web > sites to appear unreachable/down for regular eyeballs after introducing > AAAA records. It's responsible for almost all of it, I cannot really > point out any other single cause of significance, of the 0.094% of total > brokenness I measured in February, 0.090 percentage points is due to > 6to4/Teredo.... > > Had it not been for 6to4 I doubt I would have had an problems convincing > my customers to dualstack their content. But now they're understandably > concerned about losing visitors and thus revenue. Probably most content > providers wants everyone else to go first and take the pain, so that the > problematic users hopefully will be mostly fixed by the time they add > IPv6 capability themselves. > >> Nathan Ward has suggested a way to fix this (and the equivalent >> problem with Vista/Teredo) but it does need sites or ISPs to install >> a box to catch the anycasts. > > Do you have a pointer to his suggested solution? > > Best regards, From paul at paulstewart.org Fri Mar 19 03:40:39 2010 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 18 Mar 2010 22:40:39 -0400 Subject: DNS Behaviour - Dual Stack Clients In-Reply-To: <4BA2D240.2020502@gmail.com> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <002801cac6ea$3a57cd00$af076700$@org> <4BA2AB38.5000307@dougbarton.us> <002b01cac6ee$24ac53f0$6e04fbd0$@org> <4BA2B0F5.10306@dougbarton.us> <4BA2D240.2020502@gmail.com> Message-ID: <000601cac70d$900e29b0$b02a7d10$@org> Excellent - I appreciate this information. ;) This is very helpful to figure out what needs to be done first in our IPv6 conversions. Servers were last on the list and network was first... and we're migrating from Cisco over to Juniper on most fronts so this was a great time to start working on all aspects of our network. Since we require every aspect of our network to have a hostname forward and reverse we thought this a great time to update things with IPv6 in mind... Take care, Paul -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter at gmail.com] Sent: March-18-10 9:24 PM To: Paul Stewart Cc: ipv6-ops at lists.cluenet.de Subject: Re: DNS Behaviour - Dual Stack Clients Paul, On 2010-03-19 12:02, Doug Barton wrote: > On 03/18/10 15:55, Paul Stewart wrote: >> Thank you for the reply... so just to clarify further... >> >> A remote client or name server queries our nameserver (which is only reachable via IPv4). Our name server replies with A and AAAA records in the lookup. If the remote client is IPv6 capable will it ignore the AAAA information because it was only able to get the query answered via IPv4? I believe this is what you're saying - again, just looking to clarify ;) > > Um, no, what I'm saying is actually the opposite. How the client > receives the address records has nothing to do with what it does with > them. If the client is IPv6-capable, and receives AAAAs, it will use > them. The client does not even know how the resolving nameserver > retrieved the records, nor could it find out. To be even more explicit, clients that can only resolve FQDNs by DNS-over-IPv4, but that speak IPv6 and make use of AAAA records, are common; I'm using one right now (XP, to give it a name). My home ISP only provides DNS-over-IPv4 but happily serves up AAAA records: brian>nslookup Default Server: dns1.orcon.net.nz Address: 60.234.1.1 > set type=AAAA > www.ietf.org Server: dns1.orcon.net.nz Address: 60.234.1.1 Non-authoritative answer: www.ietf.org AAAA IPv6 address = 2001:1890:1112:1::20 (I get my home v6 connectivity by a tunnel, but exactly the same thing happens on an XP client with native v6.) Brian From tore.anderson at redpill-linpro.com Fri Mar 19 09:38:58 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 19 Mar 2010 09:38:58 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA2D34F.8010308@gmail.com> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <4BA2B008.2060508@redpill-linpro.com> <4BA2D34F.8010308@gmail.com> Message-ID: <4BA33822.9000502@redpill-linpro.com> * Brian E Carpenter > The link for Nathan Ward's work: > > http://www.braintrust.co.nz/tui/ I see, thanks. This won't help me much, I'm afraid. My problem are with 6to4-enabled _end users_ using IPv4-only ISPs. I would have needed to persuade all of those users' ISPs to install such a TUI box, and that's completely unrealistic. Might as well try to persuade them to deploy native IPv6 instead. :-) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From mohacsi at niif.hu Fri Mar 19 10:22:18 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 19 Mar 2010 10:22:18 +0100 (CET) Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA29F49.6040307@redpill-linpro.com> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> Message-ID: On Thu, 18 Mar 2010, Tore Anderson wrote: > Hi, > > * Benedikt Stockebrand > >> Gert Doering writes: >> >>> If you connect to a dual-stacked host, and your operating system is >>> behaving as Windows does (prefer native IPv6, but if that is not >>> available, prefer IPv4 before 6to4 and Teredo), your client will >>> not use 6to4. >> >> ok, you know I'm more of a Unixer. This approach appears quite >> reasonable but either I misinterpret RFC 3484 or it is a >> Windows-specific arrangement. > > It is not a Windows-specific arrangement, it's implemented in > getaddrinfo() at least in GNU libc, probably most other modern variants > as well. This is because rule 4 of the destination address selection > (chapter 6) comes into play, which says to prefer matching labels. A > normal IPv6 address has a different label than a 6to4 address (the table > is in chapter 2.1), so communication between two normal IPv4 addresses > are preferred. > > However, if both the client and the server were to have 6to4-addresses, > a 6to4-to-6to4 connection will be preferred over IPv4-to-IPv4, since now > both the options have matching labels, but the 6to4 one wins because it > has a higher sorting precedence. In my opinion, this is a bug in the > RFC, but I don't think it has any significant operational impact. > > Another far more serious shortcoming of the RFC is that it does not take > into account the prevalence of IPv4 NAT. RFC 1918 addresses are given > the site-local scope, and rule 2 of the destination address selection > algorithm says to prefer addresses with a matching scope. A 6to4 > address is globally scoped like any other IPv6 address, so this means > that 6to4 connections will be preferred over NAT-ed IPv4 connections > from RFC 1918 prefix. This becomes a real problem if you for instance > have a SOHO router that can do 6to4 tunneling from its WAN address and > also send regular router advertisements on the LAN side, in addition to > regular IPv4 NAT. The Apple Airport Extreme is one well-known example > of such a device. 1. most of the RFC 3484 implementation changes this behaviour: RFC-1918 addresses treated as global scope due to proliferation of NAT devices. 2. IETF 6man is working on revising the RFC 3484 - express your opinion on mailing list ipv6 at ietf.org about this topic. Best Regards, Janos Mohacsi From mohacsi at niif.hu Fri Mar 19 10:33:24 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 19 Mar 2010 10:33:24 +0100 (CET) Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> Message-ID: Hi Benedikt, On Thu, 18 Mar 2010, Benedikt Stockebrand wrote: > Hi Janos (I suppose that's your first name?) and list, > >> then this provider did his jobs badly. They did not test when they >> introduced ipv6. Plan, Train, Test in small, learn, train, pilot, >> test, train, test, introduce. > > that doesn't solve the problem. > > Consider this example: A company has set up and installed a web server > connected behind a dual-stack uplink. Between the web server and the > CPE router towards their ISP they installed a packet filter configured > to silently discard all IPv6 traffic from the Internet. The web > server has both A and AAAA records in the DNS, possibly because it is > accessible internally via IPv6 as well. > > The point here is that this setup is broken in a number of ways, but > as long as the "road warriors" only have IPv4 access it still works > fine. If they install packet filter that discard all the IPv6 traffic, why they install A and AAAA records in the DNS. If they want to make it accessible internally via IPv6, they have to implement either split DNS (since they want different behaviour internally than from outside), or install IPv6 capable packet filter and allow proper IPv6 filtering > > Now bring in your own reasoning: > >>> If IPv6 disrupts a business customer's business or an end user's >>> entertainment, there is a good chance they pick up "IPv6" as the >>> keyword to blame. It doesn't take actually understanding what IPv6 is >>> to do so. >> >> They should blame the provider! Probably change to another ISP. As >> they would change if IPv4 service is badly provided. > > As soon as you, as the ISP, enable IPv6 for your customers, from the > customer's point of view you "break" that web server. I don't see the reason. If I run webserver I control what address I want in the DNS. >> Phased introduction this is the key! > > Agreed. In some cases this may get difficult because it leads to ugly > discussions with the marketing people. They may want to make the IPv6 > deployment a major event---that's difficult if you do it in small > steps. > > There is another trick along that line: Make the customers enable IPv6 > themselves. If they have to connect to a web front end, log in and > enable IPv6 for their particular hookup, then you get a somewhat > phased introduction, largely avoid the blame for the broken web server > above, and provide them with a rollback option if things break. > > On the ISP side you have to provide that web interface, somehow > convince your access router infrastructure to deal with this level of > user-specific configuration, notify your customer base, find a way how > to estimate and deal with the extra workload in your call centers and > eventually deal with the (quite likely large number of) people who > never bothered to even try. So it's still a big job. > >> This takes time! Therefore many ISPs are already late. > > Agreed again. Which means that many ISPs will have to deploy IPv6 in > a rather chaotic way at some point. > > The good news here is that the more competent ISPs are likely to gain > from this. The bad news is that there will be less ISPs afterwards > than right now, because at least some of them will go out of business; > that's bad as far as competition and alternatives for customers > go. Or some knowledgeable and competitive new ISPs will emerge... > > > Cheers, > > Benedikt > > -- > Business Grade IPv6 > Consulting, Training, Projects > > Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 > Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 > Fichardstr. 38 Mail: me at benedikt-stockebrand.de > D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ > > Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen > Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. > No spam, no unsolicited sales calls, no telephone surveys, please. Calls > may be recorded for legal purposes. > > From gert at space.net Fri Mar 19 10:35:12 2010 From: gert at space.net (Gert Doering) Date: Fri, 19 Mar 2010 10:35:12 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA278D7.40206@ipinc.net> References: <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA278D7.40206@ipinc.net> Message-ID: <20100319093511.GL69383@Space.Net> Hi, On Thu, Mar 18, 2010 at 12:02:47PM -0700, Ted Mittelstaedt wrote: > > These enterprises are the ones that will be in for a nasty surprise > > when they roll out Win7 or Server2008R2, and all of a sudden they have > > uncontrolled IPv6 all over the place. So it's quite important that they > > understand what is coming up, and get prepared. > > Since those orgs use prebuilt images when rolling that stuff out, they > always have the ability to disable IPv6 in the image then roll it out > and that is likely what they will be doing. I have been told by people who know more about Windows than I do that if you disable IPv6, a large number of windows RPC things in Win7/Server2008 will just stop working. To quote "the *base* communication protocol in W2k8R2 is IPv6, you just *can't* disable it". See, for example, http://www.networkworld.com/community/node/45032 Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100319/231a6d45/attachment.bin From gert at space.net Fri Mar 19 10:39:30 2010 From: gert at space.net (Gert Doering) Date: Fri, 19 Mar 2010 10:39:30 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA29F49.6040307@redpill-linpro.com> References: <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> Message-ID: <20100319093930.GM69383@Space.Net> Hi, On Thu, Mar 18, 2010 at 10:46:49PM +0100, Tore Anderson wrote: > However, if both the client and the server were to have 6to4-addresses, > a 6to4-to-6to4 connection will be preferred over IPv4-to-IPv4, since now > both the options have matching labels, but the 6to4 one wins because it > has a higher sorting precedence. In my opinion, this is a bug in the > RFC, but I don't think it has any significant operational impact. Since in this case, no anycast relays are used, this is should be similar to IPv4-to-IPv4 in latency - so the general preference of "if all things are equal, prefer IPv6 before IPv4" rule comes back. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 Fri Mar 19 10:41:51 2010 From: gert at space.net (Gert Doering) Date: Fri, 19 Mar 2010 10:41:51 +0100 Subject: DNS Behaviour - Dual Stack Clients In-Reply-To: <002b01cac6ee$24ac53f0$6e04fbd0$@org> References: <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <002801cac6ea$3a57cd00$af076700$@org> <4BA2AB38.5000307@dougbarton.us> <002b01cac6ee$24ac53f0$6e04fbd0$@org> Message-ID: <20100319094151.GN69383@Space.Net> Hi, On Thu, Mar 18, 2010 at 06:55:45PM -0400, Paul Stewart wrote: > Thank you for the reply... so just to clarify further... > > A remote client or name server queries our nameserver (which is > only reachable via IPv4). Our name server replies with A and AAAA > records in the lookup. If the remote client is IPv6 capable will > it ignore the AAAA information because it was only able to get the > query answered via IPv4? I believe this is what you're saying - > again, just looking to clarify ;) The "transport protocol for DNS information" and the "transported information inside the DNS packets" are completely independent. (After all, the client might be talking to his local resolver over IPv6, so it wouldn't know at all whether your DNS servers have v6 transport or not). This is by design, and it's good design, because that way you can upgrade the egg without annoying the chicken, and vice versa :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 ghen at telenet.be Fri Mar 19 10:57:26 2010 From: ghen at telenet.be (Geert Hendrickx) Date: Fri, 19 Mar 2010 10:57:26 +0100 Subject: DNS Behaviour - Dual Stack Clients In-Reply-To: <20100319094151.GN69383@Space.Net> References: <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <002801cac6ea$3a57cd00$af076700$@org> <4BA2AB38.5000307@dougbarton.us> <002b01cac6ee$24ac53f0$6e04fbd0$@org> <20100319094151.GN69383@Space.Net> Message-ID: <20100319095726.GA6441@boris.ghen.be> On Fri, Mar 19, 2010 at 10:41:51AM +0100, Gert Doering wrote: > Hi, > > On Thu, Mar 18, 2010 at 06:55:45PM -0400, Paul Stewart wrote: > > Thank you for the reply... so just to clarify further... > > > > A remote client or name server queries our nameserver (which is > > only reachable via IPv4). Our name server replies with A and AAAA > > records in the lookup. If the remote client is IPv6 capable will > > it ignore the AAAA information because it was only able to get the > > query answered via IPv4? I believe this is what you're saying - > > again, just looking to clarify ;) > > The "transport protocol for DNS information" and the "transported > information inside the DNS packets" are completely independent. A (somewhat exaggerated) analogy would be "can you visit webpages talking about IPv6 via http-over-IPv4?". Of course you can, because the content is independent from the transport. Geert -- Geert Hendrickx -=- ghen at telenet.be -=- PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages! From tore.anderson at redpill-linpro.com Fri Mar 19 11:15:38 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 19 Mar 2010 11:15:38 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100319093930.GM69383@Space.Net> References: <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <20100319093930.GM69383@Space.Net> Message-ID: <4BA34ECA.20608@redpill-linpro.com> Hi Gert, * Gert Doering > On Thu, Mar 18, 2010 at 10:46:49PM +0100, Tore Anderson wrote: >> However, if both the client and the server were to have 6to4-addresses, >> a 6to4-to-6to4 connection will be preferred over IPv4-to-IPv4, since now >> both the options have matching labels, but the 6to4 one wins because it >> has a higher sorting precedence. In my opinion, this is a bug in the >> RFC, but I don't think it has any significant operational impact. > > Since in this case, no anycast relays are used, [...] What makes you think that? The RFC does not distinguish between anycast or unicast 6to4 being used; an implementation would have no way of determining that anyway (at least for the remote end). I just verified this on a Windows 7 host that has auto-configured anycast 6to4 connectivity, by trying a dualstacked host-name, where the AAAA record is a 6to4 address, in a web browser. The remote web server (running Linux) is also using anycast for its 6to4 connectivity. As expected (and mandated by RFC 3484), the web browser attempted to use 6to4-to-6to4 for the connection, even though the IPv4-to-IPv4 alternative (no NAT or RFC 1918 involved here by the way) is in my opinion clearly superior. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From gert at space.net Fri Mar 19 12:10:52 2010 From: gert at space.net (Gert Doering) Date: Fri, 19 Mar 2010 12:10:52 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA34ECA.20608@redpill-linpro.com> References: <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <20100319093930.GM69383@Space.Net> <4BA34ECA.20608@redpill-linpro.com> Message-ID: <20100319111052.GS69383@Space.Net> Hi, On Fri, Mar 19, 2010 at 11:15:38AM +0100, Tore Anderson wrote: > > Since in this case, no anycast relays are used, [...] > > What makes you think that? The RFC does not distinguish between anycast > or unicast 6to4 being used; an implementation would have no way of > determining that anyway (at least for the remote end). Well, the theory is that 6to4<->6to4 can always go unicast, as the IPv4 address of the correct relay is in the 2002::: address. Only when going from 6to4<->native v6 or native v6<->6to4, you need to find a "to/from native" relay - and that's either statically configured, or defaults to 192.88.99.1 - anycasted, so packets can find "the nearest relay". Now, it would be possible to send packets to 2002:0102:0304::1 and have "1.2.3.4" be anycasted to multiple relays that will then know how to access the v6 infrastructure 2002:0102:0304::/48, but that's a different issue - it's unlikely that "just some random network ops" out there will add a badly-maintained anycast relay for a specific 6to4 range. > I just verified this on a Windows 7 host that has auto-configured > anycast 6to4 connectivity, by trying a dualstacked host-name, where the > AAAA record is a 6to4 address, in a web browser. The remote web server > (running Linux) is also using anycast for its 6to4 connectivity. As > expected (and mandated by RFC 3484), the web browser attempted to use > 6to4-to-6to4 for the connection, even though the IPv4-to-IPv4 > alternative (no NAT or RFC 1918 involved here by the way) is in my > opinion clearly superior. Why is it "superior"? Is the latency (significantly) better? If you follow the assumption "if the latency is the same, IPv4 is not what I want to use", the policy table is right. If you follow the assumption "if everything else is the same, prefer non-tunneled connectivity", the policy table needs changing. But in general, "accessing a web server" is not what 6to4 is really useful for - but for peer-to-peer applications, it is: Imagine two home users, both sitting behind a single public address and a NAT, and the NAT box also does 6to4. 6to4 will given them full peer2peer connectivity to all the machines in the respective subnet, without latency-impacting detours (because the encapsulated packets will go directly "6to4 router A" --> "6to4 router B", no 3rd-party relays needed), and you really gain something here. (Now where it gets nasty is "6to4 in home A" <-> "Teredo in home B", because then you have the worst of all worlds - 6to4 anycast relay and Teredo relay are needed, and unless both are really nearby network- wise, latency will be awful) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100319/e2e1c095/attachment.bin From tore.anderson at redpill-linpro.com Fri Mar 19 12:27:00 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 19 Mar 2010 12:27:00 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100319111052.GS69383@Space.Net> References: <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <20100319093930.GM69383@Space.Net> <4BA34ECA.20608@redpill-linpro.com> <20100319111052.GS69383@Space.Net> Message-ID: <4BA35F84.5070704@redpill-linpro.com> * Gert Doering > Well, the theory is that 6to4<->6to4 can always go unicast, as the > IPv4 address of the correct relay is in the 2002::: address. Oh, indeed - quite right you are. I hadn't realised that until now, thanks for pointing it out to me! Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From pete at twisted.org.uk Fri Mar 19 12:33:30 2010 From: pete at twisted.org.uk (Pete French) Date: Fri, 19 Mar 2010 11:33:30 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA34ECA.20608@redpill-linpro.com> Message-ID: > AAAA record is a 6to4 address, in a web browser. The remote web server > (running Linux) is also using anycast for its 6to4 connectivity. As > expected (and mandated by RFC 3484), the web browser attempted to use > 6to4-to-6to4 for the connection, even though the IPv4-to-IPv4 > alternative (no NAT or RFC 1918 involved here by the way) is in my > opinion clearly superior. Superor maybe, but both of them work - there is no actual breakage by using the IPv6 in this case is there ? I've never seen any breakage when trying to talk between to 6to4 hosts, only when I have a 6to4 trying to talk to a native server (or vice-versa). Given that 6to4->6to4 will be preferred if it exists, then providing the servers with both a native IPv6 and a 6to4 address when enabling them for IPv6 would seem to handle the 6to4 breakage, no ? Any customer with working IPv4 to the server should then be able to see it on IPv6 as well, regardless of the existence if working relays or not, unless I have badly misunderstood how 6to4->6to4 routing at the IPv4 gateway works (it just sends the packet directly over IPv4 does it not?). -pete. From me at benedikt-stockebrand.de Fri Mar 19 12:53:44 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Fri, 19 Mar 2010 11:53:44 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA2A5DE.80105@gmail.com> (Brian E. Carpenter's message of "Fri, 19 Mar 2010 11:14:54 +1300") References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> Message-ID: Hi Brian, Tore and list, Brian E Carpenter writes: > On 2010-03-19 10:46, Tore Anderson wrote: > > [RFC 3484 Destination address selection and 6to4] > >> It is not a Windows-specific arrangement, it's implemented in >> getaddrinfo() at least in GNU libc, probably most other modern variants >> as well. This is because rule 4 of the destination address selection >> (chapter 6) comes into play, which says to prefer matching labels. ok, I missed that one. There are plenty of other reasons not to use 6to4 in production setups anyway, so this never had any particular relevance to me. >> However, if both the client and the server were to have 6to4-addresses, >> a 6to4-to-6to4 connection will be preferred over IPv4-to-IPv4, >> [...] > > I believe this was intentional, since the philosophy was 'prefer IPv6 > connectivity if it exists'. I also agree that reversing this in > the policy table would be very reasonable; 3484 only provides a > *default* policy table. The root problem here isn't so much RFC 3484 but the fact that people use 6to4 in ways beyond its capabilities. In the past I often found 6to4 the most convenient way to quickly set up IPv6 connectivity, make the turtle dance and show people that things actually work. I also recommend ISP techs in trainings to set up their traffic accounting to collect data on all 6in4 (not limited to 6to4) use so they can show their management how much IPv6 traffic their customers already generate. Maybe it provides them with the convincing argument to move towards IPv6. But ISPs selling 6to4 as a "solution" to their customers are about as bad as CPE routers enabling it by default. 6to4 is anything but a production grade solution, not only with the issues created by public/anycast relays but also due to the inherently asymmetric routing. >> [...] 6to4 connections will be preferred over NAT-ed IPv4 connections >> from RFC 1918 prefix. > > Again, intentional, for the same reason. And it saves you from STUN etc, too:-) You know better than me about the original intention of the 6to4 specs, but I'd say if 6to4 is a design meant to be used only after a deliberate decision rather than being enabled by default, this reasoning is perfectly justified. In hindsight, if there's something missing in RFC 3068 then it's an unmistakable statement that 6to4 shouldn't be enabled by default. >> I see quite a bit of breakage (lost clients that's using Mac OS X) >> towards my dualstack testing host due to this. So much about the difference between actual and perceived cause of a problem... > The assumption of RFC 3056 was that the placement of 6to4 relays > would be a managed process, for savvy early-adopter sites. The > addition of the anycast relay model in RFC 3068 broke that > assumption and brought about unmanaged deployment. This is a bit unfair---3068 is rather explicit about the responsibilities of a public relay operator and the problems that may occur if a public relay fails. Public relays are apparently serving a very valuable purpose right now because they help generate the IPv6 traffic we need to put more pressure on ISPs, software developers and just about anybody else. > Nathan Ward has suggested a way to fix this (and the equivalent > problem with Vista/Teredo) but it does need sites or ISPs to install > a box to catch the anycasts. Honestly, with most sites and ISPs either still ignoring IPv6 or more or less frantically struggling to get a more permanent solution set up I personally wouldn't expect them to put much effort into such a temporary solution. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From me at benedikt-stockebrand.de Fri Mar 19 13:40:18 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Fri, 19 Mar 2010 12:40:18 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: (Mohacsi Janos's message of "Fri, 19 Mar 2010 10:33:24 +0100 (CET)") References: <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> Message-ID: Hi Janos and list, Mohacsi Janos writes: > If they install packet filter that discard all the IPv6 traffic, why > they install A and AAAA records in the DNS. If they want to make it > accessible internally via IPv6, they have to implement either split > DNS (since they want different behaviour internally than from > outside), or install IPv6 capable packet filter and allow proper IPv6 > filtering again, the point with that example was that their setup was broken from the very beginning but for one reason or another worked in conjunction with the original configuration on your side. As soon as you do something to your configuration, their setup blows up in their face and they *perceive* your change as the cause of your problem---after all, they haven't changed anything. It doesn't *have* to be the cause to make you lose business and slow down the entire move towards IPv6, this is all about perception from the customer's perspective. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362 Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985 Fichardstr. 38 Mail: me at benedikt-stockebrand.de D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/ Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet. No spam, no unsolicited sales calls, no telephone surveys, please. Calls may be recorded for legal purposes. From frnkblk at iname.com Fri Mar 19 16:28:57 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Fri, 19 Mar 2010 10:28:57 -0500 Subject: Logon scripts to enable IPv6? Message-ID: Has anyone developed or come across Windows logon scripts that enables IPv6 and turns off all 6to4, ISATAP, and Teredo for Windows XP SP2, Vista, and 7? I'm looking to deploy native IPv6 access (SLAAC-based) across our 60-node corporate network, and I'd rather do it via logon scripts than policies. Regards, Frank From charles at knownelement.com Fri Mar 19 17:42:50 2010 From: charles at knownelement.com (charles at knownelement.com) Date: Fri, 19 Mar 2010 16:42:50 +0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100319093511.GL69383@Space.Net> References: <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com><20100316092839.GS69383@Space.Net><20100316145247.GC69383@Space.Net><20100316191404.GI69383@Space.Net><20100318113010.GL69383@Space.Net> <4BA278D7.40206@ipinc.net><20100319093511.GL69383@Space.Net> Message-ID: <514039916-1269016975-cardhu_decombobulator_blackberry.rim.net-1329919408-@bda2625.bisx.prod.on.blackberry> Exchange 2007 service pack 2 won't install without it. Sent via BlackBerry from T-Mobile -----Original Message----- From: Gert Doering Date: Fri, 19 Mar 2010 10:35:12 To: Ted Mittelstaedt Cc: Benedikt Stockebrand; Gert Doering; Subject: Re: On killing IPv6 transition mechanisms Hi, On Thu, Mar 18, 2010 at 12:02:47PM -0700, Ted Mittelstaedt wrote: > > These enterprises are the ones that will be in for a nasty surprise > > when they roll out Win7 or Server2008R2, and all of a sudden they have > > uncontrolled IPv6 all over the place. So it's quite important that they > > understand what is coming up, and get prepared. > > Since those orgs use prebuilt images when rolling that stuff out, they > always have the ability to disable IPv6 in the image then roll it out > and that is likely what they will be doing. I have been told by people who know more about Windows than I do that if you disable IPv6, a large number of windows RPC things in Win7/Server2008 will just stop working. To quote "the *base* communication protocol in W2k8R2 is IPv6, you just *can't* disable it". See, for example, http://www.networkworld.com/community/node/45032 Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 martin at millnert.se Fri Mar 19 19:00:13 2010 From: martin at millnert.se (Martin Millnert) Date: Fri, 19 Mar 2010 19:00:13 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100319093511.GL69383@Space.Net> References: <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA278D7.40206@ipinc.net> <20100319093511.GL69383@Space.Net> Message-ID: <1269021613.20758.9.camel@hsa.vpn.anti> Hi, On Fri, 2010-03-19 at 10:35 +0100, Gert Doering wrote: > I have been told by people who know more about Windows than I do that > if you disable IPv6, a large number of windows RPC things in Win7/Server2008 > will just stop working. To quote "the *base* communication protocol in > W2k8R2 is IPv6, you just *can't* disable it". > > See, for example, http://www.networkworld.com/community/node/45032 See also http://technet.microsoft.com/en-us/magazine/2009.07.cableguy.aspx titled "Support for IPv6 in Windows Server 2008 R2 and Windows 7", with a section labeled "The Argument against Disabling IPv6". "From Microsoft's perspective, IPv6 is a mandatory part of the Windows operating system [...] Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled." Disabling IPv6 *entirely* is impossible (lo will stay), but some partial disabling can be done with http://support.microsoft.com/kb/929852 . But it will come with pain to do so. This case closed now? :) Cheers, -- Martin Millnert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100319/94883410/attachment-0001.bin From john at sackheads.org Fri Mar 19 19:15:33 2010 From: john at sackheads.org (John Payne) Date: Fri, 19 Mar 2010 14:15:33 -0400 Subject: On killing IPv6 transition mechanisms In-Reply-To: <1269021613.20758.9.camel@hsa.vpn.anti> References: <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA278D7.40206@ipinc.net> <20100319093511.GL69383@Space.Net> <1269021613.20758.9.camel@hsa.vpn.anti> Message-ID: On Mar 19, 2010, at 2:00 PM, Martin Millnert wrote: > Hi, > > On Fri, 2010-03-19 at 10:35 +0100, Gert Doering wrote: >> I have been told by people who know more about Windows than I do that >> if you disable IPv6, a large number of windows RPC things in Win7/Server2008 >> will just stop working. To quote "the *base* communication protocol in >> W2k8R2 is IPv6, you just *can't* disable it". >> >> See, for example, http://www.networkworld.com/community/node/45032 > > See also > http://technet.microsoft.com/en-us/magazine/2009.07.cableguy.aspx titled > "Support for IPv6 in Windows Server 2008 R2 and Windows 7", with a > section labeled "The Argument against Disabling IPv6". > > "From Microsoft's perspective, IPv6 is a mandatory part of the Windows > operating system [...] Therefore, Microsoft recommends that you leave > IPv6 enabled, even if you do not have an IPv6-enabled network, either > native or tunneled." > > Disabling IPv6 *entirely* is impossible (lo will stay), but some partial > disabling can be done with http://support.microsoft.com/kb/929852 . But > it will come with pain to do so. > > This case closed now? :) Unfortunately, read this from an enterprise security perspective. Home group I do not care about. DirectAccess == "Please put my enterprise security 100% in the hands of my Windows Admins" Teredo == "Please disregard any access controls I have in place at my network perimeter" etc etc From brian.e.carpenter at gmail.com Fri Mar 19 20:27:12 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 20 Mar 2010 08:27:12 +1300 Subject: On killing IPv6 transition mechanisms In-Reply-To: <4BA33822.9000502@redpill-linpro.com> References: <87wrxfunct.fsf@violet.siamics.net> <694F6EC5-966D-4D72-A854-C99DC0429CC0@employees.org> <4B9E6A20.8020207@ipinc.net> <4B9F4BAE.1020207@redpill-linpro.com> <20100316092839.GS69383@Space.Net> <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA29F49.6040307@redpill-linpro.com> <4BA2A5DE.80105@gmail.com> <4BA2B008.2060508@redpill-linpro.com> <4BA2D34F.8010308@gmail.com> <4BA33822.9000502@redpill-linpro.com> Message-ID: <4BA3D010.4000900@gmail.com> On 2010-03-19 21:38, Tore Anderson wrote: > * Brian E Carpenter > >> The link for Nathan Ward's work: >> >> http://www.braintrust.co.nz/tui/ > > I see, thanks. This won't help me much, I'm afraid. My problem are > with 6to4-enabled _end users_ using IPv4-only ISPs. I would have needed > to persuade all of those users' ISPs to install such a TUI box, and > that's completely unrealistic. Might as well try to persuade them to > deploy native IPv6 instead. :-) Yes, ISPs and site network managers who have their hand in the sand will not see the motivation for this. But as IPv4 exhaustion begins to bite over the next 3-5 years, this will probably change when help desk calls increase. Then the motivation to make 6to4 and Teredo work will probably decrease as native support increases. Honestly the best way to kill these mechanisms is to make them unnecessary. However, for now there is a problem for content providers, I agree. Brian From gert at space.net Fri Mar 19 22:31:25 2010 From: gert at space.net (Gert Doering) Date: Fri, 19 Mar 2010 22:31:25 +0100 Subject: On killing IPv6 transition mechanisms In-Reply-To: References: <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA278D7.40206@ipinc.net> <20100319093511.GL69383@Space.Net> <1269021613.20758.9.camel@hsa.vpn.anti> Message-ID: <20100319213125.GJ69383@Space.Net> Hi, On Fri, Mar 19, 2010 at 02:15:33PM -0400, John Payne wrote: > > "From Microsoft's perspective, IPv6 is a mandatory part of the Windows > > operating system [...] Therefore, Microsoft recommends that you leave > > IPv6 enabled, even if you do not have an IPv6-enabled network, either > > native or tunneled." [..] > Unfortunately, read this from an enterprise security perspective. > Home group I do not care about. > DirectAccess == "Please put my enterprise security 100% in the hands of my Windows Admins" No need to use DirectAccess (and *that* can be turned off just fine, or specifically, not installed in the first place). But given the sad state of "commercial VPN clients on client OSes", I rather like DirectAccess. (Not that there is nothing that prevents putting the DA Server in a well-controlled firewall DMZ zone, and have IPv6 firewalling in place between the DA server and the rest of the enterprise network). > Teredo == "Please disregard any access controls I have in place at my network perimeter" Teredo can be turned off as well. The point is: IPv6 in Windows Land is there to stay. So for a prudent enterprise network admin, the way forward is: accept life, accept IPv6, and integrate it in your security concepts. Turn off Teredo and 6to4 on the machines, give them native IPv6, and control native IPv6 on the firewalls the same way IPv4 is controlled. If said network admin choses to ignore IPv6, and pretend it doesn't exist, Teredo etc. are going to bite him in the back side. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100319/29e5ab77/attachment.bin From john at sackheads.org Fri Mar 19 22:46:38 2010 From: john at sackheads.org (John Payne) Date: Fri, 19 Mar 2010 17:46:38 -0400 Subject: On killing IPv6 transition mechanisms In-Reply-To: <20100319213125.GJ69383@Space.Net> References: <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA278D7.40206@ipinc.net> <20100319093511.GL69383@Space.Net> <1269021613.20758.9.camel@hsa.vpn.anti> <20100319213125.GJ69383@Space.Net> Message-ID: <3ADC1887-6236-466C-BF04-50F22B5B7A7E@sackheads.org> On Mar 19, 2010, at 5:31 PM, Gert Doering wrote: > Hi, > > On Fri, Mar 19, 2010 at 02:15:33PM -0400, John Payne wrote: >>> "From Microsoft's perspective, IPv6 is a mandatory part of the Windows >>> operating system [...] Therefore, Microsoft recommends that you leave >>> IPv6 enabled, even if you do not have an IPv6-enabled network, either >>> native or tunneled." > [..] >> Unfortunately, read this from an enterprise security perspective. >> Home group I do not care about. >> DirectAccess == "Please put my enterprise security 100% in the hands of my Windows Admins" > > No need to use DirectAccess (and *that* can be turned off just fine, > or specifically, not installed in the first place). > > But given the sad state of "commercial VPN clients on client OSes", I > rather like DirectAccess. (Not that there is nothing that prevents > putting the DA Server in a well-controlled firewall DMZ zone, and > have IPv6 firewalling in place between the DA server and the rest of > the enterprise network). > >> Teredo == "Please disregard any access controls I have in place at my network perimeter" > > Teredo can be turned off as well. > > The point is: IPv6 in Windows Land is there to stay. So for a prudent > enterprise network admin, the way forward is: accept life, accept IPv6, > and integrate it in your security concepts. Turn off Teredo and 6to4 > on the machines, give them native IPv6, and control native IPv6 on the > firewalls the same way IPv4 is controlled. > > If said network admin choses to ignore IPv6, and pretend it doesn't > exist, Teredo etc. are going to bite him in the back side. My point was mostly that the article saying is saying don't turn of IPv6 because it breaks these things. However all those things are things that enterprises _want_ broken :p Teredo is a royal PITA. The people running the firewalls often don't care about the client OS. The end users have been instructed not to tunnel. The windows admins don't care about IPv6, so why would they notice this auto tunneling thing? Ah well... at least we had some warning about Teredo and the likes a couple of years ago. Enough to block at the firewall regardless. From frnkblk at iname.com Fri Mar 19 23:57:53 2010 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 19 Mar 2010 17:57:53 -0500 Subject: Logon scripts to enable IPv6? In-Reply-To: References: Message-ID: This is what I have thus far: Windows XP SP2 ipv6 install netsh interface ipv6 install netsh interface ipv6 set privacy enabled persistent netsh interface ipv6 set teredo disabled netsh int ipv6 renew Windows Vista/7 REM netsh interface ipv6 add dns "Local Area Connection" 2607:fe28:xxxx::1 netsh interface ipv6 reset netsh interface ipv6 set privacy state=enable netsh interface ipv6 6to4 set state disabled default netsh interface ipv6 isatap set state disabled netsh interface ipv6 set teredo disabled Frank -----Original Message----- From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of Frank Bulk - iName.com Sent: Friday, March 19, 2010 10:29 AM To: ipv6-ops at lists.cluenet.de Subject: Logon scripts to enable IPv6? Has anyone developed or come across Windows logon scripts that enables IPv6 and turns off all 6to4, ISATAP, and Teredo for Windows XP SP2, Vista, and 7? I'm looking to deploy native IPv6 access (SLAAC-based) across our 60-node corporate network, and I'd rather do it via logon scripts than policies. Regards, Frank From brian.e.carpenter at gmail.com Sat Mar 20 00:44:21 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 20 Mar 2010 12:44:21 +1300 Subject: On killing IPv6 transition mechanisms In-Reply-To: <3ADC1887-6236-466C-BF04-50F22B5B7A7E@sackheads.org> References: <20100316145247.GC69383@Space.Net> <20100316191404.GI69383@Space.Net> <20100318113010.GL69383@Space.Net> <4BA278D7.40206@ipinc.net> <20100319093511.GL69383@Space.Net> <1269021613.20758.9.camel@hsa.vpn.anti> <20100319213125.GJ69383@Space.Net> <3ADC1887-6236-466C-BF04-50F22B5B7A7E@sackheads.org> Message-ID: <4BA40C55.8020703@gmail.com> On 2010-03-20 10:46, John Payne wrote: > ... The end users have been instructed not to tunnel. My heart goes out to operators whose end users disobey orders. Seriously: it's very simple. If you don't like your users using the self-deploying mechanisms, provide a good native IPv6 service. Nobody will care if you subsequently block protocol 41. But don't do it in the opposite order. Brian From ivan at main.uusia.org Sun Mar 21 13:16:03 2010 From: ivan at main.uusia.org (Ivan Shmakov) Date: Sun, 21 Mar 2010 18:16:03 +0600 Subject: On killing IPv6 transition mechanisms References: <1268307617.2878.31.camel@hsa.vpn.anti> <2e8c64261003110356x1d4466c2oa101d59be9105c9c@mail.gmail.com> <4B98DAD5.9040607@netability.ie> <1268310122.2878.57.camel@hsa.vpn.anti> <87634zwf0d.fsf@violet.siamics.net> <20100314103642.GF69383@Space.Net> <87wrxfunct.fsf@violet.siamics.net> <4B9D2D52.8040003@he.net> Message-ID: <87zl21ooos.fsf@violet.siamics.net> >>>>> Alex Broque writes: >>>>> Ivan Shmakov wrote: [...] >> I know the difference. The problem is that HE.net offers just a few >> /64, and I need somewhat larger address space. And they don't seem >> to offer reverse DNS, which is available for 6to4. > Just want to clarify some points. We've offered reverse DNS > delegation for the /64 statically routed subnet since at least 2003, > although it was a lot more manual configuration on our side back > then. Then the /48 subnets since early 2008, which ushered in a more > automated process for delegation for both /64 and /48 subnets. And > yes, those are the only subnets that the user gets delegation control > over. So, I've set up an rDNS zone for my home /64 network. (Still have to submit the KSK to https://dlv.isc.org/.) >> Well, it seems that HE.net operates a 6to4 relay that's open for >> those subscribed to their 6in4 service. > These are actually publicly available relays, and not limited to our > tunnelbroker.net users. Those users obviously would be using static > tunnels from that service, not tunnels based on the 6to4 well known > anycasted ranges. BTW, I've checked it and it indeed works for those IPv4 addresses that weren't configured as tunnel endpoints on tunnelbroker.net. Most probably I was bitten by some other issue while trying to configure it earlier. (Perhaps it has something to do with the fact that while I'm sending packets to a unicast IPv4, I still get replies from an anycast address.) For now, I have set up ::/0 routes over both 6to4 and 6in4 tunnels, so that a few hosts that were previosly unavailable (like packages.debian.org and tools.ietf.org) now work. -- FSF associate member #7257 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100321/0b23d322/attachment.bin From ivan at main.uusia.org Sun Mar 21 13:48:41 2010 From: ivan at main.uusia.org (Ivan Shmakov) Date: Sun, 21 Mar 2010 18:48:41 +0600 Subject: On killing IPv6 transition mechanisms References: <87634zwf0d.fsf@violet.siamics.net> <28E139F46D45AF49A31950F88C4974580576EE55@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <87vdcpon6e.fsf@violet.siamics.net> >>>>> michael.dillon at bt.com writes: [...] >> With regards to leaving this ISP and looking for another, the state >> of the local market seemed (the last time I've checked it) so >> bitter, that I've chosen to make a deal with an ISP in another city >> instead, connecting to them with OpenVPN. > Hopefully the other city is Novosibirsk, the 3rd largest in the > Russian Federation. Actually, no. However, the state of the local Internet access market was in a constant change throughout the last ten years or so. (Before that, Internet access was, to my perception, quite expensive for the ?mere humans?.) In particular, one of the local ISP's has recently offered twice the bandwidth I have for almost the same price, and they claim to offer a routable IPv4 for free as well. However, the area for which the offer is valid is very limited at this moment. [...] > Also, lobby your government. The federal government in Russia has > been taking several actions recently to improve the high tech > economy. I believe that some of these actions involve IPv6. Unfortunately, the politicians don't do computer networks. And one doesn't get anything hi-tech by words alone. There should be some people experienced in the problem as well. > But one thing is certain, the federal government is ready to listen > to people who have suggestions that can help grow the high tech > economy in Russia. You shouldn't have to move to a city like > Akademgorodok or Nizhniy Novgorod to participate. Well, I think that I could say that I participate, to some extent, in such an ?activity?. But then, I actually had to visit Akademgorodok twice over the past 6 months, and will probably have to have a trip or two in the near future. -- FSF associate member #7257 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100321/1a8784ae/attachment.bin From michael.dillon at bt.com Mon Mar 22 15:43:39 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Mar 2010 14:43:39 -0000 Subject: On killing IPv6 transition mechanisms In-Reply-To: <87vdcpon6e.fsf@violet.siamics.net> Message-ID: <28E139F46D45AF49A31950F88C497458058E2736@E03MVZ2-UKDY.domain1.systemhost.net> > > Also, lobby your government. The federal government in > Russia has > been taking several actions recently to improve > the high tech > economy. I believe that some of these > actions involve IPv6. > > Unfortunately, the politicians don't do computer networks. > > And one doesn't get anything hi-tech by words alone. There > should be some people experienced in the problem as well. It looks like politicians in Minkomsvyaz are already listening and the next dialog with the EU is at the end of April. Maybe you should ask colleagues on the EU side of the dialog to communicate the importance of IPv6 development in the regions, not just in Moscow and Piter. The federal government has already invested a lot in putting sites like on the Internet. In order to benefit from that investment, they also need to invest in widespread Internet access in smaller towns and villages. And it is not only the Internet in Russia that is changing address formats The fact is that to get the Internet rolled out to the rest of the world's population we need IPv6 everywhere. Only IPv6 provides enough address space to do the job, and if politicians and business people don't yet understand this, *WE* the knowledgable experts have to tell them. It's the same in every country. --Michael Dillon From mir at ripe.net Thu Mar 25 15:29:24 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 25 Mar 2010 15:29:24 +0100 Subject: Measuring IPv6 at Web Clients and Caching Resolvers In-Reply-To: References: Message-ID: <4BAB7344.9080908@ripe.net> [apologies for duplicates] Dear colleagues, We prototyped a method to measure the IPv6 capabilities of caching DNS resolvers that end-users use when browsing the web. The results of these measurements are now published on RIPE Labs: 1. A summary of the measurements and results can be found here: http://labs.ripe.net/content/measuring-ipv6-web-clients-and-caching-resolvers-part-1 2. Some more detailed analysis (including a breakdown of IPv6 usage per country and city) are here: http://labs.ripe.net/content/measuring-ipv6-web-clients-and-caching-resolvers-part-2-country-level-and-other-statistics 3. The methodology we use for these measurements are described here: http://labs.ripe.net/content/measuring-ipv6-web-clients-and-caching-resolvers-part-3-methodology All articles can be accessed from the RIPE Labs home page at http://labs.ripe.net If you have any comments or suggestions, please do not hesitate to submit them to the RIPE Labs forum or send them directly to me. Kind Regards, Mirjam Kuehne RIPE NCC From Francis.Dupont at fdupont.fr Thu Mar 25 22:42:45 2010 From: Francis.Dupont at fdupont.fr (Francis Dupont) Date: Thu, 25 Mar 2010 22:42:45 +0100 Subject: VM systems and IPv6? In-Reply-To: Your message of Thu, 18 Mar 2010 14:13:01 +0100. <87ljdp6aea.fsf@nemi.mork.no> Message-ID: <201003252142.o2PLgjNr085550@givry.fdupont.fr> >From time to time the multicast ops are considered as privileged (IMHO a confusion with promiscuous) so IPv6 ND doesn't work. A simple solution is to run as root or at least in a group with write access. BTW this doesn't affect broadcast. Francis.Dupont at fdupont.fr PS: the worst case I saw is IPv6 working only when the issue was under debug with tcpdump. Looked funny only after... From kiwi at oav.net Sun Mar 28 16:15:35 2010 From: kiwi at oav.net (Xavier Beaudouin) Date: Sun, 28 Mar 2010 16:15:35 +0200 Subject: IPv6 Load Balancer Message-ID: Hi there, I am looking about ... IPv6 Load Balancer, I did some research (not so long, but some few months ago), but it seems that Load Balancer vendors are not too much ready for LB ipv6. I'm going to use OpenBSD Relayd to replace my old... F5 Big/IP... But... If there is a opensource way to make real LB and usuable I will be pleased to test... /Xavier From tore.anderson at redpill-linpro.com Sun Mar 28 16:29:14 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sun, 28 Mar 2010 16:29:14 +0200 (CEST) Subject: IPv6 Load Balancer In-Reply-To: <633850628.3409.1269786342888.JavaMail.root@claudius.linpro.no> Message-ID: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> * Xavier Beaudouin > I am looking about ... IPv6 Load Balancer, I did some research (not so > long, but some few months ago), but it seems that Load Balancer > vendors are not too much ready for LB ipv6. > > I'm going to use OpenBSD Relayd to replace my old... F5 Big/IP... > But... If there is a opensource way to make real LB and usuable I will > be pleased to test... Your F5 box should support IPv6, at least if it has got a fairly recent code on it. Other than that, HAProxy and nginx comes to mind. I think you could even use Varnish as a pure load balancer although that's not really what it's designed for. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From frnkblk at iname.com Sun Mar 28 18:59:30 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 28 Mar 2010 11:59:30 -0500 Subject: IPv6 Load Balancer In-Reply-To: References: Message-ID: These are my notes from last fall: A10 Networks: today Barracuda Networks: nothing on website; Foundry (Brocade) ServerIron: they support IPv6 in the 11.x loads. Coyote: "We can commit to the fact that the Coyote Point Systems Equalizers in production today (GX platform family) will support IPV6. I suspect that the earliest you will see this capability is 4th Quarter 2010." F5 BigIP: yes Kemp: does not have a solution, though it is on the horizon Zeus: zxtm has support http://www.zeus.com/products/load-balancer/index.html Frank -----Original Message----- From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of Xavier Beaudouin Sent: Sunday, March 28, 2010 9:16 AM To: ipv6-ops at lists.cluenet.de Subject: IPv6 Load Balancer Hi there, I am looking about ... IPv6 Load Balancer, I did some research (not so long, but some few months ago), but it seems that Load Balancer vendors are not too much ready for LB ipv6. I'm going to use OpenBSD Relayd to replace my old... F5 Big/IP... But... If there is a opensource way to make real LB and usuable I will be pleased to test... /Xavier= From paul at paulstewart.org Sun Mar 28 20:54:48 2010 From: paul at paulstewart.org (Paul Stewart) Date: Sun, 28 Mar 2010 14:54:48 -0400 Subject: IPv6 Load Balancer In-Reply-To: References: Message-ID: <054c01cacea8$23f58140$6be083c0$@org> Just to add to the Barracuda front - when we bought some of their gear we were told that IPv6 was in the plans. Granted that they gave us no timeline we recently went back to them explaining that we need it *now* .. they told us it's based on customer demand and maybe by end of year...;( -----Original Message----- From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf Of Frank Bulk Sent: March-28-10 12:59 PM To: 'Xavier Beaudouin'; ipv6-ops at lists.cluenet.de Subject: RE: IPv6 Load Balancer These are my notes from last fall: A10 Networks: today Barracuda Networks: nothing on website; Foundry (Brocade) ServerIron: they support IPv6 in the 11.x loads. Coyote: "We can commit to the fact that the Coyote Point Systems Equalizers in production today (GX platform family) will support IPV6. I suspect that the earliest you will see this capability is 4th Quarter 2010." F5 BigIP: yes Kemp: does not have a solution, though it is on the horizon Zeus: zxtm has support http://www.zeus.com/products/load-balancer/index.html Frank -----Original Message----- From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de [mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of Xavier Beaudouin Sent: Sunday, March 28, 2010 9:16 AM To: ipv6-ops at lists.cluenet.de Subject: IPv6 Load Balancer Hi there, I am looking about ... IPv6 Load Balancer, I did some research (not so long, but some few months ago), but it seems that Load Balancer vendors are not too much ready for LB ipv6. I'm going to use OpenBSD Relayd to replace my old... F5 Big/IP... But... If there is a opensource way to make real LB and usuable I will be pleased to test... /Xavier= From phrickman at upcbroadband.com Sun Mar 28 20:55:39 2010 From: phrickman at upcbroadband.com (Rickman, Phil) Date: Sun, 28 Mar 2010 20:55:39 +0200 Subject: IPv6 Load Balancer In-Reply-To: References: Message-ID: Radware and F5 Both are IPv 6 capable ... altho Radware are just bringing out the new image for allowing DS on a single interface. Phil Rickman NDA DD - +31 207 789 969 Mob: +31 610847604 ________________________________________ From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of Xavier Beaudouin [kiwi at oav.net] Sent: 28 March 2010 16:15 To: ipv6-ops at lists.cluenet.de Subject: IPv6 Load Balancer Hi there, I am looking about ... IPv6 Load Balancer, I did some research (not so long, but some few months ago), but it seems that Load Balancer vendors are not too much ready for LB ipv6. I'm going to use OpenBSD Relayd to replace my old... F5 Big/IP... But... If there is a opensource way to make real LB and usuable I will be pleased to test... /Xavier From kiwi at oav.net Mon Mar 29 10:54:07 2010 From: kiwi at oav.net (Xavier Beaudouin) Date: Mon, 29 Mar 2010 10:54:07 +0200 Subject: IPv6 Load Balancer In-Reply-To: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> References: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> Message-ID: Hi :) Le 28 mars 2010 ? 16:29, Tore Anderson a ?crit : > * Xavier Beaudouin > >> I am looking about ... IPv6 Load Balancer, I did some research (not so >> long, but some few months ago), but it seems that Load Balancer >> vendors are not too much ready for LB ipv6. >> >> I'm going to use OpenBSD Relayd to replace my old... F5 Big/IP... >> But... If there is a opensource way to make real LB and usuable I will >> be pleased to test... > > Your F5 box should support IPv6, at least if it has got a fairly recent > code on it. Hum... It's too old : v4.2 (the old one that didn't needs to be validated by central F5 repo when you change IPs...). > Other than that, HAProxy and nginx comes to mind. I think you could even > use Varnish as a pure load balancer although that's not really what it's > designed for. Thats's good for http, not for "everything"... And since we are non profit, we don't have budget for big LB ... even if we'd like to have a SI350 :) Xavier From tore.anderson at redpill-linpro.com Mon Mar 29 11:49:08 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 29 Mar 2010 11:49:08 +0200 Subject: IPv6 Load Balancer In-Reply-To: References: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> Message-ID: <4BB07794.6070001@redpill-linpro.com> * Xavier Beaudouin >> Other than that, HAProxy and nginx comes to mind. I think you >> could even use Varnish as a pure load balancer although that's not >> really what it's designed for. > > Thats's good for http, not for "everything"... HAProxy will happily do layer 4 (TCP) load balancing, doesn't have to be HTTP traffic. Performance is excellent, and it supports IPv6 just fine. I think you'll have a hard time finding a better open-source solution than HAProxy for layer 4 load-balancing. BR, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From pnl at ielo.net Mon Mar 29 12:29:28 2010 From: pnl at ielo.net (Bertrand Yvain) Date: Mon, 29 Mar 2010 12:29:28 +0200 Subject: IPv6 Load Balancer In-Reply-To: <4BB07794.6070001@redpill-linpro.com> References: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> <4BB07794.6070001@redpill-linpro.com> Message-ID: <20100329102928.GW2726@nexus6.adm.ielo.net> On Mon, Mar 29, 2010 at 11:49:08AM +0200, Tore Anderson wrote: > HAProxy will happily do layer 4 (TCP) load balancing Sure... but those load-balancing proxies are just that: proxies. IMHO, load balancers should do NAT or direct routing so that real servers do receive source IP address and port number. -- Bertrand Yvain http://www.IELO.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100329/5fce61b0/attachment.bin From jeroen at unfix.org Mon Mar 29 13:16:29 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 29 Mar 2010 13:16:29 +0200 Subject: IPv6 Load Balancer In-Reply-To: <20100329102928.GW2726@nexus6.adm.ielo.net> References: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> <4BB07794.6070001@redpill-linpro.com> <20100329102928.GW2726@nexus6.adm.ielo.net> Message-ID: <4BB08C0D.7060803@spaghetti.zurich.ibm.com> Bertrand Yvain wrote: > On Mon, Mar 29, 2010 at 11:49:08AM +0200, Tore Anderson wrote: >> HAProxy will happily do layer 4 (TCP) load balancing > > Sure... but those load-balancing proxies are just that: proxies. > > IMHO, load balancers should do NAT or direct routing so that real > servers do receive source IP address and port number. apt-get install mod_rpaf Which uses the X-Forwarded-For. If you want to also see the source port you can at least with NGINX add a special header which includes that, which of course can easily be read by any backend tool that you have. 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/20100329/d6e1b307/attachment.bin From tore.anderson at redpill-linpro.com Mon Mar 29 14:13:39 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 29 Mar 2010 14:13:39 +0200 Subject: IPv6 Load Balancer In-Reply-To: <20100329102928.GW2726@nexus6.adm.ielo.net> References: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> <4BB07794.6070001@redpill-linpro.com> <20100329102928.GW2726@nexus6.adm.ielo.net> Message-ID: <4BB09973.20104@redpill-linpro.com> Hi, * Bertrand Yvain > Sure... but those load-balancing proxies are just that: proxies. I'm not sure what you trying to say. Most load-balancing solutions sits in front of the application servers and proxy the incoming requests to them. The only common form of load-balancing that does not proxy requests that I can think of right now is round-robin DNS. > IMHO, load balancers should do NAT or direct routing so that real > servers do receive source IP address and port number. Some people want that, sure. Some people don't - that way the load balancer doesn't have to also operate as a default gateway for the servers. Some people (read: me) also really like the opportunity to proxy the requests from one IP version to another, which makes it really easy to provide IPv6 service since only the load balancers needs to have any idea of what IPv6 is - everything behind them can continue to speak IPv4. In this case, the source address can obviously not be retained. But as Jeroen pointed out, you can put it into an X-Forwarded-For header in the HTTP case, at least. In any case, all of these modes of operation are supported by both HAProxy and F5 BIG-IP LTM boxes, so you'll have to look at the rest of the feature set, and obviously your budget, when deciding which one you want. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From pnl at ielo.net Mon Mar 29 15:51:37 2010 From: pnl at ielo.net (Bertrand Yvain) Date: Mon, 29 Mar 2010 15:51:37 +0200 Subject: IPv6 Load Balancer In-Reply-To: <4BB09973.20104@redpill-linpro.com> References: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> <4BB07794.6070001@redpill-linpro.com> <20100329102928.GW2726@nexus6.adm.ielo.net> <4BB09973.20104@redpill-linpro.com> Message-ID: <20100329135137.GX2726@nexus6.adm.ielo.net> On Mon, Mar 29, 2010 at 02:13:39PM +0200, Tore Anderson wrote: > * Bertrand Yvain > > > Sure... but those load-balancing proxies are just that: proxies. > > I'm not sure what you trying to say. Most load-balancing solutions sits > in front of the application servers and proxy the incoming requests to > them. The only common form of load-balancing that does not proxy > requests that I can think of right now is round-robin DNS. In my understanding, NAT or DR are not proxying methods. Proxying implies the creation of another full request stack. Would you say that a NAT gateway is an IP proxy? > > IMHO, load balancers should do NAT or direct routing so that real > > servers do receive source IP address and port number. > > Some people want that, sure. Some people don't - that way the load > balancer doesn't have to also operate as a default gateway for the > servers. Please note that this is not required if you operate in direct routing: only the client to server direction needs to/should flow through the load balancer. Multi-gigabit throughput can be achieved on commodity hardware. > Some people (read: me) also really like the opportunity to > proxy the requests from one IP version to another, which makes it really > easy to provide IPv6 service since only the load balancers needs to have > any idea of what IPv6 is - everything behind them can continue to speak > IPv4. This is indeed very pleasing, though native IPv6 is not that hard to implement in a server farm. > In this case, the source address can obviously not be retained. But > as Jeroen pointed out, you can put it into an X-Forwarded-For header > in the HTTP case, at least. I still consider this quite kludgy, and HTTP is the only protocol I can think of that has provision for that. There are also other benefits to "full stack" proxies: reuse of TCP connections, large MTU, etc. Anyway... as you pointed out, different needs call to different solutions. I believe that Xavier (original poster) was looking for NAT/DR load balancers. Linux IPVS is my personnal favourite but I have no production experience with it's IPv6 version (which is shipped with mainline kernel since 2.6.28, I believe). Cheers, -- Bertrand Yvain http://www.IELO.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100329/fc0933db/attachment.bin From tore.anderson at redpill-linpro.com Mon Mar 29 22:04:44 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 29 Mar 2010 22:04:44 +0200 Subject: IPv6 Load Balancer In-Reply-To: <20100329135137.GX2726@nexus6.adm.ielo.net> References: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> <4BB07794.6070001@redpill-linpro.com> <20100329102928.GW2726@nexus6.adm.ielo.net> <4BB09973.20104@redpill-linpro.com> <20100329135137.GX2726@nexus6.adm.ielo.net> Message-ID: <4BB107DC.60801@redpill-linpro.com> * Bertrand Yvain >>> Sure... but those load-balancing proxies are just that: proxies. > > In my understanding, NAT or DR are not proxying methods. Proxying > implies the creation of another full request stack. I see what you mean. You're right, it is probably not semantically correct to call load-balancer, that only does packet forwarding and L3/L4 header rewriting, a proxy. However, my point was that you... >>> IMHO, load balancers should do NAT or direct routing so that >>> real servers do receive source IP address and port number. ...appeared to imply that ?proper? load balancers are only those that do L3/L4 header rewriting and packet-by-packet forwarding. I disagree; a load balancer that operates in proxy mode will balance load just as much as one that does packet mode, and the proxy mode one will usually be much more flexible in what you can make it do. It's not without reason that F5's BIG-IP load balancers will by default use proxy mode - in packet mode you lose the ability to use much of the iRule stuff. Whether or not the real servers see the original IP address of the client in their incoming IP packet or not is completely independent of whether or not packet or proxy mode is used. > Multi-gigabit throughput can be achieved on commodity hardware. Well, yes. But packet vs. proxy mode doesn't really make much of a difference here either. A modern x86 server with HAProxy will happily push many Gb, so will a F5 BIG-IP (which is just x86 inside nowadays). > native IPv6 is not that hard to implement in a server farm. Depends on the size of the server farm and the number of applications on it... Numbering the servers themselves is super-easy, making hundreds of applications that are running on those servers start talking to each other over IPv6 - now that's the challenge. In general I don't see it as worth-while attempting a conversion, as long as IPv6 service can be provided at the front-end layer. In a while we'll probably do the exact opposite for new customers/installations: running single-stack IPv6 in the backend networks and terminating IPv4 only at the frontends/load balancers. I don't want to be running a combination of both (ie. dual-stack) in the backend unless it's absolutely necessary for some reason - too much administrative overhead. > Anyway... as you pointed out, different needs call to different > solutions. I believe that Xavier (original poster) was looking for > NAT/DR load balancers. Linux IPVS is my personnal favourite but I > have no production experience with it's IPv6 version (which is > shipped with mainline kernel since 2.6.28, I believe). Xavier said he wanted to replace a BIG-IP box with an open-source product... and HAProxy is probably the open-source product that operates in the most similar way and has the most similar feature list. Though if he's only interested in L3/L4 rewriting/packet-by-packet balancing then IPVS is a good choice, I agree. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From kiwi at oav.net Tue Mar 30 01:04:26 2010 From: kiwi at oav.net (Xavier Beaudouin) Date: Tue, 30 Mar 2010 01:04:26 +0200 Subject: IPv6 Load Balancer In-Reply-To: <4BB107DC.60801@redpill-linpro.com> References: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> <4BB07794.6070001@redpill-linpro.com> <20100329102928.GW2726@nexus6.adm.ielo.net> <4BB09973.20104@redpill-linpro.com> <20100329135137.GX2726@nexus6.adm.ielo.net> <4BB107DC.60801@redpill-linpro.com> Message-ID: <4F2B1639-4480-4BA2-B702-8EDAB85E39FA@oav.net> Hi there, Le 29 mars 2010 ? 22:04, Tore Anderson a ?crit : > * Bertrand Yvain > >>>> Sure... but those load-balancing proxies are just that: proxies. >> >> In my understanding, NAT or DR are not proxying methods. Proxying >> implies the creation of another full request stack. > > I see what you mean. You're right, it is probably not semantically > correct to call load-balancer, that only does packet forwarding and > L3/L4 header rewriting, a proxy. However, my point was that you... By the way this is what I was looking, I didn't say proxy. >>>> IMHO, load balancers should do NAT or direct routing so that >>>> real servers do receive source IP address and port number. > > ...appeared to imply that ?proper? load balancers are only those that do > L3/L4 header rewriting and packet-by-packet forwarding. I disagree; a > load balancer that operates in proxy mode will balance load just as much > as one that does packet mode, and the proxy mode one will usually be > much more flexible in what you can make it do. It's not without reason > that F5's BIG-IP load balancers will by default use proxy mode - in > packet mode you lose the ability to use much of the iRule stuff. > > Whether or not the real servers see the original IP address of the > client in their incoming IP packet or not is completely independent of > whether or not packet or proxy mode is used Hum.. proxy are good, if the proxiefied backend support the fact the IP address is not really the same as it is connected to.... For example, how can you do p0f with this kind of stuff ? LB that work only on packet level (L2/L3) can run unmodified servers... without hacking it to make it run like real life. And for example if you have several proxies like : ->Proxy/LB---> Nginx (for static files)---> apache (for PHP stuff and nasty things) You have play with nginx then apache... etc... and add lots of bugs... [...] >> Anyway... as you pointed out, different needs call to different >> solutions. I believe that Xavier (original poster) was looking for >> NAT/DR load balancers. Linux IPVS is my personnal favourite but I >> have no production experience with it's IPv6 version (which is >> shipped with mainline kernel since 2.6.28, I believe). > > Xavier said he wanted to replace a BIG-IP box with an open-source > product... and HAProxy is probably the open-source product that > operates in the most similar way and has the most similar feature list. > Though if he's only interested in L3/L4 rewriting/packet-by-packet > balancing then IPVS is a good choice, I agree. I don't like HAProxy... I'm mostly a BSD guy, L3/L4 rewriting packet and proxy can be done with IPVS (but, I don't like the way of Linux works with IPv6, but this is my own way of thinking...), but I try to find another alternative to relayd... Do someone has tested this here? relayd : https://calomel.org/relayd.html The documentation shown here doesn't show IPv6, but it support it... Now on the opensource world we have : - ipvs - relayd - mostly sldb (but I dunno if this IPv6 compliant) and... Blackbox stuff :) Any other ideas ? /Xavier From mohacsi at niif.hu Tue Mar 30 11:42:31 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 30 Mar 2010 11:42:31 +0200 (CEST) Subject: IPv6 Load Balancer In-Reply-To: <4F2B1639-4480-4BA2-B702-8EDAB85E39FA@oav.net> References: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> <4BB07794.6070001@redpill-linpro.com> <20100329102928.GW2726@nexus6.adm.ielo.net> <4BB09973.20104@redpill-linpro.com> <20100329135137.GX2726@nexus6.adm.ielo.net> <4BB107DC.60801@redpill-linpro.com> <4F2B1639-4480-4BA2-B702-8EDAB85E39FA@oav.net> Message-ID: On Tue, 30 Mar 2010, Xavier Beaudouin wrote: > > Now on the opensource world we have : > - ipvs > - relayd > - mostly sldb (but I dunno if this IPv6 compliant) sldb was not ipv6 capable 2 years ago. Regards, Janos Mohacsi From tore.anderson at redpill-linpro.com Tue Mar 30 11:50:31 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 30 Mar 2010 11:50:31 +0200 Subject: IPv6 Load Balancer In-Reply-To: <4F2B1639-4480-4BA2-B702-8EDAB85E39FA@oav.net> References: <1489457828.3412.1269786554164.JavaMail.root@claudius.linpro.no> <4BB07794.6070001@redpill-linpro.com> <20100329102928.GW2726@nexus6.adm.ielo.net> <4BB09973.20104@redpill-linpro.com> <20100329135137.GX2726@nexus6.adm.ielo.net> <4BB107DC.60801@redpill-linpro.com> <4F2B1639-4480-4BA2-B702-8EDAB85E39FA@oav.net> Message-ID: <4BB1C967.7060407@redpill-linpro.com> Hi again, * Xavier Beaudouin > Hum.. proxy are good, if the proxiefied backend support the fact the > IP address is not really the same as it is connected to.... > > For example, how can you do p0f with this kind of stuff ? > > LB that work only on packet level (L2/L3) can run unmodified > servers... without hacking it to make it run like real life. No modification on the real servers is necessary, regardless of it being in packet or proxy mode. The real server thinks it's talking to the remote client. With the LB in packet mode, that's actually the case - the LB does not rewrite the source address field in the IP header. With the LB in proxy mode, the real server isn't talking to the end client, but it appears so anyway because the LB is using the original client's IP address as the source when making the connection to the back-end. So there's really no difference between the two from the real server's point of view. In both cases though, the server needs to be set up to be using the LB as the default router. Except for the "direct routing" mode mentioned by Bertrand where traffic only flows uni-directionally across the LB, that will only work in packet mode (you'll have to make sure the virtual IP address is present on every real-server too in that case, and possibly filter out any ARP/ND traffic involving that address in order to prevent the real-server from accidentally grabbing all the traffic). > And for example if you have several proxies like : > > ->Proxy/LB---> Nginx (for static files)---> apache (for PHP stuff and > nasty things) > > You have play with nginx then apache... etc... and add lots of > bugs... I would not have daisy-chained nginx and Apache behind an LB like that, if I were you, but instead put the different functions at the same level, all right behind the load balancer, and used L7 switching in order to route the requests to the right back-end system. For example: /->- /static/* ->- (lighttpd cluster) / (client)->-- [LB www.foo.com] +--->- /php/* ---->- (Apache/PHP cluster) \ \->- /search/* ->- (GoogleMini box) This type of setup can't be done with a LB operating in packet mode like IPVS. You'll need something that can do proxy mode and L7 like for instance nginx, HAProxy, or F5 BIG-IP LTM. I'm not sure if nginx supports retaining/spoofing the client's IP address in the back-end connections though, like HAProxy does. Or if HAProxy supports it on any other OS than Linux for that matter. Anyway, this exchange has not much to do with IPv6 anymore, so I won't be posting more to the list about it - do feel free to contact me directly if you want more input, though. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From tore.anderson at redpill-linpro.com Tue Mar 30 12:40:10 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 30 Mar 2010 12:40:10 +0200 Subject: Linux utility for sending unsolicited neighbor advertisements Message-ID: <4BB1D50A.5000409@redpill-linpro.com> Hi list, I'm wondering if any of you know of a utility (for Linux) that can send unsolicited neighbor advertisements as described in RFC 2461 section 7.2.6? Something to match the functionality of "arping -U" in IPv4, that is. Unsolicited neighbor advertisements appears necessary to facilitate rapid service address takeover in a HA cluster, but so far I've had no luck finding anything that can do it. BR, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From lists at quux.de Tue Mar 30 13:04:04 2010 From: lists at quux.de (Jens Link) Date: Tue, 30 Mar 2010 13:04:04 +0200 Subject: Linux utility for sending unsolicited neighbor advertisements In-Reply-To: <4BB1D50A.5000409@redpill-linpro.com> (Tore Anderson's message of "Tue\, 30 Mar 2010 12\:40\:10 +0200") References: <4BB1D50A.5000409@redpill-linpro.com> Message-ID: <87pr2m2hqz.fsf@bowmore.quux.de> Tore Anderson writes: Hi, > Hi list, > > I'm wondering if any of you know of a utility (for Linux) that can send > unsolicited neighbor advertisements as described in RFC 2461 section > 7.2.6? Something to match the functionality of "arping -U" in IPv4, > that is. http://freeworld.thc.org/thc-ipv6/ ? Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From gert at space.net Tue Mar 30 13:27:14 2010 From: gert at space.net (Gert Doering) Date: Tue, 30 Mar 2010 13:27:14 +0200 Subject: Windows 7 and SLAAC? Message-ID: <20100330112714.GO69383@Space.Net> Hi, I did an IPv6 training for a customer today, and discovered something interesting - Windows 7 doesn't use the MAC address of an interface for EUI64-based stateless autoconfiguration, but "something else". The host part is the same for the fe80:: and the global IPv6 address, but it's something completely unrelated to the MAC address. Does one of you have a pointer for me what Windows 7 is using here? Some sort of "windows installation global identifier"? WinXP uses the MAC address, have no Vista to test right now... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 tore.anderson at redpill-linpro.com Tue Mar 30 13:34:22 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 30 Mar 2010 13:34:22 +0200 Subject: Windows 7 and SLAAC? In-Reply-To: <20100330112714.GO69383@Space.Net> References: <20100330112714.GO69383@Space.Net> Message-ID: <4BB1E1BE.5060606@redpill-linpro.com> * Gert Doering > Does one of you have a pointer for me what Windows 7 is using here? Some > sort of "windows installation global identifier"? Hi Gert, I believe this is due to Windows 7 is using privacy extensions with SLAAC by default (RFC 4941). Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From gert at space.net Tue Mar 30 13:42:53 2010 From: gert at space.net (Gert Doering) Date: Tue, 30 Mar 2010 13:42:53 +0200 Subject: Windows 7 and SLAAC? In-Reply-To: <4BB1E1BE.5060606@redpill-linpro.com> References: <20100330112714.GO69383@Space.Net> <4BB1E1BE.5060606@redpill-linpro.com> Message-ID: <20100330114253.GQ69383@Space.Net> Hi, On Tue, Mar 30, 2010 at 01:34:22PM +0200, Tore Anderson wrote: > > Does one of you have a pointer for me what Windows 7 is using here? Some > > sort of "windows installation global identifier"? > > I believe this is due to Windows 7 is using privacy extensions with > SLAAC by default (RFC 4941). No, that's something else. I see two (global) IPv6 addresses on the link, one that keeps changing (privacy) and one that is static - but neither is related in any way to the card's MAC address. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100330/392abb42/attachment.bin From Jon.Harald.Bovre at hafslund.no Tue Mar 30 13:47:00 2010 From: Jon.Harald.Bovre at hafslund.no (=?Windows-1252?Q?B=F8vre_Jon_Harald?=) Date: Tue, 30 Mar 2010 13:47:00 +0200 Subject: SV: Windows 7 and SLAAC? In-Reply-To: <20100330114253.GQ69383@Space.Net> References: <20100330112714.GO69383@Space.Net> <4BB1E1BE.5060606@redpill-linpro.com>, <20100330114253.GQ69383@Space.Net> Message-ID: Copy/paste from this page: http://ipv6.net/ (check section 'Latest Post') You are right. Windows 7 (Server 2008 & Vista as well) by default randomizes ipv6 auto-configured address selection. This is in violation with section 4 of RFC 2464 that mandates that the network identifier part of the IPv6 address is derived from the 48-bit MAC address for Ethernet (and Wireless) interfaces. It may be that Microsoft chose to do this for privacy reasons.. For most users this will not be much of a problem but for those running a server it will. There is however a solution: netsh interface ipv6 set global randomizeidentifiers=disabled This will switch the feature off and address selection will be based upon the EUI-64 identifier, derived from the interface?s built-in 48-bit IEEE 802 address. jon ________________________________________ Fra: ipv6-ops-bounces+jon.harald.bovre=hafslund.no at lists.cluenet.de [ipv6-ops-bounces+jon.harald.bovre=hafslund.no at lists.cluenet.de] på vegne av Gert Doering [gert at space.net] Sendt: 30. mars 2010 13:42 Til: Tore Anderson Kopi: Gert Doering; ipv6-ops at lists.cluenet.de Emne: Re: Windows 7 and SLAAC? Hi, On Tue, Mar 30, 2010 at 01:34:22PM +0200, Tore Anderson wrote: > > Does one of you have a pointer for me what Windows 7 is using here? Some > > sort of "windows installation global identifier"? > > I believe this is due to Windows 7 is using privacy extensions with > SLAAC by default (RFC 4941). No, that's something else. I see two (global) IPv6 addresses on the link, one that keeps changing (privacy) and one that is static - but neither is related in any way to the card's MAC address. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 dhorn2000 at gmail.com Tue Mar 30 13:54:37 2010 From: dhorn2000 at gmail.com (David Horn) Date: Tue, 30 Mar 2010 07:54:37 -0400 Subject: Windows 7 and SLAAC? In-Reply-To: <20100330112714.GO69383@Space.Net> References: <20100330112714.GO69383@Space.Net> Message-ID: <25ff90d61003300454r1d21f43aoff9553e2f16feb0e@mail.gmail.com> On Tue, Mar 30, 2010 at 7:27 AM, Gert Doering wrote: > > Hi, > > I did an IPv6 training for a customer today, and discovered something > interesting - Windows 7 doesn't use the MAC address of an interface > for EUI64-based stateless autoconfiguration, but "something else". > > The host part is the same for the fe80:: and the global IPv6 address, > but it's something completely unrelated to the MAC address. > > Does one of you have a pointer for me what Windows 7 is using here? ?Some > sort of "windows installation global identifier"? > Microsoft has a "Cable Guy" article that describes Vista/Win 7 autoconf behavior, including the netsh CLI interface syntax for this particular setting. netsh interface ipv6 set global randomize?identifiers=disabled http://technet.microsoft.com/en-us/magazine/2007.08.cableguy.aspx for more information. Good Luck. ---_Dave Horn > > WinXP uses the MAC address, have no Vista to test right now... > > Gert Doering > ? ? ? ?-- NetMaster > -- > Total number of prefixes smaller than registry allocations: ?150584 > > 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 mir at ripe.net Tue Mar 30 16:45:11 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 30 Mar 2010 16:45:11 +0200 Subject: Spam sent over IPv6 - See results on RIPE Labs Message-ID: <4BB20E77.9060308@ripe.net> [apologies for duplicates] Dear colleagues, We were curious to see how much spam is sent over IPv6 these days. Find the results on RIPE Labs: http://labs.ripe.net/content/spam-over-ipv6 We will continue to measure this. If you have any comments or suggestions, please let us know. Kind Regards, Mirjam K?hne RIPE NCC From marcoh at marcoh.net Tue Mar 30 16:49:23 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 30 Mar 2010 16:49:23 +0200 Subject: For the dutchies: seeking trial customers Message-ID: Hi all, Sorry for the spam, I know this list is populated with not people from all over the world. XS4ALL a Dutch ISP is seeking 1000 customers to take part in a trial to get IPv6 native connectivity over ADSL. I you happen to live in NL and you have an XS4ALL connection at your home feel free to subscribe. More details can be found on the website: http://www.xs4all.nl/klant/ipv6/ Groet, MarcoH From swmike at swm.pp.se Tue Mar 30 18:02:32 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 30 Mar 2010 18:02:32 +0200 (CEST) Subject: Windows 7 and SLAAC? In-Reply-To: References: <20100330112714.GO69383@Space.Net> <4BB1E1BE.5060606@redpill-linpro.com>, <20100330114253.GQ69383@Space.Net> Message-ID: On Tue, 30 Mar 2010, B?vre Jon Harald wrote: > For most users this will not be much of a problem but for those running > a server it will. There is however a solution: I'd imagine people running servers will statically configure their address, not let it be done on basis of the mac address. What happens if you need to replace the hardware, do you really want to change DNS information then? From mohacsi at niif.hu Tue Mar 30 18:06:17 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 30 Mar 2010 18:06:17 +0200 (CEST) Subject: Windows 7 and SLAAC? In-Reply-To: References: <20100330112714.GO69383@Space.Net> <4BB1E1BE.5060606@redpill-linpro.com>, <20100330114253.GQ69383@Space.Net> Message-ID: On Tue, 30 Mar 2010, Mikael Abrahamsson wrote: > On Tue, 30 Mar 2010, B?vre Jon Harald wrote: > >> For most users this will not be much of a problem but for those running a >> server it will. There is however a solution: > > I'd imagine people running servers will statically configure their address, > not let it be done on basis of the mac address. What happens if you need to > replace the hardware, do you really want to change DNS information then? Agreed. Server should use manual addresses... However on windows environment the builtin dynamic dns update can help you keeping up-to-date the DNS zone files.... Best Regards, Janos Mohacsi From gert at space.net Tue Mar 30 18:07:38 2010 From: gert at space.net (Gert Doering) Date: Tue, 30 Mar 2010 18:07:38 +0200 Subject: Windows 7 and SLAAC? In-Reply-To: <25ff90d61003300454r1d21f43aoff9553e2f16feb0e@mail.gmail.com> References: <20100330112714.GO69383@Space.Net> <25ff90d61003300454r1d21f43aoff9553e2f16feb0e@mail.gmail.com> Message-ID: <20100330160738.GR69383@Space.Net> Hi, On Tue, Mar 30, 2010 at 07:54:37AM -0400, David Horn wrote: > Microsoft has a "Cable Guy" article that describes Vista/Win 7 > autoconf behavior, including the netsh CLI interface syntax for this > particular setting. > > netsh interface ipv6 set global randomize?identifiers=disabled > > http://technet.microsoft.com/en-us/magazine/2007.08.cableguy.aspx for > more information. Thanks to all that have responded. Yes indeed, this is what I was observing. It didn't actually cause any troubles, but I was telling people "IPv6 host part is built from the MAC address of that interface" and then one user then asked "ok, so I have *this* MAC and *that* IPv6 address, and I can't see any relationship"... - now I have an answer for him :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100330/6a2aa9ef/attachment.bin From Sam.Wilson at ed.ac.uk Tue Mar 30 18:18:40 2010 From: Sam.Wilson at ed.ac.uk (Sam Wilson) Date: Tue, 30 Mar 2010 17:18:40 +0100 Subject: Windows 7 and SLAAC? In-Reply-To: <25ff90d61003300454r1d21f43aoff9553e2f16feb0e@mail.gmail.com> References: <20100330112714.GO69383@Space.Net> <25ff90d61003300454r1d21f43aoff9553e2f16feb0e@mail.gmail.com> Message-ID: <274D8AA0-C4E1-4B1F-AABB-B37DC976ECBD@ed.ac.uk> On 30 Mar 2010, at 12:54, David Horn wrote: > On Tue, Mar 30, 2010 at 7:27 AM, Gert Doering wrote: >> >> Hi, >> >> I did an IPv6 training for a customer today, and discovered something >> interesting - Windows 7 doesn't use the MAC address of an interface >> for EUI64-based stateless autoconfiguration, but "something else". >> [snip] > >> > Microsoft has a "Cable Guy" article that describes Vista/Win 7 > autoconf behavior, including the netsh CLI interface syntax for this > particular setting. > > netsh interface ipv6 set global randomize identifiers=disabled > > http://technet.microsoft.com/en-us/magazine/2007.08.cableguy.aspx for > more information. That's a very useful article. I can't find in it (at a quick glance) anything that says whether the random address generation logic tries to generate the same (set of) random address(es) each time it is initialised. That would be a useful property for keeping tabs on machines and would save the hassle of DDNS and the like. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From tme at americafree.tv Tue Mar 30 19:04:57 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 30 Mar 2010 13:04:57 -0400 Subject: Windows 7 and SLAAC? In-Reply-To: <274D8AA0-C4E1-4B1F-AABB-B37DC976ECBD@ed.ac.uk> References: <20100330112714.GO69383@Space.Net> <25ff90d61003300454r1d21f43aoff9553e2f16feb0e@mail.gmail.com> <274D8AA0-C4E1-4B1F-AABB-B37DC976ECBD@ed.ac.uk> Message-ID: On Mar 30, 2010, at 12:18 PM, Sam Wilson wrote: > > On 30 Mar 2010, at 12:54, David Horn wrote: > >> On Tue, Mar 30, 2010 at 7:27 AM, Gert Doering wrote: >>> >>> Hi, >>> >>> I did an IPv6 training for a customer today, and discovered >>> something >>> interesting - Windows 7 doesn't use the MAC address of an interface >>> for EUI64-based stateless autoconfiguration, but "something else". >>> [snip] >> >>> >> Microsoft has a "Cable Guy" article that describes Vista/Win 7 >> autoconf behavior, including the netsh CLI interface syntax for this >> particular setting. >> >> netsh interface ipv6 set global randomize identifiers=disabled >> >> http://technet.microsoft.com/en-us/magazine/2007.08.cableguy.aspx >> for >> more information. > > That's a very useful article. I can't find in it (at a quick > glance) anything that says whether the random address generation > logic tries to generate the same (set of) random address(es) each > time it is initialised. That would be a useful property for keeping > tabs on machines and would save the hassle of DDNS and the like. > I would assume that these are not constant. RFCs 4941 describes "privacy extensions" that yield changing (pseudo) random interface IDs and RFC 5157 provides a background into why this is could be a good thing. Regards Marshall > Sam > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > From dougb at dougbarton.us Tue Mar 30 20:03:48 2010 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 30 Mar 2010 11:03:48 -0700 Subject: Windows 7 and SLAAC? In-Reply-To: <20100330160738.GR69383@Space.Net> References: <20100330112714.GO69383@Space.Net> <25ff90d61003300454r1d21f43aoff9553e2f16feb0e@mail.gmail.com> <20100330160738.GR69383@Space.Net> Message-ID: <4BB23D04.7050200@dougbarton.us> On 03/30/10 09:07, Gert Doering wrote: > It didn't actually cause any troubles, but I was telling people "IPv6 > host part is built from the MAC address of that interface" and then one > user then asked "ok, so I have *this* MAC and *that* IPv6 address, and I > can't see any relationship"... - now I have an answer for him :-) Don't you just hate smart users. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From gert at space.net Tue Mar 30 20:55:41 2010 From: gert at space.net (Gert Doering) Date: Tue, 30 Mar 2010 20:55:41 +0200 Subject: Windows 7 and SLAAC? In-Reply-To: References: <20100330112714.GO69383@Space.Net> <25ff90d61003300454r1d21f43aoff9553e2f16feb0e@mail.gmail.com> <274D8AA0-C4E1-4B1F-AABB-B37DC976ECBD@ed.ac.uk> Message-ID: <20100330185541.GU69383@Space.Net> Hi, On Tue, Mar 30, 2010 at 01:04:57PM -0400, Marshall Eubanks wrote: > >> Microsoft has a "Cable Guy" article that describes Vista/Win 7 > >> autoconf behavior, including the netsh CLI interface syntax for this > >> particular setting. > >> > >> netsh interface ipv6 set global randomize identifiers=disabled > >> > >> http://technet.microsoft.com/en-us/magazine/2007.08.cableguy.aspx > >> for > >> more information. > > I would assume that these are not constant. > > RFCs 4941 describes "privacy extensions" that yield changing (pseudo) > random interface IDs and RFC 5157 provides a background into why this > is could be a good thing. Different thing. Win7 has 4941 IPv6 addresses *and* not-directly-MAC- related IPv6 addresses. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100330/a4abba99/attachment.bin From dhorn2000 at gmail.com Tue Mar 30 21:23:38 2010 From: dhorn2000 at gmail.com (David Horn) Date: Tue, 30 Mar 2010 15:23:38 -0400 Subject: Windows 7 and SLAAC? In-Reply-To: <20100330185541.GU69383@Space.Net> References: <20100330112714.GO69383@Space.Net> <25ff90d61003300454r1d21f43aoff9553e2f16feb0e@mail.gmail.com> <274D8AA0-C4E1-4B1F-AABB-B37DC976ECBD@ed.ac.uk> <20100330185541.GU69383@Space.Net> Message-ID: <25ff90d61003301223x1eb0b7b9h3adb62870493d607@mail.gmail.com> On Tue, Mar 30, 2010 at 2:55 PM, Gert Doering wrote: > Hi, > > On Tue, Mar 30, 2010 at 01:04:57PM -0400, Marshall Eubanks wrote: > > >> Microsoft has a "Cable Guy" article that describes Vista/Win 7 > > >> autoconf behavior, including the netsh CLI interface syntax for this > > >> particular setting. > > >> > > >> netsh interface ipv6 set global randomize identifiers=disabled > > >> > > >> http://technet.microsoft.com/en-us/magazine/2007.08.cableguy.aspx > > >> for > > >> more information. > > > > I would assume that these are not constant. > > > > RFCs 4941 describes "privacy extensions" that yield changing (pseudo) > > random interface IDs and RFC 5157 provides a background into why this > > is could be a good thing. > > Different thing. Win7 has 4941 IPv6 addresses *and* not-directly-MAC- > related IPv6 addresses. > > Based upon my own Win7 observations, the default random IID is at least somewhat permanent (In that it survives across reboots), and that it is stored somewhere (as the random IID is the same even after disabling and re-enabling randomization via netsh) Based upon a document from MS: http://download.microsoft.com/download/e/9/b/e9bd20d3-cc8d-4162-aa60-3aa3abc2b2e9/ipv6.doc I think the default Vista/Win7 IID is a "permanant" randomized identifier. See snippet below: - It is a permanent interface identifier that is randomly generated to mitigate address scans of unicast IPv6 addresses on a subnet. This is the default behavior for IPv6 in Windows Vista and Windows Server 2008. You can disable this behavior with the netsh interface ipv6 set global randomizeidentifiers=disabled command.? Good Luck. -_Dave Horn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100330/dc296fb9/attachment.html From brian.e.carpenter at gmail.com Tue Mar 30 22:39:51 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 31 Mar 2010 09:39:51 +1300 Subject: Windows 7 and SLAAC? In-Reply-To: <25ff90d61003301223x1eb0b7b9h3adb62870493d607@mail.gmail.com> References: <20100330112714.GO69383@Space.Net> <25ff90d61003300454r1d21f43aoff9553e2f16feb0e@mail.gmail.com> <274D8AA0-C4E1-4B1F-AABB-B37DC976ECBD@ed.ac.uk> <20100330185541.GU69383@Space.Net> <25ff90d61003301223x1eb0b7b9h3adb62870493d607@mail.gmail.com> Message-ID: <4BB26197.80607@gmail.com> A knowledgeable Microsoft source says: > Windows 7 and Vista (but not Server 2008) use randomized addresses by default, > but it can be turned off as noted. This is in line with RFC 4941. > RFC 2464 did not envision privacy addresses or CGAs. Windows is more robust > against address scanning as a result. Server OS's like 2008 already have > this off by default, so that part of the post is in error. Regards Brian Carpenter From frnkblk at iname.com Tue Mar 30 23:02:48 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 30 Mar 2010 16:02:48 -0500 Subject: Logon scripts to enable IPv6? Message-ID: Below you'll find what I came up with. I had to use a product called "runasspc" (http://robotronic.de/runasspc/) in order to run the netsh commands as a privileged user. ====================================================================== Excerpt from logon script: ====================================================================== if "%allusersprofile%"=="C:\ProgramData" goto WinVista if %os%==Windows_NT goto WinXP :: ::if it gets here, assume 9x base :: exit :: :WinVista \\NT1\netlogon\runasspc /cryptfile:"\\NT1\netlogon\vista7.spc" /quiet goto fin :: :WinXP \\NT1\netlogon\runasspc /cryptfile:"\\NT1\netlogon\xp.spc" /quiet goto fin :fin ====================================================================== ipv6-xp.bat ====================================================================== @echo off netsh interface ipv6 show interface | find "1280" > nul if errorlevel 1 goto NotInstalledonWinXP echo IPv6 already installed on Windows XP goto ReapplyingonWinXP :: :NotInstalledonWinXP echo Installing IPv6 on Windows XP netsh interface ipv6 install netsh interface ipv6 reset netsh interface ipv6 set privacy disabled persistent netsh interface ipv6 isatap set state disabled netsh interface ipv6 6to4 set state disabled netsh interface ipv6 set teredo disabled netsh interface ipv6 delete interface "Teredo Tunneling Pseudo-Interface" active netsh int ipv6 renew echo IPv6 installed. shutdown -r -t 10 -c "Restarting computer after IPv6 installation" goto fin :ReapplyingonWinXP echo Reapplying IPv6 configuration on Windows XP netsh interface ipv6 set privacy disabled persistent netsh interface ipv6 isatap set state disabled netsh interface ipv6 6to4 set state disabled netsh interface ipv6 set teredo disabled netsh interface ipv6 delete interface "Teredo Tunneling Pseudo-Interface" active echo IPv6 configuration reapplied. goto fin :fin ====================================================================== ipv6-vista7.bat ====================================================================== @echo off netsh interface ipv6 show interfaces | find "1280" > nul if "%errorlevel%" == "0" goto NotInstalledonWinVista7 echo IPv6 already installed on Windows Vista and Windows 7 goto ReapplyingWinVista7 :NotInstalledonWinVista7 echo Installing IPv6 on Windows Vista and Windows 7 netsh interface ipv6 reset netsh interface ipv6 set privacy state=disable netsh interface ipv6 set global randomize identifiers=disabled netsh interface ipv6 6to4 set state disabled default netsh interface ipv6 isatap set state disabled netsh interface ipv6 set teredo disabled regedit /s \\nt1\netlogon\ipv6-vista7.reg echo IPv6 installed. shutdown /r /t 10 /c "Restarting computer after IPv6 installation" goto fin :ReapplyingWinVista7 echo Reapplying IPv6 on Windows Vista and Windows 7 netsh interface ipv6 set privacy state=disable netsh interface ipv6 set global randomize identifiers=disabled netsh interface ipv6 6to4 set state disabled default netsh interface ipv6 isatap set state disabled netsh interface ipv6 set teredo disabled echo IPv6 configuration reapplied. goto fin :fin ====================================================================== ipv6-vista7.reg ====================================================================== Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters] "DisabledComponents"=dword:00000001 ====================================================================== -----Original Message----- From: Frank Bulk - iName.com [mailto:frnkblk at iname.com] Sent: Friday, March 19, 2010 10:29 AM To: 'ipv6-ops at lists.cluenet.de' Subject: Logon scripts to enable IPv6? Has anyone developed or come across Windows logon scripts that enables IPv6 and turns off all 6to4, ISATAP, and Teredo for Windows XP SP2, Vista, and 7? I'm looking to deploy native IPv6 access (SLAAC-based) across our 60-node corporate network, and I'd rather do it via logon scripts than policies. Regards, Frank From holger.zuleger at vodafone.com Wed Mar 31 12:55:28 2010 From: holger.zuleger at vodafone.com (Zuleger, Holger, VF-DE) Date: Wed, 31 Mar 2010 12:55:28 +0200 Subject: Windows 7 and SLAAC? In-Reply-To: References: Message-ID: > -----Original Message----- > From: > ipv6-ops-bounces+holger.zuleger=arcor.net at lists.cluenet.de@ARC OR On Behalf Of Mikael Abrahamsson > Sent: Tuesday, March 30, 2010 6:03 PM > To: B?vre Jon Harald > Cc: Gert Doering; ipv6-ops at lists.cluenet.de > Subject: Re: Windows 7 and SLAAC? > > On Tue, 30 Mar 2010, B?vre Jon Harald wrote: > > > For most users this will not be much of a problem but for > those running > > a server it will. There is however a solution: > > I'd imagine people running servers will statically configure their > address, not let it be done on basis of the mac address. What > happens if > you need to replace the hardware, do you really want to change DNS > information then? Yes, for sure. Why not? As long as there is no support in operating systems to specify the host id independent of the network portion, that's the only way to minimize the work in case of network renumbering. So SLAAC is indeed very helpful here. Holger From nick-lists at netability.ie Wed Mar 31 14:36:27 2010 From: nick-lists at netability.ie (Nick Hilliard) Date: Wed, 31 Mar 2010 13:36:27 +0100 Subject: Logon scripts to enable IPv6? In-Reply-To: References: Message-ID: <4BB341CB.7090409@netability.ie> On 30/03/2010 22:02, Frank Bulk - iName.com wrote: > ====================================================================== > ipv6-vista7.bat > ====================================================================== [...] > netsh interface ipv6 set global randomize identifiers=disabled [...] > netsh interface ipv6 set global randomize identifiers=disabled I think you mean: netsh interface ipv6 set global randomizeidentifiers=disabled Nick From frnkblk at iname.com Wed Mar 31 14:59:44 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Wed, 31 Mar 2010 07:59:44 -0500 Subject: Logon scripts to enable IPv6? In-Reply-To: <4BB341CB.7090409@netability.ie> References: <4BB341CB.7090409@netability.ie> Message-ID: That's right, thanks for catching that! Frank -----Original Message----- From: Nick Hilliard [mailto:nick-lists at netability.ie] Sent: Wednesday, March 31, 2010 7:36 AM To: frnkblk at iname.com Cc: ipv6-ops at lists.cluenet.de Subject: Re: Logon scripts to enable IPv6? On 30/03/2010 22:02, Frank Bulk - iName.com wrote: > ====================================================================== > ipv6-vista7.bat > ====================================================================== [...] > netsh interface ipv6 set global randomize identifiers=disabled [...] > netsh interface ipv6 set global randomize identifiers=disabled I think you mean: netsh interface ipv6 set global randomizeidentifiers=disabled Nick From frnkblk at iname.com Wed Mar 31 15:05:07 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Wed, 31 Mar 2010 08:05:07 -0500 Subject: IPv6 equivalent of ARP - possibly dumb question Message-ID: It's my understanding that the closest equivalent of ARP in IPv6 is "sh ipv6 neighbors". When I do that on our Cisco 7206VXR running 12.2(31)SB16 I see only a few addresses, not nearly all the ones that I know that the PCs "obtained" via SLAAC. How do I see which IPv6 hosts are actively sending traffic through/to our router? Frank