From hank at efes.iucc.ac.il Wed Jun 1 00:26:21 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 01 Jun 2011 08:26:21 +0300 Subject: Verisign Internet Defence Network In-Reply-To: <20110530142558.GF95215@reptiles.org> Message-ID: <5.1.0.14.2.20110601081330.0377fd28@efes.iucc.ac.il> At 10:25 30/05/2011 -0400, Jim Mercer wrote: My knowledge is from 1.5 years ago when I compared Verisign, Prolexic, Akamai and others so things may have changed since then. VeriSign claim that they are servicing their own network globally which has performed with zero down time over the last decade. Verisign have 2 offerings - one over BGP and the other over GRE/SSL VPNs. The BGP solution would be faster to turn on but will require more configuration set-up. Interestingly, their mitigation service is not 'always-on' (they sell their monitoring and mitigation services seperately). On detection of an attack, they contact the customer and only once the customer acknowledges that they want their services "redirected" do they turn on the filtering. My biggest gripe was their SLA - or lack of one. Back in Dec 2009 I forced them to start writing an SLA which they had not thought of, which back then showed an immaturity of service. Things might be different now. Verisign then took the view that the SLA should be based on *their* mitigation platform availability ("our scrubbing center has 100% SLA") and not on the customer site availability (all great and wonderful that your scrubbing center is up and running - but my site is down). They were willing to give service credits if their scrubbing center was down but not if the customer site was down. I found they had a well established customer portal and ample reporting facilities. Just make sure they have improved on their SLA before buying. Regards, Hank >Heyo, > >So, I asked to look into the viability and usefullness of the "Verisign >Internet Defence Network" service. > >I don't claim to be any kind of expert in DDoS mitigation, but some of the >claims made by the product descriptions seem suspect to me. > >it claims to be "Carrier-agnostic and ISP-neutral", yet "When an event is >detected, Verisign will work with the customer to redirect Internet traffic >destined for the protected service to a Verisign Internet Defense Network >site." > >anyone here have any comments on how this works, and how effective it will be >vs. dealing directly with your upstream providers and getting them to assist >in shutting down the attack? > >-- >Jim Mercer jim at reptiles.org +1 416 410-5633 >You are more likely to be arrested as a terrorist than you are to be >blown up by one. -- Dianora From sethm at rollernet.us Wed Jun 1 01:44:04 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 31 May 2011 23:44:04 -0700 Subject: Verisign Internet Defence Network In-Reply-To: <5.1.0.14.2.20110601081330.0377fd28@efes.iucc.ac.il> References: <5.1.0.14.2.20110601081330.0377fd28@efes.iucc.ac.il> Message-ID: <4DE5DFB4.20708@rollernet.us> On 5/31/11 10:26 PM, Hank Nussbacher wrote: > > My biggest gripe was their SLA - or lack of one. Back in Dec 2009 I > forced them to start writing an SLA which they had not thought of, which > back then showed an immaturity of service. Things might be different > now. Verisign then took the view that the SLA should be based on > *their* mitigation platform availability ("our scrubbing center has 100% > SLA") and not on the customer site availability (all great and wonderful > that your scrubbing center is up and running - but my site is down). > They were willing to give service credits if their scrubbing center was > down but not if the customer site was down. > > I found they had a well established customer portal and ample reporting > facilities. > > Just make sure they have improved on their SLA before buying. > Sounds like a catch-22 though; if it's not always on and only starts scrubbing after an attack begins (pending activation approval from the customer which may take time), then the customer site is quite possibly already down when they start doing their thing to make it come back up. ~Seth From sclark at netwolves.com Wed Jun 1 05:49:44 2011 From: sclark at netwolves.com (Steve Clark) Date: Wed, 01 Jun 2011 06:49:44 -0400 Subject: Yahoo and IPv6 In-Reply-To: References: Message-ID: <4DE61948.3090306@netwolves.com> On 05/31/2011 05:31 PM, Voll, Toivo wrote: > Going to http://help.yahoo.com/l/us/yahoo/ipv6/ and hitting "Start IPv6 Test" I get: > "Your system will continue to work for you on World IPv6 day. However, we found that your server only supports IPv4 at this time. You'll simply continue to use IPv4 to reach your favorite web sites." > > Netalyzr (http://n3.netalyzr.icsi.berkeley.edu/analysis) finds no issues with my IPv6 status, but alerts me to the fact (since confirmed by switching to IE) that Google Chrome defaults to IPv4 rather than IPv6, and consequently a lot of the testing tools claim that my IPv6 is broken. > > Toivo Voll > Network Administrator > Information Technology Communications > University of South Florida > > -----Original Message----- > From: Brandon Ross [mailto:bross at pobox.com] > Sent: Monday, May 09, 2011 12:25 > To: Arie Vayner > Cc: nanog at nanog.org > Subject: Re: Yahoo and IPv6 > > Even more disturbing than that is that when I run a test from here it says > that I have broken v6. But I don't have broken v6 and test-v6.com proves > it with a 10/10. This Yahoo tool doesn't seem to even give a hint as to > what it thinks is broken. > > Can anyone from Yahoo shed some light on what this tool is doing and how > to get it to tell us what it thinks is broken? > Interesting - must be a windows issue, Google Chrome on Linux works fine at http://help.yahoo.com/l/us/yahoo/ipv6/ -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From tjc at ecs.soton.ac.uk Wed Jun 1 06:18:07 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 1 Jun 2011 12:18:07 +0100 Subject: Yahoo and IPv6 In-Reply-To: References: Message-ID: On 31 May 2011, at 22:31, Voll, Toivo wrote: > > Netalyzr (http://n3.netalyzr.icsi.berkeley.edu/analysis) finds no issues with my IPv6 status, but alerts me to the fact (since confirmed by switching to IE) that Google Chrome defaults to IPv4 rather than IPv6, and consequently a lot of the testing tools claim that my IPv6 is broken. I'm a little confused there - the current Chrome prefers IPv6, and also now includes code to allow fast failover to IPv4 in the event IPv6 connectivity is down/slow (300ms headstart). I had some issues with Netalyzer detecting my dual-stack status, which the chaps there are helping with. Tim From jeroen at unfix.org Wed Jun 1 06:38:20 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 01 Jun 2011 13:38:20 +0200 Subject: Berkely Netalyzr for IPv6/IPv4 testing (Was: Yahoo and IPv6) In-Reply-To: References: Message-ID: <4DE624AC.8060902@unfix.org> On 2011-Jun-01 13:18, Tim Chown wrote: > > On 31 May 2011, at 22:31, Voll, Toivo wrote: > >> >> Netalyzr (http://n3.netalyzr.icsi.berkeley.edu/analysis) finds no >> issues with my IPv6 status, but alerts me to the fact (since >> confirmed by switching to IE) that Google Chrome defaults to IPv4 >> rather than IPv6, and consequently a lot of the testing tools claim >> that my IPv6 is broken. > > I'm a little confused there - the current Chrome prefers IPv6, and > also now includes code to allow fast failover to IPv4 in the event > IPv6 connectivity is down/slow (300ms headstart). > > I had some issues with Netalyzer detecting my dual-stack status, > which the chaps there are helping with. Netalyzer is Java-based, thus it uses the Java stack and not the Javascript/ECMAScript stack that Chrome provides. As such it just bypasses all of that and the coolest thing is that you might not even have an IPv6-capable Java stack for your host. The 1.6.0_25-b06 Oracle/Sun version on Windows that I have here seems to do IPv6 just fine btw in combination with Netalyzr. Apparently in my home case I have a slow DNS lookup (odd, never had issues with that, maybe it has to do with me having to click 'accept' on the windows firewall UI ;) 8<----------------------------------------------- It takes 239 ms for your computer to fetch a response from our test server using IPv6, while it takes 7289 ms for the same host to fetch a response using IPv4 from the same server. ----------------------------------------------->8 Definitely has to do with clicking 'ok' on the firewall button ;) Greets, Jeroen From grobe0ba at gmail.com Wed Jun 1 06:54:28 2011 From: grobe0ba at gmail.com (Atticus) Date: Wed, 1 Jun 2011 07:54:28 -0400 Subject: Berkely Netalyzr for IPv6/IPv4 testing (Was: Yahoo and IPv6) In-Reply-To: <4DE624AC.8060902@unfix.org> References: <4DE624AC.8060902@unfix.org> Message-ID: Disable the firewall and try again or all results are worthless. From Valdis.Kletnieks at vt.edu Wed Jun 1 11:36:03 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 01 Jun 2011 12:36:03 -0400 Subject: Berkely Netalyzr for IPv6/IPv4 testing (Was: Yahoo and IPv6) In-Reply-To: Your message of "Wed, 01 Jun 2011 07:54:28 EDT." References: <4DE624AC.8060902@unfix.org> Message-ID: <7096.1306946163@turing-police.cc.vt.edu> On Wed, 01 Jun 2011 07:54:28 EDT, Atticus said: > Disable the firewall and try again or all results are worthless. On the other hand, if you have a firewall you need to disable in order for it to get valid IPv6 results, you don't actually have a working IPv6 configuration, do you? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sfouant at shortestpathfirst.net Wed Jun 1 11:53:51 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 1 Jun 2011 12:53:51 -0400 Subject: Verisign Internet Defence Network In-Reply-To: <4DE5DFB4.20708@rollernet.us> References: <5.1.0.14.2.20110601081330.0377fd28@efes.iucc.ac.il> <4DE5DFB4.20708@rollernet.us> Message-ID: <00a201cc207c$7ce5f2e0$76b1d8a0$@net> > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Wednesday, June 01, 2011 2:44 AM > To: nanog at nanog.org > Subject: Re: Verisign Internet Defence Network > > Sounds like a catch-22 though; if it's not always on and only starts > scrubbing after an attack begins (pending activation approval from the > customer which may take time), then the customer site is quite possibly > already down when they start doing their thing to make it come back up. Well that's exactly how it works in most cases. Customers don't usually avail of these types of services until there is a problem, which usually means their site is down in most cases. This is why having proper visibility is key as they can serve as an early warning system giving indication of an impending attack prior to it becoming big enough to bring the site down (usually it takes several minutes to ramp up the attack during the time the bots receive instruction-set from the bot herder). The problem with an always-on mitigation service is that there are additional latencies involved in the redirection (assuming it's not in-line), not to mention the inspections/proxying/filtering that the mitigation devices perform. Note that these latencies will be substantially less on an on-net service offering like Verizon's whereas they can be substantially higher on an off-net service offering from folks like Verisign/Prolexic, etc. These latencies are generally acceptable when a site is under attack, but not desired under normal circumstances. Stefan Fouant JNCIE-M #513, JNCIE-ER #70, JNCI GPG Key ID: 0xB4C956EC From sil at infiltrated.net Wed Jun 1 12:04:33 2011 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 01 Jun 2011 13:04:33 -0400 Subject: Philips contact Message-ID: <4DE67121.1050407@infiltrated.net> Hello all, really hate posting these messages here, but some of you are tops are pinpointing a direct point of contact. I need to get a hold of someone in Philips Corp. as about 12 different managed networks of ours have been probed from one of their netblocks. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From jeroen at unfix.org Wed Jun 1 12:14:43 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 01 Jun 2011 19:14:43 +0200 Subject: Berkely Netalyzr for IPv6/IPv4 testing (Was: Yahoo and IPv6) In-Reply-To: <7096.1306946163@turing-police.cc.vt.edu> References: <4DE624AC.8060902@unfix.org> <7096.1306946163@turing-police.cc.vt.edu> Message-ID: <4DE67383.8030305@unfix.org> On 2011-Jun-01 18:36, Valdis.Kletnieks at vt.edu wrote: > On Wed, 01 Jun 2011 07:54:28 EDT, Atticus said: >> Disable the firewall and try again or all results are worthless. That is quite what I noted, the thing is that apparently the delay for clicking 'ok' is taken into account for the measurements ;) > On the other hand, if you have a firewall you need to disable in order > for it to get valid IPv6 results, you don't actually have a working IPv6 > configuration, do you? The standard Windows Firewall on XP asks the user if it is okay if a program, in this case java, is allowed to open a listen socket. This is common for quite a few firewall tools out there, and the moment you have hit okay, all is fine. On Win7 one can even enable the same question for outbound requests, one of the few things that is actually missing in XP IMHO. But all of that is not really operational.... Greets, Jeroen From fernando at gont.com.ar Wed Jun 1 12:20:12 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 01 Jun 2011 14:20:12 -0300 Subject: Ra-Guard evasion (new Internet-Drafts) Message-ID: <4DE674CC.2000402@gont.com.ar> Folks, I've just published two new IETF Internet-Drafts, that document the problem of RA-Guard evasion, and propose mitigations. They are two Internet-Drafts: * "IPv6 Router Advertisement Guard (RA-Guard) Evasion", available at: http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt * "Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery", available at: http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt Any comments on these documents will be more than welcome. Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From Valdis.Kletnieks at vt.edu Wed Jun 1 13:07:41 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 01 Jun 2011 14:07:41 -0400 Subject: Berkely Netalyzr for IPv6/IPv4 testing (Was: Yahoo and IPv6) In-Reply-To: Your message of "Wed, 01 Jun 2011 19:14:43 +0200." <4DE67383.8030305@unfix.org> References: <4DE624AC.8060902@unfix.org> <7096.1306946163@turing-police.cc.vt.edu> <4DE67383.8030305@unfix.org> Message-ID: <12120.1306951661@turing-police.cc.vt.edu> On Wed, 01 Jun 2011 19:14:43 +0200, Jeroen Massar said: > On 2011-Jun-01 18:36, Valdis.Kletnieks at vt.edu wrote: > > On the other hand, if you have a firewall you need to disable in order > > for it to get valid IPv6 results, you don't actually have a working IPv6 > > configuration, do you? > > The standard Windows Firewall on XP asks the user if it is okay if a > program, in this case java, is allowed to open a listen socket. That's reconfiguring the firewall, not disabling it entirely... > But all of that is not really operational.... Your help desk will probably say it's an operation issue for them this time next week. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Eric.Morin at corp.xplornet.com Wed Jun 1 14:09:38 2011 From: Eric.Morin at corp.xplornet.com (Eric Morin) Date: Wed, 1 Jun 2011 16:09:38 -0300 Subject: 7206 NPE-G2 with 4 full table feeds References: <0884FC66D0F02545ABF9E7E29CB5A1C901E7A975@nawd103067.barrett.com> Message-ID: Hi I have an application where I have a 7206 with NPE-G2 (1G RAM) that currently has a full table from an eBGP peer and a full table from a co-located IBGP peer. I want to mesh this guy to two other IBGP peers that will also send their full tables. There is roughly 400Mbps (adding both direction) with an OSPF process (<30 routes) and an ISIS process (<20 routes). I haven't been very successful at finding real life BGP scaling for this platform and was hoping that someone out there may be doing something similar (4 x full table feeds with ~400Mbps) and can provide feedback on performance and/or stability. I have soft reconfig inbound enabled on the current two feeds, I assume that this will make a difference in this application with regards to available memory for all 4 feeds? Thanks in advance Eric From carlosm3011 at gmail.com Wed Jun 1 15:29:43 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 1 Jun 2011 17:29:43 -0300 Subject: Someone from Telefonica Wholesale on the list ? Message-ID: Specifically someone with admin rights over the router at 2001:1498:1:200::100:5d (got Telefonica from WHOIS as there is no DNS reverse). Can you pls contact me off-list ? Thanks! Carlos -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From lukasz at bromirski.net Wed Jun 1 17:34:48 2011 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Thu, 02 Jun 2011 00:34:48 +0200 Subject: 7206 NPE-G2 with 4 full table feeds In-Reply-To: References: <0884FC66D0F02545ABF9E7E29CB5A1C901E7A975@nawd103067.barrett.com> Message-ID: <4DE6BE88.4070009@bromirski.net> On 2011-06-01 21:09, Eric Morin wrote: > Hi > > I have an application where I have a 7206 with NPE-G2 (1G RAM) that > currently has a full table from an eBGP peer and a full table from a > co-located IBGP peer. I want to mesh this guy to two other IBGP peers > that will also send their full tables. There is roughly 400Mbps (adding > both direction) with an OSPF process (<30 routes) and an ISIS process > (<20 routes). First of all - cisco-nsp@ is a better place to ask such question and if you search archives of it, you'll find a lot of comments for such config. > I haven't been very successful at finding real life BGP scaling for this > platform and was hoping that someone out there may be doing something > similar (4 x full table feeds with ~400Mbps) and can provide feedback on > performance and/or stability. I have soft reconfig inbound enabled on > the current two feeds, I assume that this will make a difference in this > application with regards to available memory for all 4 feeds? With 1GB of RAM you may run short (check current actual usage), but I'd recommend in such situation to rely rather on the route refresh standard capability, than the soft reconfig - it eats memory per-peer, and with route refresh you can get almost the same, trading bandwidth on the link for RAM in the RP. NPE-G2 can take 2GB of RAM, so if that's going to stay I'd also recommend upgrading if you're running short of memory either way. Or upgrade to ASR 1k and move into the world of hardware-forwarding platforms. -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From woody at pch.net Thu Jun 2 17:26:29 2011 From: woody at pch.net (Bill Woodcock) Date: Thu, 2 Jun 2011 15:26:29 -0700 Subject: Microsoft's participation in World IPv6 day Message-ID: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 http://support.microsoft.com/kb/2533454/ Uh... -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBCAAGBQJN6A4VAAoJEG+kcEsoi3+H7uoQAMrSuAXqXo+L+Wkiqx+OvwU8 v4TJEeTU8Hp+ap0Kuka0Jq2HFC2ReABwfwZEX9wywdcXKFYu1u8znVa6neX6rjcv uxghsoqZEp9A4KB/J2q/ulM6B8/40oRHK1IuHdv0fZwC0oLyJ1W10n1VzsiE3qxx JOWbn1SIPo4nXnTIVU60yDOySlsclpW3fuqQoUIHzwEZEFgYf2l7ywcPfuCvVQJw FuqASIk0c9hQJVnBKTpaIQaNdRExkYtQSs5i8+TyzxhyGx1XGDOeJoRHRBQhSfcS DS8Vuwvblh+UjGFDIEF9Oen7NxrK2xjBCJIDV+MbJwAJdjs5wM3H9nFdhCX9Z2cl TRIj4/qQcS7m8cl4gNFY3nplALrWHjs2WK8jk0HlDnEgvSe7D2YC6Te5vnGgY9sX JXif1D36Pzx1V1JwbmMIwvvlUalPH/jyciMVUGrMMKc+0w7/75IerzGsSabdTIzJ t0/4jh5/h8db+q37CfN1Xj/gWkBcIyXmGGCd3pny4+YJwI5hnspWoeRq5lkB64Pn zDCJANGd5PZxtcTBgYJkZCK+sNjzycThkS1UP8pKdajbyQNlbRWkDFbQwMQ0DQEa IanX3BioesZmfashzRu+khdczhLVtFLKLUT7/yI2RqQOekx5sO+HqzTIiIIp5mkd KbOBvdIvnaz5FI94I8jk =OyB3 -----END PGP SIGNATURE----- From drais at icantclick.org Thu Jun 2 17:45:51 2011 From: drais at icantclick.org (david raistrick) Date: Thu, 2 Jun 2011 18:45:51 -0400 (EDT) Subject: Microsoft's participation in World IPv6 day In-Reply-To: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> Message-ID: On Thu, 2 Jun 2011, Bill Woodcock wrote: > http://support.microsoft.com/kb/2533454/ > > Uh... snicker. snicker. lol. rofl. "we'll fix our ipv6 support by, well, not using it!" -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From paul at paulgraydon.co.uk Thu Jun 2 17:53:46 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 02 Jun 2011 12:53:46 -1000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> Message-ID: <4DE8147A.9020004@paulgraydon.co.uk> On 06/02/2011 12:45 PM, david raistrick wrote: > On Thu, 2 Jun 2011, Bill Woodcock wrote: > >> http://support.microsoft.com/kb/2533454/ >> >> Uh... > > snicker. snicker. lol. rofl. "we'll fix our ipv6 support by, well, > not using it!" It's not Microsoft's IPv6 support they're fixing, which works fine from my experience with it, they're making sure you can access sites if your ISP or Router's IPv6 handling is screwed up. Paul From surfer at mauigateway.com Thu Jun 2 18:06:40 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 2 Jun 2011 16:06:40 -0700 Subject: Microsoft's participation in World IPv6 day Message-ID: <20110602160640.4F24DCB5@resin04.mta.everyone.net> --- paul at paulgraydon.co.uk wrote: On 06/02/2011 12:45 PM, david raistrick wrote: > On Thu, 2 Jun 2011, Bill Woodcock wrote: > >> http://support.microsoft.com/kb/2533454/ >> >> Uh... > > snicker. snicker. lol. rofl. "we'll fix our ipv6 support by, well, > not using it!" It's not Microsoft's IPv6 support they're fixing, which works fine from my experience with it, they're making sure you can access sites if your ISP or Router's IPv6 handling is screwed up. --------------------------------------------------- No, they're just going to force Micr0$loth machines prefer IPv4 on World IPv6 day, rather than the normal prefer IPv6: "The following Fix it solution will resolve the issue by configuring your computer to prefer IPv4, instead of IPv6. By default, Windows prefers IPv6 over IPv4." Kinda makes IPv6 day semi-moot doesn't it... scott From nanog at jima.tk Thu Jun 2 18:20:58 2011 From: nanog at jima.tk (Jima) Date: Thu, 02 Jun 2011 18:20:58 -0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> Message-ID: <4DE81ADA.3010806@jima.tk> On 2011-06-02 17:26, Bill Woodcock wrote: > http://support.microsoft.com/kb/2533454/ > > Uh... While I'm far from a Microsoft apologist (not really even a fan, TBH), it's worth pointing out that they're not pushing this out via Windows Update or anything. It's intended only as a remedy for the (as they themselves claim) <0.1% of users who may encounter issues next Wednesday: http://blogs.technet.com/b/ipv6/archive/2011/02/11/ipv6-day.aspx Fun as it might be to take it out of context, at least they're not telling people to disable IPv6 entirely (like some organizations still are). Jima From surfer at mauigateway.com Thu Jun 2 18:35:01 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 2 Jun 2011 16:35:01 -0700 Subject: Microsoft's participation in World IPv6 day Message-ID: <20110602163501.4F24DE5E@resin04.mta.everyone.net> --- nanog at jima.tk wrote: From: Jima On 2011-06-02 17:26, Bill Woodcock wrote: > http://support.microsoft.com/kb/2533454/ > > Uh... While I'm far from a Microsoft apologist (not really even a fan, TBH), it's worth pointing out that they're not pushing this out via Windows Update or anything. It's intended only as a remedy for the (as they ------------------------------------------------- Ah, I have to take back what I just wrote then. I thought they were pushing it out via their patch program. scott From bill at herrin.us Thu Jun 2 18:58:28 2011 From: bill at herrin.us (William Herrin) Date: Thu, 2 Jun 2011 19:58:28 -0400 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> Message-ID: On Thu, Jun 2, 2011 at 6:26 PM, Bill Woodcock wrote: > http://support.microsoft.com/kb/2533454/ "This article describes step-by-step instructions for mitigating issues you may have connecting to the Internet, or certain websites, on World IPv6 Day (June 8, 2011). The following Fix it solution will _resolve_ the issue by configuring your computer to prefer IPv4, instead of IPv6." [Insert Nelson Muntz laugh here] -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From andrew.wallace at rocketmail.com Thu Jun 2 19:08:29 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 2 Jun 2011 17:08:29 -0700 (PDT) Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> Message-ID: <586376.10713.qm@web59601.mail.ac4.yahoo.com> World day is a sure-shot bet win at an anti-climax, and an industry failure and waste of investment and publicity campaign. Andrew From nanog at jima.tk Thu Jun 2 20:00:59 2011 From: nanog at jima.tk (Jima) Date: Thu, 02 Jun 2011 20:00:59 -0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <586376.10713.qm@web59601.mail.ac4.yahoo.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> Message-ID: <4DE8324B.2080807@jima.tk> On 2011-06-02 19:08, andrew.wallace wrote: > World day is a sure-shot bet win at an anti-climax, and an industry failure and waste of investment and publicity campaign. No kidding. We wouldn't want to raise public awareness of IPv6 or anything. That might take it out of the realm of geeky plaything. :-( Jima From Valdis.Kletnieks at vt.edu Thu Jun 2 20:29:48 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 02 Jun 2011 21:29:48 -0400 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Thu, 02 Jun 2011 17:08:29 PDT." <586376.10713.qm@web59601.mail.ac4.yahoo.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> Message-ID: <6469.1307064588@turing-police.cc.vt.edu> On Thu, 02 Jun 2011 17:08:29 PDT, "andrew.wallace" said: > World day is a sure-shot bet win at an anti-climax, and an > industry failure and waste of investment and publicity campaign. Got a better idea? Some of us have been running IPv6 since 1998 and this is still the closest thing to getting people motivated to switch we've seen this century. And I doubt it will be a *total* failure - even if a lot of things unexpectedly break, the post-mortems will of value. In fact, the cynic in me says the post-mortems are what's really driving this whole event. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From marka at isc.org Thu Jun 2 21:49:26 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 03 Jun 2011 12:49:26 +1000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Thu, 02 Jun 2011 18:20:58 EST." <4DE81ADA.3010806@jima.tk> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <4DE81ADA.3010806@jima.tk> Message-ID: <20110603024926.50445103C61B@drugs.dv.isc.org> In message <4DE81ADA.3010806 at jima.tk>, Jima writes: > On 2011-06-02 17:26, Bill Woodcock wrote: > > http://support.microsoft.com/kb/2533454/ > > > > Uh... > > While I'm far from a Microsoft apologist (not really even a fan, TBH), > it's worth pointing out that they're not pushing this out via Windows > Update or anything. It's intended only as a remedy for the (as they > themselves claim) <0.1% of users who may encounter issues next Wednesday: > > http://blogs.technet.com/b/ipv6/archive/2011/02/11/ipv6-day.aspx > > Fun as it might be to take it out of context, at least they're not > telling people to disable IPv6 entirely (like some organizations still are). > > Jima > They need to fix the typo. You vs Your. :-) Mark Your ready for World IPv6 Day, and have nothing to worry about. You also are lucky enough to have IPv6 connectivity along with IPv4 - meaning you have two ways to connect to the Internet! -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Thu Jun 2 22:53:36 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 2 Jun 2011 20:53:36 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <6469.1307064588@turing-police.cc.vt.edu> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> <6469.1307064588@turing-police.cc.vt.edu> Message-ID: On Thu, Jun 2, 2011 at 6:29 PM, wrote: > On Thu, 02 Jun 2011 17:08:29 PDT, "andrew.wallace" said: >> World day is a sure-shot bet win at an anti-climax, and an >> industry failure and waste of investment and publicity campaign. > > Got a better idea? ?Some of us have been running IPv6 since 1998 and this is > still the closest thing to getting people motivated to switch we've seen this > century. > > And I doubt it will be a *total* failure - even if a lot of things unexpectedly > break, the post-mortems will of value. ?In fact, the cynic in me says the > post-mortems are what's really driving this whole event. ;) > +1 IPv6 day is already a huge success since it has brought technology competitors like Facebook, Bing, Google, Yahoo, Akamai, Limelight and many others all together to help move this VERY IMPORTANT rock up the hill. The ideal state of IPv6 day is that the Internet keeps working with "no news" from a network operator perspective ... aside from a very slight bump in IPv6 traffic (we still have edge IPv6 reach issues in the Internet (understatement)... but there is progress there too (true statement)). If you have not been to the website, you should go and have a look. This list should have a high level of interest in the success and IPv6 day.... since most of us get pay checks based on the continued growth and success of this here network of networks. http://www.worldipv6day.org/ And, in case you have not seen a hockey stick lately http://v6asns.ripe.net/v/6 Cameron From owen at delong.com Thu Jun 2 23:22:00 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 2 Jun 2011 21:22:00 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> Message-ID: <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> It provides a handy space to comment at the bottom. Perhaps people here would like to let M$ know that it would be preferable to provide pointers to real workable IPv6 connectivity solutions rather than merely hotwire the system to temporarily bypass IPv6 in favor of IPv4. That's the path I chose. Owen On Jun 2, 2011, at 3:26 PM, Bill Woodcock wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > http://support.microsoft.com/kb/2533454/ > > Uh... > > -Bill > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (Darwin) > > iQIcBAEBCAAGBQJN6A4VAAoJEG+kcEsoi3+H7uoQAMrSuAXqXo+L+Wkiqx+OvwU8 > v4TJEeTU8Hp+ap0Kuka0Jq2HFC2ReABwfwZEX9wywdcXKFYu1u8znVa6neX6rjcv > uxghsoqZEp9A4KB/J2q/ulM6B8/40oRHK1IuHdv0fZwC0oLyJ1W10n1VzsiE3qxx > JOWbn1SIPo4nXnTIVU60yDOySlsclpW3fuqQoUIHzwEZEFgYf2l7ywcPfuCvVQJw > FuqASIk0c9hQJVnBKTpaIQaNdRExkYtQSs5i8+TyzxhyGx1XGDOeJoRHRBQhSfcS > DS8Vuwvblh+UjGFDIEF9Oen7NxrK2xjBCJIDV+MbJwAJdjs5wM3H9nFdhCX9Z2cl > TRIj4/qQcS7m8cl4gNFY3nplALrWHjs2WK8jk0HlDnEgvSe7D2YC6Te5vnGgY9sX > JXif1D36Pzx1V1JwbmMIwvvlUalPH/jyciMVUGrMMKc+0w7/75IerzGsSabdTIzJ > t0/4jh5/h8db+q37CfN1Xj/gWkBcIyXmGGCd3pny4+YJwI5hnspWoeRq5lkB64Pn > zDCJANGd5PZxtcTBgYJkZCK+sNjzycThkS1UP8pKdajbyQNlbRWkDFbQwMQ0DQEa > IanX3BioesZmfashzRu+khdczhLVtFLKLUT7/yI2RqQOekx5sO+HqzTIiIIp5mkd > KbOBvdIvnaz5FI94I8jk > =OyB3 > -----END PGP SIGNATURE----- > From hank at efes.iucc.ac.il Thu Jun 2 23:34:09 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 3 Jun 2011 07:34:09 +0300 (IDT) Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> <6469.1307064588@turing-police.cc.vt.edu> Message-ID: On Thu, 2 Jun 2011, Cameron Byrne wrote: In that case can anyone explain why the number of IPv4 *only* systems is increasing rather than decreasing: http://server8.test-ipv6.com/stats.html I would have expected the green+azure areas in those graphs to have increased in the past half year but counter-intutitively, it appears that IPv4 only usage is increasing. -Hank > IPv6 day is already a huge success since it has brought technology > competitors like Facebook, Bing, Google, Yahoo, Akamai, Limelight and > many others all together to help move this VERY IMPORTANT rock up the > hill. From dougb at dougbarton.us Thu Jun 2 23:38:38 2011 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 02 Jun 2011 21:38:38 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> <6469.1307064588@turing-police.cc.vt.edu> Message-ID: <4DE8654E.20308@dougbarton.us> On 06/02/2011 21:34, Hank Nussbacher wrote: > On Thu, 2 Jun 2011, Cameron Byrne wrote: > > In that case can anyone explain why the number of IPv4 *only* systems is > increasing rather than decreasing: > http://server8.test-ipv6.com/stats.html > > I would have expected the green+azure areas in those graphs to have > increased in the past half year but counter-intutitively, it appears > that IPv4 only usage is increasing. I think the graph is becoming more reflective of the real world as the test site gets more exposure. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From cb.list6 at gmail.com Thu Jun 2 23:42:21 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 2 Jun 2011 21:42:21 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> <6469.1307064588@turing-police.cc.vt.edu> Message-ID: On Thu, Jun 2, 2011 at 9:34 PM, Hank Nussbacher wrote: > On Thu, 2 Jun 2011, Cameron Byrne wrote: > > In that case can anyone explain why the number of IPv4 *only* systems is > increasing rather than decreasing: > http://server8.test-ipv6.com/stats.html > > I would have expected the green+azure areas in those graphs to have > increased in the past half year but counter-intutitively, it appears that > IPv4 only usage is increasing. Pure speculation here, but these stats that you refer to are not a scientifically representative sample of the internet at large, this sample is a self selecting group of people who have chosen to run an ipv6 test. These people who run the test, likely know what IPv6 is and therefore are more likely to have IPv6 enabled. As world ipv6 day gets more general press coverage, the graph is bending more towards a more realistic sample of the internet ... which does not usually have IPv6 access. Assuming Google users represent the general internet, this is the graph that displays what you are likely looking for http://www.google.com/intl/en/ipv6/statistics/ Cameron From cb.list6 at gmail.com Thu Jun 2 23:56:48 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 2 Jun 2011 21:56:48 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> <6469.1307064588@turing-police.cc.vt.edu> Message-ID: On Thu, Jun 2, 2011 at 9:42 PM, Cameron Byrne wrote: > On Thu, Jun 2, 2011 at 9:34 PM, Hank Nussbacher wrote: >> On Thu, 2 Jun 2011, Cameron Byrne wrote: >> >> In that case can anyone explain why the number of IPv4 *only* systems is >> increasing rather than decreasing: >> http://server8.test-ipv6.com/stats.html >> >> I would have expected the green+azure areas in those graphs to have >> increased in the past half year but counter-intutitively, it appears that >> IPv4 only usage is increasing. > > Pure speculation here, but these stats that you refer to are not a > scientifically representative sample of the internet at large, this > sample is a self selecting group of people who have chosen to run an > ipv6 test. ?These people who run the test, likely know what IPv6 is > and therefore are more likely to have IPv6 enabled. > > As world ipv6 day gets more general press coverage, the graph is > bending more towards a more realistic sample of the internet ... which > does not usually have IPv6 access. > > Assuming Google users represent the general internet, this is the > graph that displays what you are likely looking for > > http://www.google.com/intl/en/ipv6/statistics/ > This data is probably a better reference regarding ipv6 traffic growth http://www.ams-ix.net/sflow-stats/ipv6/ cb From marka at isc.org Fri Jun 3 00:08:35 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 03 Jun 2011 15:08:35 +1000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Thu, 02 Jun 2011 21:42:21 MST." References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> <6469.1307064588@turing-police.cc.vt.edu> Message-ID: <20110603050835.89F5B1048C5B@drugs.dv.isc.org> In message , Cameron Byrne writes: > On Thu, Jun 2, 2011 at 9:34 PM, Hank Nussbacher wrote: > > On Thu, 2 Jun 2011, Cameron Byrne wrote: > > > > In that case can anyone explain why the number of IPv4 *only* systems is > > increasing rather than decreasing: > > http://server8.test-ipv6.com/stats.html > > > > I would have expected the green+azure areas in those graphs to have > > increased in the past half year but counter-intutitively, it appears that > > IPv4 only usage is increasing. > > Pure speculation here, but these stats that you refer to are not a > scientifically representative sample of the internet at large, this > sample is a self selecting group of people who have chosen to run an > ipv6 test. These people who run the test, likely know what IPv6 is > and therefore are more likely to have IPv6 enabled. > > As world ipv6 day gets more general press coverage, the graph is > bending more towards a more realistic sample of the internet ... which > does not usually have IPv6 access. > > Assuming Google users represent the general internet, this is the > graph that displays what you are likely looking for > > http://www.google.com/intl/en/ipv6/statistics/ > > Cameron Which is good as it is showing 6to4 fixes being deployed to preference IPv4 over 6to4 and a strong growth in IPv6 native. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gary.buhrmaster at gmail.com Fri Jun 3 00:24:29 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 2 Jun 2011 22:24:29 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> <6469.1307064588@turing-police.cc.vt.edu> Message-ID: On Thu, Jun 2, 2011 at 21:42, Cameron Byrne wrote: ....> > Pure speculation here, but these stats that you refer to are not a > scientifically representative sample of the internet at large, this > sample is a self selecting group of people who have chosen to run an > ipv6 test. Commonly called sample bias. Good statistical analysis will address (and adjust for) such bias, but that can be (very) hard work. As with all the "CNN polls", there should be a disclaimer on such sites that say "this is not a scientific poll", but that would ruin the fun..... Gary From mail at jaidev.info Fri Jun 3 01:30:16 2011 From: mail at jaidev.info (Jaidev Sridhar) Date: Thu, 2 Jun 2011 23:30:16 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> Message-ID: On Thu, Jun 2, 2011 at 21:22, Owen DeLong wrote: > It provides a handy space to comment at the bottom. > > Perhaps people here would like to let M$ know that it would be preferable > to provide pointers to real workable IPv6 connectivity solutions rather than > merely hotwire the system to temporarily bypass IPv6 in favor of IPv4. > > That's the path I chose. I guess you're all missing the point here. I've never agreed too much with M$, but what they're doing is right. IPv6 stacks are quite mature these days but IPv6 connectivity can be broken due to incorrectly implemented networks / tunnels (see: http://ripe61.ripe.net/presentations/223-World_IPv6_day.pdf). For those clients there is no option other than disabling IPv6. Hopefully the service providers & network admins get to identify and fix issues. This problem is not client OS specific. I'm all for M$ bashing, but not for this reason. -Jaidev > > Owen > > On Jun 2, 2011, at 3:26 PM, Bill Woodcock wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> >> http://support.microsoft.com/kb/2533454/ >> >> Uh... >> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-Bill >> >> >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (Darwin) >> >> iQIcBAEBCAAGBQJN6A4VAAoJEG+kcEsoi3+H7uoQAMrSuAXqXo+L+Wkiqx+OvwU8 >> v4TJEeTU8Hp+ap0Kuka0Jq2HFC2ReABwfwZEX9wywdcXKFYu1u8znVa6neX6rjcv >> uxghsoqZEp9A4KB/J2q/ulM6B8/40oRHK1IuHdv0fZwC0oLyJ1W10n1VzsiE3qxx >> JOWbn1SIPo4nXnTIVU60yDOySlsclpW3fuqQoUIHzwEZEFgYf2l7ywcPfuCvVQJw >> FuqASIk0c9hQJVnBKTpaIQaNdRExkYtQSs5i8+TyzxhyGx1XGDOeJoRHRBQhSfcS >> DS8Vuwvblh+UjGFDIEF9Oen7NxrK2xjBCJIDV+MbJwAJdjs5wM3H9nFdhCX9Z2cl >> TRIj4/qQcS7m8cl4gNFY3nplALrWHjs2WK8jk0HlDnEgvSe7D2YC6Te5vnGgY9sX >> JXif1D36Pzx1V1JwbmMIwvvlUalPH/jyciMVUGrMMKc+0w7/75IerzGsSabdTIzJ >> t0/4jh5/h8db+q37CfN1Xj/gWkBcIyXmGGCd3pny4+YJwI5hnspWoeRq5lkB64Pn >> zDCJANGd5PZxtcTBgYJkZCK+sNjzycThkS1UP8pKdajbyQNlbRWkDFbQwMQ0DQEa >> IanX3BioesZmfashzRu+khdczhLVtFLKLUT7/yI2RqQOekx5sO+HqzTIiIIp5mkd >> KbOBvdIvnaz5FI94I8jk >> =OyB3 >> -----END PGP SIGNATURE----- >> > > > > -- The older a man gets, the farther he had to walk to school as a boy. From owen at delong.com Fri Jun 3 02:44:12 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Jun 2011 00:44:12 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> Message-ID: <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> On Jun 2, 2011, at 11:30 PM, Jaidev Sridhar wrote: > On Thu, Jun 2, 2011 at 21:22, Owen DeLong wrote: >> It provides a handy space to comment at the bottom. >> >> Perhaps people here would like to let M$ know that it would be preferable >> to provide pointers to real workable IPv6 connectivity solutions rather than >> merely hotwire the system to temporarily bypass IPv6 in favor of IPv4. >> >> That's the path I chose. > > I guess you're all missing the point here. I've never agreed too much > with M$, but what they're doing is right. IPv6 stacks are quite mature > these days but IPv6 connectivity can be broken due to incorrectly > implemented networks / tunnels (see: > http://ripe61.ripe.net/presentations/223-World_IPv6_day.pdf). > I'm not missing the point, just suggesting that it would be better if Micr0$0ft were part of the solution instead of just hotwiring past the problem. > For those clients there is no option other than disabling IPv6. No, there is the option of troubleshooting why IPv6 doesn't work for them and working to correct it. > Hopefully the service providers & network admins get to identify and > fix issues. This problem is not client OS specific. I'm all for M$ > bashing, but not for this reason. > I didn't see where in the M$ propaganda it suggested calling your ISP or network admin to have them help you fix the issue, so, I don't see how what they are proposing has any hope of enabling this. Owen > -Jaidev > >> >> Owen >> >> On Jun 2, 2011, at 3:26 PM, Bill Woodcock wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> >>> http://support.microsoft.com/kb/2533454/ >>> >>> Uh... >>> >>> -Bill >>> >>> >>> >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (Darwin) >>> >>> iQIcBAEBCAAGBQJN6A4VAAoJEG+kcEsoi3+H7uoQAMrSuAXqXo+L+Wkiqx+OvwU8 >>> v4TJEeTU8Hp+ap0Kuka0Jq2HFC2ReABwfwZEX9wywdcXKFYu1u8znVa6neX6rjcv >>> uxghsoqZEp9A4KB/J2q/ulM6B8/40oRHK1IuHdv0fZwC0oLyJ1W10n1VzsiE3qxx >>> JOWbn1SIPo4nXnTIVU60yDOySlsclpW3fuqQoUIHzwEZEFgYf2l7ywcPfuCvVQJw >>> FuqASIk0c9hQJVnBKTpaIQaNdRExkYtQSs5i8+TyzxhyGx1XGDOeJoRHRBQhSfcS >>> DS8Vuwvblh+UjGFDIEF9Oen7NxrK2xjBCJIDV+MbJwAJdjs5wM3H9nFdhCX9Z2cl >>> TRIj4/qQcS7m8cl4gNFY3nplALrWHjs2WK8jk0HlDnEgvSe7D2YC6Te5vnGgY9sX >>> JXif1D36Pzx1V1JwbmMIwvvlUalPH/jyciMVUGrMMKc+0w7/75IerzGsSabdTIzJ >>> t0/4jh5/h8db+q37CfN1Xj/gWkBcIyXmGGCd3pny4+YJwI5hnspWoeRq5lkB64Pn >>> zDCJANGd5PZxtcTBgYJkZCK+sNjzycThkS1UP8pKdajbyQNlbRWkDFbQwMQ0DQEa >>> IanX3BioesZmfashzRu+khdczhLVtFLKLUT7/yI2RqQOekx5sO+HqzTIiIIp5mkd >>> KbOBvdIvnaz5FI94I8jk >>> =OyB3 >>> -----END PGP SIGNATURE----- >>> >> >> >> >> > > > > -- > The older a man gets, the farther he had to walk to school as a boy. From sdhillon at decarta.com Fri Jun 3 03:08:01 2011 From: sdhillon at decarta.com (Sargun Dhillon) Date: Fri, 3 Jun 2011 03:08:01 -0500 (CDT) Subject: sFlow and NetFlow data collection and monitoring In-Reply-To: <162006952.204671.1307087916175.JavaMail.root@mail-1.01.com> Message-ID: <1040426015.204738.1307088481906.JavaMail.root@mail-1.01.com> I'm looking into network monitoring utilities for both gathering basic statistics conducive to my enterprise as well as looking for anomalies in traffic traffic. I'm curious as to how NANOG approaches this problem. Are most of your statistics gathered via netflow, or sFlow? How do you gather them, and process them? What do most of you use the data for? Deciding (de)peering agreements? Reducing latency to your biggest customers? How 'standard' are the industry standards (Fluke, Arbour). I've experimented with pm-acct, and flow-tools. How do you leverage flow-tools and pmacct? -- Sargun Dhillon deCarta VoIP (US): +1-925-235-1105 From goemon at anime.net Fri Jun 3 03:18:08 2011 From: goemon at anime.net (goemon at anime.net) Date: Fri, 3 Jun 2011 01:18:08 -0700 (PDT) Subject: Microsoft's participation in World IPv6 day In-Reply-To: <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> Message-ID: On Fri, 3 Jun 2011, Owen DeLong wrote: > I'm not missing the point, just suggesting that it would be better if > Micr0$0ft were part of the solution instead of just hotwiring past > the problem. and your solution is what? -Dan From owen at delong.com Fri Jun 3 04:13:49 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Jun 2011 02:13:49 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> Message-ID: <48664031-D689-4C65-8E22-91ADEE9C37BA@delong.com> On Jun 3, 2011, at 1:18 AM, goemon at anime.net wrote: > On Fri, 3 Jun 2011, Owen DeLong wrote: >> I'm not missing the point, just suggesting that it would be better if >> Micr0$0ft were part of the solution instead of just hotwiring past >> the problem. > > and your solution is what? > > -Dan As I said before, provide pointers to resources where users can follow up on actually resolving the issues. Their ISP, their IT department, web pages with additional information on how to diagnose the problem, etc. Owen From tjc at ecs.soton.ac.uk Fri Jun 3 04:23:13 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 3 Jun 2011 10:23:13 +0100 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <48664031-D689-4C65-8E22-91ADEE9C37BA@delong.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <48664031-D689-4C65-8E22-91ADEE9C37BA@delong.com> <79509D37-80D3-41D6-B2F1-E0062ED7E1BB@ecs.soton.ac.uk> Message-ID: On 3 Jun 2011, at 10:13, Owen DeLong wrote: > > As I said before, provide pointers to resources where users can follow up on actually > resolving the issues. Their ISP, their IT department, web pages with additional > information on how to diagnose the problem, etc. I would guess a typical user will call their local helpdesk or ISP first if they have problems. They won't have a clue that Google or Facebook are down or slow due to IPv6 connectivity issues. In which case MS providing a syskb entry for those support people to point the user at seems pretty reasonable. One major MS site has gone dual-stack this morning btw :) Tim From tjc at ecs.soton.ac.uk Fri Jun 3 04:29:42 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 3 Jun 2011 10:29:42 +0100 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <586376.10713.qm@web59601.mail.ac4.yahoo.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> <32F3A0CF-9123-4081-8908-C67F14E7A1AB@ecs.soton.ac.uk> Message-ID: On 3 Jun 2011, at 01:08, andrew.wallace wrote: > World day is a sure-shot bet win at an anti-climax, and an industry failure and waste of investment and publicity campaign. The day passing without any significant userland issues would make it a success. It's a good opportunity to ensure you have the right measurement tools in place so you can learn something from the day. For sites that have dual-stack deployed, a one-day peek into the future where perhaps 15% or more of external traffic will be IPv6 is pretty useful, given it's currently 1% or less. Tim From jared at puck.nether.net Fri Jun 3 06:49:24 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 3 Jun 2011 07:49:24 -0400 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> Message-ID: <20110603114924.GA885@puck.nether.net> On Fri, Jun 03, 2011 at 01:18:08AM -0700, goemon at anime.net wrote: > On Fri, 3 Jun 2011, Owen DeLong wrote: > >I'm not missing the point, just suggesting that it would be better if > >Micr0$0ft were part of the solution instead of just hotwiring past > >the problem. > > and your solution is what? Being a techie, I do want some people to have broken networks that day so they can *fix* it. Very few things are going to break in a new way that there isn't a known fix for. I do expect that this while thing will be a giant noop. Some people with old software/firmware or broken hardware may see something, but without proper maintence I would expect that with anything. Cars, Planes and Trains included. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From fredan-nanog at fredan.se Fri Jun 3 07:27:06 2011 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 3 Jun 2011 14:27:06 +0200 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> Message-ID: <201106031427.07262.fredan-nanog@fredan.se> The problem is not all on Microsoft at this case. For example; I've bought a ZyXEL P-2612HNU-F1(which has 802.11n Wireless ADSL 2+ 4-port gateway 2 SIP 2 USB 3G Backup) in december 2010. It basiclly has everything in it. How do I as a customer do to have a working IPv6 setup on this modem since ZyXEL, basicilly, has decide that it will not support IPv6 at all? I mean, you can not say it does not have the the cpu power for handling IPv6 when it can also act as a fileserver and a printserver for example. What they (ZyXEL) are saying to me (for not haveing IPv6 at this moment) is that they don't have the skills to implement IPv6 in their current products. Think about all the CPE that will not be upgraded, since those that makes them don't care at all, even tough it probably has the cpu power to handle IPv6. And I haven't even started at the network equiment that exists between me as a ISP and my customer (this equiment is out of my control), that can't handle IPv6 even if my customer got an working CPE with IPv6. How fun is that? > http://support.microsoft.com/kb/2533454/ > > Uh... > > -Bill -- //fredan From jared at puck.nether.net Fri Jun 3 07:42:01 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 3 Jun 2011 08:42:01 -0400 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <201106031427.07262.fredan-nanog@fredan.se> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <201106031427.07262.fredan-nanog@fredan.se> Message-ID: On Jun 3, 2011, at 8:27 AM, fredrik danerklint wrote: > The problem is not all on Microsoft at this case. > > > For example; I've bought a ZyXEL P-2612HNU-F1(which has > 802.11n Wireless ADSL 2+ 4-port gateway 2 SIP 2 USB 3G Backup) > in december 2010. It basiclly has everything in it. You made the mistake of buying something that wasn't compliant with the following draft: http://tools.ietf.org/html/draft-george-ipv6-required-02 > How do I as a customer do to have a working IPv6 setup on this modem since > ZyXEL, basicilly, has decide that it will not support IPv6 at all? > > I mean, you can not say it does not have the the cpu power for handling IPv6 > when it can also act as a fileserver and a printserver for example. > > What they (ZyXEL) are saying to me (for not haveing IPv6 at this moment) is > that they don't have the skills to implement IPv6 in their current products. > > Think about all the CPE that will not be upgraded, since those that makes them > don't care at all, even tough it probably has the cpu power to handle IPv6. Replacing CPE will come naturally with entropy over time combined with the early-adopters. I know many people who would walk into the store today and buy a docsis 3 cable modem if cox/charter/twcable etc had ipv6 available. > And I haven't even started at the network equiment that exists between me as a > ISP and my customer (this equiment is out of my control), that can't handle > IPv6 even if my customer got an working CPE with IPv6. This is a whole other issue but getting better. I do want to see what Qwest (Centurylink?) plans on the consumer side as well as any form of an upgrade to the 2WIRE devices that AT&T is using. Looking at the other providers out there, it's interesting to watch the table growing daily. Somewhere around 10-20 new ASNs appear in the IPv6 table right now. (Weekends tend to show few if any adds). 2WIRE rant: These have a whole host of issues that seem to constantly cause problems. (I do like that if you send a SIP notify to devices behind them they sometimes reboot themselves and solve the problem due to their broken SIP-ALG that can't be disabled). > How fun is that? The usual fun. We have had discussions with vendors about IPv6 support and capabilities and they are really interesting. Just ask about v6 lawful-intercept for compliance next time. Interesting days ahead, but all Is the bright future. The network is real now, even if you don't like the smell or color of IPv6. - Jared From outsider at scarynet.org Fri Jun 3 07:48:34 2011 From: outsider at scarynet.org (Alexander Maassen) Date: Fri, 03 Jun 2011 14:48:34 +0200 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> Message-ID: <4DE8D822.3050108@scarynet.org> You are missing a big point here, most NL users for example cannot use ipv6 tunnels because the isp's equipment doesn't allow them. When I called my ISP (online.nl) for example to ask about it, they first had something like: what the heck are you talking about. In fact, one of the only major isp's in the netherlands actively supporting ipv6 for customers is xs4all. On several other providers I had I am simply unable to setup a tunnel. The provider itself is the one blocking proto 41. Not me or my router, and surely not he.net. Another issue is, as long as not many homeusers are aware of ipv6 (for them it's just technical mumbo jumbo they don't care about, as long as they get the webpages shown they wanna access it's fine for them). So having said previous, maybe there should be a World IPv6 only week. That would piss off users, make them complain at their isp, and maybe THEN they finally wanna do some implementations. Op 3-6-2011 9:44, Owen DeLong schreef: > > On Jun 2, 2011, at 11:30 PM, Jaidev Sridhar wrote: > >> On Thu, Jun 2, 2011 at 21:22, Owen DeLong wrote: >>> It provides a handy space to comment at the bottom. >>> >>> Perhaps people here would like to let M$ know that it would be preferable >>> to provide pointers to real workable IPv6 connectivity solutions rather than >>> merely hotwire the system to temporarily bypass IPv6 in favor of IPv4. >>> >>> That's the path I chose. >> >> I guess you're all missing the point here. I've never agreed too much >> with M$, but what they're doing is right. IPv6 stacks are quite mature >> these days but IPv6 connectivity can be broken due to incorrectly >> implemented networks / tunnels (see: >> http://ripe61.ripe.net/presentations/223-World_IPv6_day.pdf). >> > > I'm not missing the point, just suggesting that it would be better if > Micr0$0ft were part of the solution instead of just hotwiring past > the problem. > >> For those clients there is no option other than disabling IPv6. > > No, there is the option of troubleshooting why IPv6 doesn't work for > them and working to correct it. > >> Hopefully the service providers & network admins get to identify and >> fix issues. This problem is not client OS specific. I'm all for M$ >> bashing, but not for this reason. >> > > I didn't see where in the M$ propaganda it suggested calling your ISP > or network admin to have them help you fix the issue, so, I don't see > how what they are proposing has any hope of enabling this. > > Owen > >> -Jaidev >> >>> >>> Owen >>> >>> On Jun 2, 2011, at 3:26 PM, Bill Woodcock wrote: >>> > > http://support.microsoft.com/kb/2533454/ > > Uh... > > -Bill > > > > >>>> >>> >>> >>> >>> >> >> >> >> -- >> The older a man gets, the farther he had to walk to school as a boy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From joelja at bogus.com Fri Jun 3 07:54:29 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 3 Jun 2011 05:54:29 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <201106031427.07262.fredan-nanog@fredan.se> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <201106031427.07262.fredan-nanog@fredan.se> Message-ID: On Jun 3, 2011, at 5:27 AM, fredrik danerklint wrote: > The problem is not all on Microsoft at this case. > > > For example; I've bought a ZyXEL P-2612HNU-F1(which has > 802.11n Wireless ADSL 2+ 4-port gateway 2 SIP 2 USB 3G Backup) > in december 2010. It basiclly has everything in it. > > How do I as a customer do to have a working IPv6 setup on this modem since > ZyXEL, basicilly, has decide that it will not support IPv6 at all? irrelevant, nothing is going to break for you on june 8th. At some point you'll buy a new modem, maybe not soon. > I mean, you can not say it does not have the the cpu power for handling IPv6 > when it can also act as a fileserver and a printserver for example. > > What they (ZyXEL) are saying to me (for not haveing IPv6 at this moment) is > that they don't have the skills to implement IPv6 in their current products. > > > Think about all the CPE that will not be upgraded, since those that makes them > don't care at all, even tough it probably has the cpu power to handle IPv6. > > > And I haven't even started at the network equiment that exists between me as a > ISP and my customer (this equiment is out of my control), that can't handle > IPv6 even if my customer got an working CPE with IPv6. > > > How fun is that? > > >> http://support.microsoft.com/kb/2533454/ >> >> Uh... >> >> -Bill > > > -- > //fredan > From jeroen at unfix.org Fri Jun 3 08:00:27 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 03 Jun 2011 15:00:27 +0200 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <201106031427.07262.fredan-nanog@fredan.se> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <201106031427.07262.fredan-nanog@fredan.se> Message-ID: <4DE8DAEB.3080806@unfix.org> On 2011-Jun-03 14:27, fredrik danerklint wrote: > The problem is not all on Microsoft at this case. > > > For example; I've bought a ZyXEL P-2612HNU-F1(which has > 802.11n Wireless ADSL 2+ 4-port gateway 2 SIP 2 USB 3G Backup) > in december 2010. It basiclly has everything in it. > > How do I as a customer do to have a working IPv6 setup on this modem since > ZyXEL, basicilly, has decide that it will not support IPv6 at all? Strange, we have 3 SixXS users who work at Zyxel and are actively terminating their stuff on Zyxel equipment which btw has AICCU support. Now, that model of a router might not be out yet, but it is coming, just don't hold your breath, but it might be a software upgrade if you are lucky. Greets, Jeroen From Valdis.Kletnieks at vt.edu Fri Jun 3 08:04:38 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Jun 2011 09:04:38 -0400 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Fri, 03 Jun 2011 08:42:01 EDT." References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <201106031427.07262.fredan-nanog@fredan.se> Message-ID: <43020.1307106278@turing-police.cc.vt.edu> On Fri, 03 Jun 2011 08:42:01 EDT, Jared Mauch said: > On Jun 3, 2011, at 8:27 AM, fredrik danerklint wrote: > > The problem is not all on Microsoft at this case. > > For example; I've bought a ZyXEL P-2612HNU-F1(which has > > 802.11n Wireless ADSL 2+ 4-port gateway 2 SIP 2 USB 3G Backup) > > in december 2010. It basiclly has everything in it. > You made the mistake of buying something that wasn't compliant with the > following draft: > http://tools.ietf.org/html/draft-george-ipv6-required-02 s/mistake/decision/. There, fixed that for you. I went out 3 years ago and bought a cablemodem and a router that are *also* not IPv6 ready, because it made economic sense at the time (Got them on sale, they had every *other* feature I needed, they were easier/cheaper to find at Best Buy than IPv6-ready gear, Comcast has yet to deploy IPv6 in my area, and they were cheap enough I don't mind forklift-upgrading them when IPv6 becomes actually available here.). They'll probably get replaced within 48 hours of it being *worth* replacing them. But at the time, paying literally twice as much for a box that had a feature I was not likely to be able to use before the box needed replacing *anyhow* didn't make any economic sense. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From aftab.siddiqui at gmail.com Fri Jun 3 08:19:14 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Fri, 3 Jun 2011 18:19:14 +0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <4DE8D822.3050108@scarynet.org> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> Message-ID: Do they have any good reason to block proto 41? Generic Homeusers never asked for IPv4 so they won't ask for IPv6. The time will change many things from CPE to perspective as well. I'm not ready to answer million calls on World IPv6 only week :) Regards, Aftab A. Siddiqui On Fri, Jun 3, 2011 at 5:48 PM, Alexander Maassen wrote: > You are missing a big point here, most NL users for example cannot use > ipv6 tunnels because the isp's equipment doesn't allow them. When I > called my ISP (online.nl) for example to ask about it, they first had > something like: what the heck are you talking about. In fact, one of the > only major isp's in the netherlands actively supporting ipv6 for > customers is xs4all. On several other providers I had I am simply unable > to setup a tunnel. The provider itself is the one blocking proto 41. Not > me or my router, and surely not he.net. > Another issue is, as long as not many homeusers are aware of ipv6 (for > them it's just technical mumbo jumbo they don't care about, as long as > they get the webpages shown they wanna access it's fine for them). > So having said previous, maybe there should be a World IPv6 only week. > That would piss off users, make them complain at their isp, and maybe > THEN they finally wanna do some implementations. > > Op 3-6-2011 9:44, Owen DeLong schreef: > > > > On Jun 2, 2011, at 11:30 PM, Jaidev Sridhar wrote: > > > >> On Thu, Jun 2, 2011 at 21:22, Owen DeLong wrote: > >>> It provides a handy space to comment at the bottom. > >>> > >>> Perhaps people here would like to let M$ know that it would be > preferable > >>> to provide pointers to real workable IPv6 connectivity solutions > rather than > >>> merely hotwire the system to temporarily bypass IPv6 in favor of IPv4. > >>> > >>> That's the path I chose. > >> > >> I guess you're all missing the point here. I've never agreed too much > >> with M$, but what they're doing is right. IPv6 stacks are quite mature > >> these days but IPv6 connectivity can be broken due to incorrectly > >> implemented networks / tunnels (see: > >> http://ripe61.ripe.net/presentations/223-World_IPv6_day.pdf). > >> > > > > I'm not missing the point, just suggesting that it would be better if > > Micr0$0ft were part of the solution instead of just hotwiring past > > the problem. > > > >> For those clients there is no option other than disabling IPv6. > > > > No, there is the option of troubleshooting why IPv6 doesn't work for > > them and working to correct it. > > > >> Hopefully the service providers & network admins get to identify and > >> fix issues. This problem is not client OS specific. I'm all for M$ > >> bashing, but not for this reason. > >> > > > > I didn't see where in the M$ propaganda it suggested calling your ISP > > or network admin to have them help you fix the issue, so, I don't see > > how what they are proposing has any hope of enabling this. > > > > Owen > > > >> -Jaidev > >> > >>> > >>> Owen > >>> > >>> On Jun 2, 2011, at 3:26 PM, Bill Woodcock wrote: > >>> > > > > http://support.microsoft.com/kb/2533454/ > > > > Uh... > > > > -Bill > > > > > > > > > >>>> > >>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> The older a man gets, the farther he had to walk to school as a boy. > > > From jeroen at unfix.org Fri Jun 3 08:38:40 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 03 Jun 2011 15:38:40 +0200 Subject: Protocol-41 is not the only tunneling protocol (Re: Microsoft's participation in World IPv6 day) In-Reply-To: <4DE8D822.3050108@scarynet.org> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> Message-ID: <4DE8E3E0.7010204@unfix.org> On 2011-Jun-03 14:48, Alexander Maassen wrote: > You are missing a big point here, most NL users for example cannot use > ipv6 tunnels because the isp's equipment doesn't allow them. Which is why Freenet6/Gogo6 has TSP and SixXS has AYIYA because tunneling over UDP works fine, just like every other VPN product in the market does (though most VPN products don't do IPv6 yet, it is coming). Take a guess why these protocols exist ;) > When I > called my ISP (online.nl) for example to ask about it, they first had > something like: what the heck are you talking about. That layer 1 personnel does not know about IPv6 just shows that the company did not invest in IPv6 training yet. Their problem that they need to resolve sooner or later and actually the bigger problem than upgrading software or even hardware as those things just cycle out in a few years time. > On several other providers I had I am simply unable > to setup a tunnel. The provider itself is the one blocking proto 41. Not > me or my router, and surely not he.net. Let me guess, you are behind a NAT and expect protocol-41 to be forwarded exactly where? Anyway, as stated above, just use TSP or AYIYA. Having lived in The Netherlands for a long time and various other places, I have never had a problem, even in hotels with broken setups, to get IPv6 going. Heck it even works in most airports ;) > Another issue is, as long as not many homeusers are aware of ipv6 (for > them it's just technical mumbo jumbo they don't care about, as long as > they get the webpages shown they wanna access it's fine for them). > So having said previous, maybe there should be a World IPv6 only week. > That would piss off users, make them complain at their isp, and maybe > THEN they finally wanna do some implementations. "IPv6 only" was the original plan of World IPv6 Day, but take a guess how many phone calls would go to ISPs then and how much money folks would lose when that would be done. Greets, Jeroen From tjc at ecs.soton.ac.uk Fri Jun 3 08:58:43 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 3 Jun 2011 14:58:43 +0100 Subject: Protocol-41 is not the only tunneling protocol (Re: Microsoft's participation in World IPv6 day) In-Reply-To: <4DE8E3E0.7010204@unfix.org> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <4DE8E3E0.7010204@unfix.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> Message-ID: On 3 Jun 2011, at 14:38, Jeroen Massar wrote: > "IPv6 only" was the original plan of World IPv6 Day It was? Tim From cb.list6 at gmail.com Fri Jun 3 09:13:19 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 3 Jun 2011 07:13:19 -0700 Subject: Protocol-41 is not the only tunneling protocol (Re: Microsoft's participation in World IPv6 day) In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> Message-ID: On Jun 3, 2011 6:59 AM, "Tim Chown" wrote: > > > On 3 Jun 2011, at 14:38, Jeroen Massar wrote: > > > "IPv6 only" was the original plan of World IPv6 Day > > It was? No. I think there is confusion with ipv6 hour that happens at ietf where they turn off ipv4 for an hour on the conference wifi. Ipv6 day was never about turning v4 off Cb > Tim > From jeroen at unfix.org Fri Jun 3 09:31:37 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 03 Jun 2011 16:31:37 +0200 Subject: Protocol-41 is not the only tunneling protocol (Re: Microsoft's participation in World IPv6 day) In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> Message-ID: <4DE8F049.9000509@unfix.org> On 2011-Jun-03 16:13, Cameron Byrne wrote: > On Jun 3, 2011 6:59 AM, "Tim Chown" wrote: >> >> >> On 3 Jun 2011, at 14:38, Jeroen Massar wrote: >> >>> "IPv6 only" was the original plan of World IPv6 Day >> >> It was? > > No. I think there is confusion with ipv6 hour that happens at ietf where > they turn off ipv4 for an hour on the conference wifi. Ipv6 day was never > about turning v4 off No confusion there, there was an earlier plan to do an IPv6-only stint, but that was withdrawn as it would have caused too much amok in the world. Greets, Jeroen From owen at delong.com Fri Jun 3 11:13:31 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Jun 2011 09:13:31 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <201106031427.07262.fredan-nanog@fredan.se> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <201106031427.07262.fredan-nanog@fredan.se> Message-ID: <3B310FF6-8946-4701-B810-67DD749794C4@delong.com> On Jun 3, 2011, at 5:27 AM, fredrik danerklint wrote: > The problem is not all on Microsoft at this case. > > > For example; I've bought a ZyXEL P-2612HNU-F1(which has > 802.11n Wireless ADSL 2+ 4-port gateway 2 SIP 2 USB 3G Backup) > in december 2010. It basiclly has everything in it. > OK... > How do I as a customer do to have a working IPv6 setup on this modem since > ZyXEL, basicilly, has decide that it will not support IPv6 at all? > You don't. However, that's not the issue. All you need to do is make sure that your Micr0$0ft boxes don't think they have working IPv6 behind your ZyXEL and you're fine for now. Of course, if your home gateway vendor has decided that they will absolutely not support IPv6, then, it's time to get a new home gateway. > I mean, you can not say it does not have the the cpu power for handling IPv6 > when it can also act as a fileserver and a printserver for example. > True, but, it may not have the flash or RAM to handle the job. > What they (ZyXEL) are saying to me (for not haveing IPv6 at this moment) is > that they don't have the skills to implement IPv6 in their current products. > I would let them know that they are overdue for developing this skill set and better get cracking if I were their customer. > > Think about all the CPE that will not be upgraded, since those that makes them > don't care at all, even tough it probably has the cpu power to handle IPv6. > I think part of the point of W6D is to identify these and raise awareness among the users of such devices that a vital upgrade is in their near future. By just hotwiring past the IPv6 issues, Micr0$0ft is removing this opportunity. > > And I haven't even started at the network equiment that exists between me as a > ISP and my customer (this equiment is out of my control), that can't handle > IPv6 even if my customer got an working CPE with IPv6. > That's what solutions like 6rd and 6in4 are intended for. > > How fun is that? > There are many things that are fun in this industry. The next couple of years are definitely going to be interesting. Owen > >> http://support.microsoft.com/kb/2533454/ >> >> Uh... >> >> -Bill > > > -- > //fredan From frnkblk at iname.com Fri Jun 3 11:16:18 2011 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 3 Jun 2011 11:16:18 -0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> Message-ID: <001b01cc2209$922d3cb0$b687b610$@iname.com> As Owen is suggesting, if would have been helpful if Microsoft's Network troubleshooting wizard in Windows Vista and 7 had an inkling about IPv6 and would check IPv6 connectivity in the same way it checks IPv6 connectivity, and work through things link 6to4 issues. Frank -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, June 03, 2011 2:44 AM To: mail at jaidev.info Cc: NANOG list Subject: Re: Microsoft's participation in World IPv6 day On Jun 2, 2011, at 11:30 PM, Jaidev Sridhar wrote: > On Thu, Jun 2, 2011 at 21:22, Owen DeLong wrote: >> It provides a handy space to comment at the bottom. >> >> Perhaps people here would like to let M$ know that it would be preferable >> to provide pointers to real workable IPv6 connectivity solutions rather than >> merely hotwire the system to temporarily bypass IPv6 in favor of IPv4. >> >> That's the path I chose. > > I guess you're all missing the point here. I've never agreed too much > with M$, but what they're doing is right. IPv6 stacks are quite mature > these days but IPv6 connectivity can be broken due to incorrectly > implemented networks / tunnels (see: > http://ripe61.ripe.net/presentations/223-World_IPv6_day.pdf). > I'm not missing the point, just suggesting that it would be better if Micr0$0ft were part of the solution instead of just hotwiring past the problem. > For those clients there is no option other than disabling IPv6. No, there is the option of troubleshooting why IPv6 doesn't work for them and working to correct it. > Hopefully the service providers & network admins get to identify and > fix issues. This problem is not client OS specific. I'm all for M$ > bashing, but not for this reason. > I didn't see where in the M$ propaganda it suggested calling your ISP or network admin to have them help you fix the issue, so, I don't see how what they are proposing has any hope of enabling this. Owen > -Jaidev > >> >> Owen >> >> On Jun 2, 2011, at 3:26 PM, Bill Woodcock wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> >>> http://support.microsoft.com/kb/2533454/ >>> >>> Uh... >>> >>> -Bill >>> >>> >>> >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (Darwin) >>> >>> iQIcBAEBCAAGBQJN6A4VAAoJEG+kcEsoi3+H7uoQAMrSuAXqXo+L+Wkiqx+OvwU8 >>> v4TJEeTU8Hp+ap0Kuka0Jq2HFC2ReABwfwZEX9wywdcXKFYu1u8znVa6neX6rjcv >>> uxghsoqZEp9A4KB/J2q/ulM6B8/40oRHK1IuHdv0fZwC0oLyJ1W10n1VzsiE3qxx >>> JOWbn1SIPo4nXnTIVU60yDOySlsclpW3fuqQoUIHzwEZEFgYf2l7ywcPfuCvVQJw >>> FuqASIk0c9hQJVnBKTpaIQaNdRExkYtQSs5i8+TyzxhyGx1XGDOeJoRHRBQhSfcS >>> DS8Vuwvblh+UjGFDIEF9Oen7NxrK2xjBCJIDV+MbJwAJdjs5wM3H9nFdhCX9Z2cl >>> TRIj4/qQcS7m8cl4gNFY3nplALrWHjs2WK8jk0HlDnEgvSe7D2YC6Te5vnGgY9sX >>> JXif1D36Pzx1V1JwbmMIwvvlUalPH/jyciMVUGrMMKc+0w7/75IerzGsSabdTIzJ >>> t0/4jh5/h8db+q37CfN1Xj/gWkBcIyXmGGCd3pny4+YJwI5hnspWoeRq5lkB64Pn >>> zDCJANGd5PZxtcTBgYJkZCK+sNjzycThkS1UP8pKdajbyQNlbRWkDFbQwMQ0DQEa >>> IanX3BioesZmfashzRu+khdczhLVtFLKLUT7/yI2RqQOekx5sO+HqzTIiIIp5mkd >>> KbOBvdIvnaz5FI94I8jk >>> =OyB3 >>> -----END PGP SIGNATURE----- >>> >> >> >> >> > > > > -- > The older a man gets, the farther he had to walk to school as a boy. From frnkblk at iname.com Fri Jun 3 11:18:41 2011 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 3 Jun 2011 11:18:41 -0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <201106031427.07262.fredan-nanog@fredan.se> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <201106031427.07262.fredan-nanog@fredan.se> Message-ID: <001c01cc2209$e727d860$b5778920$@iname.com> Have a ZyXEL VSG1432 right behind me where the IPv6 works pretty good (http://www.getipv6.info/index.php/Broadband_CPE#DSL). All the DSL modem vendors could stand improving their GUI. Frank -----Original Message----- From: fredrik danerklint [mailto:fredan-nanog at fredan.se] Sent: Friday, June 03, 2011 7:27 AM To: nanog at nanog.org Subject: Re: Microsoft's participation in World IPv6 day The problem is not all on Microsoft at this case. For example; I've bought a ZyXEL P-2612HNU-F1(which has 802.11n Wireless ADSL 2+ 4-port gateway 2 SIP 2 USB 3G Backup) in december 2010. It basiclly has everything in it. How do I as a customer do to have a working IPv6 setup on this modem since ZyXEL, basicilly, has decide that it will not support IPv6 at all? I mean, you can not say it does not have the the cpu power for handling IPv6 when it can also act as a fileserver and a printserver for example. What they (ZyXEL) are saying to me (for not haveing IPv6 at this moment) is that they don't have the skills to implement IPv6 in their current products. Think about all the CPE that will not be upgraded, since those that makes them don't care at all, even tough it probably has the cpu power to handle IPv6. And I haven't even started at the network equiment that exists between me as a ISP and my customer (this equiment is out of my control), that can't handle IPv6 even if my customer got an working CPE with IPv6. How fun is that? > http://support.microsoft.com/kb/2533454/ > > Uh... > > -Bill -- //fredan From owen at delong.com Fri Jun 3 11:20:28 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Jun 2011 09:20:28 -0700 Subject: Protocol-41 is not the only tunneling protocol (Re: Microsoft's participation in World IPv6 day) In-Reply-To: <4DE8F049.9000509@unfix.org> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> Message-ID: On Jun 3, 2011, at 7:31 AM, Jeroen Massar wrote: > On 2011-Jun-03 16:13, Cameron Byrne wrote: >> On Jun 3, 2011 6:59 AM, "Tim Chown" wrote: >>> >>> >>> On 3 Jun 2011, at 14:38, Jeroen Massar wrote: >>> >>>> "IPv6 only" was the original plan of World IPv6 Day >>> >>> It was? >> >> No. I think there is confusion with ipv6 hour that happens at ietf where >> they turn off ipv4 for an hour on the conference wifi. Ipv6 day was never >> about turning v4 off > > No confusion there, there was an earlier plan to do an IPv6-only stint, > but that was withdrawn as it would have caused too much amok in the world. > > Greets, > Jeroen FIrst I've heard of such a thing. The original organizers of W6D have zero motivation to try such a thing and I can't imagine why they would even consider it for more than a picosecond. Owen From feldman at newnog.org Fri Jun 3 13:04:25 2011 From: feldman at newnog.org (Steven Feldman) Date: Fri, 3 Jun 2011 11:04:25 -0700 Subject: [NANOG-announce] updated NANOG 52 registration and hotel information Message-ID: Two items for those of you still working on your NANOG 52 travel arrangements: - Today is the cutoff for the standard registration fee. After today the fee increases by $75. - The Sheraton is completely sold out for the night of Tuesday, June 14. We have not been able to secure additional room blocks, but we did find two hotels nearby that still had availability as of last night. They are: Grand Hyatt Denver 1750 Welton Street, Denver, CO 80202 Tel: +1 303 295 1234 Fax: +1 303 292 2472 http://www.granddenver.hyatt.com/ Warwick Denver Hotel 1776 Grant Street, Denver, CO 80203 Tel: +1 303 861 2000 Fax: +1 303 832 0320 http://www.warwickdenver.com/ See you in Denver! Steve _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From cscora at apnic.net Fri Jun 3 14:01:02 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Jun 2011 05:01:02 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201106031901.p53J126U028199@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 04 Jun, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 358561 Prefixes after maximum aggregation: 162439 Deaggregation factor: 2.21 Unique aggregates announced to Internet: 178183 Total ASes present in the Internet Routing Table: 37775 Prefixes per ASN: 9.49 Origin-only ASes present in the Internet Routing Table: 31544 Origin ASes announcing only one prefix: 15151 Transit ASes present in the Internet Routing Table: 5102 Transit-only ASes present in the Internet Routing Table: 134 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 36 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 747 Unregistered ASNs in the Routing Table: 395 Number of 32-bit ASNs allocated by the RIRs: 1425 Number of 32-bit ASNs visible in the Routing Table: 1129 Prefixes from 32-bit ASNs in the Routing Table: 2579 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 165 Number of addresses announced to Internet: 2450918336 Equivalent to 146 /8s, 22 /16s and 11 /24s Percentage of available address space announced: 66.1 Percentage of allocated address space announced: 66.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.0 Total number of prefixes smaller than registry allocations: 149599 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 88800 Total APNIC prefixes after maximum aggregation: 30084 APNIC Deaggregation factor: 2.95 Prefixes being announced from the APNIC address blocks: 85253 Unique aggregates announced from the APNIC address blocks: 36662 APNIC Region origin ASes present in the Internet Routing Table: 4475 APNIC Prefixes per ASN: 19.05 APNIC Region origin ASes announcing only one prefix: 1253 APNIC Region transit ASes present in the Internet Routing Table: 705 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 47 Number of APNIC addresses announced to Internet: 619636256 Equivalent to 36 /8s, 238 /16s and 230 /24s Percentage of available APNIC address space announced: 78.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 140579 Total ARIN prefixes after maximum aggregation: 71516 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 112681 Unique aggregates announced from the ARIN address blocks: 46229 ARIN Region origin ASes present in the Internet Routing Table: 14406 ARIN Prefixes per ASN: 7.82 ARIN Region origin ASes announcing only one prefix: 5495 ARIN Region transit ASes present in the Internet Routing Table: 1510 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 801985792 Equivalent to 47 /8s, 205 /16s and 85 /24s Percentage of available ARIN address space announced: 63.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 85208 Total RIPE prefixes after maximum aggregation: 48504 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 78635 Unique aggregates announced from the RIPE address blocks: 52035 RIPE Region origin ASes present in the Internet Routing Table: 15661 RIPE Prefixes per ASN: 5.02 RIPE Region origin ASes announcing only one prefix: 7830 RIPE Region transit ASes present in the Internet Routing Table: 2461 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 834 Number of RIPE addresses announced to Internet: 475054592 Equivalent to 28 /8s, 80 /16s and 194 /24s Percentage of available RIPE address space announced: 76.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 33171 Total LACNIC prefixes after maximum aggregation: 7536 LACNIC Deaggregation factor: 4.40 Prefixes being announced from the LACNIC address blocks: 32258 Unique aggregates announced from the LACNIC address blocks: 16961 LACNIC Region origin ASes present in the Internet Routing Table: 1462 LACNIC Prefixes per ASN: 22.06 LACNIC Region origin ASes announcing only one prefix: 431 LACNIC Region transit ASes present in the Internet Routing Table: 263 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 231 Number of LACNIC addresses announced to Internet: 84647424 Equivalent to 5 /8s, 11 /16s and 158 /24s Percentage of available LACNIC address space announced: 56.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7999 Total AfriNIC prefixes after maximum aggregation: 1909 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 6308 Unique aggregates announced from the AfriNIC address blocks: 1917 AfriNIC Region origin ASes present in the Internet Routing Table: 458 AfriNIC Prefixes per ASN: 13.77 AfriNIC Region origin ASes announcing only one prefix: 142 AfriNIC Region transit ASes present in the Internet Routing Table: 100 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 23586048 Equivalent to 1 /8s, 103 /16s and 229 /24s Percentage of available AfriNIC address space announced: 35.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2460 9500 922 Korea Telecom (KIX) 17974 1541 441 38 PT TELEKOMUNIKASI INDONESIA 7545 1537 301 86 TPG Internet Pty Ltd 4755 1470 634 166 TATA Communications formerly 24560 1155 337 187 Bharti Airtel Ltd., Telemedia 7552 1141 1064 7 Vietel Corporation 4808 1086 2144 308 CNCGROUP IP network: China169 9583 1082 80 510 Sify Limited 9829 956 843 82 BSNL National Internet Backbo 18101 931 116 139 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3641 3822 256 bellsouth.net, inc. 4323 1973 1081 400 Time Warner Telecom 18566 1875 355 269 Covad Communications 1785 1790 681 122 PaeTec Communications, Inc. 6478 1716 318 45 AT&T Worldnet Services 20115 1535 1540 633 Charter Communications 19262 1492 4936 307 Verizon Global Networks 7018 1367 7068 892 AT&T WorldNet Services 22773 1337 2897 88 Cox Communications, Inc. 2386 1268 536 911 AT&T Data Communications Serv Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 517 1780 320 UPC Distribution Services 34984 517 106 179 BILISIM TELEKOM 3292 461 2078 396 TDC Tele Danmark 20940 458 134 350 Akamai Technologies European 29049 451 33 48 AzerSat LLC. 8866 445 134 26 Bulgarian Telecommunication C 12479 432 593 7 Uni2 Autonomous System 3320 425 8152 370 Deutsche Telekom AG 8551 405 354 48 Bezeq International 702 396 1803 310 UUNET - Commercial IP service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1512 278 157 TVCABLE BOGOTA 8151 1383 2724 364 UniNet S.A. de C.V. 28573 1319 992 86 NET Servicos de Comunicao S.A 7303 960 504 154 Telecom Argentina Stet-France 6503 734 354 73 AVANTEL, S.A. 14420 675 54 89 CORPORACION NACIONAL DE TELEC 22047 565 310 15 VTR PUNTO NET S.A. 3816 527 231 93 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 13489 515 262 124 Orbitel S.A. E.S.P. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 833 445 11 TEDATA 24863 721 147 37 LINKdotNET AS number 15475 544 90 8 Nile Online 36992 294 399 14 Etisalat MISR 3741 265 937 226 The Internet Solution 6713 241 215 13 Itissalat Al-MAGHRIB 33776 218 12 11 Starcomms Nigeria Limited 24835 208 78 10 RAYA Telecom - Egypt 29571 193 19 12 Ci Telecom Autonomous system 16637 150 441 86 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3641 3822 256 bellsouth.net, inc. 23456 2579 639 1398 32-bit ASN transition 4766 2460 9500 922 Korea Telecom (KIX) 4323 1973 1081 400 Time Warner Telecom 18566 1875 355 269 Covad Communications 1785 1790 681 122 PaeTec Communications, Inc. 6478 1716 318 45 AT&T Worldnet Services 17974 1541 441 38 PT TELEKOMUNIKASI INDONESIA 7545 1537 301 86 TPG Internet Pty Ltd 20115 1535 1540 633 Charter Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6478 1716 1671 AT&T Worldnet Services 1785 1790 1668 PaeTec Communications, Inc. 18566 1875 1606 Covad Communications 4323 1973 1573 Time Warner Telecom 4766 2460 1538 Korea Telecom (KIX) 17974 1541 1503 PT TELEKOMUNIKASI INDONESIA 7545 1537 1451 TPG Internet Pty Ltd 10620 1512 1355 TVCABLE BOGOTA 4755 1470 1304 TATA Communications formerly 22773 1337 1249 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 27.0.128.0/17 7514 Media Exchange, Inc. 41.190.32.0/23 31856 CABSAS 41.190.34.0/23 31856 CABSAS 41.190.36.0/23 31856 CABSAS Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:12 /10:28 /11:81 /12:228 /13:461 /14:798 /15:1395 /16:11917 /17:5834 /18:9733 /19:19342 /20:25663 /21:25940 /22:34114 /23:33063 /24:186681 /25:1084 /26:1275 /27:711 /28:165 /29:8 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2243 3641 bellsouth.net, inc. 18566 1838 1875 Covad Communications 6478 1670 1716 AT&T Worldnet Services 10620 1402 1512 TVCABLE BOGOTA 23456 1260 2579 32-bit ASN transition 11492 1107 1153 Cable One 7011 1061 1160 Citizens Utilities 1785 1050 1790 PaeTec Communications, Inc. 4323 886 1973 Time Warner Telecom 22773 852 1337 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:282 2:48 4:16 5:1 6:3 8:336 12:1980 13:1 14:464 15:15 16:3 17:8 20:10 23:6 24:1613 27:752 31:419 32:60 33:4 34:2 37:1 38:737 40:102 41:2524 42:6 44:3 46:934 47:3 49:200 50:435 52:13 54:2 55:6 56:2 57:29 58:840 59:479 60:387 61:1131 62:1035 63:1937 64:3941 65:2289 66:4148 67:1867 68:1091 69:2989 70:704 71:352 72:1883 73:1 74:2354 75:305 76:341 77:873 78:700 79:460 80:1078 81:836 82:493 83:440 84:677 85:1070 86:592 87:753 88:331 89:1531 90:203 91:3808 92:524 93:1049 94:1283 95:820 96:506 97:249 98:860 99:35 101:61 103:47 106:1 107:7 108:85 109:957 110:600 111:708 112:304 113:404 114:535 115:668 116:957 117:693 118:797 119:1148 120:311 121:671 122:1626 123:962 124:1270 125:1217 128:261 129:173 130:164 131:570 132:109 133:19 134:213 135:48 136:214 137:145 138:300 139:109 140:481 141:239 142:404 143:406 144:487 145:54 146:447 147:211 148:595 149:244 150:172 151:185 152:328 153:179 154:3 155:397 156:195 157:352 158:138 159:380 160:317 161:207 162:281 163:165 164:501 165:354 166:515 167:427 168:728 169:155 170:801 171:77 172:1 173:1554 174:551 175:370 176:130 177:145 178:995 180:858 181:18 182:459 183:211 184:293 185:1 186:1215 187:771 188:849 189:897 190:4863 192:5849 193:4901 194:3494 195:2997 196:1220 197:19 198:3565 199:3923 200:5547 201:1484 202:8271 203:8390 204:4180 205:2310 206:2686 207:2875 208:3973 209:3476 210:2725 211:1398 212:1998 213:1723 214:730 215:72 216:4943 217:1638 218:546 219:363 220:1204 221:490 222:316 223:150 End of report From feldman at newnog.org Fri Jun 3 14:41:51 2011 From: feldman at newnog.org (Steven Feldman) Date: Fri, 3 Jun 2011 12:41:51 -0700 Subject: [NANOG-announce] additional hotel information for NANOG 52 Message-ID: Late breaking news: The Warwick Denver Hotel has set aside some rooms for at a special rate of $159/night. To make reservations using this rate, call the hotel directly at 303-861-2000 and ask for Customer Reservations. At last check, there were 19 rooms left for the Tuesday night, and plenty of availability for the other nights. Steve _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From fmartin at linkedin.com Fri Jun 3 16:31:57 2011 From: fmartin at linkedin.com (Franck Martin) Date: Fri, 3 Jun 2011 21:31:57 +0000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Message-ID: http://www.google.com/intl/en/ipv6/statistics/ Something is happening... On 6/2/11 21:34 , "Hank Nussbacher" wrote: >On Thu, 2 Jun 2011, Cameron Byrne wrote: > >In that case can anyone explain why the number of IPv4 *only* systems is >increasing rather than decreasing: >http://server8.test-ipv6.com/stats.html > >I would have expected the green+azure areas in those graphs to have >increased in the past half year but counter-intutitively, it appears that >IPv4 only usage is increasing. From Valdis.Kletnieks at vt.edu Fri Jun 3 16:53:02 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Jun 2011 17:53:02 -0400 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Fri, 03 Jun 2011 21:31:57 -0000." References: Message-ID: <25584.1307137982@turing-police.cc.vt.edu> On Fri, 03 Jun 2011 21:31:57 -0000, Franck Martin said: > http://www.google.com/intl/en/ipv6/statistics/ > > Something is happening... What's special about Sunday peaks and Friday lows on that graph? I think I asked that once before, with no firm conclusions. But there's a definite sawtooth there, big enough that we probably want to understand it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cidr-report at potaroo.net Fri Jun 3 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Jun 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201106032200.p53M0132078074@wattle.apnic.net> BGP Update Report Interval: 26-May-11 -to- 02-Jun-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 57552 3.9% 88.8 -- BSNL-NIB National Internet Backbone 2 - AS33475 45744 3.1% 333.9 -- RSN-1 - RockSolid Network, Inc. 3 - AS24560 33904 2.3% 29.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - AS19743 33903 2.3% 5650.5 -- 5 - AS9498 27999 1.9% 34.4 -- BBIL-AP BHARTI Airtel Ltd. 6 - AS27738 22165 1.5% 65.4 -- Ecuadortelecom S.A. 7 - AS17974 17751 1.2% 12.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS11492 17633 1.2% 15.9 -- CABLEONE - CABLE ONE, INC. 9 - AS32528 15576 1.1% 2596.0 -- ABBOTT Abbot Labs 10 - AS3320 9731 0.7% 405.5 -- DTAG Deutsche Telekom AG 11 - AS17488 9398 0.6% 25.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 12 - AS2697 9387 0.6% 69.5 -- ERX-ERNET-AS Education and Research Network 13 - AS45514 8527 0.6% 28.0 -- TELEMEDIA-SMB-AS-AP Bharti Airtel Ltd., TELEMEDIA Services, for SMB customers 14 - AS45595 8318 0.6% 81.5 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 15 - AS27065 7747 0.5% 73.8 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 16 - AS3454 7635 0.5% 7635.0 -- Universidad Autonoma de Nuevo Leon 17 - AS7552 7577 0.5% 7.2 -- VIETEL-AS-AP Vietel Corporation 18 - AS701 7050 0.5% 119.5 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 19 - AS8151 6906 0.5% 7.1 -- Uninet S.A. de C.V. 20 - AS18002 6859 0.5% 43.7 -- WORLDPHONE-IN AS Number for Interdomain Routing TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3454 7635 0.5% 7635.0 -- Universidad Autonoma de Nuevo Leon 2 - AS19743 33903 2.3% 5650.5 -- 3 - AS32528 15576 1.1% 2596.0 -- ABBOTT Abbot Labs 4 - AS31815 2624 0.2% 1312.0 -- MEDIATEMPLE - Media Temple, Inc. 5 - AS51722 1118 0.1% 1118.0 -- EAD-TELECOM-AS EAD TELECOM SRL 6 - AS24919 3679 0.2% 919.8 -- CUBIO-AS Oy Cubio Communications Ltd. 7 - AS49600 869 0.1% 869.0 -- LASEDA La Seda de Barcelona, S.A 8 - AS50347 781 0.1% 781.0 -- ZONTERRA-AS Zonterra Corp SRL 9 - AS21429 768 0.1% 768.0 -- SICOB Sicob S.r.l. Autonomous System 10 - AS38789 723 0.1% 723.0 -- IAHGAMES-AS-ID IAHGames Indonesia PT 11 - AS46820 617 0.0% 617.0 -- LRHNET1 - Littleton Regional Hospital 12 - AS3 588 0.0% 735.0 -- TELLUS-AS Tellus BV 13 - AS10445 2362 0.2% 472.4 -- HTG - Huntleigh Telcom 14 - AS3320 9731 0.7% 405.5 -- DTAG Deutsche Telekom AG 15 - AS48068 401 0.0% 401.0 -- VISONIC Visonic Ltd 16 - AS8745 366 0.0% 366.0 -- AS-BG-BAS BASNET autonomous system Bulgaria 17 - AS36948 721 0.1% 360.5 -- KENIC 18 - AS36372 353 0.0% 353.0 -- VENYU-3 - Venyu Solutions Inc. 19 - AS38388 3015 0.2% 335.0 -- BEN-AS-KR Bukbu District Office of Education in Seoul 20 - AS33475 45744 3.1% 333.9 -- RSN-1 - RockSolid Network, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 11224 0.7% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 91.217.214.0/24 9569 0.6% AS3320 -- DTAG Deutsche Telekom AG 3 - 130.36.35.0/24 7783 0.5% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.34.0/24 7781 0.5% AS32528 -- ABBOTT Abbot Labs 5 - 200.23.202.0/24 7635 0.5% AS3454 -- Universidad Autonoma de Nuevo Leon 6 - 208.54.82.0/24 6800 0.4% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 7 - 65.122.196.0/24 6418 0.4% AS19743 -- 8 - 72.164.144.0/24 5504 0.3% AS19743 -- 9 - 66.238.91.0/24 5497 0.3% AS19743 -- 10 - 66.89.98.0/24 5495 0.3% AS19743 -- 11 - 65.163.182.0/24 5495 0.3% AS19743 -- 12 - 65.162.204.0/24 5494 0.3% AS19743 -- 13 - 202.153.174.0/24 3413 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 14 - 205.91.160.0/20 2984 0.2% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - 65.181.192.0/23 2041 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 16 - 77.74.144.0/24 1536 0.1% AS21429 -- SICOB Sicob S.r.l. Autonomous System AS5396 -- MC-LINK MC-link Spa 17 - 192.80.43.0/24 1508 0.1% AS1706 -- UNIV-ARIZ - University of Arizona 18 - 24.116.2.0/24 1497 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 19 - 24.116.1.0/24 1388 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 20 - 190.15.21.128/26 1360 0.1% AS27817 -- Red Nacional Acad?mica de Tecnolog?a Avanzada - RENATA Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 3 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Jun 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201106032200.p53M00X2078069@wattle.apnic.net> This report has been generated at Fri Jun 3 21:11:57 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 27-05-11 361620 212256 28-05-11 361939 212249 29-05-11 362005 212296 30-05-11 361957 212301 31-05-11 362044 212140 01-06-11 361502 212100 02-06-11 361940 212371 03-06-11 362189 212296 AS Summary 37870 Number of ASes in routing system 15946 Number of ASes announcing only one prefix 3640 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 110390016 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 03Jun11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 362185 212308 149877 41.4% All ASes AS6389 3640 260 3380 92.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 1975 402 1573 79.6% TWTC - tw telecom holdings, inc. AS4766 2460 932 1528 62.1% KIXS-AS-KR Korea Telecom AS6478 1716 279 1437 83.7% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1338 97 1241 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1492 307 1185 79.4% VZGNI-TRANSIT - Verizon Online LLC AS18566 1875 720 1155 61.6% COVAD - Covad Communications Co. AS4755 1471 384 1087 73.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1793 759 1034 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1322 313 1009 76.3% NET Servicos de Comunicao S.A. AS7552 1141 133 1008 88.3% VIETEL-AS-AP Vietel Corporation AS10620 1512 591 921 60.9% Telmex Colombia S.A. AS7545 1538 746 792 51.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 933 145 788 84.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1155 387 768 66.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4808 1090 343 747 68.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS8151 1385 651 734 53.0% Uninet S.A. de C.V. AS7303 960 294 666 69.4% Telecom Argentina S.A. AS3356 1113 453 660 59.3% LEVEL3 Level 3 Communications AS17974 1542 922 620 40.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS17488 930 312 618 66.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS17676 658 70 588 89.4% GIGAINFRA Softbank BB Corp. AS14420 675 89 586 86.8% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22561 929 364 565 60.8% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 954 398 556 58.3% GBLX Global Crossing Ltd. AS855 646 109 537 83.1% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4780 749 213 536 71.6% SEEDNET Digital United Inc. AS22047 565 30 535 94.7% VTR BANDA ANCHA S.A. AS4804 586 87 499 85.2% MPX-AS Microplex PTY LTD AS30693 506 10 496 98.0% EONI- X-C- ORP- ORA- TIO- N-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation Total 38649 10800 27849 72.1% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 27.0.128.0/17 AS7514 MEX Media EXchange, Inc. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.22.32.0/19 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.228.170.0/24 AS48344 NETZWERK68A Sven Wefels 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 131.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.72.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.100.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.161.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.221.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.157.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.184.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.191.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 134.175.0.0/16 AS14576 RHNL-NET - Righthosting.com 138.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.36.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.94.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.97.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.99.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.117.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.118.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.122.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.185.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.186.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.219.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 143.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.137.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.208.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.101.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.102.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.103.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.156.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.166.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.167.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.168.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.169.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.170.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.171.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.172.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.173.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.174.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.175.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.200.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.201.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.203.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.206.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.207.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.230.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.235.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.236.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.237.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.240.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.241.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.242.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.243.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.248.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.252.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.253.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 161.10.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.18.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.22.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.138.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.140.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.212.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.57.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.58.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.60.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.61.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.62.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.63.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.116.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.90.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.181.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.194.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.195.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.196.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.197.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.227.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.228.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.78.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.79.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.80.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.81.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.82.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.83.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.84.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.150.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.158.25.0/24 AS2717 CUMMINS-AS1 - Cummins Engine Co. Inc. 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.63.80.0/24 AS9557 PKTELECOM-AS-PK Paknet Limited Merged into PTCL 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.147.110.0/24 AS45165 203.147.111.0/24 AS45165 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.190.32.0/22 AS24564 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From surfer at mauigateway.com Fri Jun 3 17:20:22 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 3 Jun 2011 15:20:22 -0700 Subject: Microsoft's participation in World IPv6 day Message-ID: <20110603152022.4F2BD78B@resin18.mta.everyone.net> --- Valdis.Kletnieks at vt.edu wrote: What's special about Sunday peaks and Friday lows on that graph? I think I asked that once before, with no firm conclusions. But there's a definite sawtooth there, big enough that we probably want to understand it. ----------------------------------------- There're about 52 peaks in a year on the timeline... :-) scott From Valdis.Kletnieks at vt.edu Fri Jun 3 17:24:42 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Jun 2011 18:24:42 -0400 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Fri, 03 Jun 2011 15:20:22 PDT." <20110603152022.4F2BD78B@resin18.mta.everyone.net> References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> Message-ID: <26988.1307139882@turing-police.cc.vt.edu> On Fri, 03 Jun 2011 15:20:22 PDT, Scott Weeks said: > There're about 52 peaks in a year on the timeline... :-) Right. But why is Google seeing noticeably higher IPv6 loads on Sunday and lower loads on Friday? I'd buy a "different traffic pattern for home/office", but then you'd expect Friday to be about the same as M-Th, and Sat/Sun to be about even. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tvarriale at comcast.net Fri Jun 3 17:50:23 2011 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 03 Jun 2011 17:50:23 -0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <586376.10713.qm@web59601.mail.ac4.yahoo.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> Message-ID: <4DE9652F.5090605@comcast.net> On 6/2/2011 7:08 PM, andrew.wallace wrote: > World day is a sure-shot bet win at an anti-climax, and an industry failure and waste of investment and publicity campaign. > > Andrew > I've had more customers ask and now willing to participate than ever before. Any better suggestions? Or, maybe take your pissing mechanism and try a subject more worthy. tv From tony.mccrory at gmail.com Fri Jun 3 18:04:42 2011 From: tony.mccrory at gmail.com (Tony McCrory) Date: Sat, 4 Jun 2011 00:04:42 +0100 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <26988.1307139882@turing-police.cc.vt.edu> References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> Message-ID: On 3 June 2011 23:24, wrote: > On Fri, 03 Jun 2011 15:20:22 PDT, Scott Weeks said: > >> There're about 52 peaks in a year on the timeline... ?:-) > > Right. But why is Google seeing noticeably higher IPv6 loads on Sunday and > lower loads on Friday? I'd buy a "different traffic pattern for home/office", > but then you'd expect Friday to be about the same as M-Th, and Sat/Sun to be > about even. > > I wonder if there is a disproportionately large amount of IPv6 usage in the Middle East where a number of countries have their weekend on Friday and Saturday, with Sunday being the first day of their working week? UAE and Israel as examples. Tony From simon at slimey.org Fri Jun 3 18:13:32 2011 From: simon at slimey.org (Simon Lockhart) Date: Sat, 4 Jun 2011 00:13:32 +0100 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> Message-ID: <20110603231331.GL26122@virtual.bogons.net> On Sat Jun 04, 2011 at 12:04:42AM +0100, Tony McCrory wrote: > I wonder if there is a disproportionately large amount of IPv6 usage > in the Middle East where a number of countries have their weekend on > Friday and Saturday, with Sunday being the first day of their working > week? UAE and Israel as examples. Interestingly, providing access services to students in the UK, I see Friday and Saturday as my quiet days, with Sunday being as busy as Monday - Thursday. I always just put it down to students going out drinking on Fridays and Saturdays. Simon From owen at delong.com Fri Jun 3 18:13:35 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Jun 2011 16:13:35 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <26988.1307139882@turing-police.cc.vt.edu> References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> Message-ID: <35344579-21D6-4ADF-9F29-FCC91219BFF5@delong.com> On Jun 3, 2011, at 3:24 PM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 03 Jun 2011 15:20:22 PDT, Scott Weeks said: > >> There're about 52 peaks in a year on the timeline... :-) > > Right. But why is Google seeing noticeably higher IPv6 loads on Sunday and > lower loads on Friday? I'd buy a "different traffic pattern for home/office", > but then you'd expect Friday to be about the same as M-Th, and Sat/Sun to be > about even. > Everyone is out interacting with Humans on Friday nights. Sunday, everyone is home trying to avoid dealing with their families. (Mostly tongue in cheek) Owen From bonomi at mail.r-bonomi.com Fri Jun 3 19:20:28 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 3 Jun 2011 19:20:28 -0500 (CDT) Subject: Microsoft's participation in World IPv6 day In-Reply-To: <26988.1307139882@turing-police.cc.vt.edu> Message-ID: <201106040020.p540KS60012599@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Fri Jun 3 17:25:39 2011 > To: surfer at mauigateway.com > Subject: Re: Microsoft's participation in World IPv6 day > From: Valdis.Kletnieks at vt.edu > Date: Fri, 03 Jun 2011 18:24:42 -0400 > Cc: nanog at nanog.org > > --==_Exmh_1307139882_2680P > Content-Type: text/plain; charset=us-ascii > > On Fri, 03 Jun 2011 15:20:22 PDT, Scott Weeks said: > > > There're about 52 peaks in a year on the timeline... :-) > > Right. But why is Google seeing noticeably higher IPv6 loads on Sunday and > lower loads on Friday? I'd buy a "different traffic pattern for home/office", > but then you'd expect Friday to be about the same as M-Th, and Sat/Sun to be > about even. Possibly traffic from the 'wrong side' of the International Date line?? From tony at lavanauts.org Fri Jun 3 21:45:06 2011 From: tony at lavanauts.org (Antonio Querubin) Date: Fri, 3 Jun 2011 16:45:06 -1000 (HST) Subject: Microsoft's participation in World IPv6 day In-Reply-To: <25584.1307137982@turing-police.cc.vt.edu> References: <25584.1307137982@turing-police.cc.vt.edu> Message-ID: On Fri, 3 Jun 2011, Valdis.Kletnieks at vt.edu wrote: > What's special about Sunday peaks and Friday lows on that graph? I think I > asked that once before, with no firm conclusions. But there's a definite > sawtooth there, big enough that we probably want to understand it. It means that IPv6 geeks have lives too :) -- Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From m.hotze at hotze.com Sat Jun 4 00:28:18 2011 From: m.hotze at hotze.com (Martin Hotze) Date: Sat, 4 Jun 2011 05:28:18 +0000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: Message-ID: <9DDD3733AE0DB544B7E2B78F81BFDCD30341E225@SBSSRV.hotze.local> > Date: Fri, 3 Jun 2011 09:13:31 -0700 > From: Owen DeLong > Subject: Re: Microsoft's participation in World IPv6 day > To: fredrik danerklint > Cc: nanog at nanog.org > > On Jun 3, 2011, at 5:27 AM, fredrik danerklint wrote: > > > The problem is not all on Microsoft at this case. > > > > > > For example; I've bought a ZyXEL P-2612HNU-F1(which has > > 802.11n Wireless ADSL 2+ 4-port gateway 2 SIP 2 USB 3G Backup) > > in december 2010. It basiclly has everything in it. (...) > > What they (ZyXEL) are saying to me (for not haveing IPv6 at this moment) > is > > that they don't have the skills to implement IPv6 in their current > products. > > > > I would let them know that they are overdue for developing this skill > set and better get cracking if I were their customer. well, directly from their (ZyXEL) US homepage you will be directed to: http://us.zyxel.com/info/ipv6/ with at least some information. #m From joly at punkcast.com Sat Jun 4 01:38:32 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 4 Jun 2011 02:38:32 -0400 Subject: Syrian Internet shutdown Message-ID: Renesys yesterday reported a Syrian Internet shutdown. http://www.renesys.com/blog/2011/06/syrian-internet-shutdown.shtml I'm getting through to some but not all of the sites reported down. Any further info? -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From jeroen at unfix.org Sat Jun 4 03:17:08 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 04 Jun 2011 10:17:08 +0200 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> Message-ID: <4DE9EA04.2050605@unfix.org> On 2011-Jun-03 18:20, Owen DeLong wrote: [..] > FIrst I've heard of such a thing. There is a first time for everything ;) > The original organizers of W6D have zero > motivation to try such a thing and I can't imagine why they would even > consider it for more than a picosecond. As you where not part of that group of folks, how do you think you can guess what their plans where? :) But anyway, just consider it: a portion of the major websites go IPv6-only for 24 hours. What happens is that well, 99% of the populace can't reach them anymore, as the known ones are down, they start calling and thus overloading the helpdesks of their ISPs. There are then two possible results: - an actual realization at the ISPs that there might be a day that they need to do IPv6 - lawsuits from the ISPs because they got overloaded in their callcenters blabla... One of the other realizations was something that happened when the Pirate Bay went IPv6-only as their IPv4 connectivity was broken, people just appended .sixxs.org to the website and presto, they got the IPv6 version of the Pirate Bay over IPv4, including the torrents mind you. Now the website itself was not a problem, the amount of traffic from tracker was though, but blocking torrent clients and adding more boxes solved that issue mostly. The other realization was that the burden will quickly fall on sites which provide IPv6 access, and that is something that will have turned out in a similar way as the above into a situation that will not work out positively either. Just typing the above took longer than a picosecond, but it is always good to know that there are people who can think that fast and consider all the options ;) The current plan of turning on AAAAs will, in my guesses, not have a major impact though it will break things for some people: - folks who have IPv6 enabled already, already have issues with sites when their local DNS recursor does not handle AAAA properly. - folks who have IPv6 enabled already, already have issues with sites when their connectivity is broken, it will now just start breaking for sites that they 'rely' on a lot as they use them often, thus they will realize that it is broken. - folks who don't have IPv6 enabled (XP default mostly) won't notice a thing as they have no AAAA support thus nothing will happen. leaving mostly one group: - people who are technically not so clueful but do see in the news all the hype about IPv6 and suddenly start wanting it and enable IPv6 probably ending up trying to set up IPv6 and then breaking it in the process. I have seen bunches of folks already getting IPv6 tunnels solely for the reason of "being ready for IPv6 day", while they are ready if they got working IPv4 and non-broken IPv6 ;) nevertheless, the broken connectivity case is the one I think will be seen the most, as the DNS case people should have noticed already if they have issues with it, and that won't differ from the problems they already have. Greets, Jeroen From joelja at bogus.com Sat Jun 4 03:26:38 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 4 Jun 2011 01:26:38 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <35344579-21D6-4ADF-9F29-FCC91219BFF5@delong.com> References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> <35344579-21D6-4ADF-9F29-FCC91219BFF5@delong.com> Message-ID: <92235325-8BDF-4290-9489-67DC12DF103F@bogus.com> On Jun 3, 2011, at 4:13 PM, Owen DeLong wrote: > > On Jun 3, 2011, at 3:24 PM, Valdis.Kletnieks at vt.edu wrote: > >> On Fri, 03 Jun 2011 15:20:22 PDT, Scott Weeks said: >> >>> There're about 52 peaks in a year on the timeline... :-) >> >> Right. But why is Google seeing noticeably higher IPv6 loads on Sunday and >> lower loads on Friday? I'd buy a "different traffic pattern for home/office", >> but then you'd expect Friday to be about the same as M-Th, and Sat/Sun to be >> about even. >> > > Everyone is out interacting with Humans on Friday nights. > > Sunday, everyone is home trying to avoid dealing with their families. Note that from Geoff's published experiment presented in IETF v6ops the success rate of v6 connection attempts particularly auto-tunneled is higher on the weekends than during weekdays, you can thank corporate firewall policy for that particular phenomena. http://tools.ietf.org/agenda/80/slides/v6ops-22.pdf > > (Mostly tongue in cheek) > > Owen > > > From brandon at rd.bbc.co.uk Sat Jun 4 09:40:52 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 4 Jun 2011 15:40:52 +0100 (BST) Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) Message-ID: <201106041440.PAA02549@sunf10.rd.bbc.co.uk> > > The original organizers of W6D have zero > > motivation to try such a thing and I can't imagine why they would even > > consider it for more than a picosecond. This W6D is about turning v6 on. At some point, many years from now, when everyone has got bored of supporting legacy v4 for a hand full of legacy users there might be a v6 only day where we turn v4 off to test if it can be generally ceased. brandon From mysidia at gmail.com Sat Jun 4 10:58:05 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 4 Jun 2011 10:58:05 -0500 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: <201106041440.PAA02549@sunf10.rd.bbc.co.uk> References: <201106041440.PAA02549@sunf10.rd.bbc.co.uk> Message-ID: On Sat, Jun 4, 2011 at 9:40 AM, Brandon Butterworth wrote: [snip] > This W6D is about turning v6 on. At some point, many years from now, > when everyone has got bored of supporting legacy v4 for a hand full of > legacy users there might be a v6 only day where we turn v4 off to test > if it can be generally ceased. Or maybe at some point a year or so from now... display a warning to all users accessing the site over IPv4; reminding them of the need to upgrade their internet connection to IPv6 in order to be able to access new 'premium' content :-) -- -JH From Valdis.Kletnieks at vt.edu Sat Jun 4 12:05:21 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 04 Jun 2011 13:05:21 -0400 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: Your message of "Sat, 04 Jun 2011 10:58:05 CDT." References: <201106041440.PAA02549@sunf10.rd.bbc.co.uk> Message-ID: <49511.1307207121@turing-police.cc.vt.edu> On Sat, 04 Jun 2011 10:58:05 CDT, Jimmy Hess said: > Or maybe at some point a year or so from now... display a warning to all users > accessing the site over IPv4; reminding them of the need to upgrade > their internet connection to IPv6 in order to be able to access new 'premium' > content :-) Somebody a few years back was working on "free pr0n over IPv6" as a motivator, whatever happened to that? Or did it just die on the vine due to the immense amount of free pr0n available on IPv4? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Sat Jun 4 14:09:42 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Jun 2011 12:09:42 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <92235325-8BDF-4290-9489-67DC12DF103F@bogus.com> References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> <35344579-21D6-4ADF-9F29-FCC91219BFF5@delong.com> <92235325-8BDF-4290-9489-67DC12DF103F@bogus.com> Message-ID: <19EA8FC7-F2BF-4377-A797-B8D1ABCE2D34@delong.com> > > Note that from Geoff's published experiment presented in IETF v6ops the success rate of v6 connection attempts particularly auto-tunneled is higher on the weekends than during weekdays, you can thank corporate firewall policy for that particular phenomena. > > http://tools.ietf.org/agenda/80/slides/v6ops-22.pdf Indeed... Unfortunately, this means that LSN is going to _REALLY_ suck for such tunnel users. Owen From owen at delong.com Sat Jun 4 14:08:45 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Jun 2011 12:08:45 -0700 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: <4DE9EA04.2050605@unfix.org> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> Message-ID: On Jun 4, 2011, at 1:17 AM, Jeroen Massar wrote: > On 2011-Jun-03 18:20, Owen DeLong wrote: > [..] >> FIrst I've heard of such a thing. > > There is a first time for everything ;) > >> The original organizers of W6D have zero >> motivation to try such a thing and I can't imagine why they would even >> consider it for more than a picosecond. > > As you where not part of that group of folks, how do you think you can > guess what their plans where? :) > While I wasn't there, I have talked to many of them about the subject. > But anyway, just consider it: a portion of the major websites go > IPv6-only for 24 hours. What happens is that well, 99% of the populace > can't reach them anymore, as the known ones are down, they start calling > and thus overloading the helpdesks of their ISPs. > Uh, right... > There are then two possible results: > - an actual realization at the ISPs that there might be a day > that they need to do IPv6 I think most ISPs realize that at this point, therefore, little or nothing could be gained in this respect by such an action. > - lawsuits from the ISPs because they got overloaded > in their callcenters blabla... This is absurd. There's no valid cause of action. No content provider has a duty to prevent calls to an ISP's callcenter and there is no valid basis for an ISP to argue that Google is liable to them because they terminated services to their users. > > One of the other realizations was something that happened when the > Pirate Bay went IPv6-only as their IPv4 connectivity was broken, people > just appended .sixxs.org to the website and presto, they got the IPv6 > version of the Pirate Bay over IPv4, including the torrents mind you. > Now the website itself was not a problem, the amount of traffic from > tracker was though, but blocking torrent clients and adding more boxes > solved that issue mostly. > Yeah, I'm not seeing the point here or how that would relate to any rational intent for World IPv6 Day. > The other realization was that the burden will quickly fall on sites > which provide IPv6 access, and that is something that will have turned > out in a similar way as the above into a situation that will not work > out positively either. > If you got all the way down to this point before realizing that IPv6-only day at this stage was a bad idea, then, you weren't paying attention to your earlier thoughts. > Just typing the above took longer than a picosecond, but it is always > good to know that there are people who can think that fast and consider > all the options ;) > If you can type faster than you think, either your fingers are impressively fast, or, your brain is impressively slow. I'll leave it to you to decide which applies. > The current plan of turning on AAAAs will, in my guesses, not have a > major impact though it will break things for some people: > Which is exactly the intent... To have minimal impact, increase IPv6 deployment and awareness, and identify places where things do break. > - folks who have IPv6 enabled already, already have issues with sites > when their local DNS recursor does not handle AAAA properly. > Right, but those folks also already have a visible effect that they can debug. > - folks who have IPv6 enabled already, already have issues with sites > when their connectivity is broken, it will now just start breaking > for sites that they 'rely' on a lot as they use them often, thus they > will realize that it is broken. > Many of those folks don't go to the sites where they have issues and so are unaware of the issues. This provides an opportunity to identify and correct a much larger portion of those. Finally, I think we need to make a differentiation here that you are not making. I already have IPv6 enabled, but, I have none of the issues you describe above because my IPv6 is working. The real issue is folks who have all of the following: + IPv6 enabled + Machines that think they have a legitimate IPv6 next-hop to the destination + The IPv6 next-hop is not working or folks who have: + IPv6 connectivity + Broken DNS resolvers in their path that do not properly pass along AAAA records. > - folks who don't have IPv6 enabled (XP default mostly) won't notice a > thing as they have no AAAA support thus nothing will happen. > True, but, these folks are not a reason that cannot turn on AAAA records. > leaving mostly one group: > - people who are technically not so clueful but do see in the news all > the hype about IPv6 and suddenly start wanting it and enable IPv6 > probably ending up trying to set up IPv6 and then breaking it in the > process. I have seen bunches of folks already getting IPv6 tunnels > solely for the reason of "being ready for IPv6 day", while they are > ready if they got working IPv4 and non-broken IPv6 ;) > Actually, there are lots of folks running default OS configurations where their OS has decided they have an IPv6 default route or such and will experience problems. They are a trivially small percentage (0.1% or less) of the population by most estimates, but, that's enough to prevent some of the large content providers from deploying AAAA records on their services at this time. Thus, the point of W6D is to provide a safe-harbour day when all the content providers can jump into the same pool together so that it doesn't look like just one of them is broken to that subset of users. This will allow us to better: + Scope the problem + Identify the affected users + Look at possible mitigation strategies + Measure and quantify the extent of the problem > nevertheless, the broken connectivity case is the one I think will be > seen the most, as the DNS case people should have noticed already if > they have issues with it, and that won't differ from the problems they > already have. > Agreed, but, this broken connectivity case is currently a stumbling block to getting major content providers on to dual-stack, so, if we can get data that allows us to work past that point, it's a pretty big win. In all of my discussions with the W6D organizers, this has always been the stated intent and expected benefit expressed by them. As such, I simply don't see how v6 only would ever have fit into that plan. Owen From owen at delong.com Sat Jun 4 14:17:40 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Jun 2011 12:17:40 -0700 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: <49511.1307207121@turing-police.cc.vt.edu> References: <201106041440.PAA02549@sunf10.rd.bbc.co.uk> <49511.1307207121@turing-police.cc.vt.edu> Message-ID: <2F93BA45-5599-412E-A091-6CE797D5E13B@delong.com> On Jun 4, 2011, at 10:05 AM, Valdis.Kletnieks at vt.edu wrote: > On Sat, 04 Jun 2011 10:58:05 CDT, Jimmy Hess said: > >> Or maybe at some point a year or so from now... display a warning to all users >> accessing the site over IPv4; reminding them of the need to upgrade >> their internet connection to IPv6 in order to be able to access new 'premium' >> content :-) > > Somebody a few years back was working on "free pr0n over IPv6" as a motivator, > whatever happened to that? Or did it just die on the vine due to the immense > amount of free pr0n available on IPv4? > They couldn't get enough transit to fully launch the experiment. Owen From joelja at bogus.com Sat Jun 4 14:28:16 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 4 Jun 2011 12:28:16 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <19EA8FC7-F2BF-4377-A797-B8D1ABCE2D34@delong.com> References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> <35344579-21D6-4ADF-9F29-FCC91219BFF5@delong.com> <92235325-8BDF-4290-9489-67DC12DF103F@bogus.com> <19EA8FC7-F2BF-4377-A797-B8D1ABCE2D34@delong.com> Message-ID: On Jun 4, 2011, at 12:09 PM, Owen DeLong wrote: >> >> Note that from Geoff's published experiment presented in IETF v6ops the success rate of v6 connection attempts particularly auto-tunneled is higher on the weekends than during weekdays, you can thank corporate firewall policy for that particular phenomena. >> >> http://tools.ietf.org/agenda/80/slides/v6ops-22.pdf > > Indeed... Unfortunately, this means that LSN is going to _REALLY_ suck for such tunnel users. The smart money is on there being no-saving the auto-tunneling users. The situation is not that good now and it will get worse. > Owen > > From jeroen at unfix.org Sun Jun 5 08:22:21 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 05 Jun 2011 15:22:21 +0200 Subject: messagelabs.com contact - SMTP-side domaincheck checks IPv4 only, rejects domains with first MX on IPv6 Message-ID: <4DEB830D.1020607@unfix.org> As the subject states, MAILER-DAEMON at messagelabs.com: <.... at ford.com>: Connected to 136.1.7.8 but sender was rejected. Remote host said: 501 Sender domain must exist As it obviously checks only the first MX record if there are A records, and if there are none it rejects it. This while there are AAAA records on the first MX, and even A records on the remaining MXs. Thus a proper fix would already be to check the other MXs and of course to check for AAAA too ;) And that affects all customers at messagelabs, thus if somebody can pass that along to them to fix it, that would be great ;) Oh and of course the check is also there for postmaster@ thus no way to tell them through that route. Greets, Jeroen From luke.marrott at gmail.com Sun Jun 5 15:32:08 2011 From: luke.marrott at gmail.com (Luke Marrott) Date: Sun, 5 Jun 2011 14:32:08 -0600 Subject: IPv6 Availability on XO In-Reply-To: References: <835617D6-5709-467B-91F0-91E20448AEA9@u13.net> Message-ID: We have a 10GigE connection with XO in Utah and have gotten little to no response from XO on our IPv6 requests for months. We finally got our L3 IPv6, but they don't have a complete routing table. :Luke Marrott On Sat, May 28, 2011 at 11:38 AM, Jonathan Lassoff wrote: > On Mon, May 23, 2011 at 4:39 PM, Ryan Rawdon wrote: > > I've heard some mixed reports of XO's IPv6 availability - some that they > have full deployment/availability, but others like the answer back from our > XO reseller that XO does not offer IPv6 on circuits under 45mbit/s. > > > > What is the experience of NANOG on this matter, particularly with XO > connectivity under 45mbit/s? > > Interesting. Perhaps they haven't plumbed native v6 throughout their > network? > > For comparison, I'm currently running some native IPv6 over XO in the > San Francisco Bay Area (homed off of an XO router in Fremont, CA). > The circuit is GigE. > > Cheers, > jof > > From msergeant at messagelabs.com Sun Jun 5 17:07:34 2011 From: msergeant at messagelabs.com (Matt Sergeant) Date: Sun, 05 Jun 2011 18:07:34 -0400 Subject: messagelabs.com contact - SMTP-side domaincheck checks IPv4 only, rejects domains with first MX on IPv6 In-Reply-To: <4DEB830D.1020607@unfix.org> References: <4DEB830D.1020607@unfix.org> Message-ID: <4DEBFE26.1070800@messagelabs.com> I'll get someone to contact Ford and see what they are running. From google it looks like Exchange. Is this a known bug with Exchange? If so I think there's bigger problems than messagelabs :) Jeroen Massar wrote: > As the subject states, > > MAILER-DAEMON at messagelabs.com: > > <.... at ford.com>: > Connected to 136.1.7.8 but sender was rejected. > Remote host said: 501 Sender domain must exist > > As it obviously checks only the first MX record if there are A records, > and if there are none it rejects it. This while there are AAAA records > on the first MX, and even A records on the remaining MXs. Thus a proper > fix would already be to check the other MXs and of course to check for > AAAA too ;) > > And that affects all customers at messagelabs, thus if somebody can pass > that along to them to fix it, that would be great ;) > > Oh and of course the check is also there for postmaster@ thus no way to > tell them through that route. > > Greets, > Jeroen > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From ge at linuxbox.org Sun Jun 5 18:39:45 2011 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 06 Jun 2011 02:39:45 +0300 Subject: UN declares Internet access a "human right" Message-ID: <4DEC13C1.1050800@linuxbox.org> The title is misleading, as this is more about "denying" access. But this is still quite interesting. I don't think this has *any* operational implications, but every operator to see this was immediately worried. I figure it warrants a discussion. http://m.wired.com/threatlevel/2011/06/internet-a-human-right Gadi. From Bryan at bryanfields.net Sun Jun 5 19:11:21 2011 From: Bryan at bryanfields.net (Bryan Fields) Date: Sun, 05 Jun 2011 20:11:21 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <4DEC13C1.1050800@linuxbox.org> References: <4DEC13C1.1050800@linuxbox.org> Message-ID: <4DEC1B29.1010802@bryanfields.net> On 6/5/2011 19:39, Gadi Evron wrote: > The title is misleading, as this is more about "denying" access. But > this is still quite interesting. I don't think this has *any* > operational implications, but every operator to see this was immediately > worried. I figure it warrants a discussion. This is the same organization that says there is no basic human right to keep and bear arms. They have no standing to lecture us about human rights, as their body largely consists of mass murderers and thieves. Not that I don't agree it's criminal for a tyrant to disconnect their country from the Internet, but they are tyrants after all. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From jra at baylink.com Sun Jun 5 19:09:50 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 5 Jun 2011 20:09:50 -0400 (EDT) Subject: WIPv6 Day - Facebook Message-ID: <18046929.330.1307318990639.JavaMail.root@benjamin.baylink.com> Facebook Engineering makes their internal announcement -- to anyone who follows that page: http://www.facebook.com/notes/facebook-engineering/facebook-and-world-ipv6-day/10150195205068920 -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From marka at isc.org Sun Jun 5 19:18:19 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 06 Jun 2011 10:18:19 +1000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Sat, 04 Jun 2011 12:28:16 MST." References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> <35344579-21D6-4ADF-9F29-FCC91219BFF5@delong.com> <92235325-8BDF-4290-9489-67DC12DF103F@bogus.com> <19EA8FC7-F2BF-4377-A797-B8D1ABCE2D34@delong.com> Message-ID: <20110606001819.D3B94105946C@drugs.dv.isc.org> In message , Joel Jaeggli write s: > > On Jun 4, 2011, at 12:09 PM, Owen DeLong wrote: > > >>=20 > >> Note that from Geoff's published experiment presented in IETF v6ops = > the success rate of v6 connection attempts particularly auto-tunneled is = > higher on the weekends than during weekdays, you can thank corporate = > firewall policy for that particular phenomena. > >>=20 > >> http://tools.ietf.org/agenda/80/slides/v6ops-22.pdf > >=20 > > Indeed... Unfortunately, this means that LSN is going to _REALLY_ suck = > for such tunnel users. > > The smart money is on there being no-saving the auto-tunneling users. = > The situation is not that good now and it will get worse. There really is no reason that everyone has to be behind a LSN. ISP's offer residential customers differentent levels of service today. See the web pages to re-open port 25 for examples of this. There is no reason that they can't do a similar thing to move customers who are doing things that break with LSN out from behind the LSN. Also when Microsoft and Apple have shipped fixed versions of IE and Safari that have sub-second failover most of the visible issues with broken 6to4 tunnels will disappear. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Valdis.Kletnieks at vt.edu Sun Jun 5 19:18:40 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 05 Jun 2011 20:18:40 -0400 Subject: UN declares Internet access a "human right" In-Reply-To: Your message of "Mon, 06 Jun 2011 02:39:45 +0300." <4DEC13C1.1050800@linuxbox.org> References: <4DEC13C1.1050800@linuxbox.org> Message-ID: <132521.1307319520@turing-police.cc.vt.edu> On Mon, 06 Jun 2011 02:39:45 +0300, Gadi Evron said: > The title is misleading, as this is more about "denying" access. But > this is still quite interesting. I don't think this has *any* > operational implications, but every operator to see this was immediately > worried. I figure it warrants a discussion. No discussion needed - yes, it appears to conflict with "3 strikes you're off" copyright laws, until you accept that only criminals will get hit with 3 strikes, and criminals can be required to give up some rights as punishment, so it's OK. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From john-nanog at johnpeach.com Sun Jun 5 19:44:39 2011 From: john-nanog at johnpeach.com (John Peach) Date: Sun, 05 Jun 2011 20:44:39 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <4DEC1B29.1010802@bryanfields.net> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> Message-ID: <20110605204439.2a888183@milhouse> On Sun, 05 Jun 2011 20:11:21 -0400 Bryan Fields wrote: > On 6/5/2011 19:39, Gadi Evron wrote: > > The title is misleading, as this is more about "denying" access. But > > this is still quite interesting. I don't think this has *any* > > operational implications, but every operator to see this was immediately > > worried. I figure it warrants a discussion. > > This is the same organization that says there is no basic human right to keep > and bear arms. They have no standing to lecture us about human rights, as > their body largely consists of mass murderers and thieves. > - PLONK What a moron -- John From jerome at ceriz.fr Sun Jun 5 19:46:59 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Mon, 6 Jun 2011 02:46:59 +0200 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <20110606001819.D3B94105946C@drugs.dv.isc.org> References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> <35344579-21D6-4ADF-9F29-FCC91219BFF5@delong.com> <92235325-8BDF-4290-9489-67DC12DF103F@bogus.com> <19EA8FC7-F2BF-4377-A797-B8D1ABCE2D34@delong.com> <20110606001819.D3B94105946C@drugs.dv.isc.org> Message-ID: 2011/6/6 Mark Andrews : > There is no reason that they can't do a similar thing to move > customers who are doing things that break with LSN out from behind > the LSN. Oh, you're right, they'll surelly do that. But not in time, and not for free. LSN is beeing actively implemented in the core network of several ISPs, and most didn't yet consider it as optional. Nor are ready for v6 connectivity to residential customers, though. For users behind a forced NAT (no way to disable it on the CPE) or LSN, the only way out is still tunneling. Talking about bandwidth and infrastructure waste... -- J?r?me Nicolle From Bryan at bryanfields.net Sun Jun 5 19:48:11 2011 From: Bryan at bryanfields.net (Bryan Fields) Date: Sun, 05 Jun 2011 20:48:11 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <20110605204439.2a888183@milhouse> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <20110605204439.2a888183@milhouse> Message-ID: <4DEC23CB.5070304@bryanfields.net> On 6/5/2011 20:44, John Peach wrote: > On Sun, 05 Jun 2011 20:11:21 -0400 > Bryan Fields wrote: > >> On 6/5/2011 19:39, Gadi Evron wrote: >>> The title is misleading, as this is more about "denying" access. But >>> this is still quite interesting. I don't think this has *any* >>> operational implications, but every operator to see this was immediately >>> worried. I figure it warrants a discussion. >> >> This is the same organization that says there is no basic human right to keep >> and bear arms. They have no standing to lecture us about human rights, as >> their body largely consists of mass murderers and thieves. >> > - PLONK > What a moron Nice to see you took the time to form a well thought out and concise argument. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From Bryan at bryanfields.net Sun Jun 5 19:48:56 2011 From: Bryan at bryanfields.net (Bryan Fields) Date: Sun, 05 Jun 2011 20:48:56 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <20110605204439.2a888183@milhouse> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <20110605204439.2a888183@milhouse> Message-ID: <4DEC23F8.7060106@bryanfields.net> On 6/5/2011 20:44, John Peach wrote: > On Sun, 05 Jun 2011 20:11:21 -0400 > Bryan Fields wrote: > >> On 6/5/2011 19:39, Gadi Evron wrote: >>> The title is misleading, as this is more about "denying" access. But >>> this is still quite interesting. I don't think this has *any* >>> operational implications, but every operator to see this was immediately >>> worried. I figure it warrants a discussion. >> >> This is the same organization that says there is no basic human right to keep >> and bear arms. They have no standing to lecture us about human rights, as >> their body largely consists of mass murderers and thieves. >> > - PLONK > What a moron Nice to see you took the time to form a well thought out and concise argument. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From marka at isc.org Sun Jun 5 20:14:11 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 06 Jun 2011 11:14:11 +1000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Mon, 06 Jun 2011 02:46:59 +0200." References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> <35344579-21D6-4ADF-9F29-FCC91219BFF5@delong.com> <92235325-8BDF-4290-9489-67DC12DF103F@bogus.com> <19EA8FC7-F2BF-4377-A797-B8D1ABCE2D34@delong.com> <20110606001819.D3B94105946C@drugs.dv.isc.org> Message-ID: <20110606011411.946661059E2F@drugs.dv.isc.org> In message , =?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?= writes: > 2011/6/6 Mark Andrews : > > > There is no reason that they can't do a similar thing to move > > customers who are doing things that break with LSN out from behind > > the LSN. > > Oh, you're right, they'll surelly do that. But not in time, and not for fre= > e. Well here in Australia I would be calling the ACCC is a ISP tried to charge extra for a address that is not behind a LSN. As for in time it should be in place before they turn on LSN. If you can adjust port 25 filters whenever a customer gets a new address you can also ensure that they get address from the correct pool when they connect to the network. This really isn't rocket science. It's updating the provisioning database from a web form and generating new configs based on that database. Yes there is some work required to ensure that this gets done properly and there needs to be checks that address pools are appropriately sized. If I were doing it I would also have checkboxes for some of the more common reasons and include IPv6 connectivity as one then have a 6 month grace period once the ISP offers IPv6 connectivity before removing that as a valid reason for needing a address that is not behind the LSN. > LSN is beeing actively implemented in the core network of several > ISPs, and most didn't yet consider it as optional. Nor are ready for > v6 connectivity to residential customers, though. > > For users behind a forced NAT (no way to disable it on the CPE) or > LSN, the only way out is still tunneling. Talking about bandwidth and > infrastructure waste... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Sun Jun 5 20:33:16 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 5 Jun 2011 18:33:16 -0700 Subject: Microsoft's participation in World IPv6 day Message-ID: On Jun 5, 2011 6:15 PM, "Mark Andrews" wrote: > > > In message > , =?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?= writes: > > 2011/6/6 Mark Andrews : > > > > > There is no reason that they can't do a similar thing to move > > > customers who are doing things that break with LSN out from behind > > > the LSN. > > > > Oh, you're right, they'll surelly do that. But not in time, and not for fre= > > e. > > Well here in Australia I would be calling the ACCC is a ISP tried > to charge extra for a address that is not behind a LSN. As for in > time it should be in place before they turn on LSN. If you can > adjust port 25 filters whenever a customer gets a new address you > can also ensure that they get address from the correct pool when > they connect to the network. This really isn't rocket science. > It's updating the provisioning database from a web form and generating > new configs based on that database. Yes there is some work required > to ensure that this gets done properly and there needs to be checks > that address pools are appropriately sized. > Can you cite an example of an isp doing this? My assumption is that people will get LSN by default for standard residential broad band and business class will get public ip's. Without any commitments to cite, plan for the worst and hope for the best. Cb > If I were doing it I would also have checkboxes for some of the > more common reasons and include IPv6 connectivity as one then have > a 6 month grace period once the ISP offers IPv6 connectivity before > removing that as a valid reason for needing a address that is not > behind the LSN. > > > LSN is beeing actively implemented in the core network of several > > ISPs, and most didn't yet consider it as optional. Nor are ready for > > v6 connectivity to residential customers, though. > > > > For users behind a forced NAT (no way to disable it on the CPE) or > > LSN, the only way out is still tunneling. Talking about bandwidth and > > infrastructure waste... > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From mkarir at merit.edu Sun Jun 5 20:58:29 2011 From: mkarir at merit.edu (Manish Karir) Date: Sun, 5 Jun 2011 21:58:29 -0400 (EDT) Subject: IPv6 day - request for datasets Message-ID: <0152FFF5-13A9-4DCE-AB35-192BCB89210A@merit.edu> I know quite a few folks are planning some sort of monitoring/measurement activity related with IPv6 day. If there is any chance you might be able to make this information(raw or derived data) available to the broader network research community please let me know. Merit and the University of Michigan are involved in an ongoing research effort to collect/archive and make available such datasets. If you are uncertain regarding privacy/ anonymization issues please feel free to get in touch with me and we might be able to make some suggestions. If you are planning some data collection/monitoring activity it would be great if you could drop me a quick email off list. The more diverse the datasets (data types,views,scales) the better. Thanks. -manish Manish Karir Merit Network Inc. From jerome at ceriz.fr Sun Jun 5 21:04:06 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Mon, 6 Jun 2011 04:04:06 +0200 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <20110606011411.946661059E2F@drugs.dv.isc.org> References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> <35344579-21D6-4ADF-9F29-FCC91219BFF5@delong.com> <92235325-8BDF-4290-9489-67DC12DF103F@bogus.com> <19EA8FC7-F2BF-4377-A797-B8D1ABCE2D34@delong.com> <20110606001819.D3B94105946C@drugs.dv.isc.org> <20110606011411.946661059E2F@drugs.dv.isc.org> Message-ID: 2011/6/6 Mark Andrews : > Well here in Australia I would be calling the ACCC is a ISP tried > to charge extra for a address that is not behind a LSN. On France, our bigger ISP charges extra for a fixed IP. Its network beeing rather old-fashioned, every DSL (and residential fiber) line is terminated on a LNS through a PPP session. Assigning a fixed IP is technically done by adding a RADIUS parameter to force the termination LNS to those having a static pool. The same method could be applied to get a user out of the LSN, but as their LSN isn't yet in place, we have no clue of what they'll do. We just know their CEO just announced ongoing discussions with CDNs (including google) about service differenciation and charging users for priority bandwidth. >?If you can > adjust port 25 filters whenever a customer gets a new address you > can also ensure that they get address from the correct pool when > they connect to the network. ?This really isn't rocket science. Well, you can't open port25 on Orange's ADSL service ;) -- J?r?me Nicolle From Valdis.Kletnieks at vt.edu Sun Jun 5 21:11:42 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 05 Jun 2011 22:11:42 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: Your message of "Sun, 05 Jun 2011 20:48:56 EDT." <4DEC23F8.7060106@bryanfields.net> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <20110605204439.2a888183@milhouse> <4DEC23F8.7060106@bryanfields.net> Message-ID: <136746.1307326302@turing-police.cc.vt.edu> On Sun, 05 Jun 2011 20:48:56 EDT, Bryan Fields said: > On 6/5/2011 20:44, John Peach wrote: > > On Sun, 05 Jun 2011 20:11:21 -0400 Bryan Fields wrote: > >> This is the same organization that says there is no basic human right to keep > >> and bear arms. They have no standing to lecture us about human rights, as > >> their body largely consists of mass murderers and thieves. > > - PLONK > > What a moron > Nice to see you took the time to form a well thought out and concise argument OK, if you need it spelled out for you - you asked for it. :) "The basis of our government being the opinion of the people, the very first object should be to keep that right; and were it left to me to decide whether we should have a government without newspapers or newspapers without a government, I should not hesitate a moment to prefer the latter." --- Thomas Jefferson Concise enough for you? You may also want to investigate the relative importance of communications and armaments in Ghandi's struggle for a free India, the US civil rights movement, and the collapse of the Soviet Union. That's 3 examples of change mediated by communications without rifles. Then there's Darfur - an example of rifles without communications infrastructure. Oh, and as Bryan said... 'PLONK'. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From marka at isc.org Sun Jun 5 21:14:49 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 06 Jun 2011 12:14:49 +1000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Sun, 05 Jun 2011 18:33:16 MST." References: Message-ID: <20110606021449.402A2105A596@drugs.dv.isc.org> In message , Cameron Byrne writes: > On Jun 5, 2011 6:15 PM, "Mark Andrews" wrote: > > > > > > In message 0Pxw at mail.gmail.com> > > , =?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?= writes: > > > 2011/6/6 Mark Andrews : > > > > > > > There is no reason that they can't do a similar thing to move > > > > customers who are doing things that break with LSN out from behind > > > > the LSN. > > > > > > Oh, you're right, they'll surelly do that. But not in time, and not for > fre= > > > e. > > > > Well here in Australia I would be calling the ACCC is a ISP tried > > to charge extra for a address that is not behind a LSN. As for in > > time it should be in place before they turn on LSN. If you can > > adjust port 25 filters whenever a customer gets a new address you > > can also ensure that they get address from the correct pool when > > they connect to the network. This really isn't rocket science. > > It's updating the provisioning database from a web form and generating > > new configs based on that database. Yes there is some work required > > to ensure that this gets done properly and there needs to be checks > > that address pools are appropriately sized. > > > > Can you cite an example of an isp doing this? My assumption is that people > will get LSN by default for standard residential broad band and business > class will get public ip's. It's how you handle the exceptions. Home users have port 25 off by default but can still get it turned on. Most home users don't need a public IP address as they are not running stuff that requires it however some do so planning to handle the exceptions as efficiently as possible is a good thing to do. I've got two applications that won't work behind a LSN. A sip phone and a 6in4 tunnel however I'm not typical. Looking at 6to4 and auto tunnels they really are a small percentage of customers that could be auto detected by the ISP and be put into the exception pool prior to enabling LSN. Most CPE routers today don't enable 6to4 (they either don't support IPv6 let alone 6to4 or its not turned on by default). As for directly connected machines many of then still require 6to4 to be turned on by hand (XP, Mac OS). What's easier for the ISP, detecting the customers that use protocol 41 today and automatically adding them to a exception pool or fielding the support calls? Mark > Without any commitments to cite, plan for the worst and hope for the best. > > Cb > > If I were doing it I would also have checkboxes for some of the > > more common reasons and include IPv6 connectivity as one then have > > a 6 month grace period once the ISP offers IPv6 connectivity before > > removing that as a valid reason for needing a address that is not > > behind the LSN. > > > > > LSN is beeing actively implemented in the core network of several > > > ISPs, and most didn't yet consider it as optional. Nor are ready for > > > v6 connectivity to residential customers, though. > > > > > > For users behind a forced NAT (no way to disable it on the CPE) or > > > LSN, the only way out is still tunneling. Talking about bandwidth and > > > infrastructure waste... > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Sun Jun 5 21:29:44 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 5 Jun 2011 19:29:44 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <20110606021449.402A2105A596@drugs.dv.isc.org> References: <20110606021449.402A2105A596@drugs.dv.isc.org> Message-ID: On Jun 5, 2011 7:15 PM, "Mark Andrews" wrote: > > > In message , Cameron Byrne > writes: > > On Jun 5, 2011 6:15 PM, "Mark Andrews" wrote: > > > > > > > > > In message > 0Pxw at mail.gmail.com> > > > , =?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?= writes: > > > > 2011/6/6 Mark Andrews : > > > > > > > > > There is no reason that they can't do a similar thing to move > > > > > customers who are doing things that break with LSN out from behind > > > > > the LSN. > > > > > > > > Oh, you're right, they'll surelly do that. But not in time, and not for > > fre= > > > > e. > > > > > > Well here in Australia I would be calling the ACCC is a ISP tried > > > to charge extra for a address that is not behind a LSN. As for in > > > time it should be in place before they turn on LSN. If you can > > > adjust port 25 filters whenever a customer gets a new address you > > > can also ensure that they get address from the correct pool when > > > they connect to the network. This really isn't rocket science. > > > It's updating the provisioning database from a web form and generating > > > new configs based on that database. Yes there is some work required > > > to ensure that this gets done properly and there needs to be checks > > > that address pools are appropriately sized. > > > > > > > Can you cite an example of an isp doing this? My assumption is that people > > will get LSN by default for standard residential broad band and business > > class will get public ip's. > > It's how you handle the exceptions. Home users have port 25 off > by default but can still get it turned on. Most home users don't > need a public IP address as they are not running stuff that requires > it however some do so planning to handle the exceptions as efficiently > as possible is a good thing to do. > > I've got two applications that won't work behind a LSN. A sip phone > and a 6in4 tunnel however I'm not typical. > > Looking at 6to4 and auto tunnels they really are a small percentage > of customers that could be auto detected by the ISP and be put into > the exception pool prior to enabling LSN. Most CPE routers today > don't enable 6to4 (they either don't support IPv6 let alone 6to4 > or its not turned on by default). As for directly connected machines > many of then still require 6to4 to be turned on by hand (XP, Mac > OS). > > What's easier for the ISP, detecting the customers that use protocol > 41 today and automatically adding them to a exception pool or > fielding the support calls? I understand your scenario and logic clearly. I assume you understood my question about an example isp that also follows your logic... so we are left to assume that none exists. If ISPs were going to follow your plan they would not be cooking up 6to4-pmt and charging extra for static ip's today. Cb > Mark > > > Without any commitments to cite, plan for the worst and hope for the best. > > > > Cb > > > If I were doing it I would also have checkboxes for some of the > > > more common reasons and include IPv6 connectivity as one then have > > > a 6 month grace period once the ISP offers IPv6 connectivity before > > > removing that as a valid reason for needing a address that is not > > > behind the LSN. > > > > > > > LSN is beeing actively implemented in the core network of several > > > > ISPs, and most didn't yet consider it as optional. Nor are ready for > > > > v6 connectivity to residential customers, though. > > > > > > > > For users behind a forced NAT (no way to disable it on the CPE) or > > > > LSN, the only way out is still tunneling. Talking about bandwidth and > > > > infrastructure waste... > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sun Jun 5 21:58:53 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 06 Jun 2011 12:58:53 +1000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Mon, 06 Jun 2011 04:04:06 +0200." References: <20110603152022.4F2BD78B@resin18.mta.everyone.net> <26988.1307139882@turing-police.cc.vt.edu> <35344579-21D6-4ADF-9F29-FCC91219BFF5@delong.com> <92235325-8BDF-4290-9489-67DC12DF103F@bogus.com> <19EA8FC7-F2BF-4377-A797-B8D1ABCE2D34@delong.com> <20110606001819.D3B94105946C@drugs.dv.isc.org> <20110606011411.946661059E2F@drugs.dv.isc.org> Message-ID: <20110606025853.6694A105B14F@drugs.dv.isc.org> In message , = ?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?= writes: > 2011/6/6 Mark Andrews : > > > Well here in Australia I would be calling the ACCC is a ISP tried > > to charge extra for a address that is not behind a LSN. > > On France, our bigger ISP charges extra for a fixed IP. Its network > beeing rather old-fashioned, every DSL (and residential fiber) line is > terminated on a LNS through a PPP session. Assigning a fixed IP is > technically done by adding a RADIUS parameter to force the termination > LNS to those having a static pool. The same method could be applied to > get a user out of the LSN, but as their LSN isn't yet in place, we > have no clue of what they'll do. We just know their CEO just announced > ongoing discussions with CDNs (including google) about service > differenciation and charging users for priority bandwidth. Which just reinforces the point that it is not technically hard. Remember when you introduce LSN you are degrading the service not adding to it. I can seen consumer bodies saying thay you need to compensate your customers unless there is a free path to get into the exception pool. > >=C2=A0If you can > > adjust port 25 filters whenever a customer gets a new address you > > can also ensure that they get address from the correct pool when > > they connect to the network. =C2=A0This really isn't rocket science. > > Well, you can't open port25 on Orange's ADSL service ;) > > --=20 > J=C3=A9r=C3=B4me Nicolle -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From trelane at trelane.net Sun Jun 5 23:59:55 2011 From: trelane at trelane.net (Andrew D Kirch) Date: Mon, 06 Jun 2011 00:59:55 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <4DEC1B29.1010802@bryanfields.net> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> Message-ID: <4DEC5ECB.6080407@trelane.net> On 6/5/2011 8:11 PM, Bryan Fields wrote: > On 6/5/2011 19:39, Gadi Evron wrote: >> The title is misleading, as this is more about "denying" access. But >> this is still quite interesting. I don't think this has *any* >> operational implications, but every operator to see this was immediately >> worried. I figure it warrants a discussion. > This is the same organization that says there is no basic human right to keep > and bear arms. They have no standing to lecture us about human rights, as > their body largely consists of mass murderers and thieves. > > Not that I don't agree it's criminal for a tyrant to disconnect their country > from the Internet, but they are tyrants after all. The problem is that even stating that denying access to the internet violates human rights allows the UN to begin to get it's claws into regulating the internet. These guys want it to be a right? I'm forwarding the UNSG my home DSL bill. Let him pay it. Obviously you're correct regarding firearms, without recognizing the basic right to protect human life against criminals and despots, there are no other rights (as a criminal and despot will take those rights with impunity). Andrew From trelane at trelane.net Mon Jun 6 00:00:30 2011 From: trelane at trelane.net (Andrew D Kirch) Date: Mon, 06 Jun 2011 01:00:30 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <20110605204439.2a888183@milhouse> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <20110605204439.2a888183@milhouse> Message-ID: <4DEC5EEE.5070109@trelane.net> On 6/5/2011 8:44 PM, John Peach wrote: > On Sun, 05 Jun 2011 20:11:21 -0400 > Bryan Fields wrote: > >> On 6/5/2011 19:39, Gadi Evron wrote: >>> The title is misleading, as this is more about "denying" access. But >>> this is still quite interesting. I don't think this has *any* >>> operational implications, but every operator to see this was immediately >>> worried. I figure it warrants a discussion. >> This is the same organization that says there is no basic human right to keep >> and bear arms. They have no standing to lecture us about human rights, as >> their body largely consists of mass murderers and thieves. >> > - PLONK > What a moron > > admins? Warning? hello? From trelane at trelane.net Mon Jun 6 00:16:03 2011 From: trelane at trelane.net (Andrew D Kirch) Date: Mon, 06 Jun 2011 01:16:03 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <136746.1307326302@turing-police.cc.vt.edu> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <20110605204439.2a888183@milhouse> <4DEC23F8.7060106@bryanfields.net> <136746.1307326302@turing-police.cc.vt.edu> Message-ID: <4DEC6293.9050604@trelane.net> On 6/5/2011 10:11 PM, Valdis.Kletnieks at vt.edu wrote: > On Sun, 05 Jun 2011 20:48:56 EDT, Bryan Fields said: >> On 6/5/2011 20:44, John Peach wrote: >>> On Sun, 05 Jun 2011 20:11:21 -0400 Bryan Fields wrote: >>>> This is the same organization that says there is no basic human right to keep >>>> and bear arms. They have no standing to lecture us about human rights, as >>>> their body largely consists of mass murderers and thieves. >>> - PLONK >>> What a moron >> Nice to see you took the time to form a well thought out and concise argument > OK, if you need it spelled out for you - you asked for it. :) > > "The basis of our government being the opinion of the people, the very first > object should be to keep that right; and were it left to me to decide whether > we should have a government without newspapers or newspapers without a > government, I should not hesitate a moment to prefer the latter." > --- Thomas Jefferson You had the temerity to quote Jefferson while arguing for gun control? "As to the species of exercise, I advise the gun. While this gives [only] moderate exercise to the body, it gives boldness, enterprise, and independence to the mind. Games played with the ball and others of that nature, are too violent for the body and stamp no character on the mind. Let your gun, therefore, be the constant companion to your walks." -- Jefferson "False is the idea of utility that sacrifices a thousand real advantages for one imaginary or trifling inconvenience; that would take fire from men because it burns, and water because one may drown in it; that has no remedy for evils except destruction. The laws that forbid the carrying of arms are laws of such a nature. They disarm only those who are neither inclined nor determined to commit crimes." -- Cesare Beccaria, as quoted by Thomas Jefferson's Commonplace book "No free man shall ever be debarred the use of arms. The strongest reason for the people to retain the right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government"-- Thomas Jefferson, 1 Thomas Jefferson Papers, 334 "Today, we need a nation of Minutemen, citizens who are not only prepared to take arms, but citizens who regard the preservation of freedom as the basic purpose of their daily life and who are willing to consciously work and sacrifice for that freedom."-- John F. Kennedy Ooh right the last one was Kennedy, my bad. > Concise enough for you? You may also want to investigate the relative > importance of communications and armaments in Ghandi's struggle for a free > India, the US civil rights movement, and the collapse of the Soviet Union. I did, and guess what I found! Malcolm X on firearms: ?Last but not least, I must say this concerning the great controversy over rifles and shotguns. The only thing I?ve ever said is that in areas where the government has proven itself either unwilling or unable to defend the lives and the property of N, it?s time for N to defend themselves. Article number two of the Constitutional amendments provides you and me the right to own a rifle or a shotgun. It is constitutionally legal to own a shotgun or a rifle. This doesn?t mean you?re going to get a rifle and form battalions and go out looking for white folks, although you?d be within your rights ? I mean, you?d be justified; but that would be illegal and we don?t do anything illegal. If the white man doesn?t want the black man buying rifles and shotguns, then let the government do its job. That?s all.? There's no quotes from Dr. Martin Luther King, but he both possessed firearms, and a permit to carry them. (this being a matter of public record) Gandi was pro gun: 'Among the many misdeeds of the British rule in India, history will look upon the Act depriving a whole nation of arms as the blackest.' --Mahatma Gandi So of your three "communication over armament" examples, two were run by people armed, and pro gun, one deprived of his arms by a tyrannical British government. > That's 3 examples of change mediated by communications without rifles. Then > there's Darfur - an example of rifles without communications infrastructure. French Revolution American Revolution Russian Revolution There's three that overthrew tyrants with force of arms. > Oh, and as Bryan said... 'PLONK'. Immaturity astounds. Andrew From hank at efes.iucc.ac.il Mon Jun 6 00:19:37 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 06 Jun 2011 08:19:37 +0300 Subject: Google and IPv6 inverse? Message-ID: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> Will Google have inverse working by June 8th? [hank at noc ~]$ traceroute6 ipv6.google.com traceroute to ipv6.l.google.com (2a00:1450:8001::68) from 2001:bf8:0:3:202:b3ff:feaf:f3fc, 30 hops max, 16 byte packets 1 2001:bf8:0:3::1 (2001:bf8:0:3::1) 0.407 ms 221.144 ms 5.218 ms 2 2001:bf8:0:b::1 (2001:bf8:0:b::1) 0.559 ms 0.54 ms 0.486 ms 3 iucc-lb1.rt1.fra.de.geant2.net (2001:798:14:10aa::1d) 50.665 ms 50.611 ms 50.567 ms 4 google-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::e) 56.821 ms 50.525 ms 50.486 ms 5 2001:4860::1:0:11 (2001:4860::1:0:11) 51.266 ms 51.106 ms 51.068 ms 6 2001:4860::1:0:4b3 (2001:4860::1:0:4b3) 58.309 ms 58.078 ms 58.442 ms 7 2001:4860::8:0:2db0 (2001:4860::8:0:2db0) 57.174 ms 57.339 ms 57.195 ms 8 2001:4860::2:0:66f (2001:4860::2:0:66f) 72.496 ms 60.803 ms 72.381 ms 9 2001:4860:0:1::1b (2001:4860:0:1::1b) 68.165 ms 62.21 ms 70.3 ms 10 2a00:1450:8001::68 (2a00:1450:8001::68) 61.21 ms 61.862 ms 61.331 ms Thanks, Hank From jcdill.lists at gmail.com Mon Jun 6 00:33:01 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 05 Jun 2011 22:33:01 -0700 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <4DEC5ECB.6080407@trelane.net> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <4DEC5ECB.6080407@trelane.net> Message-ID: <4DEC668D.30305@gmail.com> On 05/06/11 9:59 PM, Andrew D Kirch wrote: > On 6/5/2011 8:11 PM, Bryan Fields wrote: >> On 6/5/2011 19:39, Gadi Evron wrote: >>> The title is misleading, as this is more about "denying" access. But >>> this is still quite interesting. I don't think this has *any* >>> operational implications, but every operator to see this was >>> immediately >>> worried. I figure it warrants a discussion. >> This is the same organization that says there is no basic human right >> to keep >> and bear arms. They have no standing to lecture us about human >> rights, as >> their body largely consists of mass murderers and thieves. >> >> Not that I don't agree it's criminal for a tyrant to disconnect their >> country >> from the Internet, but they are tyrants after all. > The problem is that even stating that denying access to the internet > violates human rights allows the UN to begin to get it's claws into > regulating the internet. These guys want it to be a right? I'm > forwarding the UNSG my home DSL bill. Let him pay it. There's a significant difference between Internet "access" and Internet "service". I have access to the roads. But that doesn't magically get me vehicular transportation from place A to place B. I need to buy a bus ticket, or buy a car and gasoline, in order to get service over these roads to transport myself from place A to place B. When the UN says that Internet access is a human right, they aren't saying it should be provided for free, but they are saying that it should be available (for those who can afford a service fee), and more importantly that cutting it off for political purposes should be treated as a violation of human rights of freedom of assembly and communication. In the 1700s the US revolution and subsequent state formation (the United States of America) was created first by people assembling at public halls and private houses. In 2011, the Arab Spring revolutions have taken place by public assemblies that were initially organized in internet forums (Facebook, Twitter, private blogs, etc.). I do not see anything wrong with the UN position on Internet access. jc From jcdill.lists at gmail.com Mon Jun 6 00:40:57 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 05 Jun 2011 22:40:57 -0700 Subject: UN declares Internet access a "human right" In-Reply-To: <132521.1307319520@turing-police.cc.vt.edu> References: <4DEC13C1.1050800@linuxbox.org> <132521.1307319520@turing-police.cc.vt.edu> Message-ID: <4DEC6869.5020205@gmail.com> On 05/06/11 5:18 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 06 Jun 2011 02:39:45 +0300, Gadi Evron said: >> The title is misleading, as this is more about "denying" access. But >> this is still quite interesting. I don't think this has *any* >> operational implications, but every operator to see this was immediately >> worried. I figure it warrants a discussion. > No discussion needed - yes, it appears to conflict with "3 strikes you're off" > copyright laws, until you accept that only criminals will get hit with 3 > strikes, and criminals can be required to give up some rights as punishment, so > it's OK. I will happily go along with this argument when the "3 strikes you're off" copyright laws are enforced thru a process which A) assumes you are innocent until proven guilty; B) that you are allowed to present a defense and challenge all witnesses; and C) that you are entitled to have your case heard by a jury of your peers. To the best of my knowledge, none of the "3 strikes you're off" copyright laws proposed or enacted have provided these basic human rights. jc From owen at delong.com Mon Jun 6 01:24:31 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 5 Jun 2011 23:24:31 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <20110606021449.402A2105A596@drugs.dv.isc.org> References: <20110606021449.402A2105A596@drugs.dv.isc.org> Message-ID: > > It's how you handle the exceptions. Home users have port 25 off > by default but can still get it turned on. Most home users don't > need a public IP address as they are not running stuff that requires > it however some do so planning to handle the exceptions as efficiently > as possible is a good thing to do. > I disagree. I look forward to a day when all home users by default have a public IPv6 address for each of their machines and hopefully enough to support multiple subnets within the home. Until then, IPv4 service without at least one public IP is degraded at best compared to what most people consider normal residential internet access today (which, frankly, is degraded at best compared to what I consider normal internet access). > I've got two applications that won't work behind a LSN. A sip phone > and a 6in4 tunnel however I'm not typical. > You're not that atypical either, at least compared to US users. The following very common applications are known to have problems with LSN: Playstation Network X-Box Live AIM/iChat/FaceTime SIP/Vonage/other VoIP services The HTTPs Server on TiVO boxes Peer to Peer (torrent, etc.) Other less common applications also have problems: HTTP servers SMTP servers Back to my Mac VNC Tunnels > Looking at 6to4 and auto tunnels they really are a small percentage > of customers that could be auto detected by the ISP and be put into > the exception pool prior to enabling LSN. Most CPE routers today > don't enable 6to4 (they either don't support IPv6 let alone 6to4 > or its not turned on by default). As for directly connected machines > many of then still require 6to4 to be turned on by hand (XP, Mac > OS). While this is true, I'm not sure it's all that relevant. Most ISPs I have talked to in the US are dreading the deployment of LSN and not planning to deploy it by default except to the extent absolutely necessary to meet customer demand. > > What's easier for the ISP, detecting the customers that use protocol > 41 today and automatically adding them to a exception pool or > fielding the support calls? > Moving them to IPv6 and hoping that enough of the content providers move forward fast enough to minimize the extent of the LSN deployment required. Owen > Mark > >> Without any commitments to cite, plan for the worst and hope for the best. >> >> Cb >>> If I were doing it I would also have checkboxes for some of the >>> more common reasons and include IPv6 connectivity as one then have >>> a 6 month grace period once the ISP offers IPv6 connectivity before >>> removing that as a valid reason for needing a address that is not >>> behind the LSN. >>> >>>> LSN is beeing actively implemented in the core network of several >>>> ISPs, and most didn't yet consider it as optional. Nor are ready for >>>> v6 connectivity to residential customers, though. >>>> >>>> For users behind a forced NAT (no way to disable it on the CPE) or >>>> LSN, the only way out is still tunneling. Talking about bandwidth and >>>> infrastructure waste... >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gbonser at seven.com Mon Jun 6 01:36:10 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 5 Jun 2011 23:36:10 -0700 Subject: UN declares Internet access a "human right" In-Reply-To: <4DEC6869.5020205@gmail.com> References: <4DEC13C1.1050800@linuxbox.org><132521.1307319520@turing-police.cc.vt.edu> <4DEC6869.5020205@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3640@RWC-EX1.corp.seven.com> > I will happily go along with this argument when the "3 strikes you're > off" copyright laws are enforced thru a process which A) assumes you > are > innocent until proven guilty; B) that you are allowed to present a > defense and challenge all witnesses; and C) that you are entitled to > have your case heard by a jury of your peers. To the best of my > knowledge, none of the "3 strikes you're off" copyright laws proposed > or > enacted have provided these basic human rights. > > jc > I think we should just kick those UN buggers right out of office the next time they stand for election. Oh, wait - nevermind. From marka at isc.org Mon Jun 6 02:20:26 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 06 Jun 2011 17:20:26 +1000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Sun, 05 Jun 2011 23:24:31 MST." References: <20110606021449.402A2105A596@drugs.dv.isc.org> Message-ID: <20110606072026.27ADF105C925@drugs.dv.isc.org> In message , Owen DeLong writes: > > > > It's how you handle the exceptions. Home users have port 25 off > > by default but can still get it turned on. Most home users don't > > need a public IP address as they are not running stuff that requires > > it however some do so planning to handle the exceptions as efficiently > > as possible is a good thing to do. > > I disagree. I look forward to a day when all home users by default > have a public IPv6 address for each of their machines and hopefully > enough to support multiple subnets within the home. need == something they currently do will break without it when LSN is deployed for IPv4 and there is not a suitable workaround. I'm all for customers getting public IPv6 addresses. Keeping IPv4 running until IPv6 is ubiquitous with minimal breakage is the challenge. > Until then, IPv4 service without at least one public IP is degraded > at best compared to what most people consider normal residential > internet access today (which, frankly, is degraded at best compared > to what I consider normal internet access). > > > I've got two applications that won't work behind a LSN. A sip phone > > and a 6in4 tunnel however I'm not typical. > > You're not that atypical either, at least compared to US users. The > following very common applications are known to have problems > with LSN: > Playstation Network > X-Box Live > AIM/iChat/FaceTime > SIP/Vonage/other VoIP services > The HTTPs Server on TiVO boxes > Peer to Peer (torrent, etc.) > > Other less common applications also have problems: > HTTP servers > SMTP servers > Back to my Mac > VNC > Tunnels So you take these things that are known to break as exceptions to being behind a LSN and when there is a workable alternative you remove it from the exception list with a desription of the work around. e.g. SMTP servers don't require a public IPv4 address. STARTTLS with authenticated TURN to a external MX will work. Similarly a external dual stack MX + IPv6 support will work. The ISP could supply that external MX. > > Looking at 6to4 and auto tunnels they really are a small percentage > > of customers that could be auto detected by the ISP and be put into > > the exception pool prior to enabling LSN. Most CPE routers today > > don't enable 6to4 (they either don't support IPv6 let alone 6to4 > > or its not turned on by default). As for directly connected machines > > many of then still require 6to4 to be turned on by hand (XP, Mac > > OS). > > While this is true, I'm not sure it's all that relevant. > > Most ISPs I have talked to in the US are dreading the deployment > of LSN and not planning to deploy it by default except to the > extent absolutely necessary to meet customer demand. > > > What's easier for the ISP, detecting the customers that use protocol > > 41 today and automatically adding them to a exception pool or > > fielding the support calls? > > Moving them to IPv6 and hoping that enough of the content providers > move forward fast enough to minimize the extent of the LSN deployment > required. > > Owen > > > Mark > > > >> Without any commitments to cite, plan for the worst and hope for the best. > >> > >> Cb > >>> If I were doing it I would also have checkboxes for some of the > >>> more common reasons and include IPv6 connectivity as one then have > >>> a 6 month grace period once the ISP offers IPv6 connectivity before > >>> removing that as a valid reason for needing a address that is not > >>> behind the LSN. > >>> > >>>> LSN is beeing actively implemented in the core network of several > >>>> ISPs, and most didn't yet consider it as optional. Nor are ready for > >>>> v6 connectivity to residential customers, though. > >>>> > >>>> For users behind a forced NAT (no way to disable it on the CPE) or > >>>> LSN, the only way out is still tunneling. Talking about bandwidth and > >>>> infrastructure waste... > >>> -- > >>> Mark Andrews, ISC > >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jeroen at unfix.org Mon Jun 6 03:20:09 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 06 Jun 2011 10:20:09 +0200 Subject: messagelabs.com contact - SMTP-side domaincheck checks IPv4 only, rejects domains with first MX on IPv6 In-Reply-To: <4DEBFE26.1070800@messagelabs.com> References: <4DEB830D.1020607@unfix.org> <4DEBFE26.1070800@messagelabs.com> Message-ID: <4DEC8DB9.30705@unfix.org> On 2011-Jun-06 00:07, Matt Sergeant wrote: > I'll get someone to contact Ford and see what they are running. From > google it looks like Exchange. Is this a known bug with Exchange? If so > I think there's bigger problems than messagelabs :) Ah good catch, indeed the messagelabs.com SMTP is not the blame here, it forwards it internally to a ford.com one which rejects it. One of the mail servers that is broken in that respect upto a very recent version is Communigate Pro. As for the backscatter that the above setup can generate, you might want to implement the same checks on the front-ends, or at least ask the customers you are forwarding to to disable these checks at least for your frontend servers as now as you can see, the messagelabs.com smtp accepted the email and then started rejecting it. If somebody thus nicely 'forges' (well just fills in a random) email address, the ford.com server will reject it, and messagelabs starts spamming them with the full message which is included in the bounce.... Oh, gee, now lets hope spammers don't abuse that 'feature' eh... Greets, Jeroen From greg at bestnet.kharkov.ua Mon Jun 6 03:53:51 2011 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Mon, 6 Jun 2011 11:53:51 +0300 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: References: <201106041440.PAA02549@sunf10.rd.bbc.co.uk> Message-ID: <20110606115351.00643e42@greg.bestnet.kharkov.ua> On Sat, 4 Jun 2011 10:58:05 -0500 Jimmy Hess wrote: > On Sat, Jun 4, 2011 at 9:40 AM, Brandon Butterworth > wrote: > [snip] > > This W6D is about turning v6 on. At some point, many years from now, > > when everyone has got bored of supporting legacy v4 for a hand full > > of legacy users there might be a v6 only day where we turn v4 off > > to test if it can be generally ceased. > > Or maybe at some point a year or so from now... display a warning to > all users accessing the site over IPv4; reminding them of the need > to upgrade their internet connection to IPv6 in order to be able to > access new 'premium' content :-) Hope it will NEVER happen From jeroen at mompl.net Mon Jun 6 03:53:49 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 06 Jun 2011 01:53:49 -0700 Subject: Protocol-41 is not the only tunneling protocol (Re: Microsoft's participation in World IPv6 day) In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> Message-ID: <4DEC959D.1080106@mompl.net> Owen DeLong wrote: > FIrst I've heard of such a thing. The original organizers of W6D have zero > motivation to try such a thing and I can't imagine why they would even > consider it for more than a picosecond. It'd be a great way to get a point across. ;-) -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From leigh.porter at ukbroadband.com Mon Jun 6 05:36:40 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 6 Jun 2011 10:36:40 +0000 Subject: UN declares Internet access a "human right" In-Reply-To: <4DEC13C1.1050800@linuxbox.org> References: <4DEC13C1.1050800@linuxbox.org> Message-ID: > From: Gadi Evron [mailto:ge at linuxbox.org] > > The title is misleading, as this is more about "denying" access. But > this is still quite interesting. I don't think this has *any* > operational implications, but every operator to see this was > immediately > worried. I figure it warrants a discussion. > IPv4 or IPv6 ? -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From morrowc.lists at gmail.com Mon Jun 6 07:45:31 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 6 Jun 2011 08:45:31 -0400 Subject: Google and IPv6 inverse? In-Reply-To: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> Message-ID: On Mon, Jun 6, 2011 at 1:19 AM, Hank Nussbacher wrote: > Will Google have inverse working by June 8th? > poking the tiger some... 'why?' > [hank at noc ~]$ traceroute6 ipv6.google.com > traceroute to ipv6.l.google.com (2a00:1450:8001::68) from > 2001:bf8:0:3:202:b3ff:feaf:f3fc, 30 hops max, 16 byte packets > ?1 ?2001:bf8:0:3::1 (2001:bf8:0:3::1) ?0.407 ms ?221.144 ms ?5.218 ms > ?2 ?2001:bf8:0:b::1 (2001:bf8:0:b::1) ?0.559 ms ?0.54 ms ?0.486 ms > ?3 ?iucc-lb1.rt1.fra.de.geant2.net (2001:798:14:10aa::1d) ?50.665 ms ?50.611 > ms ?50.567 ms > ?4 ?google-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::e) ?56.821 ms ?50.525 > ms ?50.486 ms > ?5 ?2001:4860::1:0:11 (2001:4860::1:0:11) ?51.266 ms ?51.106 ms ?51.068 ms > ?6 ?2001:4860::1:0:4b3 (2001:4860::1:0:4b3) ?58.309 ms ?58.078 ms ?58.442 ms > ?7 ?2001:4860::8:0:2db0 (2001:4860::8:0:2db0) ?57.174 ms ?57.339 ms ?57.195 > ms > ?8 ?2001:4860::2:0:66f (2001:4860::2:0:66f) ?72.496 ms ?60.803 ms ?72.381 ms > ?9 ?2001:4860:0:1::1b (2001:4860:0:1::1b) ?68.165 ms ?62.21 ms ?70.3 ms > 10 ?2a00:1450:8001::68 (2a00:1450:8001::68) ?61.21 ms ?61.862 ms ?61.331 ms > > Thanks, > Hank > > > From hank at efes.iucc.ac.il Mon Jun 6 07:53:07 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 06 Jun 2011 15:53:07 +0300 Subject: Google and IPv6 inverse? In-Reply-To: References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> Message-ID: <5.1.0.14.2.20110606155214.03751598@efes.iucc.ac.il> At 08:45 06/06/2011 -0400, Christopher Morrow wrote: >On Mon, Jun 6, 2011 at 1:19 AM, Hank Nussbacher wrote: > > Will Google have inverse working by June 8th? > > > >poking the tiger some... 'why?' Just curious. -Hank > > [hank at noc ~]$ traceroute6 ipv6.google.com > > traceroute to ipv6.l.google.com (2a00:1450:8001::68) from > > 2001:bf8:0:3:202:b3ff:feaf:f3fc, 30 hops max, 16 byte packets > > 1 2001:bf8:0:3::1 (2001:bf8:0:3::1) 0.407 ms 221.144 ms 5.218 ms > > 2 2001:bf8:0:b::1 (2001:bf8:0:b::1) 0.559 ms 0.54 ms 0.486 ms > > 3 iucc-lb1.rt1.fra.de.geant2.net (2001:798:14:10aa::1d) 50.665 > ms 50.611 > > ms 50.567 ms > > 4 google-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::e) 56.821 > ms 50.525 > > ms 50.486 ms > > 5 2001:4860::1:0:11 (2001:4860::1:0:11) 51.266 ms 51.106 ms 51.068 ms > > 6 2001:4860::1:0:4b3 (2001:4860::1:0:4b3) 58.309 ms 58.078 > ms 58.442 ms > > 7 2001:4860::8:0:2db0 (2001:4860::8:0:2db0) 57.174 ms 57.339 ms 57.195 > > ms > > 8 2001:4860::2:0:66f (2001:4860::2:0:66f) 72.496 ms 60.803 > ms 72.381 ms > > 9 2001:4860:0:1::1b (2001:4860:0:1::1b) 68.165 ms 62.21 ms 70.3 ms > > 10 2a00:1450:8001::68 (2a00:1450:8001::68) 61.21 ms 61.862 ms 61.331 ms > > > > Thanks, > > Hank > > > > > > From cmadams at hiwaay.net Mon Jun 6 07:55:56 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 6 Jun 2011 07:55:56 -0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> Message-ID: <20110606125556.GB12144@hiwaay.net> Once upon a time, Owen DeLong said: > You're not that atypical either, at least compared to US users. The > following very common applications are known to have problems > with LSN: > The HTTPs Server on TiVO boxes I'm curious: how does this have any problem with any particular NAT implementation? The TiVo HTTPS server is only intended to be accessed from the local LAN, so what happens outside your house (e.g. LSN) shouldn't matter. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Curtis.Starnes at granburyisd.org Mon Jun 6 08:12:26 2011 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Mon, 6 Jun 2011 08:12:26 -0500 Subject: Google and IPv6 inverse? In-Reply-To: <5.1.0.14.2.20110606155214.03751598@efes.iucc.ac.il> References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> <5.1.0.14.2.20110606155214.03751598@efes.iucc.ac.il> Message-ID: It works from North Texas. [cstarnes at tec-mgmt]~ host -6 ipv6.google.com ipv6.google.com is an alias for ipv6.l.google.com. ipv6.l.google.com has IPv6 address 2001:4860:800a::6a [cstarnes at tec-mgmt]~ traceroute ipv6.google.com traceroute to ipv6.google.com (2001:4860:800a::6a), 30 hops max, 40 byte packets1 6506-sup720.granbury.k12.tx.us (2620:101:3000:111::1) 0.731 ms 0.793 ms 0.872 ms 2 ipv6-rtr.granburyisd.org (2620:101:303f::1) 1.619 ms 1.662 ms 1.611 ms 3 tunnel144.tserv1.fmt.ipv6.he.net (2001:470:1f02:90::1) 53.564 ms 53.147 ms 53.540 ms 4 2001:470:0:1f::1 (2001:470:0:1f::1) 53.055 ms 53.021 ms 52.996 ms 5 10gigabitethernet1-2.core1.sjc2.he.net (2001:470:0:2f::2) 52.979 ms 53.115 ms 53.109 ms 6 2001:470:0:15e::2 (2001:470:0:15e::2) 53.405 ms 2001:4860:1:1:0:1b1b:0:9 (2001:4860:1:1:0:1b1b:0:9) 52.686 ms 2001:470:0:15e::2 (2001:470:0:15e::2) 52.511 ms 7 2001:4860::1:0:7ea (2001:4860::1:0:7ea) 66.009 ms 2001:4860::1:0:21 (2001:4860::1:0:21) 54.049 ms 2001:4860::1:0:7ea (2001:4860::1:0:7ea) 62.659 ms 8 2001:4860::8:0:2cb6 (2001:4860::8:0:2cb6) 85.601 ms 2001:4860::8:0:2cb7 (2001:4860::8:0:2cb7) 54.416 ms 2001:4860::8:0:2cb6 (2001:4860::8:0:2cb6) 53.600 ms 9 2001:4860::1:0:489 (2001:4860::1:0:489) 124.579 ms 2001:4860::1:0:5db (2001:4860::1:0:5db) 112.969 ms 113.006 ms 10 2001:4860::2:0:a7 (2001:4860::2:0:a7) 146.322 ms 147.518 ms 115.466 ms 11 2001:4860:0:1::10b (2001:4860:0:1::10b) 112.987 ms 112.185 ms 113.447 ms 12 yx-in-x6a.1e100.net (2001:4860:800a::6a) 113.500 ms 113.493 ms 113.881 ms Curtis -----Original Message----- From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il] Sent: Monday, June 06, 2011 7:53 AM To: Christopher Morrow Cc: nanog at nanog.org Subject: Re: Google and IPv6 inverse? At 08:45 06/06/2011 -0400, Christopher Morrow wrote: >On Mon, Jun 6, 2011 at 1:19 AM, Hank Nussbacher wrote: > > Will Google have inverse working by June 8th? > > > >poking the tiger some... 'why?' Just curious. -Hank > > [hank at noc ~]$ traceroute6 ipv6.google.com traceroute to > > ipv6.l.google.com (2a00:1450:8001::68) from > > 2001:bf8:0:3:202:b3ff:feaf:f3fc, 30 hops max, 16 byte packets > > 1 2001:bf8:0:3::1 (2001:bf8:0:3::1) 0.407 ms 221.144 ms 5.218 > > ms > > 2 2001:bf8:0:b::1 (2001:bf8:0:b::1) 0.559 ms 0.54 ms 0.486 ms > > 3 iucc-lb1.rt1.fra.de.geant2.net (2001:798:14:10aa::1d) 50.665 > ms 50.611 > > ms 50.567 ms > > 4 google-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::e) 56.821 > ms 50.525 > > ms 50.486 ms > > 5 2001:4860::1:0:11 (2001:4860::1:0:11) 51.266 ms 51.106 ms > > 51.068 ms > > 6 2001:4860::1:0:4b3 (2001:4860::1:0:4b3) 58.309 ms 58.078 > ms 58.442 ms > > 7 2001:4860::8:0:2db0 (2001:4860::8:0:2db0) 57.174 ms 57.339 ms > > 57.195 ms > > 8 2001:4860::2:0:66f (2001:4860::2:0:66f) 72.496 ms 60.803 > ms 72.381 ms > > 9 2001:4860:0:1::1b (2001:4860:0:1::1b) 68.165 ms 62.21 ms 70.3 > > ms > > 10 2a00:1450:8001::68 (2a00:1450:8001::68) 61.21 ms 61.862 ms > > 61.331 ms > > > > Thanks, > > Hank > > > > > > From Valdis.Kletnieks at vt.edu Mon Jun 6 08:41:44 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 06 Jun 2011 09:41:44 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: Your message of "Mon, 06 Jun 2011 00:59:55 EDT." <4DEC5ECB.6080407@trelane.net> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <4DEC5ECB.6080407@trelane.net> Message-ID: <170007.1307367704@turing-police.cc.vt.edu> On Mon, 06 Jun 2011 00:59:55 EDT, Andrew D Kirch said: > correct regarding firearms, without recognizing the basic right to > protect human life against criminals and despots, there are no other > rights (as a criminal and despot will take those rights with impunity). Nice try, but the human right you just made a case for is "the right to rid yourself of criminals and despots". A "fundamental right" for citizens to have firearms does *not* automatically follow. Yes, despots usually need to be removed by force. What Ghandi showed was that the force didn't have to be military - there are other types of force that work well too... Anyhow, enough of that, except as it relates to communications.. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Mon Jun 6 08:42:37 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 06 Jun 2011 09:42:37 -0400 Subject: UN declares Internet access a "human right" In-Reply-To: Your message of "Sun, 05 Jun 2011 22:40:57 PDT." <4DEC6869.5020205@gmail.com> References: <4DEC13C1.1050800@linuxbox.org> <132521.1307319520@turing-police.cc.vt.edu> <4DEC6869.5020205@gmail.com> Message-ID: <170049.1307367757@turing-police.cc.vt.edu> On Sun, 05 Jun 2011 22:40:57 PDT, JC Dill said: > I will happily go along with this argument when the "3 strikes you're > off" copyright laws are enforced thru a process which A) assumes you are > innocent until proven guilty; B) that you are allowed to present a > defense and challenge all witnesses; and C) that you are entitled to > have your case heard by a jury of your peers. To the best of my > knowledge, none of the "3 strikes you're off" copyright laws proposed or > enacted have provided these basic human rights. You missed the '' at the end, didn't you? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From eesslinger at fpu-tn.com Mon Jun 6 08:43:26 2011 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Mon, 6 Jun 2011 08:43:26 -0500 Subject: blocking annoying 'bounce mail' "feature" from customers use. (Solution, mostly) In-Reply-To: Message-ID: > -----Original Message----- > From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] > Sent: Wednesday, May 25, 2011 11:10 AM > To: 'nanog at nanog.org' > Subject: blocking annoying 'bounce mail' "feature" from customers use. > > > Mac Mail (and others) have a "feature" that allows my > customers to generate a fake NDR message and send it back > through my server. I get about a customer every few months > that discovers this 'solution' to spam emails, and when it > happens they cause delivery problems for my customer mail > server by generating backscatter. > > Today I just ended up on a list that won't take me off for > quite a while (or unless I pay). > > Does anyone know of a way for me to block the following, > using postfix, either via refusing to accept the mail or by > dropping it in /dev/null: Mail from <> or postmaster that > originates within our customer IP blocks/is sent using > authentication at the submission port and/or that does not > have a valid local recipient. > > I can't find any ready made recipies online for this sort of > thing in a short dig around for it, and while I think it's > possible, I was wondering if anyone else was already dealing > with this and could say 'oh yeah just put line blah in > header_checks'. I would think it would be simple once you > find it but you know how it is. > > (I've already dealt with the customer in question but I'm > getting tired of this popping up every month or three.) > __________________________ Eric Esslinger Information > Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ (931)433-1522 ext 165 > A couple of people asked me to follow up with a solution if I found one. What I did was perhaps not elegant, but functional. I was hindered by a lack of time and lack of clear understanding of something in the header checks (namely, that the various postfix UCE 'checks' are not stateful and only can do multiple comparisons against a single line at a time. I can't check to: and from: both using header_checks if/endifs. I don't have time to learn how to build a custom milter atm so this will have to do for now, though that would likely be the ideal solution). After some research, some trial and error, and some suggestions, this is what I came up with: For all of the clients that have this capability on the windows side (I don't have direct access to a mac at this time, and apparantly everyone using this is using mailwasher and similar apps) it appears the following line in the body_checks filter catches all of them: /mail.local: unknown name:/ DISCARD I had one other user that I've located that was a problem after that. I fixed his issue by discussion with him and some jusdicious port filtering; His issue was a bit more complex: He is running his own mail server in my static range; He doesn't have a good spam filtering setup, specifically his new spam filter is unaware of actual valid email addresses on his domain, thus accepts a lot of illegitimate email for his domain, which the server then bounces with an invalid recipient. Since he realized he had a problem with getting on bounce lists last month, he decided the solution was a custom delivery filter. Bounce messages from his server are relayed through our public mail server. Since he doesn't see any issues with maintaining this solution on his end, I see no issue with blocking his smtp access to our mail server. BTW: If anyone out there has a mac and wishes to generate a bounce to my address above so I can check my filters against what mac mail generates, I'd appreciate it. I can send an email directly to you for that purpose. (a bounce to fpu-tn.com will get through because it's our corporate mail server and not filtering the same way). Thanks to the list for the assistance rendered. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: Eric J Esslinger.vcf Type: text/x-vcard Size: 498 bytes Desc: Eric J Esslinger.vcf URL: From morrowc.lists at gmail.com Mon Jun 6 08:55:08 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 6 Jun 2011 09:55:08 -0400 Subject: Google and IPv6 inverse? In-Reply-To: References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> <5.1.0.14.2.20110606155214.03751598@efes.iucc.ac.il> Message-ID: On Mon, Jun 6, 2011 at 9:12 AM, STARNES, CURTIS wrote: > (2001:4860:800a::6a I think this is a case of some ips have this, some don't... I think all are SUPPOSED to... -chris From morrowc.lists at gmail.com Mon Jun 6 08:55:49 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 6 Jun 2011 09:55:49 -0400 Subject: Google and IPv6 inverse? In-Reply-To: <5.1.0.14.2.20110606155214.03751598@efes.iucc.ac.il> References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> <5.1.0.14.2.20110606155214.03751598@efes.iucc.ac.il> Message-ID: On Mon, Jun 6, 2011 at 8:53 AM, Hank Nussbacher wrote: > At 08:45 06/06/2011 -0400, Christopher Morrow wrote: >> >> On Mon, Jun 6, 2011 at 1:19 AM, Hank Nussbacher >> wrote: >> > Will Google have inverse working by June 8th? >> > >> >> poking the tiger some... 'why?' > > Just curious. it occurs to me that I should have also asked: "router hops or end-systems" ? (in v4 it seems google does end-hosts, but not routed hops) >> > [hank at noc ~]$ traceroute6 ipv6.google.com >> > traceroute to ipv6.l.google.com (2a00:1450:8001::68) from >> > 2001:bf8:0:3:202:b3ff:feaf:f3fc, 30 hops max, 16 byte packets >> > ?1 ?2001:bf8:0:3::1 (2001:bf8:0:3::1) ?0.407 ms ?221.144 ms ?5.218 ms >> > ?2 ?2001:bf8:0:b::1 (2001:bf8:0:b::1) ?0.559 ms ?0.54 ms ?0.486 ms >> > ?3 ?iucc-lb1.rt1.fra.de.geant2.net (2001:798:14:10aa::1d) ?50.665 ms >> > ?50.611 >> > ms ?50.567 ms >> > ?4 ?google-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::e) ?56.821 ms >> > ?50.525 >> > ms ?50.486 ms >> > ?5 ?2001:4860::1:0:11 (2001:4860::1:0:11) ?51.266 ms ?51.106 ms ?51.068 >> > ms >> > ?6 ?2001:4860::1:0:4b3 (2001:4860::1:0:4b3) ?58.309 ms ?58.078 ms >> > ?58.442 ms >> > ?7 ?2001:4860::8:0:2db0 (2001:4860::8:0:2db0) ?57.174 ms ?57.339 ms >> > ?57.195 >> > ms >> > ?8 ?2001:4860::2:0:66f (2001:4860::2:0:66f) ?72.496 ms ?60.803 ms >> > ?72.381 ms >> > ?9 ?2001:4860:0:1::1b (2001:4860:0:1::1b) ?68.165 ms ?62.21 ms ?70.3 ms >> > 10 ?2a00:1450:8001::68 (2a00:1450:8001::68) ?61.21 ms ?61.862 ms ?61.331 >> > ms >> > >> > Thanks, >> > Hank >> > >> > >> > > > From bicknell at ufp.org Mon Jun 6 09:05:19 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 6 Jun 2011 07:05:19 -0700 Subject: Google and IPv6 inverse? In-Reply-To: References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> Message-ID: <20110606140519.GA43463@ussenterprise.ufp.org> In a message written on Mon, Jun 06, 2011 at 08:45:31AM -0400, Christopher Morrow wrote: > On Mon, Jun 6, 2011 at 1:19 AM, Hank Nussbacher wrote: > > Will Google have inverse working by June 8th? > > poking the tiger some... 'why?' It's the network equivilent of holding open the door for someone or saying please and thank you. Civilized network operators do it to be polite. Picking on the name in Hank's e-mail: % traceroute -n efes.iucc.ac.il traceroute to efes.iucc.ac.il (128.139.202.17), 64 hops max, 52 byte packets 1 149.20.48.1 1.515 ms 0.783 ms 0.706 ms 2 149.20.65.9 2.756 ms 0.972 ms 3.156 ms 3 64.215.195.21 50.607 ms 50.524 ms 54.705 ms 4 207.138.144.46 166.234 ms 166.235 ms 166.240 ms 5 62.40.125.122 230.584 ms 230.520 ms 237.217 ms 6 128.139.188.1 230.609 ms 443.760 ms 230.629 ms 7 * * * Quick question, which network providers were involved in that trace? Have fun hitting up whois to find out! % traceroute efes.iucc.ac.il traceroute to efes.iucc.ac.il (128.139.202.17), 64 hops max, 52 byte packets 1 exit.blue.sql1.isc.org (149.20.48.1) 2.410 ms 2.275 ms 0.782 ms 2 int-0-4-0-0.r1.pao1.isc.org (149.20.65.9) 3.493 ms 2.452 ms 0.958 ms 3 ge-9-15-1G.ar1.PAO2.gblx.net (64.215.195.21) 50.488 ms 50.540 ms 54.440 ms 4 DANTE.TenGigabitEthernet7-3.ar1.FRA4.gblx.net (207.138.144.46) 166.227 ms 166.231 ms 166.217 ms 5 iucc-lb1-gw.rt1.fra.de.geant2.net (62.40.125.122) 234.928 ms 245.142 ms 244.414 ms 6 gp1-gp0-te.ilan.net.il (128.139.188.1) 230.536 ms 230.618 ms 230.655 ms 7 *^C Ah, ISC->Global Crossing->GEANT2. See, rDNS just saved me about 2 minutes of whois pain. Which is what being polite is all about, making a very minor effort on your part to save someone else a minor amount of pain. Or, if you want another view on it: http://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf Start at slide 12. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jfesler at gigo.com Mon Jun 6 09:30:20 2011 From: jfesler at gigo.com (Jason Fesler) Date: Mon, 6 Jun 2011 07:30:20 -0700 (PDT) Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> <6469.1307064588@turing-police.cc.vt.edu> Message-ID: > In that case can anyone explain why the number of IPv4 *only* systems is > increasing rather than decreasing: > http://server8.test-ipv6.com/stats.html Increased traffic from less-geeky people = more sane numbers overall. The problem with the graphs on that site is that the audience is self selecting; so only when some major site says "go here!" do we get a more random(ish) audience, versus people setting up tunnelbrokers and the like. > I would have expected the green+azure areas in those graphs to have increased > in the past half year but counter-intutitively, it appears that IPv4 only > usage is increasing. You're assuming there's significant rollout of IPv6. Everything I've seen so far says that *starts* nowish, and more laterish this year, in any impacting way. Really, we're just just before the start of getting end user adoption to start rising. From dseagrav at humancapitaldev.com Mon Jun 6 09:31:49 2011 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Mon, 6 Jun 2011 09:31:49 -0500 Subject: (OT) Firearms Was: UN declares Internet access a "human right" In-Reply-To: <170007.1307367704@turing-police.cc.vt.edu> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <4DEC5ECB.6080407@trelane.net> <170007.1307367704@turing-police.cc.vt.edu> Message-ID: <51A5D7AA-F758-4AD8-97F6-CB0F46490858@humancapitaldev.com> On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > Nice try, but the human right you just made a case for is "the right to rid > yourself of criminals and despots". A "fundamental right" for citizens to have > firearms does *not* automatically follow. Yes, despots usually need to be > removed by force. What Ghandi showed was that the force didn't have to be > military - there are other types of force that work well too... I believe that as a law-abiding citizen, I should have the right to be at least as well-armed as the average criminal. If the average criminal has access to firearms, then I should have that option as well. I should not be forced into a disadvantage against criminals by virtue of my compliance with the law. Once law enforcement is effective enough to prevent the average criminal from having access to firearms, then the law-abiding population can be compelled to disarm. This stance can result in an escalation scenario in which criminals strive to remain better-armed than their intended victims, but the job of law enforcement is to prevent them from being successful. At present, the average criminal in my area does not have firearms, and so I do not own one. Gun crime is on the increase, however, so this situation may change. From jfesler at gigo.com Mon Jun 6 09:36:45 2011 From: jfesler at gigo.com (Jason Fesler) Date: Mon, 6 Jun 2011 07:36:45 -0700 (PDT) Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: <4DE9EA04.2050605@unfix.org> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> Message-ID: > But anyway, just consider it: a portion of the major websites go > IPv6-only for 24 hours. What happens is that well, 99% of the populace > can't reach them anymore, as the known ones are down, they start calling > and thus overloading the helpdesks of their ISPs. Won't happen this year or next. Too much money at stake for the web sites. Only when IPv4 is single digits or less could this be even remotely considered. Even the 0.05% hit for a day was controverial at $dayjob. From bjorn at mork.no Mon Jun 6 09:38:26 2011 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Mon, 06 Jun 2011 16:38:26 +0200 Subject: Google and IPv6 inverse? In-Reply-To: <20110606140519.GA43463@ussenterprise.ufp.org> (Leo Bicknell's message of "Mon, 6 Jun 2011 07:05:19 -0700") References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> <20110606140519.GA43463@ussenterprise.ufp.org> Message-ID: <8762ojvxct.fsf@nemi.mork.no> Leo Bicknell writes: > Quick question, which network providers were involved in that trace? > Have fun hitting up whois to find out! You can convince your traceroute to do that for you: -A --as-path-lookups Perform AS path lookups in routing registries and print results directly after the corresponding addresses traceroute to ipv6.google.com (2a00:1450:4008:c00::93), 30 hops max, 80 byte packets 1 canardo-br0-7.ipv6.mork.no (2001:4620:9:2::1) [AS2119] 1.174 ms 1.349 ms 1.373 ms 2 2001:4600:10:101::1 (2001:4600:10:101::1) [AS2119] 14.623 ms 14.800 ms 14.956 ms 3 * * * 4 * * * 5 * * * 6 2001:4860::1:0:60d (2001:4860::1:0:60d) [AS15169] 60.938 ms 42.619 ms 42.614 ms 7 2001:4860:1:1:0:847:: (2001:4860:1:1:0:847::) [AS15169] 27.633 ms 27.732 ms 27.886 ms 8 2001:4860::1:0:26ec (2001:4860::1:0:26ec) [AS15169] 30.820 ms 30.873 ms 34.980 ms 9 2001:4860::1:0:60d (2001:4860::1:0:60d) [AS15169] 54.459 ms 39.116 ms 43.212 ms 10 2001:4860:0:1::217 (2001:4860:0:1::217) [AS15169] 47.002 ms 44.100 ms 44.174 ms 11 2a00:1450:4008:c00::93 (2a00:1450:4008:c00::93) [AS15169] 43.446 ms 43.726 ms 40.642 ms Now Juniper, it would be really nice if we also could see those intermediate MPLS nodes at hop 3, 4 and 5, but I know those are AS2119 anyway :-) Bj?rn From caldcv at gmail.com Mon Jun 6 09:45:13 2011 From: caldcv at gmail.com (Chris) Date: Mon, 6 Jun 2011 10:45:13 -0400 Subject: (OT) Firearms Was: UN declares Internet access a "human right" In-Reply-To: <51A5D7AA-F758-4AD8-97F6-CB0F46490858@humancapitaldev.com> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <4DEC5ECB.6080407@trelane.net> <170007.1307367704@turing-police.cc.vt.edu> <51A5D7AA-F758-4AD8-97F6-CB0F46490858@humancapitaldev.com> Message-ID: > Once law enforcement is effective enough to prevent the average > criminal from having access to firearms, then the law-abiding population can > be compelled to disarm. That day is coming through US force as "Operation Gun Runner" from the ATF allowed Mexican drug cartel straw purchasers to come in, purchase 5 or so AK-47 rifles, and when the gun store owner had suspicions about not selling it - the ATF told the owner to "let the guns walk" so the group could track down the weapons. Unfortunately, those weapons were used to kill a DEA agent in Mexico and a Border Patrol agent who was only armed with bean bag rounds in his shotgun then died trying to cycle out those rounds to put in live rounds. Also with al-CIAda patsy Adam Gahdan inaccurately reporting in his latest video to other jihadists about purchasing "automatic weapons" from gun shows, I believe the ball is rolling for everyone in the United States to be disarmed through force by new legislation to outlaw weapons. I do not think the average gun owner would ever disarm because the gun culture in our country is so deep and passionate in any freedom loving citizen's blood. The Second Amendment, in my opinion and most gun owners agree with, was put in the Bill of Rights for the average citizen to remove tyrants if the process of democracy does not work. > At present, the average criminal in my area does not have firearms, and so I > do not own one. Gun crime is on the increase, however, so this situation may > change. Better get one before it's too late :-) -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From bicknell at ufp.org Mon Jun 6 09:49:41 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 6 Jun 2011 07:49:41 -0700 Subject: Google and IPv6 inverse? In-Reply-To: <8762ojvxct.fsf@nemi.mork.no> References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> <20110606140519.GA43463@ussenterprise.ufp.org> <8762ojvxct.fsf@nemi.mork.no> Message-ID: <20110606144941.GA45774@ussenterprise.ufp.org> In a message written on Mon, Jun 06, 2011 at 04:38:26PM +0200, Bj?rn Mork wrote: > You can convince your traceroute to do that for you: > > -A --as-path-lookups Perform AS path lookups in routing registries and > print results directly after the corresponding > addresses I have not had good luck with that feature. Here's a FreeBSD traceroute, using the same host I referenced before: % traceroute -a efes.iucc.ac.il traceroute to efes.iucc.ac.il (128.139.202.17), 64 hops max, 52 byte packets 1 [AS1280] exit.blue.sql1.isc.org (149.20.48.1) 4.658 ms 2.718 ms 1.778 ms 2 [AS1280] int-0-4-0-0.r1.pao1.isc.org (149.20.65.9) 3.656 ms 2.363 ms 0.944 ms 3 [AS1221] ge-9-15-1G.ar1.PAO2.gblx.net (64.215.195.21) 50.539 ms 50.508 ms 59.709 ms 4 [AS3549] DANTE.TenGigabitEthernet7-3.ar1.FRA4.gblx.net (207.138.144.46) 166.476 ms 166.240 ms 166.243 ms 5 [AS20965] iucc-lb1-gw.rt1.fra.de.geant2.net (62.40.125.122) 230.590 ms 230.587 ms 230.545 ms 6 [AS378] gp1-gp0-te.ilan.net.il (128.139.188.1) 230.546 ms 230.579 ms 230.528 ms 7 * * * Now, I happen to administer hop #2, and know the packets are leaving on a link to Global Crossing (glbx.net). How AS 1221, which is Telstra, ends up in there is beyond me. From a Juniper box with a full table: bicknell at re0.r7.pao1> traceroute as-number-lookup efes.iucc.ac.il traceroute to efes.iucc.ac.il (128.139.202.17), 30 hops max, 40 byte packets 1 int-2-0-0.r1.pao1.isc.org (149.20.65.16) 4.448 ms 3.973 ms 3.222 ms 2 ge-9-15-1G.ar1.PAO2.gblx.net (64.215.195.21) 50.724 ms 67.135 ms 50.761 ms 3 DANTE.TenGigabitEthernet7-3.ar1.FRA4.gblx.net (207.138.144.46) [AS 3549] 159.652 ms 159.571 ms 160.003 ms 4 iucc-lb1-gw.rt1.fra.de.geant2.net (62.40.125.122) [AS 20965] 279.761 ms 275.059 ms 230.929 ms 5 gp1-gp0-te.ilan.net.il (128.139.188.1) [AS 378] 231.149 ms 231.222 ms 231.258 ms 6 * * * At least it's not wrong, but there is no ASN listed because the /30 on the link between 2 and 3 is internal, so it views hop 3 as being internal to my ASN, when it is not. But more importantly, not all traceroutes have this feature, and as I said it's about being polite. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Mon Jun 6 10:08:28 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 06 Jun 2011 11:08:28 -0400 Subject: Google and IPv6 inverse? In-Reply-To: Your message of "Mon, 06 Jun 2011 07:49:41 PDT." <20110606144941.GA45774@ussenterprise.ufp.org> References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> <20110606140519.GA43463@ussenterprise.ufp.org> <8762ojvxct.fsf@nemi.mork.no> <20110606144941.GA45774@ussenterprise.ufp.org> Message-ID: <4654.1307372908@turing-police.cc.vt.edu> On Mon, 06 Jun 2011 07:49:41 PDT, Leo Bicknell said: > I have not had good luck with that feature. > > Here's a FreeBSD traceroute, using the same host I referenced before: > > % traceroute -a efes.iucc.ac.il s/-a/-A/ - FTFY. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jcdill.lists at gmail.com Mon Jun 6 10:15:17 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 06 Jun 2011 08:15:17 -0700 Subject: UN declares Internet access a "human right" In-Reply-To: <170049.1307367757@turing-police.cc.vt.edu> References: <4DEC13C1.1050800@linuxbox.org> <132521.1307319520@turing-police.cc.vt.edu> <4DEC6869.5020205@gmail.com> <170049.1307367757@turing-police.cc.vt.edu> Message-ID: <4DECEF05.7070101@gmail.com> On 06/06/11 6:42 AM, Valdis.Kletnieks at vt.edu wrote: > On Sun, 05 Jun 2011 22:40:57 PDT, JC Dill said: > >> I will happily go along with this argument when the "3 strikes you're >> off" copyright laws are enforced thru a process which A) assumes you are >> innocent until proven guilty; B) that you are allowed to present a >> defense and challenge all witnesses; and C) that you are entitled to >> have your case heard by a jury of your peers. To the best of my >> knowledge, none of the "3 strikes you're off" copyright laws proposed or >> enacted have provided these basic human rights. > You missed the '' at the end, didn't you? :) > No, I didn't miss it. It wasn't clear what part you were snarking at. Some people DO make that argument, and I wanted to point out why it was faulty logic. The bigger point is how our basic human rights are being eroded by corporations and governments on a daily basis. People willingly submit to "exit checks" at stores, being treated like potential shoplifters because they think they HAVE to submit. (The only store where you have to submit to an exit check is a membership store where agreeing to this policy is part of your membership agreement. Unless the store has reason to suspect you are shoplifting, they can't block or detain you if you want to bypass the exit check and leave with your paid purchases. If they try to stop you when they have no evidence of shoplifting, you can sue for false arrest.) I joined a gym more than a year ago, with a pre-paid 24 month membership. Recently they put in a finger scanner, and it's "optional" to enroll to have your fingerprint scanned and then the data points stored in their computer. Then you scan your finger and enter a pin number. I choose to not opt-in to this optional system. Last night, I attempted to work out by presenting my membership card and a photocopy of my license. This was the acceptable method when I enrolled (they photocopied my license and put it in a plastic card holder along with the membership card). But now they want to see the actual physical driver's license every time I work out. I find this intrusive, and a violation of my contract for 24 months of gym membership because when I enrolled there was no requirement to show my driver's license every time I worked out - I showed it on joining and then THEY said a photocopy was sufficient for future visits. But there's no way to win this fight. It's not worth trying to get corporate to change their policy, they won't actually change their policy no matter what I do. All it will do is cause me more angst. So I have to either deal with the inconvenience (and risk of losing/misplacing my license) by bringing in my license (and thus my wallet) into the gym when I want to work out, or I have to submit to having my fingerprint put into their database. So much for my right to "opt-out" of this "optional" scanner system. It's a right, but they have made it so difficult and inconvenient to use the alternate method that my right doesn't *really* exist. And let's not forget TSA. These small incremental incidents are how rights are eroded, how people get brainwashed into believing that they must submit to these intrusions. "Show us your papers" is not far behind. jc From bicknell at ufp.org Mon Jun 6 10:26:56 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 6 Jun 2011 08:26:56 -0700 Subject: Google and IPv6 inverse? In-Reply-To: <4654.1307372908@turing-police.cc.vt.edu> References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> <20110606140519.GA43463@ussenterprise.ufp.org> <8762ojvxct.fsf@nemi.mork.no> <20110606144941.GA45774@ussenterprise.ufp.org> <4654.1307372908@turing-police.cc.vt.edu> Message-ID: <20110606152656.GA48008@ussenterprise.ufp.org> In a message written on Mon, Jun 06, 2011 at 11:08:28AM -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 06 Jun 2011 07:49:41 PDT, Leo Bicknell said: > > I have not had good luck with that feature. > > > > Here's a FreeBSD traceroute, using the same host I referenced before: > > > > % traceroute -a efes.iucc.ac.il > > s/-a/-A/ - FTFY. -a Turn on AS# lookups for each hop encountered. -A Turn on AS# lookups and use the given server instead of the default. Is there a particular server you would like to recommend? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From nick at flhsi.com Mon Jun 6 10:37:44 2011 From: nick at flhsi.com (Nick Olsen) Date: Mon, 6 Jun 2011 11:37:44 -0400 Subject: (OT) Firearms Was: UN declares Internet access a "human right" Message-ID: <59e5d003$1c7201da$35546f68$@com> Don't leave the house without my Glock 23 on my side. Truck always has a loaded 12ga in it. In the house, I've got a handful of pistols and my SR-556 (AR-15) in the "Guns and servers" closet. I've had people call me Paranoid more then once. My stance is "Better to have it and not need it, Then need it and not have it." By banning guns from a community, Your only taking them out of the hands of law abiding citizens. Not like most criminals get guns via legal channels in the first place. -Nick Olsen ---------------------------------------- From: "Daniel Seagraves" Sent: Monday, June 06, 2011 10:34 AM To: nanog at nanog.org Subject: Re: (OT) Firearms Was: UN declares Internet access a "human right" On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > Nice try, but the human right you just made a case for is "the right to rid > yourself of criminals and despots". A "fundamental right" for citizens to have > firearms does *not* automatically follow. Yes, despots usually need to be > removed by force. What Ghandi showed was that the force didn't have to be > military - there are other types of force that work well too... I believe that as a law-abiding citizen, I should have the right to be at least as well-armed as the average criminal. If the average criminal has access to firearms, then I should have that option as well. I should not be forced into a disadvantage against criminals by virtue of my compliance with the law. Once law enforcement is effective enough to prevent the average criminal from having access to firearms, then the law-abiding population can be compelled to disarm. This stance can result in an escalation scenario in which criminals strive to remain better-armed than their intended victims, but the job of law enforcement is to prevent them from being successful. At present, the average criminal in my area does not have firearms, and so I do not own one. Gun crime is on the increase, however, so this situation may change. From trelane at trelane.net Mon Jun 6 10:39:27 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 06 Jun 2011 11:39:27 -0400 Subject: (OT) Firearms Was: UN declares Internet access a "human right" In-Reply-To: <59e5d003$1c7201da$35546f68$@com> References: <59e5d003$1c7201da$35546f68$@com> Message-ID: <4DECF4AF.9050208@trelane.net> nothing like 40 short and wimpy! Might I interest you in a 45? :) On 6/6/2011 11:37 AM, Nick Olsen wrote: > Don't leave the house without my Glock 23 on my side. Truck always has a > loaded 12ga in it. In the house, I've got a handful of pistols and my > SR-556 (AR-15) in the "Guns and servers" closet. > I've had people call me Paranoid more then once. My stance is "Better to > have it and not need it, Then need it and not have it." > By banning guns from a community, Your only taking them out of the hands of > law abiding citizens. Not like most criminals get guns via legal channels > in the first place. > > -Nick Olsen > > ---------------------------------------- > From: "Daniel Seagraves" > Sent: Monday, June 06, 2011 10:34 AM > To: nanog at nanog.org > Subject: Re: (OT) Firearms Was: UN declares Internet access a "human > right" > > On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > >> Nice try, but the human right you just made a case for is "the right to > rid >> yourself of criminals and despots". A "fundamental right" for citizens > to have >> firearms does *not* automatically follow. Yes, despots usually need to > be >> removed by force. What Ghandi showed was that the force didn't have to > be >> military - there are other types of force that work well too... > I believe that as a law-abiding citizen, I should have the right to be at > least as well-armed as the average criminal. If the average criminal has > access to firearms, then I should have that option as well. I should not be > forced into a disadvantage against criminals by virtue of my compliance > with the law. Once law enforcement is effective enough to prevent the > average criminal from having access to firearms, then the law-abiding > population can be compelled to disarm. This stance can result in an > escalation scenario in which criminals strive to remain better-armed than > their intended victims, but the job of law enforcement is to prevent them > from being successful. > > At present, the average criminal in my area does not have firearms, and so > I do not own one. Gun crime is on the increase, however, so this situation > may change. > > From paul at paulstewart.org Mon Jun 6 10:41:43 2011 From: paul at paulstewart.org (Paul Stewart) Date: Mon, 6 Jun 2011 11:41:43 -0400 Subject: (OT) Firearms Was: UN declares Internet access a "human right" In-Reply-To: <59e5d003$1c7201da$35546f68$@com> References: <59e5d003$1c7201da$35546f68$@com> Message-ID: <006d01cc2460$3dc0d610$b9428230$@org> Agree 110% - wish Canada had similar laws as the USA does... way too restrictive here. The folks that are legal get thrown in jail much faster than the guys who break into your house in the first place. Paul -----Original Message----- From: Nick Olsen [mailto:nick at flhsi.com] Sent: Monday, June 06, 2011 11:38 AM To: Daniel Seagraves; nanog at nanog.org Subject: Re: (OT) Firearms Was: UN declares Internet access a "human right" Don't leave the house without my Glock 23 on my side. Truck always has a loaded 12ga in it. In the house, I've got a handful of pistols and my SR-556 (AR-15) in the "Guns and servers" closet. I've had people call me Paranoid more then once. My stance is "Better to have it and not need it, Then need it and not have it." By banning guns from a community, Your only taking them out of the hands of law abiding citizens. Not like most criminals get guns via legal channels in the first place. -Nick Olsen From caldcv at gmail.com Mon Jun 6 10:45:52 2011 From: caldcv at gmail.com (Chris) Date: Mon, 6 Jun 2011 11:45:52 -0400 Subject: (OT) Firearms Was: UN declares Internet access a "human right" In-Reply-To: <006d01cc2460$3dc0d610$b9428230$@org> References: <59e5d003$1c7201da$35546f68$@com> <006d01cc2460$3dc0d610$b9428230$@org> Message-ID: http://www.tomshardware.com/news/Joshua-Lee-Campbell-Server-Shoot-Gun-alcohol,11171.html Just don't end up like this guy. He's a personal hero of mine. We've all wanted to do this before but he had the liquid courage to do it and yet another reason to own a 45 ;-) From cb.list6 at gmail.com Mon Jun 6 11:14:04 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 6 Jun 2011 09:14:04 -0700 Subject: IPv6-only Systems Message-ID: FreeBSD is initiating IPv6-only validation work http://www.prweb.com/releases/2011/6/prweb8529718.htm My own testing of the Windows 7 shows that, at it's core, it works well as IPv6-only for most "web & email" functions. Layering on applications like Skype, things start to fall apart. Cameron From nick at flhsi.com Mon Jun 6 11:15:02 2011 From: nick at flhsi.com (Nick Olsen) Date: Mon, 6 Jun 2011 12:15:02 -0400 Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a "human right" Message-ID: <6a9bc6fe$30c180e6$40efea99$@com> I've got a 4 inch Springfield XD service model in .45ACP, I actually prefer the .40 round. Its a bit better at inducing Hydrostatic shock just because of its velocity:energy ratio. The handgun just to get me to the bigger guns :D -Nick Olsen ---------------------------------------- From: "Andrew Kirch" Sent: Monday, June 06, 2011 11:42 AM To: nanog at nanog.org Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a "human right" nothing like 40 short and wimpy! Might I interest you in a 45? :) On 6/6/2011 11:37 AM, Nick Olsen wrote: > Don't leave the house without my Glock 23 on my side. Truck always has a > loaded 12ga in it. In the house, I've got a handful of pistols and my > SR-556 (AR-15) in the "Guns and servers" closet. > I've had people call me Paranoid more then once. My stance is "Better to > have it and not need it, Then need it and not have it." > By banning guns from a community, Your only taking them out of the hands of > law abiding citizens. Not like most criminals get guns via legal channels > in the first place. > > -Nick Olsen > > ---------------------------------------- > From: "Daniel Seagraves" > Sent: Monday, June 06, 2011 10:34 AM > To: nanog at nanog.org > Subject: Re: (OT) Firearms Was: UN declares Internet access a "human > right" > > On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > >> Nice try, but the human right you just made a case for is "the right to > rid >> yourself of criminals and despots". A "fundamental right" for citizens > to have >> firearms does *not* automatically follow. Yes, despots usually need to > be >> removed by force. What Ghandi showed was that the force didn't have to > be >> military - there are other types of force that work well too... > I believe that as a law-abiding citizen, I should have the right to be at > least as well-armed as the average criminal. If the average criminal has > access to firearms, then I should have that option as well. I should not be > forced into a disadvantage against criminals by virtue of my compliance > with the law. Once law enforcement is effective enough to prevent the > average criminal from having access to firearms, then the law-abiding > population can be compelled to disarm. This stance can result in an > escalation scenario in which criminals strive to remain better-armed than > their intended victims, but the job of law enforcement is to prevent them > from being successful. > > At present, the average criminal in my area does not have firearms, and so > I do not own one. Gun crime is on the increase, however, so this situation > may change. > > From Mike.Rae at sjrb.ca Mon Jun 6 11:17:39 2011 From: Mike.Rae at sjrb.ca (Mike Rae) Date: Mon, 6 Jun 2011 10:17:39 -0600 Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" In-Reply-To: <6a9bc6fe$30c180e6$40efea99$@com> References: <6a9bc6fe$30c180e6$40efea99$@com> Message-ID: <50472F725ECB89459EBAA5708D6C66DF019C8571@PRDCG4EXVW01-5.OSS.PRD> Hi All : How is this an operational related discussion ? Perhaps it can be taken to more appropriate forum. thanks Mike -----Original Message----- From: Nick Olsen [mailto:nick at flhsi.com] Sent: Monday, June 06, 2011 10:15 AM To: Andrew Kirch; nanog at nanog.org Subject: re: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" I've got a 4 inch Springfield XD service model in .45ACP, I actually prefer the .40 round. Its a bit better at inducing Hydrostatic shock just because of its velocity:energy ratio. The handgun just to get me to the bigger guns :D -Nick Olsen ---------------------------------------- From: "Andrew Kirch" Sent: Monday, June 06, 2011 11:42 AM To: nanog at nanog.org Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a "human right" nothing like 40 short and wimpy! Might I interest you in a 45? :) On 6/6/2011 11:37 AM, Nick Olsen wrote: > Don't leave the house without my Glock 23 on my side. Truck always has a > loaded 12ga in it. In the house, I've got a handful of pistols and my > SR-556 (AR-15) in the "Guns and servers" closet. > I've had people call me Paranoid more then once. My stance is "Better to > have it and not need it, Then need it and not have it." > By banning guns from a community, Your only taking them out of the hands of > law abiding citizens. Not like most criminals get guns via legal channels > in the first place. > > -Nick Olsen > > ---------------------------------------- > From: "Daniel Seagraves" > Sent: Monday, June 06, 2011 10:34 AM > To: nanog at nanog.org > Subject: Re: (OT) Firearms Was: UN declares Internet access a "human > right" > > On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > >> Nice try, but the human right you just made a case for is "the right to > rid >> yourself of criminals and despots". A "fundamental right" for citizens > to have >> firearms does *not* automatically follow. Yes, despots usually need to > be >> removed by force. What Ghandi showed was that the force didn't have to > be >> military - there are other types of force that work well too... > I believe that as a law-abiding citizen, I should have the right to be at > least as well-armed as the average criminal. If the average criminal has > access to firearms, then I should have that option as well. I should not be > forced into a disadvantage against criminals by virtue of my compliance > with the law. Once law enforcement is effective enough to prevent the > average criminal from having access to firearms, then the law-abiding > population can be compelled to disarm. This stance can result in an > escalation scenario in which criminals strive to remain better-armed than > their intended victims, but the job of law enforcement is to prevent them > from being successful. > > At present, the average criminal in my area does not have firearms, and so > I do not own one. Gun crime is on the increase, however, so this situation > may change. > > From nick at flhsi.com Mon Jun 6 11:22:29 2011 From: nick at flhsi.com (Nick Olsen) Date: Mon, 6 Jun 2011 12:22:29 -0400 Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" Message-ID: <15c5228a$63990108$25fbe4d2$@com> Hence the (OT) tag. -Nick Olsen ---------------------------------------- From: "Mike Rae" Sent: Monday, June 06, 2011 12:20 PM To: nanog at nanog.org Subject: RE: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" Hi All : How is this an operational related discussion ? Perhaps it can be taken to more appropriate forum. thanks Mike -----Original Message----- From: Nick Olsen [mailto:nick at flhsi.com] Sent: Monday, June 06, 2011 10:15 AM To: Andrew Kirch; nanog at nanog.org Subject: re: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" I've got a 4 inch Springfield XD service model in .45ACP, I actually prefer the .40 round. Its a bit better at inducing Hydrostatic shock just because of its velocity:energy ratio. The handgun just to get me to the bigger guns :D -Nick Olsen ---------------------------------------- From: "Andrew Kirch" Sent: Monday, June 06, 2011 11:42 AM To: nanog at nanog.org Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a "human right" nothing like 40 short and wimpy! Might I interest you in a 45? :) On 6/6/2011 11:37 AM, Nick Olsen wrote: > Don't leave the house without my Glock 23 on my side. Truck always has a > loaded 12ga in it. In the house, I've got a handful of pistols and my > SR-556 (AR-15) in the "Guns and servers" closet. > I've had people call me Paranoid more then once. My stance is "Better to > have it and not need it, Then need it and not have it." > By banning guns from a community, Your only taking them out of the hands of > law abiding citizens. Not like most criminals get guns via legal channels > in the first place. > > -Nick Olsen > > ---------------------------------------- > From: "Daniel Seagraves" > Sent: Monday, June 06, 2011 10:34 AM > To: nanog at nanog.org > Subject: Re: (OT) Firearms Was: UN declares Internet access a "human > right" > > On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > >> Nice try, but the human right you just made a case for is "the right to > rid >> yourself of criminals and despots". A "fundamental right" for citizens > to have >> firearms does *not* automatically follow. Yes, despots usually need to > be >> removed by force. What Ghandi showed was that the force didn't have to > be >> military - there are other types of force that work well too... > I believe that as a law-abiding citizen, I should have the right to be at > least as well-armed as the average criminal. If the average criminal has > access to firearms, then I should have that option as well. I should not be > forced into a disadvantage against criminals by virtue of my compliance > with the law. Once law enforcement is effective enough to prevent the > average criminal from having access to firearms, then the law-abiding > population can be compelled to disarm. This stance can result in an > escalation scenario in which criminals strive to remain better-armed than > their intended victims, but the job of law enforcement is to prevent them > from being successful. > > At present, the average criminal in my area does not have firearms, and so > I do not own one. Gun crime is on the increase, however, so this situation > may change. > > From Mike.Rae at sjrb.ca Mon Jun 6 11:24:22 2011 From: Mike.Rae at sjrb.ca (Mike Rae) Date: Mon, 6 Jun 2011 10:24:22 -0600 Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" In-Reply-To: <15c5228a$63990108$25fbe4d2$@com> References: <15c5228a$63990108$25fbe4d2$@com> Message-ID: <50472F725ECB89459EBAA5708D6C66DF019C8572@PRDCG4EXVW01-5.OSS.PRD> Hi : Fair enough, missed that, Thanks Mike From: Nick Olsen [mailto:nick at flhsi.com] Sent: Monday, June 06, 2011 10:22 AM To: Mike Rae; nanog at nanog.org Subject: RE: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" Hence the (OT) tag. -Nick Olsen ________________________________ From: "Mike Rae" Sent: Monday, June 06, 2011 12:20 PM To: nanog at nanog.org Subject: RE: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" Hi All : How is this an operational related discussion ? Perhaps it can be taken to more appropriate forum. thanks Mike -----Original Message----- From: Nick Olsen [mailto:nick at flhsi.com] Sent: Monday, June 06, 2011 10:15 AM To: Andrew Kirch; nanog at nanog.org Subject: re: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" I've got a 4 inch Springfield XD service model in .45ACP, I actually prefer the .40 round. Its a bit better at inducing Hydrostatic shock just because of its velocity:energy ratio. The handgun just to get me to the bigger guns :D -Nick Olsen ---------------------------------------- From: "Andrew Kirch" Sent: Monday, June 06, 2011 11:42 AM To: nanog at nanog.org Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a "human right" nothing like 40 short and wimpy! Might I interest you in a 45? :) On 6/6/2011 11:37 AM, Nick Olsen wrote: > Don't leave the house without my Glock 23 on my side. Truck always has a > loaded 12ga in it. In the house, I've got a handful of pistols and my > SR-556 (AR-15) in the "Guns and servers" closet. > I've had people call me Paranoid more then once. My stance is "Better to > have it and not need it, Then need it and not have it." > By banning guns from a community, Your only taking them out of the hands of > law abiding citizens. Not like most criminals get guns via legal channels > in the first place. > > -Nick Olsen > > ---------------------------------------- > From: "Daniel Seagraves" > Sent: Monday, June 06, 2011 10:34 AM > To: nanog at nanog.org > Subject: Re: (OT) Firearms Was: UN declares Internet access a "human > right" > > On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > >> Nice try, but the human right you just made a case for is "the right to > rid >> yourself of criminals and despots". A "fundamental right" for citizens > to have >> firearms does *not* automatically follow. Yes, despots usually need to > be >> removed by force. What Ghandi showed was that the force didn't have to > be >> military - there are other types of force that work well too... > I believe that as a law-abiding citizen, I should have the right to be at > least as well-armed as the average criminal. If the average criminal has > access to firearms, then I should have that option as well. I should not be > forced into a disadvantage against criminals by virtue of my compliance > with the law. Once law enforcement is effective enough to prevent the > average criminal from having access to firearms, then the law-abiding > population can be compelled to disarm. This stance can result in an > escalation scenario in which criminals strive to remain better-armed than > their intended victims, but the job of law enforcement is to prevent them > from being successful. > > At present, the average criminal in my area does not have firearms, and so > I do not own one. Gun crime is on the increase, however, so this situation > may change. > > From jason.duerstock at gallaudet.edu Mon Jun 6 11:38:30 2011 From: jason.duerstock at gallaudet.edu (Jason Duerstock) Date: Mon, 6 Jun 2011 12:38:30 -0400 Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" In-Reply-To: <50472F725ECB89459EBAA5708D6C66DF019C8571@PRDCG4EXVW01-5.OSS.PRD> References: <6a9bc6fe$30c180e6$40efea99$@com> <50472F725ECB89459EBAA5708D6C66DF019C8571@PRDCG4EXVW01-5.OSS.PRD> Message-ID: Don't tell me you didn't see the name of the list when you subscribed: Naturally, All Nuts Over Guns ? Jason On Mon, Jun 6, 2011 at 12:17 PM, Mike Rae wrote: > Hi All : > > How is this an operational related discussion ? > > Perhaps it can be taken to more appropriate forum. > > thanks > Mike > > -----Original Message----- > From: Nick Olsen [mailto:nick at flhsi.com] > Sent: Monday, June 06, 2011 10:15 AM > To: Andrew Kirch; nanog at nanog.org > Subject: re: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet > access a"human right" > > I've got a 4 inch Springfield XD service model in .45ACP, I actually > prefer > the .40 round. Its a bit better at inducing Hydrostatic shock just > because > of its velocity:energy ratio. > The handgun just to get me to the bigger guns :D > > -Nick Olsen > > ---------------------------------------- > From: "Andrew Kirch" > Sent: Monday, June 06, 2011 11:42 AM > To: nanog at nanog.org > Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a > > "human right" > > nothing like 40 short and wimpy! Might I interest you in a 45? :) > > On 6/6/2011 11:37 AM, Nick Olsen wrote: > > Don't leave the house without my Glock 23 on my side. Truck always has > a > > > loaded 12ga in it. In the house, I've got a handful of pistols and my > > SR-556 (AR-15) in the "Guns and servers" closet. > > I've had people call me Paranoid more then once. My stance is "Better > to > > > have it and not need it, Then need it and not have it." > > By banning guns from a community, Your only taking them out of the > hands > of > > law abiding citizens. Not like most criminals get guns via legal > channels > > > in the first place. > > > > -Nick Olsen > > > > ---------------------------------------- > > From: "Daniel Seagraves" > > Sent: Monday, June 06, 2011 10:34 AM > > To: nanog at nanog.org > > Subject: Re: (OT) Firearms Was: UN declares Internet access a "human > > right" > > > > On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > > > >> Nice try, but the human right you just made a case for is "the right > to > > > rid > >> yourself of criminals and despots". A "fundamental right" for > citizens > > > to have > >> firearms does *not* automatically follow. Yes, despots usually need > to > > > be > >> removed by force. What Ghandi showed was that the force didn't have > to > > > be > >> military - there are other types of force that work well too... > > I believe that as a law-abiding citizen, I should have the right to be > at > > > least as well-armed as the average criminal. If the average criminal > has > > > access to firearms, then I should have that option as well. I should > not > be > > forced into a disadvantage against criminals by virtue of my > compliance > > with the law. Once law enforcement is effective enough to prevent the > > average criminal from having access to firearms, then the law-abiding > > population can be compelled to disarm. This stance can result in an > > escalation scenario in which criminals strive to remain better-armed > than > > > their intended victims, but the job of law enforcement is to prevent > them > > > from being successful. > > > > At present, the average criminal in my area does not have firearms, > and > so > > I do not own one. Gun crime is on the increase, however, so this > situation > > may change. > > > > > > > > From daniel.unam.ipv6 at gmail.com Mon Jun 6 11:46:19 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Mon, 6 Jun 2011 11:46:19 -0500 Subject: UN declares Internet access a "human right" Message-ID: Internet is a big set of tools just bundled in another big one. And just like another tool, we can use it for "good things and bad things". I think this UN declaration must invite us to think over how adecuate or inadecuate is the way that we use the Internet, as so as individuals and so as society. Tools aren't toys -- *Daniel Espejel P?rez * From fsck100 at gmail.com Mon Jun 6 11:47:27 2011 From: fsck100 at gmail.com (Arthur Clark) Date: Mon, 6 Jun 2011 12:47:27 -0400 Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a"human right" In-Reply-To: <50472F725ECB89459EBAA5708D6C66DF019C8571@PRDCG4EXVW01-5.OSS.PRD> References: <6a9bc6fe$30c180e6$40efea99$@com> <50472F725ECB89459EBAA5708D6C66DF019C8571@PRDCG4EXVW01-5.OSS.PRD> Message-ID: I agree. I am a gun owner (Glock model 19, Remington semi-auto 12 ga., ...) and staunch supporter of 2nd Amendment rights, but this is not the place to have this discussion. To some, it will be spam messages, and to others, whose opinions should be respected, this discussion will be very irritating and offensive. This is one of many political issues upon which very smart, well informed people can disagree vehemently. On Mon, Jun 6, 2011 at 12:17 PM, Mike Rae wrote: > Hi All : > > How is this an operational related discussion ? > > Perhaps it can be taken to more appropriate forum. > > thanks > Mike > > -----Original Message----- > From: Nick Olsen [mailto:nick at flhsi.com] > Sent: Monday, June 06, 2011 10:15 AM > To: Andrew Kirch; nanog at nanog.org > Subject: re: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet > access a"human right" > > I've got a 4 inch Springfield XD service model in .45ACP, I actually > prefer > the .40 round. Its a bit better at inducing Hydrostatic shock just > because > of its velocity:energy ratio. > The handgun just to get me to the bigger guns :D > > -Nick Olsen > > ---------------------------------------- > From: "Andrew Kirch" > Sent: Monday, June 06, 2011 11:42 AM > To: nanog at nanog.org > Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a > > "human right" > > nothing like 40 short and wimpy! Might I interest you in a 45? :) > > On 6/6/2011 11:37 AM, Nick Olsen wrote: > > Don't leave the house without my Glock 23 on my side. Truck always has > a > > > loaded 12ga in it. In the house, I've got a handful of pistols and my > > SR-556 (AR-15) in the "Guns and servers" closet. > > I've had people call me Paranoid more then once. My stance is "Better > to > > > have it and not need it, Then need it and not have it." > > By banning guns from a community, Your only taking them out of the > hands > of > > law abiding citizens. Not like most criminals get guns via legal > channels > > > in the first place. > > > > -Nick Olsen > > > > ---------------------------------------- > > From: "Daniel Seagraves" > > Sent: Monday, June 06, 2011 10:34 AM > > To: nanog at nanog.org > > Subject: Re: (OT) Firearms Was: UN declares Internet access a "human > > right" > > > > On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > > > >> Nice try, but the human right you just made a case for is "the right > to > > > rid > >> yourself of criminals and despots". A "fundamental right" for > citizens > > > to have > >> firearms does *not* automatically follow. Yes, despots usually need > to > > > be > >> removed by force. What Ghandi showed was that the force didn't have > to > > > be > >> military - there are other types of force that work well too... > > I believe that as a law-abiding citizen, I should have the right to be > at > > > least as well-armed as the average criminal. If the average criminal > has > > > access to firearms, then I should have that option as well. I should > not > be > > forced into a disadvantage against criminals by virtue of my > compliance > > with the law. Once law enforcement is effective enough to prevent the > > average criminal from having access to firearms, then the law-abiding > > population can be compelled to disarm. This stance can result in an > > escalation scenario in which criminals strive to remain better-armed > than > > > their intended victims, but the job of law enforcement is to prevent > them > > > from being successful. > > > > At present, the average criminal in my area does not have firearms, > and > so > > I do not own one. Gun crime is on the increase, however, so this > situation > > may change. > > > > > > > > From owen at delong.com Mon Jun 6 12:04:23 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2011 10:04:23 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <20110606072026.27ADF105C925@drugs.dv.isc.org> References: <20110606021449.402A2105A596@drugs.dv.isc.org> <20110606072026.27ADF105C925@drugs.dv.isc.org> Message-ID: <17B51766-80B7-4D5E-9F5F-EC41586C3E7B@delong.com> On Jun 6, 2011, at 12:20 AM, Mark Andrews wrote: > > In message , Owen DeLong writes: >>> >>> It's how you handle the exceptions. Home users have port 25 off >>> by default but can still get it turned on. Most home users don't >>> need a public IP address as they are not running stuff that requires >>> it however some do so planning to handle the exceptions as efficiently >>> as possible is a good thing to do. >> >> I disagree. I look forward to a day when all home users by default >> have a public IPv6 address for each of their machines and hopefully >> enough to support multiple subnets within the home. > > need == something they currently do will break without it when LSN is > deployed for IPv4 and there is not a suitable workaround. > We have different definitions of need. I would argue that someone needs their sight. I don't know of any blind people who, given the opportunity, would consider sight unnecessary. I don't know of any sighted people who would consider the loss of their sight an acceptable outcome given any choice in the matter. The fact that most of the internet is currently disabled (behind NAT) does not mean that they do not need complete internet access. The fact that most people do not realize they are disabled is an unfortunate consequence of the nature of their disability, not a status quo that we should seek to preserve. > I'm all for customers getting public IPv6 addresses. Keeping IPv4 > running until IPv6 is ubiquitous with minimal breakage is the > challenge. > Yep... And a challenge of questionable and dubious benefit and success as well. I would argue that it is better to put that amount of resources behind making IPv6 more ubiquitous rather than diverting them to hackery aimed at preserving the status quo. >> Until then, IPv4 service without at least one public IP is degraded >> at best compared to what most people consider normal residential >> internet access today (which, frankly, is degraded at best compared >> to what I consider normal internet access). >> >>> I've got two applications that won't work behind a LSN. A sip phone >>> and a 6in4 tunnel however I'm not typical. >> >> You're not that atypical either, at least compared to US users. The >> following very common applications are known to have problems >> with LSN: >> Playstation Network >> X-Box Live >> AIM/iChat/FaceTime >> SIP/Vonage/other VoIP services >> The HTTPs Server on TiVO boxes >> Peer to Peer (torrent, etc.) >> >> Other less common applications also have problems: >> HTTP servers >> SMTP servers >> Back to my Mac >> VNC >> Tunnels > > So you take these things that are known to break as exceptions to > being behind a LSN and when there is a workable alternative you > remove it from the exception list with a desription of the work > around. > My point is that I don't know very many US internet users that don't use at least one of the above on a regular basis, so, you've now said that everyone should get an exception until there is a workable alternative. Most of these things will likely never have workable alternatives without significant development efforts and it's questionable how effective said alternatives can be even then. > e.g. SMTP servers don't require a public IPv4 address. STARTTLS > with authenticated TURN to a external MX will work. Similarly a > external dual stack MX + IPv6 support will work. The ISP could > supply that external MX. That implies an unacceptable trust model for users that don't have their own external TURN host. If everyone has a TURN host, then, you have only increased the required number of public addresses. One reason I run my own SMTP server is because I don't want to trust my ISP with access to cleartext versions of all of my email. Owen From owen at delong.com Mon Jun 6 12:08:21 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2011 10:08:21 -0700 Subject: Protocol-41 is not the only tunneling protocol (Re: Microsoft's participation in World IPv6 day) In-Reply-To: <4DEC959D.1080106@mompl.net> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DEC959D.1080106@mompl.net> Message-ID: <062112BE-46F9-4208-87B1-949CABB9B034@delong.com> On Jun 6, 2011, at 1:53 AM, Jeroen van Aart wrote: > Owen DeLong wrote: >> FIrst I've heard of such a thing. The original organizers of W6D have zero >> motivation to try such a thing and I can't imagine why they would even >> consider it for more than a picosecond. > > It'd be a great way to get a point across. ;-) > No, it really wouldn't. What it would be, instead, would be an event with little or no participation except people who are already very IPv6 aware and committed. The goal here is to help bring IPv6 awareness to a larger group and demonstrate that it can be deployed without significant damage to the existing infrastructure. Owen From owen at delong.com Mon Jun 6 12:12:17 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2011 10:12:17 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <20110606125556.GB12144@hiwaay.net> References: <20110606021449.402A2105A596@drugs.dv.isc.org> <20110606125556.GB12144@hiwaay.net> Message-ID: <93BF60B1-A5D1-4E46-9468-21C526CA56C8@delong.com> On Jun 6, 2011, at 5:55 AM, Chris Adams wrote: > Once upon a time, Owen DeLong said: >> You're not that atypical either, at least compared to US users. The >> following very common applications are known to have problems >> with LSN: >> The HTTPs Server on TiVO boxes > > I'm curious: how does this have any problem with any particular NAT > implementation? The TiVo HTTPS server is only intended to be accessed > from the local LAN, so what happens outside your house (e.g. LSN) > shouldn't matter. I disagree. It is allowed to be accessed anywhere from within your household. A household is defined as the members who live there regardless of where in the world they are at any particular time. Since I spend a great deal of time traveling, I routinely download shows from my TiVO over the internet using the https server on the TiVO box. Fortunately, my TiVO boxes have public IPv4 addresses and this is not an issue. I have confirmed with legal counsel and with TiVO that my interpretation of the term household is valid within the meaning of their license agreement. Owen From owen at delong.com Mon Jun 6 12:21:35 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2011 10:21:35 -0700 Subject: (OT) Firearms Was: UN declares Internet access a "human right" In-Reply-To: <51A5D7AA-F758-4AD8-97F6-CB0F46490858@humancapitaldev.com> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <4DEC5ECB.6080407@trelane.net> <170007.1307367704@turing-police.cc.vt.edu> <51A5D7AA-F758-4AD8-97F6-CB0F46490858@humancapitaldev.com> Message-ID: <61366C3D-B977-4563-8246-F21675B131BC@delong.com> On Jun 6, 2011, at 7:31 AM, Daniel Seagraves wrote: > > On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > >> Nice try, but the human right you just made a case for is "the right to rid >> yourself of criminals and despots". A "fundamental right" for citizens to have >> firearms does *not* automatically follow. Yes, despots usually need to be >> removed by force. What Ghandi showed was that the force didn't have to be >> military - there are other types of force that work well too... > > I believe that as a law-abiding citizen, I should have the right to be at least as well-armed as the average criminal. If the average criminal has access to firearms, then I should have that option as well. I should not be forced into a disadvantage against criminals by virtue of my compliance with the law. Once law enforcement is effective enough to prevent the average criminal from having access to firearms, then the law-abiding population can be compelled to disarm. This stance can result in an escalation scenario in which criminals strive to remain better-armed than their intended victims, but the job of law enforcement is to prevent them from being successful. > I take it a step further. I believe that in order to preserve the ability of the people to defend themselves from the possibility of tyranny, the people must be allowed to possess any level of hardware allowed to the government. While your statement above sounds wonderfully utopian, the reality is that unless the citizens can take up arms against the government, the government can, over time, become criminal. A disarmed populace has no ability to protect itself from such a government. > At present, the average criminal in my area does not have firearms, and so I do not own one. Gun crime is on the increase, however, so this situation may change. > In my area, most of the gun murders are committed by police officers. I live in San Jose, California. Owen From mikea at mikea.ath.cx Mon Jun 6 12:31:50 2011 From: mikea at mikea.ath.cx (mikea) Date: Mon, 6 Jun 2011 12:31:50 -0500 Subject: (OT) Firearms Was: UN declares Internet access a "human right" In-Reply-To: <61366C3D-B977-4563-8246-F21675B131BC@delong.com> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <4DEC5ECB.6080407@trelane.net> <170007.1307367704@turing-police.cc.vt.edu> <51A5D7AA-F758-4AD8-97F6-CB0F46490858@humancapitaldev.com> <61366C3D-B977-4563-8246-F21675B131BC@delong.com> Message-ID: <20110606173150.GA12627@mikea.ath.cx> On Mon, Jun 06, 2011 at 10:21:35AM -0700, Owen DeLong wrote: > > On Jun 6, 2011, at 7:31 AM, Daniel Seagraves wrote: > > > > > On Jun 6, 2011, at 8:41 AM, Valdis.Kletnieks at vt.edu wrote: > > > >> Nice try, but the human right you just made a case for is "the right to rid > >> yourself of criminals and despots". A "fundamental right" for citizens to have > >> firearms does *not* automatically follow. Yes, despots usually need to be > >> removed by force. What Ghandi showed was that the force didn't have to be > >> military - there are other types of force that work well too... > > > > I believe that as a law-abiding citizen, I should have the right to be at least as well-armed as the average criminal. If the average criminal has access to firearms, then I should have that option as well. I should not be forced into a disadvantage against criminals by virtue of my compliance with the law. Once law enforcement is effective enough to prevent the average criminal from having access to firearms, then the law-abiding population can be compelled to disarm. This stance can result in an escalation scenario in which criminals strive to remain better-armed than their intended victims, but the job of law enforcement is to prevent them from being successful. > > > > I take it a step further. I believe that in order to preserve the ability of the people to defend themselves from the possibility of tyranny, the people must be allowed to possess any level of hardware allowed to the government. > > While your statement above sounds wonderfully utopian, the reality is that unless the citizens can take up arms against the government, the government can, over time, become criminal. A disarmed populace has no ability to protect itself from such a government. > > > At present, the average criminal in my area does not have firearms, and so I do not own one. Gun crime is on the increase, however, so this situation may change. > > > > In my area, most of the gun murders are committed by police officers. I live in San Jose, California. The people of the various provinces are strictly forbidden to have in their possession any swords, short swords, bows, spears, firearms, or other types of arms. The possession of unnecessary implements makes difficult the collection of taxes and dues and tends to foment uprisings. -- Toyotomi Hideyoshi, August 1588 -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From drais at icantclick.org Mon Jun 6 12:37:52 2011 From: drais at icantclick.org (david raistrick) Date: Mon, 6 Jun 2011 13:37:52 -0400 (EDT) Subject: (OT) Firearms Was: UN declares Internet access a "human right" In-Reply-To: <61366C3D-B977-4563-8246-F21675B131BC@delong.com> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <4DEC5ECB.6080407@trelane.net> <170007.1307367704@turing-police.cc.vt.edu> <51A5D7AA-F758-4AD8-97F6-CB0F46490858@humancapitaldev.com> <61366C3D-B977-4563-8246-F21675B131BC@delong.com> Message-ID: On Mon, 6 Jun 2011, Owen DeLong wrote: > While your statement above sounds wonderfully utopian, the reality is > that unless the citizens can take up arms against the government, the > government can, over time, become criminal. A disarmed populace has no > ability to protect itself from such a government. urg. obNetops anyone? not sure nanog is really the place to arm bears and bare arms.... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From rpug at linux.com Mon Jun 6 12:32:22 2011 From: rpug at linux.com (Ryan Pugatch) Date: Mon, 06 Jun 2011 13:32:22 -0400 Subject: Internap FCP Message-ID: <4DED0F26.1040600@linux.com> Hi, We are currently looking into Internap FCP as we are in the process of redoing our network infrastructure and taking on managing BGP ourselves rather than relying on blended providers. I am interested in hearing about experiences using it. Is the reporting really that good? Does it actually provide value? Or, is there something out there that is better (or should we just continue to plan to manage it ourselves?) Thanks in advance for the info. Ryan From nathan at robotics.net Mon Jun 6 13:25:43 2011 From: nathan at robotics.net (Nathan Stratton) Date: Mon, 6 Jun 2011 13:25:43 -0500 (CDT) Subject: Internap FCP In-Reply-To: <4DED0F26.1040600@linux.com> References: <4DED0F26.1040600@linux.com> Message-ID: On Mon, 6 Jun 2011, Ryan Pugatch wrote: > Hi, > > We are currently looking into Internap FCP as we are in the process of > redoing our network infrastructure and taking on managing BGP ourselves > rather than relying on blended providers. I am interested in hearing about > experiences using it. Is the reporting really that good? Does it actually > provide value? Or, is there something out there that is better (or should we > just continue to plan to manage it ourselves?) The reporting is not bad and it does an ok job. We ended up building our own because the FCP was not able to look at enough of the active flows. I believe the overall idea can provide a lot of value, it just was not the best solution for our needs. ><> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com From ryan at u13.net Mon Jun 6 11:38:37 2011 From: ryan at u13.net (ryan at u13.net) Date: Mon, 06 Jun 2011 12:38:37 -0400 Subject: Google and IPv6 =?UTF-8?Q?inverse=3F?= In-Reply-To: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> Message-ID: On Mon, 06 Jun 2011 08:19:37 +0300, Hank Nussbacher wrote: > Will Google have inverse working by June 8th? > > [hank at noc ~]$ traceroute6 ipv6.google.com > traceroute to ipv6.l.google.com (2a00:1450:8001::68) from > 2001:bf8:0:3:202:b3ff:feaf:f3fc, 30 hops max, 16 byte packets > 1 2001:bf8:0:3::1 (2001:bf8:0:3::1) 0.407 ms 221.144 ms 5.218 ms > 2 2001:bf8:0:b::1 (2001:bf8:0:b::1) 0.559 ms 0.54 ms 0.486 ms > 3 iucc-lb1.rt1.fra.de.geant2.net (2001:798:14:10aa::1d) 50.665 > ms 50.611 ms 50.567 ms > 4 google-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::e) 56.821 > ms 50.525 ms 50.486 ms > 5 2001:4860::1:0:11 (2001:4860::1:0:11) 51.266 ms 51.106 ms 51.068 ms > 6 2001:4860::1:0:4b3 (2001:4860::1:0:4b3) 58.309 ms 58.078 ms 58.442 > ms > 7 2001:4860::8:0:2db0 (2001:4860::8:0:2db0) 57.174 ms 57.339 ms > 57.195 > ms > 8 2001:4860::2:0:66f (2001:4860::2:0:66f) 72.496 ms 60.803 ms 72.381 > ms > 9 2001:4860:0:1::1b (2001:4860:0:1::1b) 68.165 ms 62.21 ms 70.3 ms > 10 2a00:1450:8001::68 (2a00:1450:8001::68) 61.21 ms 61.862 ms 61.331 > ms > In some regions Google has revere DNS for IPv6 already: Ryan-Rawdons-Work-MacBook-Pro:~ ryan$ traceroute6 ipv6.google.com traceroute6 to ipv6.l.google.com (2001:4860:800f::67) from [redacted], 64 hops max, 12 byte packets 1 [redacted] 2 2001:4870:4000:5::1 7.953 ms 8.540 ms 9.697 ms 3 2001:506:8:ffff::3 24.895 ms 26.349 ms 24.993 ms 4 2001:4860::1:0:5db 25.654 ms 32.175 ms 26.444 ms 5 2001:4860::1:0:9ff 112.931 ms 60.227 ms 56.638 ms 6 2001:4860:0:1::14f 37.783 ms 24.640 ms 34.077 ms 7 iad04s01-in-x67.1e100.net 25.574 ms 24.359 ms 24.719 ms Ryan-Rawdons-Work-MacBook-Pro:~ ryan$ They're doing it at about the same level as their IPv4 reverse DNS, that is, servers seem to have reverse DNS but intermediate hops in their infrastructure do not: Ryan-Rawdons-Work-MacBook-Pro:~ ryan$ traceroute mail.google.com traceroute: Warning: mail.google.com has multiple addresses; using 72.14.204.83 traceroute to googlemail.l.google.com (72.14.204.83), 64 hops max, 52 byte packets 1 [redacted] 2 [redacted] 3 64-129-129-49.static.twtelecom.net (64.129.129.49) 7.057 ms 7.956 ms 7.439 ms 4 dist-02-xe-0-0-0.milw.twtelecom.net (66.192.246.82) 7.082 ms 6.975 ms 8.139 ms 5 216.239.48.108 (216.239.48.108) 9.187 ms 32.129 ms 107.103 ms 6 66.249.94.46 (66.249.94.46) 10.923 ms 66.249.94.54 (66.249.94.54) 8.839 ms 12.205 ms 7 iad04s01-in-f83.1e100.net (72.14.204.83) 8.592 ms 9.672 ms 9.032 ms Ryan-Rawdons-Work-MacBook-Pro:~ ryan$ From heinrich at hstrauss.co.za Mon Jun 6 14:08:42 2011 From: heinrich at hstrauss.co.za (Heinrich Strauss) Date: Mon, 06 Jun 2011 21:08:42 +0200 Subject: Google and IPv6 inverse? In-Reply-To: References: <5.1.0.14.2.20110606080415.00c1d1e0@efes.iucc.ac.il> Message-ID: <4DED25BA.7040002@hstrauss.co.za> On 2011/06/06 18:38, ryan at u13.net wrote: > On Mon, 06 Jun 2011 08:19:37 +0300, Hank Nussbacher wrote: > >> Will Google have inverse working by June 8th? >> >> [hank at noc ~]$ traceroute6 ipv6.google.com >> traceroute to ipv6.l.google.com (2a00:1450:8001::68) from >> 2001:bf8:0:3:202:b3ff:feaf:f3fc, 30 hops max, 16 byte packets >> 1 2001:bf8:0:3::1 (2001:bf8:0:3::1) 0.407 ms 221.144 ms 5.218 ms >> 2 2001:bf8:0:b::1 (2001:bf8:0:b::1) 0.559 ms 0.54 ms 0.486 ms >> 3 iucc-lb1.rt1.fra.de.geant2.net (2001:798:14:10aa::1d) 50.665 >> ms 50.611 ms 50.567 ms >> 4 google-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::e) 56.821 >> ms 50.525 ms 50.486 ms >> 5 2001:4860::1:0:11 (2001:4860::1:0:11) 51.266 ms 51.106 ms 51.068 ms >> 6 2001:4860::1:0:4b3 (2001:4860::1:0:4b3) 58.309 ms 58.078 ms 58.442 ms >> 7 2001:4860::8:0:2db0 (2001:4860::8:0:2db0) 57.174 ms 57.339 ms 57.195 >> ms >> 8 2001:4860::2:0:66f (2001:4860::2:0:66f) 72.496 ms 60.803 ms 72.381 ms >> 9 2001:4860:0:1::1b (2001:4860:0:1::1b) 68.165 ms 62.21 ms 70.3 ms >> 10 2a00:1450:8001::68 (2a00:1450:8001::68) 61.21 ms 61.862 ms 61.331 ms From what I understand, they filter intermediate hops so that only Google internal machines see the paths. Destination hops should have reverses, though. :/ From tjc at ecs.soton.ac.uk Mon Jun 6 16:16:25 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 6 Jun 2011 22:16:25 +0100 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <586376.10713.qm@web59601.mail.ac4.yahoo.com> <6469.1307064588@turing-police.cc.vt.edu> <3DAEBC27-BA01-4436-98FE-37104C7955DA@ecs.soton.ac.uk> Message-ID: On 6 Jun 2011, at 15:30, Jason Fesler wrote: > >> I would have expected the green+azure areas in those graphs to have increased in the past half year but counter-intutitively, it appears that IPv4 only usage is increasing. > > You're assuming there's significant rollout of IPv6. Everything I've seen so far says that *starts* nowish, and more laterish this year, in any impacting way. Really, we're just just before the start of getting end user adoption to start rising. For our web presence, which has been dual-stack since 2004, we saw external IPv6 traffic rise 0.1% per year to 2010, when it 'leapt' to 1.0% and in 2011 so far the highest we've seen over any month is 1.8%, so it doubled in 2010 and is set to more than double in 2011. OK, so 2% is still small, but from tiny acorns... SMTP is still well under 1% though. Tim From marka at isc.org Mon Jun 6 16:23:24 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 07 Jun 2011 07:23:24 +1000 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: Your message of "Mon, 06 Jun 2011 07:36:45 MST." References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> Message-ID: <20110606212324.ED215105E66B@drugs.dv.isc.org> In message , Jason Fesler wr ites: > > But anyway, just consider it: a portion of the major websites go > > IPv6-only for 24 hours. What happens is that well, 99% of the populace > > can't reach them anymore, as the known ones are down, they start calling > > and thus overloading the helpdesks of their ISPs. > > Won't happen this year or next. Too much money at stake for the web > sites. Only when IPv4 is single digits or less could this be even > remotely considered. Even the 0.05% hit for a day was controverial at > $dayjob. IPv4 will never reach those figures. IPv6 isn't preferenced enough for that to happen and IPv6-only sites have methods of reaching IPv4 only sites (DS-Lite, NAT64/DNS64). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Mon Jun 6 16:36:26 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2011 14:36:26 -0700 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: <20110606212324.ED215105E66B@drugs.dv.isc.org> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> Message-ID: On Jun 6, 2011, at 2:23 PM, Mark Andrews wrote: > > In message , Jason Fesler wr > ites: >>> But anyway, just consider it: a portion of the major websites go >>> IPv6-only for 24 hours. What happens is that well, 99% of the populace >>> can't reach them anymore, as the known ones are down, they start calling >>> and thus overloading the helpdesks of their ISPs. >> >> Won't happen this year or next. Too much money at stake for the web >> sites. Only when IPv4 is single digits or less could this be even >> remotely considered. Even the 0.05% hit for a day was controverial at >> $dayjob. > > IPv4 will never reach those figures. IPv6 isn't preferenced enough for > that to happen and IPv6-only sites have methods of reaching IPv4 only > sites (DS-Lite, NAT64/DNS64). I think you'll be surprised over time. Given the tendency of the internet to nearly double in size every 2 years or so, it only takes 7 cycles (about 15 years) for the existing network to become a single-digit percentage of the future network. Owen From rucasbrown at hushmail.com Mon Jun 6 17:19:37 2011 From: rucasbrown at hushmail.com (rucasbrown at hushmail.com) Date: Mon, 06 Jun 2011 18:19:37 -0400 Subject: Why don't ISPs peer with everyone? Message-ID: <20110606221937.B362C6F437@smtp.hushmail.com> Hello, I wouldn't consider myself a network engineer, nor do I have any formal training, but why don't ISPs peer with every other ISP? It would only save EVERYONE money if they did this, no? Only issue I see is with possibly hijacked / malicious AS owners, but that's not very common to do without being caught. All the whole "don't peer with this guy" only makes your customers have worse latencies and paths to other people, making the Internet less healthy. Thanks, Rucas PS: sorry if I sent this twice; client lagged a bit. From r.hyunseog at ieee.org Mon Jun 6 17:24:46 2011 From: r.hyunseog at ieee.org (Alex Ryu) Date: Mon, 6 Jun 2011 17:24:46 -0500 Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606221937.B362C6F437@smtp.hushmail.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: Nope. It is because who pay the money, and somebody wants to earn the money because they have more control. So it is because of "money". Welcome to the world of capitalism. Alex On Mon, Jun 6, 2011 at 5:19 PM, wrote: > Hello, > > I wouldn't consider myself a network engineer, nor do I have any > formal training, but why don't ISPs peer with every other ISP? It > would only save EVERYONE money if they did this, no? Only issue I > see is with possibly hijacked / malicious AS owners, but that's not > very common to do without being caught. > > All the whole "don't peer with this guy" only makes your customers > have worse latencies and paths to other people, making the Internet > less healthy. > > Thanks, > Rucas > > PS: sorry if I sent this twice; client lagged a bit. > > > From Jay.Murphy at state.nm.us Mon Jun 6 17:26:35 2011 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 6 Jun 2011 22:26:35 +0000 Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606221937.B362C6F437@smtp.hushmail.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: <218A1779A7A0984894CBD218EFF84AC45D86BF@CEXMB003.nmes.lcl> Network utopia. ~Jay ?Engineering is about finding the sweet spot between what's solvable and what isn't." ?Good engineering demands that we understand what we?re doing and why, keep an open mind, and learn from experience.? Radia Perlman "If human beings are perceived as potentials rather than problems, as possessing strengths instead of weaknesses, as unlimited rather than dull and unresponsive, then they thrive and grow to their capabilities." ? Please consider the environment before printing e-mail -----Original Message----- From: rucasbrown at hushmail.com [mailto:rucasbrown at hushmail.com] Sent: Monday, June 06, 2011 4:20 PM To: nanog at nanog.org Subject: Why don't ISPs peer with everyone? Hello, I wouldn't consider myself a network engineer, nor do I have any formal training, but why don't ISPs peer with every other ISP? It would only save EVERYONE money if they did this, no? Only issue I see is with possibly hijacked / malicious AS owners, but that's not very common to do without being caught. All the whole "don't peer with this guy" only makes your customers have worse latencies and paths to other people, making the Internet less healthy. Thanks, Rucas PS: sorry if I sent this twice; client lagged a bit. From nathan at atlasnetworks.us Mon Jun 6 17:38:39 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 6 Jun 2011 22:38:39 +0000 Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606221937.B362C6F437@smtp.hushmail.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B484671@ex-mb-1.corp.atlasnetworks.us> > I wouldn't consider myself a network engineer, nor do I have any formal > training, but why don't ISPs peer with every other ISP? It would only save > EVERYONE money if they did this, no? Only issue I see is with possibly > hijacked / malicious AS owners, but that's not very common to do without > being caught. Some ISPs have very friendly peering policies, but some obstacles facing even the friendliest ISPs are: *Poor operator reputation or significantly different networking mindsets may make some peers undesirable *Potential peer is attempting to become a tier-1 and demands paid-peering *Potential peers do not have similar POPs or budget for transport between POPs for peering *Some ISPs do not have the ability to easily determine the destination of their traffic and which peers would be most advantageous in terms of transit reduction *Potential peer is lazy or reluctant to make changes I'm sure I'm missing a few, but I believe these are a couple significant obstacles to a more 'meshy' internet. Nathan From bmanning at vacation.karoshi.com Mon Jun 6 17:39:41 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 6 Jun 2011 22:39:41 +0000 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: <20110606223941.GA22728@vacation.karoshi.com.> its not always about money. sometimes its reputation. /bill On Mon, Jun 06, 2011 at 05:24:46PM -0500, Alex Ryu wrote: > Nope. > > It is because who pay the money, and somebody wants to earn the money > because they have more control. > So it is because of "money". > > Welcome to the world of capitalism. > > Alex > > > On Mon, Jun 6, 2011 at 5:19 PM, wrote: > > Hello, > > > > I wouldn't consider myself a network engineer, nor do I have any > > formal training, but why don't ISPs peer with every other ISP? It > > would only save EVERYONE money if they did this, no? Only issue I > > see is with possibly hijacked / malicious AS owners, but that's not > > very common to do without being caught. > > > > All the whole "don't peer with this guy" only makes your customers > > have worse latencies and paths to other people, making the Internet > > less healthy. > > > > Thanks, > > Rucas > > > > PS: sorry if I sent this twice; client lagged a bit. > > > > > > From george.herbert at gmail.com Mon Jun 6 17:51:45 2011 From: george.herbert at gmail.com (George Herbert) Date: Mon, 6 Jun 2011 15:51:45 -0700 Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606223941.GA22728@vacation.karoshi.com.> References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110606223941.GA22728@vacation.karoshi.com.> Message-ID: On Mon, Jun 6, 2011 at 3:39 PM, wrote: > > its not always about money. ?sometimes its reputation. And also reasonably hygene, and both individual and community self defense. There are some less competent network operators out there (and even good ones have bad days). And some of the people out there speaking BGP want to do really malign things with internet traffic, like hijack and snoop, inject spam, sometimes injecting spam by hijacking someone else's net temporarily, create malware sites, hack others, etc. -- -george william herbert george.herbert at gmail.com From khelms at ispalliance.net Mon Jun 6 17:55:24 2011 From: khelms at ispalliance.net (Scott Helms) Date: Mon, 06 Jun 2011 18:55:24 -0400 Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606221937.B362C6F437@smtp.hushmail.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: <4DED5ADC.9000308@ispalliance.net> I'll answer with some questions: Where should they peer? Who should/will pay for the routers and aggregation ports? How about the power, racks, and building space? Who should/will pay for the network engineers to do the configuration for the peering? In short, peering isn't free for anyone. It _can_ be efficient in some cases but in others its damn pita and you never really know which one a given case will turn into. (its not always a problem of technical competence) On 6/6/2011 6:19 PM, rucasbrown at hushmail.com wrote: > Hello, > > I wouldn't consider myself a network engineer, nor do I have any > formal training, but why don't ISPs peer with every other ISP? It > would only save EVERYONE money if they did this, no? Only issue I > see is with possibly hijacked / malicious AS owners, but that's not > very common to do without being caught. > > All the whole "don't peer with this guy" only makes your customers > have worse latencies and paths to other people, making the Internet > less healthy. > > Thanks, > Rucas > > PS: sorry if I sent this twice; client lagged a bit. > > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bonomi at mail.r-bonomi.com Mon Jun 6 18:03:00 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 6 Jun 2011 18:03:00 -0500 (CDT) Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: <201106062303.p56N30CE035523@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Mon Jun 6 17:20:16 2011 > Date: Mon, 06 Jun 2011 18:19:37 -0400 > To: nanog at nanog.org > Subject: Why don't ISPs peer with everyone? > From: rucasbrown at hushmail.com > > Hello, > > I wouldn't consider myself a network engineer, nor do I have any > formal training, but why don't ISPs peer with every other ISP? It > would only save EVERYONE money if they did this, no? Only issue I > see is with possibly hijacked / malicious AS owners, but that's not > very common to do without being caught. The answer to _every_ question that starts of "why don't they..." is "money". Who pays for the circuits to establish a 'peering connection' with an ISP half-the world away? How much does traffic does "Joes Bait Shop and ISP" in Painted Privvy, Nebraska have with a community ISP in Honshu, JP?" From gbonser at seven.com Mon Jun 6 18:35:11 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 6 Jun 2011 16:35:11 -0700 Subject: Why don't ISPs peer with everyone? In-Reply-To: <201106062303.p56N30CE035523@mail.r-bonomi.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> <201106062303.p56N30CE035523@mail.r-bonomi.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3680@RWC-EX1.corp.seven.com> > > > > Hello, > > > > I wouldn't consider myself a network engineer, nor do I have any > > formal training, but why don't ISPs peer with every other ISP? It > > would only save EVERYONE money if they did this, no? Only issue I > > see is with possibly hijacked / malicious AS owners, but that's not > > very common to do without being caught. > > The answer to _every_ question that starts of "why don't they..." is > "money". > > Who pays for the circuits to establish a 'peering connection' with an > ISP half-the world away? How much does traffic does "Joes Bait Shop > and ISP" in Painted Privvy, Nebraska have with a community ISP in > Honshu, JP?" > > There are a lot of considerations. How many peering sessions can your hardware support? How many peering locations are you going to need? What will the internal network to tie all those together look like. Will you now need to upgrade your core? Will adding a new peer place another peering agreement at risk by changing the traffic balance? So even if the peering itself is "free", the infrastructure required to support large scale peering at multiple locations can be quite expensive. Are you going to want to haul traffic from New Jersey to California to hand it to a peer who hauls the traffic all the way back to New Jersey again? Does your router in Kansas City want to hand the traffic to the peer in New York or in Seattle? For a small regional network, peering can be easy. For a large network that spans a continent, it can be pretty hard. From mpetach at netflight.com Mon Jun 6 18:41:36 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 6 Jun 2011 16:41:36 -0700 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> Message-ID: On Mon, Jun 6, 2011 at 2:36 PM, Owen DeLong wrote: > On Jun 6, 2011, at 2:23 PM, Mark Andrews wrote: ... >> IPv4 will never reach those figures. ?IPv6 isn't preferenced enough for >> that to happen and IPv6-only sites have methods of reaching IPv4 only >> sites (DS-Lite, NAT64/DNS64). > > I think you'll be surprised over time. Given the tendency of the internet > to nearly double in size every 2 years or so, it only takes 7 cycles (about > 15 years) for the existing network to become a single-digit percentage > of the future network. > > Owen Hm. With roughly 1B people on the internet today[0], 7 cycles of doubling would mean that in 15 years, we'd have 128B people on the internet? I strongly suspect the historical growth curve will *not* continue at that pace. Matt [0] http://www.internetworldstats.com/stats.htm [1] [1] I am strongly suspicious of their data, so my estimate lops their number in half. If you believe their data, in seven doublings, we'll be at 256B in 15 years. I find that number to be equally preposterous. From jtk at cymru.com Mon Jun 6 18:45:35 2011 From: jtk at cymru.com (John Kristoff) Date: Mon, 6 Jun 2011 18:45:35 -0500 Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606221937.B362C6F437@smtp.hushmail.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: <20110606184535.3bd690f3@t61p> On Mon, 06 Jun 2011 18:19:37 -0400 rucasbrown at hushmail.com wrote: > I wouldn't consider myself a network engineer, nor do I have any > formal training, but why don't ISPs peer with every other ISP? It It depends on the ISP, but there are a variety of reasons for not wanting to peer with any potential peer or in this case "every other ISP". Also let's distinguish between paid-peering and settlement-free peering. I think we can agree that if there were only paid-peering, then a complete mesh would be not only technologically impractical, but also economically as well. Plug the terms "economics", "internet" and "peering" into your favorite search engine and you should come up with some relevant reading material. > Only issue I > see is with possibly hijacked / malicious AS owners, but that's not > very common to do without being caught. Can you explain why this is a bigger issue in your scenario? > All the whole "don't peer with this guy" only makes your customers > have worse latencies and paths to other people, making the Internet > less healthy. Certainly most ISPs care about that to some degree, but to get to the heart of the matter, consider the mindset of any profit-motivated ISP, especially where one is "larger" in some sense of the word than the other who wants to peer. If I'm the larger ISP, and you're the smaller ISP coming to me to peer settlement-free, why should I peer with you? So our customers can get better performance to each other? Why don't your customers just connect to me instead? What do I lose if we don't peer? If you're small, probably not too much. John From jerome at ceriz.fr Mon Jun 6 18:45:38 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 7 Jun 2011 01:45:38 +0200 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> Message-ID: 2011/6/6 Owen DeLong : > I think you'll be surprised over time. Given the tendency of the internet > to nearly double in size every 2 years or so, it only takes 7 cycles (about > 15 years) for the existing network to become a single-digit percentage > of the future network. > > Owen Internet' growth is measured by bandwidth rather than number of active operators or prefixes. Maxing a router's backplane or upgrading it won't change the network to a whole new thing, as most operators will just keep the old ways over and over. Considering the amount of trafic will double in the next 24 months or so, wich seems a reasonable assumption, I think IPv6 trafic has some more potential growth to come than v4, but even the later will still grow. Keeping that in mind makes me expect a very progressive curve for the significance of IPv6 in the overall bandwidth usage stats, unless eyeballs networks starts to make a major move towards IPv6 effective deployments. But honestly, while working mostly for eyballs networks, I can assure you even the largest ain't close to ready for such a move ;) -- J?r?me Nicolle From streiner at cluebyfour.org Mon Jun 6 14:53:54 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 6 Jun 2011 15:53:54 -0400 (EDT) Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606221937.B362C6F437@smtp.hushmail.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: On Mon, 6 Jun 2011, rucasbrown at hushmail.com wrote: > All the whole "don't peer with this guy" only makes your customers > have worse latencies and paths to other people, making the Internet > less healthy. Not necessarily. Peering with an ISP who wants to take the traffic between your network and theirs through a saturated pipe, an overloaded router, or across an MPLS pipe with 13 underlying hops (each of which could be a choke point themselves) will not make your end-to-end latencies any better. As others have mentioned, some ISPs do have friendly peering policies. This is particularly true for ISPs that are co-located at the same IXP, because much of the opex is already baked into the ISP's relationship with the IXP. The reason most of the larger ISPs, particularly those who live in the DFZ, have peering policies (especially for settlement-free peering) that could be construed as less friendly to smaller networks is because those guys want to sell you transit, rather than let you peer for free, or for less than a the full transit rate. It doesn't make financial sense for them to exchange bits with you for free, when they can make money off of those same bits if you buy transit instead. jms From marka at isc.org Mon Jun 6 18:49:14 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 07 Jun 2011 09:49:14 +1000 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: Your message of "Mon, 06 Jun 2011 14:36:26 MST." References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> Message-ID: <20110606234914.B1CFF106068A@drugs.dv.isc.org> In message , Owen DeLong write s: > > On Jun 6, 2011, at 2:23 PM, Mark Andrews wrote: > > >=20 > > In message , Jason = > Fesler wr > > ites: > >>> But anyway, just consider it: a portion of the major websites go > >>> IPv6-only for 24 hours. What happens is that well, 99% of the = > populace > >>> can't reach them anymore, as the known ones are down, they start = > calling > >>> and thus overloading the helpdesks of their ISPs. > >>=20 > >> Won't happen this year or next. Too much money at stake for the web=20= > > >> sites. Only when IPv4 is single digits or less could this be even=20 > >> remotely considered. Even the 0.05% hit for a day was controverial = > at=20 > >> $dayjob. > >=20 > > IPv4 will never reach those figures. IPv6 isn't preferenced enough = > for > > that to happen and IPv6-only sites have methods of reaching IPv4 only > > sites (DS-Lite, NAT64/DNS64). > > I think you'll be surprised over time. Given the tendency of the = > internet > to nearly double in size every 2 years or so, it only takes 7 cycles = > (about > 15 years) for the existing network to become a single-digit percentage > of the future network. > > Owen And without there being a strong IPv6 bias in the clients they will continue to use IPv4/IPv6 on a 50/50 basis. I would be quite happy to be proven wrong and only time will tell. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mysidia at gmail.com Mon Jun 6 18:51:06 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 6 Jun 2011 18:51:06 -0500 Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606221937.B362C6F437@smtp.hushmail.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: On Mon, Jun 6, 2011 at 5:19 PM, wrote: > I wouldn't consider myself a network engineer, nor do I have any > formal training, but why don't ISPs peer with every other ISP? It > would only save EVERYONE money if they did this, no? Only issue I ISPs are often concerned about: Cost of Peering, and Loss of Revenue due to peering -- ISPs usually like to charge for internet services they provide. Free peering is only beneficial to both sides of a peering relationship when it does reduce costs more than it reduces expected revenue. (a) Costs of peering; both in terms of administrative overhead, ports, circuits, cabinet space, and system resources on existing equipment. Creating a presence in an exchange or building media connections from one ISP to another is not free, ISPs don't naturally all have equipment within range of a free patch cable. Every peering connection a router deals with requires some computing power, some memory, table entries on the router, and, depending on the exchange, possibly additional physical connections. And of course, there are man hours to maintain peering sessions. ISPs are more likely to peer when cost is low relative to advantages after all considered. (B) Loss of revenue due to peering. An extreme example is a very large ISP peering with a small ISP, to allow the small ISP to reach large ISP's customers. The large ISP loses revenue, if they provide the peering for free, since it would mean the small ISP is not paying for that transit. Example: If Level3 peered with anyone who wanted, for free... that would mean noone would have to buy transit from Level3 to send traffic to Level3 customers. There is an analogous situation for ISPs of all sizes though. And if they do agree to peer, there is usually some stipulation about the ratio of traffic beng sent versus received. ISPs do not want to peer for free, if there is a chance their partner would need to buy services from them directly, or indirectly (without the peering), that exceed the benefit/cost reduction of peering. And once a customer, never a peer. -- -JH From vixie at isc.org Mon Jun 6 18:56:32 2011 From: vixie at isc.org (Paul Vixie) Date: Mon, 06 Jun 2011 23:56:32 +0000 Subject: v6 proof of life Message-ID: <63146.1307404592@nsa.vix.com> it's been a while since i looked at the query stream still hitting {rbl,dul}.maps.vix.com. this was the world's first RBL but it was renamed from maps.vix.com to mail-abuse.org back in Y2K or so. i have not sent anything but NXDOMAIN in response to one of these queries for at least ten years, yet the queries just keep coming. here's a histogram of source-ip. feel free to remove yourself :-). it's just a half hour sample. i'll put this up on a web page soon. importantly and happily, there's a great deal of IPv6 happening here. re: 524 200.59.134.164 492 2001:288:8201:1::14 455 209.177.144.50 418 193.124.83.73 392 140.144.32.205 360 143.54.204.171 355 208.76.170.121 282 2403:2c00:1::5 262 2001:1a80:103:5::2 225 2001:288:8201:1::2 195 2604:3500::ad:1 186 2001:288:8201:1::10 174 209.157.254.10 167 2001:b30:1:100::100 158 12.47.198.68 142 2001:288:0:2::60 125 2002:d58e:8901::d58e:8901 118 77.72.136.2 115 140.118.31.99 113 66.240.198.100 102 2001:9b0:1:601:230:48ff:fe8a:c7f4 100 2001:888:0:24:194:109:20:107 99 212.73.100.132 92 2405:d000:0:100::214 86 202.177.26.107 83 2405:d000:0:100::228 82 195.101.253.253 77 210.175.244.210 77 2001:558:1014:f:69:252:96:24 76 64.168.228.129 76 2001:2c0:11:1::c02 71 2001:b30:1::190 68 2001:558:1014:f:68:87:76:185 68 2001:4dd0:100:1020:53:2:0:1 67 2001:558:1014:f:69:252:96:22 67 2001:558:1014:f:68:87:76:189 63 2001:558:1014:f:69:252:96:25 57 2607:f758:6000:13::e4 56 2001:558:1014:f:68:87:76:181 55 212.234.229.242 52 2607:f758:e000:13::e4 51 2607:fdb8:0:b:2::2 51 208.188.98.249 51 2001:558:1014:f:68:87:76:190 49 66.192.109.211 45 2001:558:1014:f:69:252:96:23 44 2001:db8::230:48ff:fef2:f340 44 2001:db8::230:48ff:fef0:1de 42 213.171.61.117 41 201.116.43.232 40 2607:fdb8:0:b:1::2 40 2001:470:1f0a:c1b::2 40 190.82.65.243 38 190.169.30.2 36 2605:d400:0:27::3 35 2001:d10:2:3::1:2 31 2605:d400:0:27::7 30 220.110.24.250 28 84.55.220.139 28 2a00:1db0:16:2::347:2 23 2607:f2e0::1:3:2 23 2001:15c8:8::2:1 22 218.44.167.26 22 2001:6c8:2:100::53 22 2001:6b0:1::201 21 193.169.45.5 20 2607:f470:1003::3:3 19 2a01:8c00:ff60:2:230:48ff:fe85:d47e 19 221.133.36.229 19 213.178.66.2 19 202.169.240.10 19 2001:c28:1:1:dad3:85ff:fee1:30ec 19 163.29.248.1 18 195.58.224.34 17 2a02:460:4:0:250:56ff:fea7:23d 17 221.245.76.99 17 2001:c28:1:1:dad3:85ff:fee0:4f68 16 2001:630:200:8120::d:1 15 2a01:1b8::1 15 218.44.236.98 15 2001:ad0:: 15 2001:41d8:1:8028::54 14 2a00:1b50::2:2 14 192.149.202.9 13 200.74.222.140 12 98.130.2.250 12 2a00:1eb8:0:1::1 12 2600:c00:0:1::301 12 2001:c28:1:1:dad3:85ff:fee0:3f20 12 2001:380:124::4 12 2001:218:4c0:1:2e0:81ff:fe55:a018 12 2001:12d0::3 12 195.228.156.150 12 194.42.134.132 11 66.111.66.240 11 2607:f010:3fe:100:0:ff:fe00:1 11 211.25.195.236 11 210.162.229.210 11 2001:c28:1:1:dad3:85ff:fee0:be80 11 2001:a10:1:ffff::2:c918 From jerome at ceriz.fr Mon Jun 6 18:56:27 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 7 Jun 2011 01:56:27 +0200 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> Message-ID: 2011/6/7 Matthew Petach : > Hm. ?With roughly 1B people on the internet today[0], 7 cycles of > doubling would mean that in 15 years, we'd have 128B people > on the internet? > > I strongly suspect the historical growth curve will *not* continue > at that pace. Well, todays Internet is made of 1B pairs of eyeballs with a roughly average of 120kbps each. Todays average in France is closer to 180kbps, it was closer to 100kbps two years ago (the 3-strikes law side-effect made individual bw consumption spikes with the emergence of many streaming services, far more BW-hungry than soft P2P protocols like eMule), whilst operators gained 8% of annual organic growth (18 to 21M subscribers). That's a bit more than 200% in 2 years. Before that, the avergae bw consumtion was relativelly stable over the last 6 years or so, only the number of residential access subscribers grew. Over the years to come, we'll still see some regions with a growing number of individual accesses while the well-connected regions will see their BW consumption grow even larger with new services. Isn't it what FTTH deployments all around the world are all about ? -- J?r?me Nicolle From jerome at ceriz.fr Mon Jun 6 19:08:01 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 7 Jun 2011 02:08:01 +0200 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: 2011/6/7 Jimmy Hess : > (a) Costs of peering; ?both in terms of administrative overhead, > ports, circuits, cabinet space,... The cost of peering on an IXP is roughly the same as setup fees for a new transit, and a BGP session to an IXP route server is not far from what will a full view cost in RAM and CPU on your edges. > (B) Loss of revenue due to peering. ?An extreme example is a very > large ISP peering > with a small ISP, to allow the small ISP to reach large ISP's customers. > The large ISP loses revenue, if they provide the peering for free, > since it would mean > the small ISP is not paying for that transit. Large ISPs do buy transit too. On a financial perspective, it can be considered as "outsourcing the peering function", with a paid SLA for this connectivity... > And once a customer, never a peer. Never peer with one of your peer's customer is one basic rule of peering agreements between tier-2 and 1 networks. It's a shame financial pragmatism makes the Internet less "meshy", and thus more fragile... -- J?r?me Nicolle From jmamodio at gmail.com Mon Jun 6 19:27:38 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 6 Jun 2011 19:27:38 -0500 Subject: UN declares Internet access a "human right" In-Reply-To: <4DEC13C1.1050800@linuxbox.org> References: <4DEC13C1.1050800@linuxbox.org> Message-ID: > http://m.wired.com/threatlevel/2011/06/internet-a-human-right Looks like the UN does not have anything more interesting or important to do, or how to waste time and money. What happened with the other rights? yada yada and a signature in a paper does not mean much. -J From jmamodio at gmail.com Mon Jun 6 19:29:22 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 6 Jun 2011 19:29:22 -0500 Subject: UN declares Internet access a "human right" In-Reply-To: References: <4DEC13C1.1050800@linuxbox.org> Message-ID: On a second thought, does this mean that you if get arrested after reading the Miranda thing you get free WiFi ? -J From jon at smugmug.com Mon Jun 6 19:33:18 2011 From: jon at smugmug.com (Jon Heise) Date: Mon, 6 Jun 2011 17:33:18 -0700 Subject: automated router config back up Message-ID: Aside from rancid, what methods do people have for doing automated backups and diffing of router configs ? - Jon Heise From jerome at ceriz.fr Mon Jun 6 19:36:05 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 7 Jun 2011 02:36:05 +0200 Subject: UN declares Internet access a "human right" In-Reply-To: References: <4DEC13C1.1050800@linuxbox.org> Message-ID: 2011/6/7 Jorge Amodio : >> http://m.wired.com/threatlevel/2011/06/internet-a-human-right > > Looks like the UN does not have anything more interesting or important > to do, or how to waste time and money. > > What happened with the other rights? ? yada yada and a signature in a > paper does not mean much. Consider two alternatives : - Finance guns, soldier training, refugee camps, humanitarian ground help and political meetings and treaties to make a revolution happens in a (more or less controled) bloodshed OR - Take a strong position to preserve freedom of speech and wider use of the Internet as a mean to let the people self-organize in a political process, thus avoiding violent revolutions What do you think is best ? -- J?r?me Nicolle From jerome at ceriz.fr Mon Jun 6 19:38:37 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 7 Jun 2011 02:38:37 +0200 Subject: automated router config back up In-Reply-To: References: Message-ID: http://redmine.nocproject.org/projects/noc/wiki 2011/6/7 Jon Heise : > Aside from rancid, what methods do people have for doing automated backups > and diffing of router configs ? > > - Jon Heise > -- J?r?me Nicolle 06 19 31 27 14 From mysidia at gmail.com Mon Jun 6 20:09:06 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 6 Jun 2011 20:09:06 -0500 Subject: automated router config back up In-Reply-To: References: Message-ID: On Mon, Jun 6, 2011 at 7:33 PM, Jon Heise wrote: > Aside from rancid, what methods do people have for doing automated backups > and diffing of router configs ? There are some commercial config management products that provide similar.. Use search engines with keywords such as router / network configuration and auditing tools. Configuration and change management is a common problem, and CM auditing requires tools for pulling, archiving, and comparing network device configurations to detect changes and anomolies, so there are _plenty_ of options. Some routers provide options for remote SCP or FTP access, then it's just a matter of using your favorite mass download tool. Check your device documentation. A popular router brand also recently had an archive function added not too long ago. That lets you auto-scp new configs with something simple like.... ! archive path scp://blahblah:blahblahblahblah at configbackup.my.example.com write-memory maximum 14 time-period 1440 log config record rc logging enable hidekeys notify syslog contenttype plaintext Regards, -- -JH > - Jon Heise From aaron at heyaaron.com Mon Jun 6 20:29:50 2011 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Mon, 6 Jun 2011 18:29:50 -0700 Subject: automated router config back up In-Reply-To: References: Message-ID: On Mon, Jun 6, 2011 at 18:09, Jimmy Hess wrote: > On Mon, Jun 6, 2011 at 7:33 PM, Jon Heise wrote: > > Aside from rancid, what methods do people have for doing automated > backups > > and diffing of router configs ? > > A popular router brand also recently had an archive function added > not too long ago. > That lets you auto-scp new configs with something simple like.... > > ! > archive > path scp://blahblah:blahblahblahblah at configbackup.my.example.com > write-memory > *sigh* Some day I'll be able to `git fetch myrouter/master`... ;) -A From packetjockey at gmail.com Mon Jun 6 20:39:45 2011 From: packetjockey at gmail.com (Rafael Rodriguez) Date: Mon, 6 Jun 2011 21:39:45 -0400 Subject: automated router config back up In-Reply-To: References: Message-ID: <92DADACB-455A-42EE-9EEB-8C18A081D5A9@gmail.com> Formally known as ZipTie: http://inventory.alterpoint.com/ Can't speak to great lengths on it; haven't started playing with it yet but looks promising. Sent from my iPhone On Jun 6, 2011, at 20:33, Jon Heise wrote: > Aside from rancid, what methods do people have for doing automated backups > and diffing of router configs ? > > - Jon Heise From ops.lists at gmail.com Mon Jun 6 20:47:31 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 7 Jun 2011 07:17:31 +0530 Subject: Internap FCP In-Reply-To: References: <4DED0F26.1040600@linux.com> Message-ID: On Mon, Jun 6, 2011 at 11:55 PM, Nathan Stratton wrote: > On Mon, 6 Jun 2011, Ryan Pugatch wrote: >> We are currently looking into Internap FCP as we are in the process of >> redoing our network infrastructure and taking on managing BGP ourselves > > The reporting is not bad and it does an ok job. We ended up building our own > because the FCP was not able to look at enough of the active flows. I > believe the overall idea can provide a lot of value, it just was not the > best solution for our needs. Any alternatives? To start with, able to optimize routes across say two to four circuits. -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Mon Jun 6 20:49:29 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 7 Jun 2011 07:19:29 +0530 Subject: automated router config back up In-Reply-To: <92DADACB-455A-42EE-9EEB-8C18A081D5A9@gmail.com> References: <92DADACB-455A-42EE-9EEB-8C18A081D5A9@gmail.com> Message-ID: On Tue, Jun 7, 2011 at 7:09 AM, Rafael Rodriguez wrote: > Formally known as ZipTie: > http://inventory.alterpoint.com/ > > Can't speak to great lengths on it; haven't started playing with it yet but looks promising. http://cisco-conf-rep.sourceforge.net/ - been around for a while (~ 2006) -- Suresh Ramasubramanian (ops.lists at gmail.com) From l at p8x.net Mon Jun 6 20:54:00 2011 From: l at p8x.net (p8x) Date: Tue, 07 Jun 2011 09:54:00 +0800 Subject: automated router config back up In-Reply-To: <92DADACB-455A-42EE-9EEB-8C18A081D5A9@gmail.com> References: <92DADACB-455A-42EE-9EEB-8C18A081D5A9@gmail.com> Message-ID: <4DED84B8.2070208@p8x.net> On 7/06/2011 9:39 AM, Rafael Rodriguez wrote: > Formally known as ZipTie: > http://inventory.alterpoint.com/ This one looks nice, thanks for the link. I did try to download it but I seem to get a 404 page for the download link (which takes me to http://www.alterpoint.com/landing-sites/landing-pages/NAI-registration-US.html). From mysidia at gmail.com Mon Jun 6 22:29:08 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 6 Jun 2011 22:29:08 -0500 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <136746.1307326302@turing-police.cc.vt.edu> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <20110605204439.2a888183@milhouse> <4DEC23F8.7060106@bryanfields.net> <136746.1307326302@turing-police.cc.vt.edu> Message-ID: On Sun, Jun 5, 2011 at 9:11 PM, wrote: Well, the operational concern is... various governments have lately shown a trend of disconnecting their countries' networks. UN action is unlikely to help; they are too delayed, and there is a lack of enforcement power - symbolic actions don't stop networks from being disconnected. A technical solution rather than a UN solution, would be more beneficial; some sort of decentralized, high-speed, unjammable wireless mesh with better performance than government severable links would be ideal. However, the internet's existence is attributable to society, not a characteristic of humans. It's odd to suggest there's a natural right for the internet to exist - the UN seems mistaken -- maybe there's a natural right whose exercise permits participation in the community without government interference. Forced internet disconnections, as in, government imposed suppression are the same concept as shutting down television networks, seizing printing presses, restricting/closing broadcast stations, taking or breaking citizens' TVs and telephones, banning possession of books/magazines. UN doesn't need to say those are bad, it's obvious; it's just politics, and the UN trying to appear to stay relevant. Hopefully "human right to internet" is not a precursor to taking up IPv4 Exhaustion and declaring itself arbiter of addressing policy. > Concise enough for you? ?You may also want to investigate the relative > importance of communications and armaments in Ghandi's struggle for a free > India, the US civil rights movement, and the collapse of the Soviet Union. > That's 3 examples of change mediated by communications without rifles. ?Then > there's Darfur - an example of rifles without communications infrastructure. Which has pretty much nil to do with the basic human right to secure arms. Making social change by force is not an individual human right. Social change is the right of societies.[*] The natural need for a rational person to keep and bear arms, is to defend their person: their life, and things they need in order to continue to be alive. The threat could be anything from a dangerous animal, to an outlaw coming to raid the last of your food and water, during a drought. The natural right is to keep items to defend yourself against threats, and to bear arms in your defense against lawless assailants; where arms refers to the prevalent weapons required.* Individual natural right does not extend to bearing arms to coerce change in government or others, whether politically viewed as despotic or not, anymore than the right to free speech guarantees every person a bullhorn to wake up their neighbors at 3am with their protest message against the alleged despot. Any 'natural right' taken to extreme, without regard to others, becomes insane/tyrannical, when taken to that extreme. *Not that anyone's rifle will do anything against the local state sponsored military. -- -JH From trelane at trelane.net Mon Jun 6 22:32:27 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 06 Jun 2011 23:32:27 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <20110605204439.2a888183@milhouse> <4DEC23F8.7060106@bryanfields.net> <136746.1307326302@turing-police.cc.vt.edu> Message-ID: <4DED9BCB.1090506@trelane.net> On 6/6/2011 11:29 PM, Jimmy Hess wrote: > On Sun, Jun 5, 2011 at 9:11 PM, wrote: > > Well, the operational concern is... various governments have lately > shown a trend of disconnecting their countries' networks. > UN action is unlikely to help; they are too delayed, and there is > a lack of enforcement power - symbolic actions don't stop > networks from being disconnected. > > A technical solution rather than a UN solution, would be more > beneficial; some sort of decentralized, high-speed, > unjammable wireless mesh with better performance than > government severable links would be ideal. > > However, the internet's existence is attributable to society, not a > characteristic of humans. It's odd to suggest there's a natural right > for the internet to exist - the UN seems mistaken -- maybe there's a > natural right whose exercise permits participation in the community > without government interference. > > Forced internet disconnections, as in, government imposed suppression > are the same concept as shutting down television networks, seizing printing > presses, restricting/closing broadcast stations, taking or breaking citizens' > TVs and telephones, banning possession of books/magazines. > > UN doesn't need to say those are bad, it's obvious; it's just politics, > and the UN trying to appear to stay relevant. Hopefully "human right > to internet" is not a precursor to taking up IPv4 Exhaustion and declaring > itself arbiter of addressing policy. > > >> Concise enough for you? You may also want to investigate the relative >> importance of communications and armaments in Ghandi's struggle for a free >> India, the US civil rights movement, and the collapse of the Soviet Union. >> That's 3 examples of change mediated by communications without rifles. Then >> there's Darfur - an example of rifles without communications infrastructure. > > Which has pretty much nil to do with the basic human right to secure arms. > Making social change by force is not an individual human right. > Social change is the right of societies.[*] > > The natural need for a rational person to keep and bear arms, is to defend > their person: their life, and things they need in order to continue > to be alive. > The threat could be anything from a dangerous animal, to an outlaw coming > to raid the last of your food and water, during a drought. > > The natural right is to keep items to defend yourself against threats, and to > bear arms in your defense against lawless assailants; where arms refers > to the prevalent weapons required.* > > > Individual natural right does not extend to bearing arms to coerce change in > government or others, whether politically viewed as despotic or not, > anymore than the right to free speech guarantees every person a bullhorn > to wake up their neighbors at 3am with their protest message against the > alleged despot. > > Any 'natural right' taken to extreme, without regard to others, > becomes insane/tyrannical, when taken to that extreme. > > *Not that anyone's rifle will do anything against the local state > sponsored military. > I might also point out that at some point we may be required to protect this "basic human right" if someone tries to shut off our internets. From wjhns61 at hardakers.net Mon Jun 6 22:47:04 2011 From: wjhns61 at hardakers.net (Wes Hardaker) Date: Mon, 06 Jun 2011 20:47:04 -0700 Subject: v6 proof of life In-Reply-To: <63146.1307404592@nsa.vix.com> (Paul Vixie's message of "Mon, 06 Jun 2011 23:56:32 +0000") References: <63146.1307404592@nsa.vix.com> Message-ID: >>>>> On Mon, 06 Jun 2011 23:56:32 +0000, Paul Vixie said: PV> it's been a while since i looked at the query stream still hitting PV> importantly and happily, there's a great deal of IPv6 happening PV> here. Which is reaffirming what many have said for a while: it'll be the server-to-server traffic that will first peak. It's just going to take the client-server relationships years to catch up. Every time I look at my maillogs I've found there is quite a bit of v6 happening. But the web logs show almost nothing. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From jared at puck.nether.net Mon Jun 6 22:50:37 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 6 Jun 2011 23:50:37 -0400 Subject: v6 proof of life In-Reply-To: References: <63146.1307404592@nsa.vix.com> Message-ID: On Jun 6, 2011, at 11:47 PM, Wes Hardaker wrote: >>>>>> On Mon, 06 Jun 2011 23:56:32 +0000, Paul Vixie said: > > PV> it's been a while since i looked at the query stream still hitting > PV> importantly and happily, there's a great deal of IPv6 happening > PV> here. > > Which is reaffirming what many have said for a while: it'll be the > server-to-server traffic that will first peak. It's just going to take > the client-server relationships years to catch up. Every time I look at > my maillogs I've found there is quite a bit of v6 happening. But the > web logs show almost nothing. There was some additional research done by Geoff Houston indicating that if you exposed tunnel capable hosts (that were able to reach IPv6 literals) you had something closer to 20% IPv6 connectivity. I'm already excited about traffic levels and patterns in less than 24 hours. Will be interesting to observe. - Jared See if you can reach this even if you don't have native IPv6? http://[2001:418:3f4::5]/ From george.herbert at gmail.com Mon Jun 6 23:10:19 2011 From: george.herbert at gmail.com (George Herbert) Date: Mon, 6 Jun 2011 21:10:19 -0700 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <4DED9BCB.1090506@trelane.net> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <20110605204439.2a888183@milhouse> <4DEC23F8.7060106@bryanfields.net> <136746.1307326302@turing-police.cc.vt.edu> <4DED9BCB.1090506@trelane.net> Message-ID: As much as I admire a good pointless wide-ranging political and human rights flame-war, this is not even vaguely on topic for NANOG, and everyone posting content here on this should be ashamed of themselves. Free speech is a wonderful thing to have, but that is not a mandatory requirement that every venue carry it. NANOG exists for a reason, and this is not it. Mods: Kill the thread, please. -- -george william herbert george.herbert at gmail.com From joly at punkcast.com Mon Jun 6 23:10:58 2011 From: joly at punkcast.com (Joly MacFie) Date: Tue, 7 Jun 2011 00:10:58 -0400 Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <4DEC668D.30305@gmail.com> References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <4DEC5ECB.6080407@trelane.net> <4DEC668D.30305@gmail.com> Message-ID: +1 On Mon, Jun 6, 2011 at 1:33 AM, JC Dill wrote: > > There's a significant difference between Internet "access" and Internet > "service". I have access to the roads. But that doesn't magically get me > vehicular transportation from place A to place B. I need to buy a bus > ticket, or buy a car and gasoline, in order to get service over these roads > to transport myself from place A to place B. > > When the UN says that Internet access is a human right, they aren't saying > it should be provided for free, but they are saying that it should be > available (for those who can afford a service fee), and more importantly > that cutting it off for political purposes should be treated as a violation > of human rights of freedom of assembly and communication. In the 1700s the > US revolution and subsequent state formation (the United States of America) > was created first by people assembling at public halls and private houses. > In 2011, the Arab Spring revolutions have taken place by public assemblies > that were initially organized in internet forums (Facebook, Twitter, private > blogs, etc.). I do not see anything wrong with the UN position on Internet > access. > > jc > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From jra at baylink.com Mon Jun 6 23:16:31 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 7 Jun 2011 00:16:31 -0400 (EDT) Subject: (OT) UN declares Internet access a "human right" In-Reply-To: <4DEC5EEE.5070109@trelane.net> Message-ID: <18217366.48.1307420191395.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Andrew D Kirch" > > - PLONK > > What a moron > admins? Warning? hello? The admins need to warn a poster before a reader can put him in their killfile? Wow; that would've been a handy rule for me back in '06. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Mon Jun 6 23:19:19 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 7 Jun 2011 00:19:19 -0400 (EDT) Subject: UN Politics Off Topic Message-ID: <18265830.50.1307420359825.JavaMail.root@benjamin.baylink.com> I'm by no means a list admin, but I think we all get along a lot better when, as our mom's taught us, we don't discuss sex, politics or our paychecks with strangers. Please stop, everyone. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From hank at efes.iucc.ac.il Mon Jun 6 23:34:25 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 7 Jun 2011 07:34:25 +0300 (IDT) Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606221937.B362C6F437@smtp.hushmail.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: On Mon, 6 Jun 2011, rucasbrown at hushmail.com wrote: Please define ISP. -Hank > Hello, > > I wouldn't consider myself a network engineer, nor do I have any > formal training, but why don't ISPs peer with every other ISP? It > would only save EVERYONE money if they did this, no? Only issue I > see is with possibly hijacked / malicious AS owners, but that's not > very common to do without being caught. > > All the whole "don't peer with this guy" only makes your customers > have worse latencies and paths to other people, making the Internet > less healthy. > > Thanks, > Rucas > > PS: sorry if I sent this twice; client lagged a bit. > > From hank at efes.iucc.ac.il Mon Jun 6 23:39:08 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 7 Jun 2011 07:39:08 +0300 (IDT) Subject: (OT) UN declares Internet access a "human right" In-Reply-To: References: <4DEC13C1.1050800@linuxbox.org> <4DEC1B29.1010802@bryanfields.net> <20110605204439.2a888183@milhouse> <4DEC23F8.7060106@bryanfields.net> <136746.1307326302@turing-police.cc.vt.edu> Message-ID: On Mon, 6 Jun 2011, Jimmy Hess wrote: > On Sun, Jun 5, 2011 at 9:11 PM, wrote: > > Well, the operational concern is... that if you config an ACL you might be accused and brought to trial for crimes against humanity. -Hank From jra at baylink.com Mon Jun 6 23:41:54 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 7 Jun 2011 00:41:54 -0400 (EDT) Subject: (OT) UN declares Internet access a "human right" In-Reply-To: Message-ID: <30166642.64.1307421714183.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Hank Nussbacher" > On Mon, 6 Jun 2011, Jimmy Hess wrote: > > > On Sun, Jun 5, 2011 at 9:11 PM, wrote: > > > > Well, the operational concern is... > > that if you config an ACL you might be accused and brought to trial > for crimes against humanity. Now *this* is a valid, on-topic issue for this list. Does your employer have written protocols concerning what should be done and who is responsible when orders are given? This is *not* the Nuremberg trials; Martinez-Baker is probably the controlling case, though IANAL. So that we're clear, though, my interpretation of the original directive is that it forbids *member governments* from cutting off Internet access, and I don't know that it got into enough detail to suggest that this applied at the tactical, rather than strategic level. If I were running an ISP or IAP, you can bet I'd have a better answer than that, though, and your employer should too -- If a CxO hasn't talked to a General Counsel since that press release came out, then someone's falling down on the job. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From ryan.finnesey at HarrierInvestments.com Tue Jun 7 00:20:26 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 7 Jun 2011 01:20:26 -0400 Subject: Cogent? Message-ID: <27a601cc24d2$be665785$2001fe0a@exch005intermedia.net> Does cogent have a true carrier/wholesale team? Cheers Ryan Sent from my Windows Phone From owen at delong.com Tue Jun 7 00:37:19 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2011 22:37:19 -0700 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: <7EA7B68C-A018-4D00-ADB1-89ABF47C0A41@delong.com> FWIW, Hurricane Electric has an aggressively open peering policy and we will peer with anyone who is willing to peer at any exchange where we are connected. We believe as stated by Rucas that this only serves to enhance the internet experience for our customers as well as our peers. So far, it seems to be working pretty well for us. I encourage others to follow our lead in this regard as it truly does make a more functional internet. Owen On Jun 6, 2011, at 3:24 PM, Alex Ryu wrote: > Nope. > > It is because who pay the money, and somebody wants to earn the money > because they have more control. > So it is because of "money". > > Welcome to the world of capitalism. > > Alex > > > On Mon, Jun 6, 2011 at 5:19 PM, wrote: >> Hello, >> >> I wouldn't consider myself a network engineer, nor do I have any >> formal training, but why don't ISPs peer with every other ISP? It >> would only save EVERYONE money if they did this, no? Only issue I >> see is with possibly hijacked / malicious AS owners, but that's not >> very common to do without being caught. >> >> All the whole "don't peer with this guy" only makes your customers >> have worse latencies and paths to other people, making the Internet >> less healthy. >> >> Thanks, >> Rucas >> >> PS: sorry if I sent this twice; client lagged a bit. >> >> >> From gbonser at seven.com Tue Jun 7 00:47:52 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 6 Jun 2011 22:47:52 -0700 Subject: v6 proof of life In-Reply-To: References: <63146.1307404592@nsa.vix.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E36A9@RWC-EX1.corp.seven.com> > > There was some additional research done by Geoff Houston indicating > that if you exposed tunnel capable hosts (that were able to reach IPv6 > literals) you had something closer to 20% IPv6 connectivity. > > I'm already excited about traffic levels and patterns in less than 24 > hours. Will be interesting to observe. > > - Jared > > See if you can reach this even if you don't have native IPv6... > > http://[2001:418:3f4::5]/ I am seeing about 33% of our DNS traffic from one server over v6 but admittedly a lot of this is to the root servers that return A records for various domains. But the number of domains with v6 capable DNS servers is rising. From owen at delong.com Tue Jun 7 00:47:16 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2011 22:47:16 -0700 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: <20110606234914.B1CFF106068A@drugs.dv.isc.org> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> <20110606234914.B1CFF106068A@drugs.dv.isc.org> Message-ID: On Jun 6, 2011, at 4:49 PM, Mark Andrews wrote: > > In message , Owen DeLong write > s: >> >> On Jun 6, 2011, at 2:23 PM, Mark Andrews wrote: >> >>> =20 >>> In message , Jason = >> Fesler wr >>> ites: >>>>> But anyway, just consider it: a portion of the major websites go >>>>> IPv6-only for 24 hours. What happens is that well, 99% of the = >> populace >>>>> can't reach them anymore, as the known ones are down, they start = >> calling >>>>> and thus overloading the helpdesks of their ISPs. >>>> =20 >>>> Won't happen this year or next. Too much money at stake for the web=20= >> >>>> sites. Only when IPv4 is single digits or less could this be even=20 >>>> remotely considered. Even the 0.05% hit for a day was controverial = >> at=20 >>>> $dayjob. >>> =20 >>> IPv4 will never reach those figures. IPv6 isn't preferenced enough = >> for >>> that to happen and IPv6-only sites have methods of reaching IPv4 only >>> sites (DS-Lite, NAT64/DNS64). >> >> I think you'll be surprised over time. Given the tendency of the = >> internet >> to nearly double in size every 2 years or so, it only takes 7 cycles = >> (about >> 15 years) for the existing network to become a single-digit percentage >> of the future network. >> >> Owen > > And without there being a strong IPv6 bias in the clients they will > continue to use IPv4/IPv6 on a 50/50 basis. I would be quite happy > to be proven wrong and only time will tell. > Almost every client does have a strong IPv6 bias if they have what appears to be native connectivity. The bias degrades rapidly with other forms of host connectivity. My linux and Mac systems certainly seem to strongly prefer IPv6 from my home. YMMV. Owen From owen at delong.com Tue Jun 7 00:46:08 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jun 2011 22:46:08 -0700 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> Message-ID: <123E129D-00D2-4054-BA0C-02B5F19DD531@delong.com> On Jun 6, 2011, at 4:41 PM, Matthew Petach wrote: > On Mon, Jun 6, 2011 at 2:36 PM, Owen DeLong wrote: >> On Jun 6, 2011, at 2:23 PM, Mark Andrews wrote: > ... >>> IPv4 will never reach those figures. IPv6 isn't preferenced enough for >>> that to happen and IPv6-only sites have methods of reaching IPv4 only >>> sites (DS-Lite, NAT64/DNS64). >> >> I think you'll be surprised over time. Given the tendency of the internet >> to nearly double in size every 2 years or so, it only takes 7 cycles (about >> 15 years) for the existing network to become a single-digit percentage >> of the future network. >> >> Owen > > Hm. With roughly 1B people on the internet today[0], 7 cycles of > doubling would mean that in 15 years, we'd have 128B people > on the internet? > Ah, but, today, we don't really have 1B people on the internet, we have about 10,000,000 people on the internet and about 990,000,000 people behind NAT boxes, so, in 7 cycles of doubling we'll be at 1,280,000,000 people on the internet. ;-) > I strongly suspect the historical growth curve will *not* continue > at that pace. > Likely, but, I couldn't resist pointing out the reality above anyway. Even without the growth curves continuing, the IPv4 internet will become a relatively small fraction of the total internet in about 15 years. Owen From surfer at mauigateway.com Tue Jun 7 01:13:26 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 6 Jun 2011 23:13:26 -0700 Subject: ipv6 day quiet period please Message-ID: <20110606231326.4F2548F1@resin04.mta.everyone.net> Based on recent conversations, I hope everyone got their feelings expressed... :-) I would like to ask politely that we stop those conversations (and the other ones we all have fun with (or plonk)) and let the IPv6 day observations/discussions rule the floor when the world's day starts at the international dateline on June 8th. scott From marka at isc.org Tue Jun 7 01:24:37 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 07 Jun 2011 16:24:37 +1000 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: Your message of "Mon, 06 Jun 2011 22:47:16 MST." References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> <20110606234914.B1CFF106068A@drugs.dv.isc.org> Message-ID: <20110607062437.EC10B106B625@drugs.dv.isc.org> In message , Owen DeLong writes: > > On Jun 6, 2011, at 4:49 PM, Mark Andrews wrote: > > >=20 > > In message , Owen = > DeLong write > > s: > >>=20 > >> On Jun 6, 2011, at 2:23 PM, Mark Andrews wrote: > >>=20 > >>> =3D20 > >>> In message , = > Jason =3D > >> Fesler wr > >>> ites: > >>>>> But anyway, just consider it: a portion of the major websites go > >>>>> IPv6-only for 24 hours. What happens is that well, 99% of the =3D > >> populace > >>>>> can't reach them anymore, as the known ones are down, they start =3D= > > >> calling > >>>>> and thus overloading the helpdesks of their ISPs. > >>>> =3D20 > >>>> Won't happen this year or next. Too much money at stake for the = > web=3D20=3D > >>=20 > >>>> sites. Only when IPv4 is single digits or less could this be = > even=3D20 > >>>> remotely considered. Even the 0.05% hit for a day was controverial = > =3D > >> at=3D20 > >>>> $dayjob. > >>> =3D20 > >>> IPv4 will never reach those figures. IPv6 isn't preferenced enough = > =3D > >> for > >>> that to happen and IPv6-only sites have methods of reaching IPv4 = > only > >>> sites (DS-Lite, NAT64/DNS64). > >>=20 > >> I think you'll be surprised over time. Given the tendency of the =3D > >> internet > >> to nearly double in size every 2 years or so, it only takes 7 cycles = > =3D > >> (about > >> 15 years) for the existing network to become a single-digit = > percentage > >> of the future network. > >>=20 > >> Owen > >=20 > > And without there being a strong IPv6 bias in the clients they will > > continue to use IPv4/IPv6 on a 50/50 basis. I would be quite happy > > to be proven wrong and only time will tell. > >=20 > Almost every client does have a strong IPv6 bias if they have what > appears to be native connectivity. The bias degrades rapidly with > other forms of host connectivity. > > My linux and Mac systems certainly seem to strongly prefer IPv6 > from my home. YMMV. Things like happy-eyeballs diminish it even with perfect IPv6 connectivity. 100ms rtt doesn't cover the world and to make multi-homed servers (includes dual stack) work well clients will make additional connections. > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From patrick at ianai.net Tue Jun 7 01:50:52 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 7 Jun 2011 02:50:52 -0400 Subject: ipv6 day quiet period please In-Reply-To: <20110606231326.4F2548F1@resin04.mta.everyone.net> References: <20110606231326.4F2548F1@resin04.mta.everyone.net> Message-ID: On Jun 7, 2011, at 2:13 AM, Scott Weeks wrote: > Based on recent conversations, I hope everyone got their feelings expressed... :-) > > I would like to ask politely that we stop those conversations (and the other ones we all have fun with (or plonk)) and let the IPv6 day observations/discussions rule the floor when the world's day starts at the international dateline on June 8th. Seconded. Except that World IPv6 Day is 00:00 -> 23:59 June 8 UTC, not int'l date line time. -- TTFN, patrick From tjc at ecs.soton.ac.uk Tue Jun 7 02:02:06 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 7 Jun 2011 08:02:06 +0100 Subject: v6 proof of life In-Reply-To: References: <63146.1307404592@nsa.vix.com> <60B538E7-4DC8-4815-BA90-66A7B8E87CCE@ecs.soton.ac.uk> Message-ID: On 7 Jun 2011, at 04:47, Wes Hardaker wrote: >>>>>> On Mon, 06 Jun 2011 23:56:32 +0000, Paul Vixie said: > > PV> it's been a while since i looked at the query stream still hitting > PV> importantly and happily, there's a great deal of IPv6 happening > PV> here. > > Which is reaffirming what many have said for a while: it'll be the > server-to-server traffic that will first peak. It's just going to take > the client-server relationships years to catch up. Every time I look at > my maillogs I've found there is quite a bit of v6 happening. But the > web logs show almost nothing. Other way around here... pushing 2% external web traffic by IPv6, but only about 0.2% of mail traffic, and that would be lower if some of our users weren't on various IETF mail lists. Tim From joly at punkcast.com Tue Jun 7 02:41:17 2011 From: joly at punkcast.com (Joly MacFie) Date: Tue, 7 Jun 2011 03:41:17 -0400 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> Message-ID: Cisco just published a report saying that bandwidth will increase 400% by 2015, http://isoc-ny.org/p2/?p=2182 That does mean doubling every two years as far as it goes.. j On Mon, Jun 6, 2011 at 7:45 PM, J?r?me Nicolle wrote: > 2011/6/6 Owen DeLong : >> I think you'll be surprised over time. Given the tendency of the internet >> to nearly double in size every 2 years or so, it only takes 7 cycles (about >> 15 years) for the existing network to become a single-digit percentage >> of the future network. >> >> Owen > -- --------------------------------------------------------------- Joly MacFie? 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com ?http://pinstand.com - http://punkcast.com ?VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From joly at punkcast.com Tue Jun 7 02:45:59 2011 From: joly at punkcast.com (Joly MacFie) Date: Tue, 7 Jun 2011 03:45:59 -0400 Subject: New York World IPv6 Day meetup Message-ID: A reminder: Since World IPv6 Day is based on UTC it will conclude at 8pm EDT. ISOC-NY will present an informal wrap up meetup at NYU starting at 7pm EDT. Among those who have promised to attend will be Sagi Brody of Webair who will give a brief talk on that company?s IPv6 implementation efforts. What: World IPv6 Day ? Test Flight post-game meetup When: Wed. June 8, 2011 - 7pm-8.30 pm Where: Courant Institute NYU, Rm 201, 251 Mercer St. NYC Who: Free. Public welcome, especially network admins! Shorturl: http://bit.ly/ipv6daynyc I've had a few RSVPs - so we'll have a quorum. There will be WiFi. We will retire to a bar after. -- --------------------------------------------------------------- Joly MacFie? 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com ?http://pinstand.com - http://punkcast.com ?VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From leigh.porter at ukbroadband.com Tue Jun 7 02:48:27 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 7 Jun 2011 07:48:27 +0000 Subject: Why don't ISPs peer with everyone? In-Reply-To: <7EA7B68C-A018-4D00-ADB1-89ABF47C0A41@delong.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> , <7EA7B68C-A018-4D00-ADB1-89ABF47C0A41@delong.com> Message-ID: I agree, HE's peering policy makes them an attractive transit provider. However, money and strategy still come into play here. For example, ISP Z will think "I need some peering and transit. But if I get HE transit then some people may not peer with me at X-exchange because they will already see my routes via their HE peering" So then they get some transit from a network who is useless with their settlement free peering, then get the peers on the X-exchange and only when they are happily peered will they go to HE. -- Leigh Porter ________________________________________ From: Owen DeLong [owen at delong.com] Sent: 07 June 2011 06:43 To: Alex Ryu Cc: nanog at nanog.org Subject: Re: Why don't ISPs peer with everyone? FWIW, Hurricane Electric has an aggressively open peering policy and we will peer with anyone who is willing to peer at any exchange where we are connected. We believe as stated by Rucas that this only serves to enhance the internet experience for our customers as well as our peers. So far, it seems to be working pretty well for us. I encourage others to follow our lead in this regard as it truly does make a more functional internet. Owen On Jun 6, 2011, at 3:24 PM, Alex Ryu wrote: > Nope. > > It is because who pay the money, and somebody wants to earn the money > because they have more control. > So it is because of "money". > > Welcome to the world of capitalism. > > Alex > > > On Mon, Jun 6, 2011 at 5:19 PM, wrote: >> Hello, >> >> I wouldn't consider myself a network engineer, nor do I have any >> formal training, but why don't ISPs peer with every other ISP? It >> would only save EVERYONE money if they did this, no? Only issue I >> see is with possibly hijacked / malicious AS owners, but that's not >> very common to do without being caught. >> >> All the whole "don't peer with this guy" only makes your customers >> have worse latencies and paths to other people, making the Internet >> less healthy. >> >> Thanks, >> Rucas >> >> PS: sorry if I sent this twice; client lagged a bit. >> >> >> ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From shain.singh at gmail.com Tue Jun 7 02:58:27 2011 From: shain.singh at gmail.com (Shain Singh) Date: Tue, 7 Jun 2011 17:58:27 +1000 Subject: automated router config back up In-Reply-To: References: Message-ID: On 7 June 2011 10:33, Jon Heise wrote: > Aside from rancid, what methods do people have for doing automated backups > and diffing of router configs ? > > http://code.google.com/p/notch/ and it's assortment of tools is something I've been meaning to look into. -- Shaineel Singh e: shain.singh at gmail.com p: +61 422 921 951 w: http://buffet.shainsingh.com -- "Too many have dispensed with generosity to practice charity" - Albert Camus From xxnog at ledeuns.net Tue Jun 7 03:13:50 2011 From: xxnog at ledeuns.net (Denis F.) Date: Tue, 07 Jun 2011 10:13:50 +0200 Subject: v6 proof of life In-Reply-To: <63146.1307404592@nsa.vix.com> References: <63146.1307404592@nsa.vix.com> Message-ID: <4DEDDDBE.2040108@ledeuns.net> Le 07/06/2011 01:56, Paul Vixie a ?crit : > > 44 2001:db8::230:48ff:fef2:f340 > 44 2001:db8::230:48ff:fef0:1de How can 2001:db8::/32 reach your machines ? Denis From regnauld at nsrc.org Tue Jun 7 03:41:28 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 7 Jun 2011 11:41:28 +0300 Subject: automated router config back up - summary In-Reply-To: References: Message-ID: <20110607084128.GF48623@macbook.catpipe.net> Ok, so based on what's been written here, here is the list of tools mentioned so far RANCID - http://www.shrubbery.net/rancid/ Inventory (formerly ZipTie) - http://inventory.alterpoint.com/ NocProject - http://redmine.nocproject.org/projects/noc/wiki Notch - http://code.google.com/p/notch/ Cisco-Conf-Repository http://cisco-conf-rep.sourceforge.net/ I've also heard of Gerty, though as far as I understand, it's still a work in progress: https://github.com/ssinyagin/gerty And another solution is Netdot - http://netdot.uoregon.edu/ which will do inventory management (at least on Cisco), though it will rely on Rancid to fetch the configurations. ... I'll try and find the time to write a short summary of features for each (conf. backup, conf management/provisioning, inventory management) and post here. Cheers, Phil From bmanning at vacation.karoshi.com Tue Jun 7 04:17:33 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 7 Jun 2011 09:17:33 +0000 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: <20110607091733.GA24602@vacation.karoshi.com.> in this context, anyone who is a BGP speaker is an ISP. /bill On Tue, Jun 07, 2011 at 07:34:25AM +0300, Hank Nussbacher wrote: > On Mon, 6 Jun 2011, rucasbrown at hushmail.com wrote: > > Please define ISP. > > -Hank > > >Hello, > > > >I wouldn't consider myself a network engineer, nor do I have any > >formal training, but why don't ISPs peer with every other ISP? It > >would only save EVERYONE money if they did this, no? Only issue I > >see is with possibly hijacked / malicious AS owners, but that's not > >very common to do without being caught. > > > >All the whole "don't peer with this guy" only makes your customers > >have worse latencies and paths to other people, making the Internet > >less healthy. > > > >Thanks, > >Rucas > > > >PS: sorry if I sent this twice; client lagged a bit. > > > > From copraphage at gmail.com Tue Jun 7 05:27:27 2011 From: copraphage at gmail.com (Chris McDonald) Date: Tue, 7 Jun 2011 06:27:27 -0400 Subject: Cogent? In-Reply-To: <27a601cc24d2$be665785$2001fe0a@exch005intermedia.net> References: <27a601cc24d2$be665785$2001fe0a@exch005intermedia.net> Message-ID: As in sales? Isn't that all they have? On 6/7/11, Ryan Finnesey wrote: > Does cogent have a true carrier/wholesale team? Cheers Ryan Sent from my > Windows Phone -- Sent from my mobile device From ebais at a2b-internet.com Tue Jun 7 05:46:09 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 7 Jun 2011 12:46:09 +0200 Subject: Cogent? In-Reply-To: References: <27a601cc24d2$be665785$2001fe0a@exch005intermedia.net> Message-ID: <02e701cc2500$1cb196d0$5614c470$@com> > As in sales? Isn't that all they have? He probably means who understands the business. Erik From aservin at lacnic.net Tue Jun 7 06:47:12 2011 From: aservin at lacnic.net (Arturo Servin) Date: Tue, 7 Jun 2011 14:47:12 +0300 Subject: v6 proof of life In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E36A9@RWC-EX1.corp.seven.com> References: <63146.1307404592@nsa.vix.com> <5A6D953473350C4B9995546AFE9939EE0C9E36A9@RWC-EX1.corp.seven.com> Message-ID: Sometimes more than 25% of the traffic in our webserver is v6 http://lacnic.net/v6stat/hour_access_log_counter.png http://lacnic.net/v6stat/hour_access_log_counter.txt Haven't time to check the details about URLs, countries, user-agents but I am working on it. Regards, .as On 7 Jun 2011, at 08:47, George Bonser wrote: >> >> There was some additional research done by Geoff Houston indicating >> that if you exposed tunnel capable hosts (that were able to reach IPv6 >> literals) you had something closer to 20% IPv6 connectivity. >> >> I'm already excited about traffic levels and patterns in less than 24 >> hours. Will be interesting to observe. >> >> - Jared >> >> See if you can reach this even if you don't have native IPv6... >> >> http://[2001:418:3f4::5]/ > > I am seeing about 33% of our DNS traffic from one server over v6 but > admittedly a lot of this is to the root servers that return A records > for various domains. But the number of domains with v6 capable DNS > servers is rising. > > From owen at delong.com Tue Jun 7 07:37:00 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 7 Jun 2011 05:37:00 -0700 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: <20110607062437.EC10B106B625@drugs.dv.isc.org> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> <20110606234914.B1CFF106068A@drugs.dv.isc.org> <20110607062437.EC10B106B625@drugs.dv.isc.org> Message-ID: <8A6A00C3-BD6D-4FB4-AE82-73816DFD9EC0@delong.com> > > Things like happy-eyeballs diminish it even with perfect IPv6 > connectivity. 100ms rtt doesn't cover the world and to make > multi-homed servers (includes dual stack) work well clients will > make additional connections. Is happy eyeballs actually running code ANYWHERE? Owen From fredan-nanog at fredan.se Tue Jun 7 07:45:30 2011 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Tue, 7 Jun 2011 14:45:30 +0200 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <001c01cc2209$e727d860$b5778920$@iname.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <201106031427.07262.fredan-nanog@fredan.se> <001c01cc2209$e727d860$b5778920$@iname.com> Message-ID: <201106071445.31185.fredan-nanog@fredan.se> Two thing about this one after have read the manual of this product. This is probably for the american market. I'm in europe. Second, nowhere in their manual is the word "ipv6" or "v6" found. > Have a ZyXEL VSG1432 right behind me where the IPv6 works pretty good > (http://www.getipv6.info/index.php/Broadband_CPE#DSL). All the DSL modem > vendors could stand improving their GUI. > > Frank > > -----Original Message----- > From: fredrik danerklint [mailto:fredan-nanog at fredan.se] > Sent: Friday, June 03, 2011 7:27 AM > To: nanog at nanog.org > Subject: Re: Microsoft's participation in World IPv6 day > > The problem is not all on Microsoft at this case. > > > For example; I've bought a ZyXEL P-2612HNU-F1(which has > 802.11n Wireless ADSL 2+ 4-port gateway 2 SIP 2 USB 3G Backup) > in december 2010. It basiclly has everything in it. > > How do I as a customer do to have a working IPv6 setup on this modem since > ZyXEL, basicilly, has decide that it will not support IPv6 at all? > > I mean, you can not say it does not have the the cpu power for handling > IPv6 > > when it can also act as a fileserver and a printserver for example. > > What they (ZyXEL) are saying to me (for not haveing IPv6 at this moment) is > that they don't have the skills to implement IPv6 in their current > products. > > > Think about all the CPE that will not be upgraded, since those that makes > them > don't care at all, even tough it probably has the cpu power to handle IPv6. > > > And I haven't even started at the network equiment that exists between me > as a > ISP and my customer (this equiment is out of my control), that can't handle > IPv6 even if my customer got an working CPE with IPv6. > > > How fun is that? > > > http://support.microsoft.com/kb/2533454/ > > > > Uh... > > > > -Bill -- //fredan From dwcarder at wisc.edu Tue Jun 7 08:04:52 2011 From: dwcarder at wisc.edu (Dale W. Carder) Date: Tue, 07 Jun 2011 08:04:52 -0500 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: <8A6A00C3-BD6D-4FB4-AE82-73816DFD9EC0@delong.com> References: <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> <20110606234914.B1CFF106068A@drugs.dv.isc.org> <20110607062437.EC10B106B625@drugs.dv.isc.org> <8A6A00C3-BD6D-4FB4-AE82-73816DFD9EC0@delong.com> Message-ID: <20110607130451.GA79042@ricotta.doit.wisc.edu> Thus spake Owen DeLong (owen at delong.com) on Tue, Jun 07, 2011 at 05:37:00AM -0700: > > > > Things like happy-eyeballs diminish it even with perfect IPv6 > > connectivity. 100ms rtt doesn't cover the world and to make > > multi-homed servers (includes dual stack) work well clients will > > make additional connections. > > Is happy eyeballs actually running code ANYWHERE? Very similar, but with a static 300ms timer: http://code.google.com/p/chromium/issues/detail?id=81686 Dale From nanog at jima.tk Tue Jun 7 08:30:57 2011 From: nanog at jima.tk (Jima) Date: Tue, 07 Jun 2011 08:30:57 -0500 Subject: v6 proof of life In-Reply-To: <4DEDDDBE.2040108@ledeuns.net> References: <63146.1307404592@nsa.vix.com> <4DEDDDBE.2040108@ledeuns.net> Message-ID: <4DEE2811.2020103@jima.tk> On 06/07/2011 03:13 AM, Denis F. wrote: > Le 07/06/2011 01:56, Paul Vixie a ?crit : >> >> 44 2001:db8::230:48ff:fef2:f340 >> 44 2001:db8::230:48ff:fef0:1de > > > How can 2001:db8::/32 reach your machines ? Lack of ingress filtering on Mr. Vixie's part, and lack of egress filtering on whoever-owns-those-Supermicro-board's part. That's not to say there's a route back, by any means. Jima From randy at psg.com Tue Jun 7 08:40:32 2011 From: randy at psg.com (Randy Bush) Date: Tue, 07 Jun 2011 13:40:32 +0000 Subject: skype Message-ID: http://heartbeat.skype.com/ skype has been microsofted already. "small number of users" my ass. probably 7/8 of the users i would see at this time are not on. randy From jlewis at lewis.org Tue Jun 7 08:59:44 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 7 Jun 2011 09:59:44 -0400 (EDT) Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110607091733.GA24602@vacation.karoshi.com.> References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110607091733.GA24602@vacation.karoshi.com.> Message-ID: On Tue, 7 Jun 2011 bmanning at vacation.karoshi.com wrote: > in this context, anyone who is a BGP speaker is an ISP. Peering costs money. The transit bandwidth saved by peering with another network may not be sufficient to cover the cost of installing and maintaining whatever connections are necessary to peer. Then there's the big networks who really don't want to peer with anyone other than similarly sized big networks...everyone else should be their transit customer. I manage a network that's primarily a hosting network. There's a similar hosting network at the other end of the building. We both have multiple gigs of transit. We don't peer with each other. Perhaps we should, because the cost of the connection would be negligible (I think we already have multiple fiber pairs between our suites), but looking at my sampled netflow data, I'm guessing we average about 100kbit/s or less traffic in each direction between us. At that low a level, is it even worth the time and trouble to coordinate setting up a peering connection, much less tying up a gigE port at each end? Anyone from hostdime reading this? :) If so, what are your thoughts? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From aftab.siddiqui at gmail.com Tue Jun 7 08:59:55 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Tue, 7 Jun 2011 18:59:55 +0500 Subject: skype In-Reply-To: References: Message-ID: +1, My number is not working at all even the call not switching to voice mail. Regards, Aftab A. Siddiqui On Tue, Jun 7, 2011 at 6:40 PM, Randy Bush wrote: > http://heartbeat.skype.com/ > > skype has been microsofted already. "small number of users" my ass. > probably 7/8 of the users i would see at this time are not on. > > randy > > From andyring at inebraska.com Tue Jun 7 09:13:49 2011 From: andyring at inebraska.com (Andy Ringsmuth) Date: Tue, 7 Jun 2011 09:13:49 -0500 Subject: Cox outage in Alexandria, Va. Message-ID: One of my employees is reporting that Cox told her a backhoe "cut a main line" somewhere in the Alexandria, Virginia area earlier this morning. More than likely a fiber cut I'd imagine. Apparently it's affecting about 50,000 residential customers and has been down since 5 a.m. Anyone have more info? --- Andy Ringsmuth (402) 304-0083 andyring at inebraska.com From drew.weaver at thenap.com Tue Jun 7 09:15:48 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 7 Jun 2011 10:15:48 -0400 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110607091733.GA24602@vacation.karoshi.com.> Message-ID: -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Tuesday, June 07, 2011 10:00 AM -snip- I manage a network that's primarily a hosting network. There's a similar hosting network at the other end of the building. We both have multiple gigs of transit. We don't peer with each other. Perhaps we should, because the cost of the connection would be negligible (I think we already have multiple fiber pairs between our suites), but looking at my sampled netflow data, I'm guessing we average about 100kbit/s or less traffic in each direction between us. At that low a level, is it even worth the time and trouble to coordinate setting up a peering connection, much less tying up a gigE port at each end? ----- 100kbit/s at <1ms is better than 100kbit/s at > 1ms. We are hosting as well and some of our top 25 ASNs are other hosting networks, YMMV. -Drew From jmamodio at gmail.com Tue Jun 7 09:20:49 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 7 Jun 2011 09:20:49 -0500 Subject: skype In-Reply-To: References: Message-ID: Is not working for me since early today, first the connection went down and later the application crashed ... I refuse to switch to MSN. I'm afraid that soon my monitor will explode if microsoft acquisition of NVIDIA goes through. BTW, after yesterday announcements at WWDC I wonder if there are some flying chairs at Redmond, Mr. Bald-mer is probably freaking out Cheers -J From tme at americafree.tv Tue Jun 7 09:25:55 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 7 Jun 2011 10:25:55 -0400 Subject: skype In-Reply-To: References: Message-ID: <590CAAA9-9D4C-462F-B170-BD63EDE79EB0@americafree.tv> On Jun 7, 2011, at 9:40 AM, Randy Bush wrote: > http://heartbeat.skype.com/ > > skype has been microsofted already. "small number of users" my ass. > probably 7/8 of the users i would see at this time are not on. On this topic, it has also been penetrated, by the Egyptian ?Electronic Penetration Department," no less : http://www.mideastnewswire.com/skype-rebellion-hightech-listening Regards Marshall > > randy > > From marka at isc.org Tue Jun 7 09:28:18 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 08 Jun 2011 00:28:18 +1000 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: Your message of "Tue, 07 Jun 2011 05:37:00 MST." <8A6A00C3-BD6D-4FB4-AE82-73816DFD9EC0@delong.com> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <154C19F0-4D8A-4A97-AE77-542104EF6507@delong.com> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> <20110606234914.B1CFF106068A@drugs.dv.isc.org> <20110607062437.EC10B106B625@drugs.dv.isc.org> <8A6A00C3-BD6D-4FB4-AE82-73816DFD9EC0@delong.com> Message-ID: <20110607142818.DFC5A106EB9D@drugs.dv.isc.org> In message <8A6A00C3-BD6D-4FB4-AE82-73816DFD9EC0 at delong.com>, Owen DeLong write s: > > > > Things like happy-eyeballs diminish it even with perfect IPv6 > > connectivity. 100ms rtt doesn't cover the world and to make > > multi-homed servers (includes dual stack) work well clients will > > make additional connections. > > Is happy eyeballs actually running code ANYWHERE? > > Owen Chrome does something close using 300ms. There is code out there that does it and there really should be lots more of it as it mitigates lots of problems. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From leigh.porter at ukbroadband.com Tue Jun 7 09:29:47 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 7 Jun 2011 14:29:47 +0000 Subject: skype In-Reply-To: <590CAAA9-9D4C-462F-B170-BD63EDE79EB0@americafree.tv> References: <590CAAA9-9D4C-462F-B170-BD63EDE79EB0@americafree.tv> Message-ID: I love how this story was published AFTER MSFT purchased them ;-) -- Leigh Porter > -----Original Message----- > From: Marshall Eubanks [mailto:tme at americafree.tv] > Sent: 07 June 2011 15:28 > To: Randy Bush > Cc: NANOG Operators' Group > Subject: Re: skype > > > On Jun 7, 2011, at 9:40 AM, Randy Bush wrote: > > > http://heartbeat.skype.com/ > > > > skype has been microsofted already. "small number of users" my ass. > > probably 7/8 of the users i would see at this time are not on. > > On this topic, it has also been penetrated, by the > Egyptian "Electronic Penetration Department," no less : > > http://www.mideastnewswire.com/skype-rebellion-hightech-listening > > Regards > Marshall > > > > > > randy > > > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From tme at americafree.tv Tue Jun 7 09:33:36 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 7 Jun 2011 10:33:36 -0400 Subject: Cox outage in Alexandria, Va. In-Reply-To: References: Message-ID: <70956EA3-ACFB-4FFC-8304-DC869C74E14E@americafree.tv> On Jun 7, 2011, at 10:13 AM, Andy Ringsmuth wrote: > One of my employees is reporting that Cox told her a backhoe "cut a main line" somewhere in the Alexandria, Virginia area earlier this morning. More than likely a fiber cut I'd imagine. Apparently it's affecting about 50,000 residential customers and has been down since 5 a.m. > > Anyone have more info? > > --- > Andy Ringsmuth > (402) 304-0083 > andyring at inebraska.com > > > Absolutely no problems on my home circuit in Clifton, Virginia (20124, 25 miles due West of Alexandria). Last time I checked I was connected to Head End 8. Regards Marshall From jmamodio at gmail.com Tue Jun 7 09:35:32 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 7 Jun 2011 09:35:32 -0500 Subject: UN declares Internet access a "human right" In-Reply-To: References: <4DEC13C1.1050800@linuxbox.org> Message-ID: > Consider two alternatives : > > - Finance guns, soldier training, refugee camps, humanitarian ground > help and political meetings and treaties to make a revolution happens > in a (more or less controled) bloodshed > > OR > > - Take a strong position to preserve freedom of speech and wider use > of the Internet as a mean to let the people self-organize in a > political process, thus avoiding violent revolutions > > What do you think is best ? None of the above. If you don't walk the talk, all the talk is useless and only for the self benefit of the talking heads. -J From ray at oneunified.net Tue Jun 7 09:39:39 2011 From: ray at oneunified.net (Raymond Burkholder) Date: Tue, 7 Jun 2011 11:39:39 -0300 Subject: skype In-Reply-To: References: <590CAAA9-9D4C-462F-B170-BD63EDE79EB0@americafree.tv> Message-ID: <02da01cc2520$bb5c6ec0$32154c40$@oneunified.net> > I love how this story was published AFTER MSFT purchased them ;-) > http://plug2play.blogspot.com/2010/12/skypes-biggest-secret-revealed.html reverse engineering hack was reported back in mid December. > > > > On Jun 7, 2011, at 9:40 AM, Randy Bush wrote: > > > > > http://heartbeat.skype.com/ > > > > > > skype has been microsofted already. "small number of users" my ass. > > > probably 7/8 of the users i would see at this time are not on. > > > > On this topic, it has also been penetrated, by the > > Egyptian "Electronic Penetration Department," no less : > > > > http://www.mideastnewswire.com/skype-rebellion-hightech-listening > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From neil at tonal.clara.co.uk Tue Jun 7 09:41:11 2011 From: neil at tonal.clara.co.uk (Neil Harris) Date: Tue, 07 Jun 2011 15:41:11 +0100 Subject: Why no IPv6-only day (Was: Protocol-41 is not the only tunneling protocol) In-Reply-To: <20110607142818.DFC5A106EB9D@drugs.dv.isc.org> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <5B96FD72-1070-4E76-BDB2-EB4F3936A8E2@delong.com> <4DE8D822.3050108@scarynet.org> <82C305C8-5B8D-4017-8AD6-F352CF3D049D@ecs.soton.ac.uk> <4DE8E3E0.7010204@unfix.org> <4DE8F049.9000509@unfix.org> <4DE9EA04.2050605@unfix.org> <20110606212324.ED215105E66B@drugs.dv.isc.org> <20110606234914.B1CFF106068A@drugs.dv.isc.org> <20110607062437.EC10B106B625@drugs.dv.isc.org> <8A6A00C3-BD6D-4FB4-AE82-73816DFD9EC0@delong.com> <20110607142818.DFC5A106EB9D@drugs.dv.isc.org> Message-ID: <4DEE3887.3080000@tonal.clara.co.uk> On 07/06/11 15:28, Mark Andrews wrote: > In message<8A6A00C3-BD6D-4FB4-AE82-73816DFD9EC0 at delong.com>, Owen DeLong write > s: >>> Things like happy-eyeballs diminish it even with perfect IPv6 >>> connectivity. 100ms rtt doesn't cover the world and to make >>> multi-homed servers (includes dual stack) work well clients will >>> make additional connections. >> Is happy eyeballs actually running code ANYWHERE? >> >> Owen > Chrome does something close using 300ms. There is code out there > that does it and there really should be lots more of it as it mitigates > lots of problems. > There's also a bug currently open for the equivalent functionality in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=621558 -- Neil From rmaxwell at umd.edu Tue Jun 7 09:44:53 2011 From: rmaxwell at umd.edu (Robert F Maxwell) Date: Tue, 7 Jun 2011 10:44:53 -0400 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110607091733.GA24602@vacation.karoshi.com.> Message-ID: <57C0613A-CCAF-4662-A1C6-FF286B3D6B56@umd.edu> I'd like to foster a discussion here to better understand this, not rile anyone up. That said, what I see so far is a representation of those who do not recall the halcyon days before a rabid profit motive was the driving force behind ISPs. Peering in it's original sense is/was free. It was a swap of traffic. That profit motive has created the phrase "settlement free peering" to refer to the original definition so it seems like the free swap of traffic is the aberration. The big ISPs used to seek to balance content hosting and the customer load to avoid having to pay for any sort of transit. AOL was known to acquire companies which had huge downstream traffic for this purpose. Now we see ISPs waging an economic war with content providers wanting to find a way to charge, say, Google for allowing them to to pass their YouTube content along to the ISP's subscribers. This is the result of letting non-technical, profit-driven managers run the show and not the usually eager to cooperate network engineers who actually understand how this stuff works. The problem here is that the closer you are to the end user, the harder you're getting screwed, and not in a good way. The very large ISPs are doing real peering, and charging smaller, end-user focused ISPs high transit rates so that they can't possibly compete on price with the inferior, customer-service-impaired ISP end-user offerings. The US government has declined to enforce any sort of rule which might require the huge ISPs to grant wholesale-type access to their physical networks (for better or worse depending on your POV) or examine any of this cartel-type behavior under the light of monopoly rules. So please, short of socialism, and in light of the rampant legislation-for-sale culture in our government (how many FCC commissioners get jobs with huge ISPs?) how do we fix this? Please note: I'm not advocating socialism. I might advocate regulation a la public utilities. There is universal agreement that the internet is "critical infrastructure." deregulating other utilities hasn't been uniformly successful, especially when measured from the consumers' point of view. Thoughts? Rob Sent from my iPad, so I can't have a fun sig. On Jun 7, 2011, at 10:00 AM, "Jon Lewis" wrote: > On Tue, 7 Jun 2011 bmanning at vacation.karoshi.com wrote: > >> in this context, anyone who is a BGP speaker is an ISP. > > Peering costs money. The transit bandwidth saved by peering with another > network may not be sufficient to cover the cost of installing and > maintaining whatever connections are necessary to peer. Then there's the > big networks who really don't want to peer with anyone other than > similarly sized big networks...everyone else should be their transit > customer. > > I manage a network that's primarily a hosting network. There's a similar > hosting network at the other end of the building. We both have multiple > gigs of transit. We don't peer with each other. Perhaps we should, > because the cost of the connection would be negligible (I think we already > have multiple fiber pairs between our suites), but looking at my sampled > netflow data, I'm guessing we average about 100kbit/s or less traffic in > each direction between us. At that low a level, is it even worth the time > and trouble to coordinate setting up a peering connection, much less > tying up a gigE port at each end? > > Anyone from hostdime reading this? :) > If so, what are your thoughts? > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From leigh.porter at ukbroadband.com Tue Jun 7 10:44:45 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 7 Jun 2011 15:44:45 +0000 Subject: skype In-Reply-To: <02da01cc2520$bb5c6ec0$32154c40$@oneunified.net> References: <590CAAA9-9D4C-462F-B170-BD63EDE79EB0@americafree.tv> <02da01cc2520$bb5c6ec0$32154c40$@oneunified.net> Message-ID: > From: Raymond Burkholder [mailto:ray at oneunified.net] > > > I love how this story was published AFTER MSFT purchased them ;-) > > > > http://plug2play.blogspot.com/2010/12/skypes-biggest-secret- > revealed.html > > reverse engineering hack was reported back in mid December. Indeed, but "reverse engineered" and "Egyptian government snooping Skype calls" are quite different. Whilst some people may have rather foolishly relied on Skype for privacy, this is now not going to happen. I doubt it'll make a big dent on the user base though. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jra at baylink.com Tue Jun 7 10:42:10 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 7 Jun 2011 11:42:10 -0400 (EDT) Subject: Why don't ISPs peer with everyone? In-Reply-To: <7EA7B68C-A018-4D00-ADB1-89ABF47C0A41@delong.com> Message-ID: <31272804.94.1307461330911.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > So far, it seems to be working pretty well for us. I encourage others > to follow our lead in this regard as it truly does make a more functional > internet. I concur, and I specifically would like to see a lot more *geographically* local peering, so packets from Roar Runner[1] Tampa Bay to FiOS Tampa Bay don't have to clog up an exchang point in Reston or Dallas; this stuff *will* eventually bite us in another Katrina-scale event. Cheers, -- jra [1]Roar Runner was a typo, but given most of what the Internet is used for these days[2], it's so funny I'm going to leave it in. [2]"Recreational Indignation". -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jared at puck.nether.net Tue Jun 7 10:52:31 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 7 Jun 2011 11:52:31 -0400 Subject: Why don't ISPs peer with everyone? In-Reply-To: <31272804.94.1307461330911.JavaMail.root@benjamin.baylink.com> References: <31272804.94.1307461330911.JavaMail.root@benjamin.baylink.com> Message-ID: <2026B657-3DBF-49F4-A5B7-0C8787755464@puck.nether.net> On Jun 7, 2011, at 11:42 AM, Jay Ashworth wrote: > I concur, and I specifically would like to see a lot more *geographically* > local peering, so packets from Roar Runner[1] Tampa Bay to FiOS Tampa Bay don't > have to clog up an exchang point in Reston or Dallas; this stuff *will* > eventually bite us in another Katrina-scale event. What I've found interesting is the cost of circuits seem to not be distance-sensitive. I think this will contribute to mega-regional peering for the foreseeable future. (ie: dc, sj, dfw, chi, nyc, etc?) Unless these costs come closer to reflecting a balance then I suspect we will continue to see this regional networking. I had a hard time getting people to interconnect even in the CLEC COLO spaces. very few people had bgp capable devices in those locations, while they were big and had traffic, the gear for running bgp just wasn't there. - Jared From Brian.Rettke at cableone.biz Tue Jun 7 11:08:57 2011 From: Brian.Rettke at cableone.biz (Rettke, Brian) Date: Tue, 7 Jun 2011 09:08:57 -0700 Subject: Why don't ISPs peer with everyone? In-Reply-To: <57C0613A-CCAF-4662-A1C6-FF286B3D6B56@umd.edu> References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110607091733.GA24602@vacation.karoshi.com.> <57C0613A-CCAF-4662-A1C6-FF286B3D6B56@umd.edu> Message-ID: <96CA80CDCD822B4F9B41FB3A109C9359A4616D8732@E2K7MAILBOX1.corp.cableone.net> Content providers (e.g. Netflix, Hulu, YouTube) will always try to get their content serviced for little to no cost. The low cost, web-only plan isn't sustainable, and the amount of Netflix traffic around the globe is a good example; There's a lot of traffic that they aren't paying for. The free market only works if entities self-police. But as has been expertly stated, there's no money in that. I had an idea, I'm sure it's been said before: If we actually had solid "Tier 1 vs Tier 2 vs Tier 3" thresholds, and we could come up with an agreeable metric, we might be able to minimize the impact of bandwidth hogs (sorry Netflix, pointing at you). So, if you are a Tier 1, you are required to have at least 10 piers in 10 locations, 5 of which must be Tier 1 providers. If you are Tier 2, that number is halved. It could be a combination of having the "status" of being a Tier 1 provider, but the major benefit is a reduction of the diameter of the Internet. Even done by continent, this could offer enough parallel paths to help address (potentially) the cost of doing business. I think we would need to have something similar for content providers. To reach Tier 1 status, you are required to have 10 piers in 10 locations, which should cover a set multiple of your total bandwidth (1 TB if it is 500 GB, etc....) For reaching different tiers, they could receive a price break on the cost of Internet circuits. There would also need to be a middle ground somewhere. Circuits would either need to stop being unlimited or have service thresholds. For exceeding, the content provider would be liable to pay X amount per Gigabit of bandwidth. This would then force Content providers to scale their business rather than relying on the upstream providers' upstream provider to do so. Not perfect by a great margin, but I think something like that could help. Sincerely, Brian A . Rettke -----Original Message----- From: Robert F Maxwell [mailto:rmaxwell at umd.edu] Sent: Tuesday, June 07, 2011 7:45 AM To: Jon Lewis Cc: bmanning at vacation.karoshi.com; nanog at nanog.org Subject: Re: Why don't ISPs peer with everyone? I'd like to foster a discussion here to better understand this, not rile anyone up. That said, what I see so far is a representation of those who do not recall the halcyon days before a rabid profit motive was the driving force behind ISPs. Peering in it's original sense is/was free. It was a swap of traffic. That profit motive has created the phrase "settlement free peering" to refer to the original definition so it seems like the free swap of traffic is the aberration. The big ISPs used to seek to balance content hosting and the customer load to avoid having to pay for any sort of transit. AOL was known to acquire companies which had huge downstream traffic for this purpose. Now we see ISPs waging an economic war with content providers wanting to find a way to charge, say, Google for allowing them to to pass their YouTube content along to the ISP's subscribers. This is the result of letting non-technical, profit-driven managers run the show and not the usually eager to cooperate network engineers who actually understand how this stuff works. The problem here is that the closer you are to the end user, the harder you're getting screwed, and not in a good way. The very large ISPs are doing real peering, and charging smaller, end-user focused ISPs high transit rates so that they can't possibly compete on price with the inferior, customer-service-impaired ISP end-user offerings. The US government has declined to enforce any sort of rule which might require the huge ISPs to grant wholesale-type access to their physical networks (for better or worse depending on your POV) or examine any of this cartel-type behavior under the light of monopoly rules. So please, short of socialism, and in light of the rampant legislation-for-sale culture in our government (how many FCC commissioners get jobs with huge ISPs?) how do we fix this? Please note: I'm not advocating socialism. I might advocate regulation a la public utilities. There is universal agreement that the internet is "critical infrastructure." deregulating other utilities hasn't been uniformly successful, especially when measured from the consumers' point of view. Thoughts? Rob Sent from my iPad, so I can't have a fun sig. On Jun 7, 2011, at 10:00 AM, "Jon Lewis" wrote: > On Tue, 7 Jun 2011 bmanning at vacation.karoshi.com wrote: > >> in this context, anyone who is a BGP speaker is an ISP. > > Peering costs money. The transit bandwidth saved by peering with another > network may not be sufficient to cover the cost of installing and > maintaining whatever connections are necessary to peer. Then there's the > big networks who really don't want to peer with anyone other than > similarly sized big networks...everyone else should be their transit > customer. > > I manage a network that's primarily a hosting network. There's a similar > hosting network at the other end of the building. We both have multiple > gigs of transit. We don't peer with each other. Perhaps we should, > because the cost of the connection would be negligible (I think we already > have multiple fiber pairs between our suites), but looking at my sampled > netflow data, I'm guessing we average about 100kbit/s or less traffic in > each direction between us. At that low a level, is it even worth the time > and trouble to coordinate setting up a peering connection, much less > tying up a gigE port at each end? > > Anyone from hostdime reading this? :) > If so, what are your thoughts? > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From mpalmer at hezmatt.org Tue Jun 7 10:05:49 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 8 Jun 2011 01:05:49 +1000 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110607091733.GA24602@vacation.karoshi.com.> Message-ID: <20110607150549.GH20444@hezmatt.org> On Tue, Jun 07, 2011 at 10:15:48AM -0400, Drew Weaver wrote: > -----Original Message----- > From: Jon Lewis [mailto:jlewis at lewis.org] > Sent: Tuesday, June 07, 2011 10:00 AM > > -snip- > > I manage a network that's primarily a hosting network. There's a similar > hosting network at the other end of the building. We both have multiple > gigs of transit. We don't peer with each other. Perhaps we should, > because the cost of the connection would be negligible (I think we already > have multiple fiber pairs between our suites), but looking at my sampled > netflow data, I'm guessing we average about 100kbit/s or less traffic in > each direction between us. At that low a level, is it even worth the time > and trouble to coordinate setting up a peering connection, much less > tying up a gigE port at each end? > ----- > > 100kbit/s at <1ms is better than 100kbit/s at > 1ms. True, but the point being made is: how *much* better? Is it enough better to justify the cost of installing and maintaining another peering link? - Matt -- "Ah, the beauty of OSS. Hundreds of volunteers worldwide volunteering their time inventing and implementing new, exciting ways for software to suck." -- Toni Lassila, in the Monastery From jmamodio at gmail.com Tue Jun 7 11:25:26 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 7 Jun 2011 11:25:26 -0500 Subject: skype In-Reply-To: References: <590CAAA9-9D4C-462F-B170-BD63EDE79EB0@americafree.tv> <02da01cc2520$bb5c6ec0$32154c40$@oneunified.net> Message-ID: > Indeed, but "reverse engineered" and "Egyptian government snooping Skype calls" are quite different. Whilst some people may have rather foolishly relied on Skype for privacy, this is now not going to happen. I doubt it'll make a big dent on the user base though. Skype privacy ? hehe, the only way to have privacy is under Control's cone of silence. Carrier Detected->Connected->LinkUp->PrivacyGone -J From pheller at me.com Tue Jun 7 11:28:43 2011 From: pheller at me.com (Phillip Heller) Date: Tue, 07 Jun 2011 12:28:43 -0400 Subject: IPv6 Availability on XO In-Reply-To: References: <835617D6-5709-467B-91F0-91E20448AEA9@u13.net> Message-ID: <08E67BBD-7CAA-4F50-A9A5-FA0FEEA3B782@me.com> I turned up ipv6 on a 10gig in the Boston market with XO today. They'll definitely do it, but it might take a bit of pushing on an account manager. I've also turned up ipv6 with Level(3), and have noted the same incompleteness of the routing table. It will be a shame if the majority of complaints on the 8th are related to reachability, and not truly representative of host stack and/or application issues. Regards, --phil On Jun 5, 2011, at 4:32 PM, Luke Marrott wrote: > We have a 10GigE connection with XO in Utah and have gotten little to no > response from XO on our IPv6 requests for months. > > We finally got our L3 IPv6, but they don't have a complete routing table. > > :Luke Marrott -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4385 bytes Desc: not available URL: From vixie at isc.org Tue Jun 7 11:33:10 2011 From: vixie at isc.org (Paul Vixie) Date: Tue, 07 Jun 2011 16:33:10 +0000 Subject: v6 proof of life In-Reply-To: <4DEE2811.2020103@jima.tk> (Jima's message of "Tue, 07 Jun 2011 08:30:57 -0500") References: <63146.1307404592@nsa.vix.com> <4DEDDDBE.2040108@ledeuns.net> <4DEE2811.2020103@jima.tk> Message-ID: Jima writes: >>> 44 2001:db8::230:48ff:fef2:f340 >>> 44 2001:db8::230:48ff:fef0:1de >> >> How can 2001:db8::/32 reach your machines ? > > Lack of ingress filtering on Mr. Vixie's part, ... indeed. i had no idea. > and lack of egress > filtering on whoever-owns-those-Supermicro-board's part. > That's not to say there's a route back, by any means. i'll bet i'm not alone in seeing traffic from this prefix. as a rootop i can tell you that we see plenty of queries from ipv4 rfc1918 as well. -- Paul Vixie KI6YSY From jlewis at lewis.org Tue Jun 7 11:38:33 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 7 Jun 2011 12:38:33 -0400 (EDT) Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110607150549.GH20444@hezmatt.org> References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110607091733.GA24602@vacation.karoshi.com.> <20110607150549.GH20444@hezmatt.org> Message-ID: On Wed, 8 Jun 2011, Matthew Palmer wrote: >> netflow data, I'm guessing we average about 100kbit/s or less traffic in >> each direction between us. At that low a level, is it even worth the time >> and trouble to coordinate setting up a peering connection, much less >> tying up a gigE port at each end? >> ----- >> >> 100kbit/s at <1ms is better than 100kbit/s at > 1ms. > > True, but the point being made is: how *much* better? Is it enough better > to justify the cost of installing and maintaining another peering link? Additionally, we share at least one common transit provider, so we'd be trading <1ms for 1-2ms. Obviously, if we were talking about a leased line with any MRC, the answer would be hell no. Since we're able to utilize fiber inside the building with no MRC, the answer is more of a "why bother?" It's not going to save either of us any meaningful amount of transit bandwidth $/capacity. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ryan.finnesey at HarrierInvestments.com Tue Jun 7 11:40:22 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 7 Jun 2011 09:40:22 -0700 Subject: Cogent? In-Reply-To: <02e701cc2500$1cb196d0$5614c470$@com> References: <27a601cc24d2$be665785$2001fe0a@exch005intermedia.net> <02e701cc2500$1cb196d0$5614c470$@com> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03B25004@EXVBE005-2.exch005intermedia.net> Correct -----Original Message----- From: Erik Bais [mailto:ebais at a2b-internet.com] Sent: Tuesday, June 07, 2011 6:46 AM To: 'Chris McDonald'; Ryan Finnesey; 'NANOG' Subject: RE: Cogent? > As in sales? Isn't that all they have? He probably means who understands the business. Erik From ryan.finnesey at HarrierInvestments.com Tue Jun 7 11:42:13 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 7 Jun 2011 09:42:13 -0700 Subject: Cogent? In-Reply-To: References: <27a601cc24d2$be665785$2001fe0a@exch005intermedia.net> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03B25005@EXVBE005-2.exch005intermedia.net> I have not been able to find a group within Cogent that sells services to other carriers. Been trying to get access to a lot of the fiber Cogent has running into buildings. Cheers Ryan -----Original Message----- From: Chris McDonald [mailto:copraphage at gmail.com] Sent: Tuesday, June 07, 2011 6:27 AM To: Ryan Finnesey; NANOG Subject: Re: Cogent? As in sales? Isn't that all they have? On 6/7/11, Ryan Finnesey wrote: > Does cogent have a true carrier/wholesale team? Cheers Ryan Sent from my > Windows Phone -- Sent from my mobile device From bmanning at vacation.karoshi.com Tue Jun 7 11:49:42 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 7 Jun 2011 16:49:42 +0000 Subject: Why don't ISPs peer with everyone? In-Reply-To: <2026B657-3DBF-49F4-A5B7-0C8787755464@puck.nether.net> References: <31272804.94.1307461330911.JavaMail.root@benjamin.baylink.com> <2026B657-3DBF-49F4-A5B7-0C8787755464@puck.nether.net> Message-ID: <20110607164942.GA25776@vacation.karoshi.com.> On Tue, Jun 07, 2011 at 11:52:31AM -0400, Jared Mauch wrote: > > What I've found interesting is the cost of circuits seem to not be distance-sensitive. I think this will contribute to mega-regional peering for the foreseeable future. > > (ie: dc, sj, dfw, chi, nyc, etcb&) > > Unless these costs come closer to reflecting a balance then I suspect we will continue to see this regional networking. I had a hard time getting people to interconnect even in the CLEC COLO spaces. very few people had bgp capable devices in those locations, while they were big and had traffic, the gear for running bgp just wasn't there. > > - Jared well - no BGP, != an ISP :) this sounds very much like the folks who wanted to put up a south asian IX in guam. lots and lots of fiber pairs landed there, but it was just repeaterd and pushed back into the water. No kit for peering there. (other problems w/ Guam left as an academic eercise) /bill From kenny.sallee at gmail.com Tue Jun 7 11:51:25 2011 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Tue, 7 Jun 2011 09:51:25 -0700 Subject: Why don't ISPs peer with everyone? In-Reply-To: <96CA80CDCD822B4F9B41FB3A109C9359A4616D8732@E2K7MAILBOX1.corp.cableone.net> References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110607091733.GA24602@vacation.karoshi.com.> <57C0613A-CCAF-4662-A1C6-FF286B3D6B56@umd.edu> <96CA80CDCD822B4F9B41FB3A109C9359A4616D8732@E2K7MAILBOX1.corp.cableone.net> Message-ID: On Tue, Jun 7, 2011 at 9:08 AM, Rettke, Brian wrote: > Content providers (e.g. Netflix, Hulu, YouTube) will always try to get > their content serviced for little to no cost. The low cost, web-only plan > isn't sustainable, and the amount of Netflix traffic around the globe is a > good example; There's a lot of traffic that they aren't paying for. The > free market only works if entities self-police. But as has been expertly > stated, there's no money in that. > > I had an idea, I'm sure it's been said before: > > If we actually had solid "Tier 1 vs Tier 2 vs Tier 3" thresholds, and we > could come up with an agreeable metric, we might be able to minimize the > impact of bandwidth hogs (sorry Netflix, pointing at you). > > First - I don't work for Netflix! I'm a consumer of their product and a network engineer who mostly gets stuff. So I'd like to offer a point of distinction that's kinda bugged me whenever these conversations pop up here: Netflix the company doesn't consume bandwidth nor are *they* a bandwidth hog. The consumer is the bandwidth hog. And the consumer pays their ISP for that bandwidth. ISP's over provision in the hopes that most folks won't use what they are paying for and to help keep costs down (very valid). Companies like Netflix and even Google (I don't know this for a fact - just making logical assumptions) are not going to rely on peering arrangements of ISPs to deliver 100% of their traffic. If they did they'd place their business model in the hands of network operators who don't have Netflix's best interests in mind. They are going to use caching like products or services to bring their content closer to the consumer, develop them to be bandwidth and latency aware, or even make peering arrangements on their own (to your point). These peering arrangements and products they purchase / pay for are most likely located within Tier 1 networks in the USA. So technically, if my assumptions are correct, Netflix probably is paying for their bandwidth that exits their network. And the consumer is paying for their bandwidth. Now - Netflix like content providers may cause some of the ISP's to rethink their over provisioning strategies, but that's not my problem. I'm paying for my bandwidth, therefore, I want to use it for what I want when I want. It's my ISP's job to deliver what I'm paying for. This is just my .02 and that tangent is over for now! To the original poster - I think it'd be technically impossible to have every ISP plugged into every ISP, physically ($$ issues aside). How many ISPs are there and how many routers / ports would you need? And I'm pretty sure that most Tier 1 ISP's peer with each other - but that's an assumption not made of fact. Maybe someday when there really are no bandwidth or latency limitations an overlay routing model could abstract the physical issues we all deal with and everyone can logically peer with everyone (although I'm not sure even that would make sense) but until then a hierarchical model (Tier 1 vs Tier2 etc..) seems to me to make the most sense. Anyway, the implementation of that hierarchical Internet is driven by $$ of course. Kenny From frnkblk at iname.com Tue Jun 7 12:33:49 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 7 Jun 2011 12:33:49 -0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <201106071445.31185.fredan-nanog@fredan.se> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <201106031427.07262.fredan-nanog@fredan.se> <001c01cc2209$e727d860$b5778920$@iname.com> <201106071445.31185.fredan-nanog@fredan.se> Message-ID: <004501cc2539$0fcb3140$2f6193c0$@iname.com> I'm in the US -- could very well be available only in the N.A. market. Manuals have not been updated -- it's running with pre-GA code. Frank -----Original Message----- From: fredrik danerklint [mailto:fredan-nanog at fredan.se] Sent: Tuesday, June 07, 2011 7:45 AM To: nanog at nanog.org Cc: frnkblk at iname.com Subject: Re: Microsoft's participation in World IPv6 day Two thing about this one after have read the manual of this product. This is probably for the american market. I'm in europe. Second, nowhere in their manual is the word "ipv6" or "v6" found. > Have a ZyXEL VSG1432 right behind me where the IPv6 works pretty good > (http://www.getipv6.info/index.php/Broadband_CPE#DSL). All the DSL modem > vendors could stand improving their GUI. > > Frank > > -----Original Message----- > From: fredrik danerklint [mailto:fredan-nanog at fredan.se] > Sent: Friday, June 03, 2011 7:27 AM > To: nanog at nanog.org > Subject: Re: Microsoft's participation in World IPv6 day > > The problem is not all on Microsoft at this case. > > > For example; I've bought a ZyXEL P-2612HNU-F1(which has > 802.11n Wireless ADSL 2+ 4-port gateway 2 SIP 2 USB 3G Backup) > in december 2010. It basiclly has everything in it. > > How do I as a customer do to have a working IPv6 setup on this modem since > ZyXEL, basicilly, has decide that it will not support IPv6 at all? > > I mean, you can not say it does not have the the cpu power for handling > IPv6 > > when it can also act as a fileserver and a printserver for example. > > What they (ZyXEL) are saying to me (for not haveing IPv6 at this moment) is > that they don't have the skills to implement IPv6 in their current > products. > > > Think about all the CPE that will not be upgraded, since those that makes > them > don't care at all, even tough it probably has the cpu power to handle IPv6. > > > And I haven't even started at the network equiment that exists between me > as a > ISP and my customer (this equiment is out of my control), that can't handle > IPv6 even if my customer got an working CPE with IPv6. > > > How fun is that? > > > http://support.microsoft.com/kb/2533454/ > > > > Uh... > > > > -Bill -- //fredan From pace at jolokianetworks.com Tue Jun 7 13:42:40 2011 From: pace at jolokianetworks.com (Mark Pace) Date: Tue, 07 Jun 2011 11:42:40 -0700 Subject: ipv6 day DDoS threat? Message-ID: <4DEE7120.8000406@jolokianetworks.com> I got an interesting contact from a large company that I will leave un-named for the moment. They said that they heard specific "chatter" about DDoS of IPv6 day participant sites and even more specifically about our website. Of course they have also offered to assist us in preventing this from affecting our site. I'm very skeptical about even calling said company at this point. I'm really feeling like this is a shakedown and was wondering if anyone else had been approached in a similar fashion? Mark Pace From tad1214 at gmail.com Tue Jun 7 13:56:39 2011 From: tad1214 at gmail.com (Thomas Donnelly) Date: Tue, 07 Jun 2011 13:56:39 -0500 Subject: ipv6 day DDoS threat? In-Reply-To: <4DEE7120.8000406@jolokianetworks.com> References: <4DEE7120.8000406@jolokianetworks.com> Message-ID: On Tue, 07 Jun 2011 13:42:40 -0500, Mark Pace wrote: > I got an interesting contact from a large company that I will leave > un-named for the moment. They said that they heard specific "chatter" > about DDoS of IPv6 day participant sites and even more specifically > about our website. Of course they have also offered to assist us in > preventing this from affecting our site. I'm very skeptical about even > calling said company at this point. I'm really feeling like this is a > shakedown and was wondering if anyone else had been approached in a > similar fashion? > > > Mark Pace Just got the same phone call from "A large company" and it was a sales call. They are "offering DDoS mitigation services" I'll pass :) -=Tom Donnelly -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From nanog at jima.tk Tue Jun 7 14:01:59 2011 From: nanog at jima.tk (Jima) Date: Tue, 07 Jun 2011 14:01:59 -0500 Subject: ipv6 day DDoS threat? In-Reply-To: <4DEE7120.8000406@jolokianetworks.com> References: <4DEE7120.8000406@jolokianetworks.com> Message-ID: <4DEE75A7.6090506@jima.tk> On 06/07/2011 01:42 PM, Mark Pace wrote: > I got an interesting contact from a large company that I will leave > un-named for the moment. It wasn't Radware, was it? http://www.networkworld.com/news/2011/060611-ipv6-security.html If not, it would seem that there's no shortage of IPv6 FUD this week. Jima From bicknell at ufp.org Tue Jun 7 14:04:47 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 7 Jun 2011 12:04:47 -0700 Subject: ipv6 day DDoS threat? In-Reply-To: <4DEE7120.8000406@jolokianetworks.com> References: <4DEE7120.8000406@jolokianetworks.com> Message-ID: <20110607190447.GA18781@ussenterprise.ufp.org> In a message written on Tue, Jun 07, 2011 at 11:42:40AM -0700, Mark Pace wrote: > I got an interesting contact from a large company that I will leave > un-named for the moment. They said that they heard specific "chatter" > about DDoS of IPv6 day participant sites and even more specifically > about our website. Of course they have also offered to assist us in I thought the goal was to get everyone to try out IPv6. Doesn't that include the miscreants? :) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From tad1214 at gmail.com Tue Jun 7 14:04:50 2011 From: tad1214 at gmail.com (Thomas Donnelly) Date: Tue, 07 Jun 2011 14:04:50 -0500 Subject: ipv6 day DDoS threat? In-Reply-To: <4DEE75A7.6090506@jima.tk> References: <4DEE7120.8000406@jolokianetworks.com> <4DEE75A7.6090506@jima.tk> Message-ID: On Tue, 07 Jun 2011 14:01:59 -0500, Jima wrote: > On 06/07/2011 01:42 PM, Mark Pace wrote: >> I got an interesting contact from a large company that I will leave >> un-named for the moment. > > It wasn't Radware, was it? > > http://www.networkworld.com/news/2011/060611-ipv6-security.html > > If not, it would seem that there's no shortage of IPv6 FUD this week. > > Jima > I can confirm it was not Radware. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From nathan at atlasnetworks.us Tue Jun 7 14:04:54 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 7 Jun 2011 19:04:54 +0000 Subject: ipv6 day DDoS threat? In-Reply-To: <4DEE7120.8000406@jolokianetworks.com> References: <4DEE7120.8000406@jolokianetworks.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B48666A@ex-mb-1.corp.atlasnetworks.us> We got the same call. I think they just trolled on through the IPv6Day participants list. They indicated that we were likely to be 'specifically targeted' as a result of 'putting ourselves out there'. I suspect it's merely a misprogrammed sales drone spewing fear-infused garbage. The caller claimed to represent Verisign (though we took no steps to verify that claim). If anyone from Verisign is on the list, you may want to look into this, especially if this is actually coming from one of your employees. Nathan > -----Original Message----- > From: Mark Pace [mailto:pace at jolokianetworks.com] > Sent: Tuesday, June 07, 2011 11:43 AM > To: nanog at nanog.org > Subject: ipv6 day DDoS threat? > > I got an interesting contact from a large company that I will leave un-named > for the moment. They said that they heard specific "chatter" > about DDoS of IPv6 day participant sites and even more specifically about our > website. Of course they have also offered to assist us in preventing this from > affecting our site. I'm very skeptical about even calling said company at this > point. I'm really feeling like this is a shakedown and was wondering if anyone > else had been approached in a similar fashion? > > > Mark Pace > > From 1qaz2wsx3edc at gmail.com Tue Jun 7 14:16:36 2011 From: 1qaz2wsx3edc at gmail.com (1qaz 2wsx) Date: Tue, 7 Jun 2011 14:16:36 -0500 Subject: ipv6 day DDoS threat? Message-ID: We too just received this phone call. The company was Verisign, felt an awful lot like a protection racket. Very unwelcomed phone call. Buyer Beware. ^1qaz2wsx^ From paul at paulstewart.org Tue Jun 7 14:16:55 2011 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 7 Jun 2011 15:16:55 -0400 Subject: ipv6 day DDoS threat? In-Reply-To: References: <4DEE7120.8000406@jolokianetworks.com> Message-ID: <014001cc2547$780faa20$682efe60$@org> Hehe.. yeah, no thanks - I'll do it myself with our existing DDOS mitigation. ;) Paul -----Original Message----- From: Thomas Donnelly [mailto:tad1214 at gmail.com] Sent: Tuesday, June 07, 2011 2:57 PM To: nanog at nanog.org Subject: Re: ipv6 day DDoS threat? On Tue, 07 Jun 2011 13:42:40 -0500, Mark Pace wrote: > I got an interesting contact from a large company that I will leave > un-named for the moment. They said that they heard specific "chatter" > about DDoS of IPv6 day participant sites and even more specifically > about our website. Of course they have also offered to assist us in > preventing this from affecting our site. I'm very skeptical about even > calling said company at this point. I'm really feeling like this is a > shakedown and was wondering if anyone else had been approached in a > similar fashion? > > > Mark Pace Just got the same phone call from "A large company" and it was a sales call. They are "offering DDoS mitigation services" I'll pass :) -=Tom Donnelly -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From tjc at ecs.soton.ac.uk Tue Jun 7 14:18:11 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 7 Jun 2011 20:18:11 +0100 Subject: ipv6 day DDoS threat? In-Reply-To: <20110607190447.GA18781@ussenterprise.ufp.org> References: <4DEE7120.8000406@jolokianetworks.com> <20110607190447.GA18781@ussenterprise.ufp.org> <0A6C7355-FCF1-4438-A4A4-593B18717749@ecs.soton.ac.uk> Message-ID: On 7 Jun 2011, at 20:04, Leo Bicknell wrote: > > I thought the goal was to get everyone to try out IPv6. Doesn't that > include the miscreants? :) Well, if I was evil I'd be looking for IPv6 back doors tomorrow... Tim From ck at sandcastl.es Tue Jun 7 14:20:52 2011 From: ck at sandcastl.es (christian koch) Date: Tue, 7 Jun 2011 12:20:52 -0700 Subject: ipv6 day DDoS threat? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B48666A@ex-mb-1.corp.atlasnetworks.us> References: <4DEE7120.8000406@jolokianetworks.com> <8C26A4FDAE599041A13EB499117D3C286B48666A@ex-mb-1.corp.atlasnetworks.us> Message-ID: I can confirm, it was indeed Verisign who emailed me with the same message. I am slightly disappointed by this course of action, needless to say I am not surprised, because this kind of behavior is expected from sales people. I had a bit more respect for them, however... -ck On Tue, Jun 7, 2011 at 12:04 PM, Nathan Eisenberg wrote: > We got the same call. I think they just trolled on through the IPv6Day > participants list. They indicated that we were likely to be 'specifically > targeted' as a result of 'putting ourselves out there'. I suspect it's > merely a misprogrammed sales drone spewing fear-infused garbage. > > The caller claimed to represent Verisign (though we took no steps to verify > that claim). If anyone from Verisign is on the list, you may want to look > into this, especially if this is actually coming from one of your employees. > > Nathan > > > -----Original Message----- > > From: Mark Pace [mailto:pace at jolokianetworks.com] > > Sent: Tuesday, June 07, 2011 11:43 AM > > To: nanog at nanog.org > > Subject: ipv6 day DDoS threat? > > > > I got an interesting contact from a large company that I will leave > un-named > > for the moment. They said that they heard specific "chatter" > > about DDoS of IPv6 day participant sites and even more specifically about > our > > website. Of course they have also offered to assist us in preventing > this from > > affecting our site. I'm very skeptical about even calling said company > at this > > point. I'm really feeling like this is a shakedown and was wondering if > anyone > > else had been approached in a similar fashion? > > > > > > Mark Pace > > > > > > > > From Valdis.Kletnieks at vt.edu Tue Jun 7 14:32:22 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 07 Jun 2011 15:32:22 -0400 Subject: ipv6 day DDoS threat? In-Reply-To: Your message of "Tue, 07 Jun 2011 20:18:11 BST." References: <4DEE7120.8000406@jolokianetworks.com> <20110607190447.GA18781@ussenterprise.ufp.org> <0A6C7355-FCF1-4438-A4A4-593B18717749@ecs.soton.ac.uk> Message-ID: <23580.1307475142@turing-police.cc.vt.edu> On Tue, 07 Jun 2011 20:18:11 BST, Tim Chown said: > > On 7 Jun 2011, at 20:04, Leo Bicknell wrote: > > > > I thought the goal was to get everyone to try out IPv6. Doesn't that > > include the miscreants? :) > > Well, if I was evil I'd be looking for IPv6 back doors tomorrow... No, that's when everybody will be looking closely for the smallest sign of wonkyness. What the *truly* evil will do is wait till Thursday for all the sites that forgot to turn IPv6 off. Or you got whacked last night and don't know it yet. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joelja at bogus.com Tue Jun 7 07:12:01 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 7 Jun 2011 05:12:01 -0700 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: <7FBD02B2-DAB9-4B5F-921D-8539D76228BC@bogus.com> On Jun 6, 2011, at 12:53 PM, Justin M. Streiner wrote: > On Mon, 6 Jun 2011, rucasbrown at hushmail.com wrote: > >> All the whole "don't peer with this guy" only makes your customers >> have worse latencies and paths to other people, making the Internet >> less healthy. > > Not necessarily. Peering with an ISP who wants to take the traffic between your network and theirs through a saturated pipe, an overloaded router, or across an MPLS pipe with 13 underlying hops (each of which could be a choke point themselves) will not make your end-to-end latencies any better. > > As others have mentioned, some ISPs do have friendly peering policies. This is particularly true for ISPs that are co-located at the same IXP, because much of the opex is already baked into the ISP's relationship with the IXP. > > The reason most of the larger ISPs, particularly those who live in the DFZ, have peering policies (especially for settlement-free peering) that could be construed as less friendly to smaller networks is because those guys want to sell you transit, rather than let you peer for free, or for less than a the full transit rate. It doesn't make financial sense for them to exchange bits with you for free, when they can make money off of those same bits if you buy transit instead. carrying packets long distances cost more than carrying them short distances... large networks have an incentive to have the cost of that conveyance be reflected in peering relationship figuring out what if relationship makes sense in the marginal sense implies both parties see mutual benifit. > jms > From John.Herbert at usc-bt.com Tue Jun 7 15:25:59 2011 From: John.Herbert at usc-bt.com (John.Herbert at usc-bt.com) Date: Tue, 7 Jun 2011 20:25:59 +0000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> Message-ID: Bill Woodcock [mailto:woody at pch.net] spake: >http://support.microsoft.com/kb/2533454/ >Uh... This does rather assume that users can access Google/Bing (both IPv6 day participants) to search for a solution to the problems they are experiencing, and then that they can actually access the KB article... j. From pheller at me.com Tue Jun 7 15:49:18 2011 From: pheller at me.com (Phillip Heller) Date: Tue, 07 Jun 2011 16:49:18 -0400 Subject: automated router config back up - summary In-Reply-To: <20110607084128.GF48623@macbook.catpipe.net> References: <20110607084128.GF48623@macbook.catpipe.net> Message-ID: <9CCEC8EF-BB55-4413-89FE-4045A53745E2@me.com> There is also http://sourceforge.net/projects/dis -- The latest version in CVS is best. It's a project I wrote for use at a previous employer, which downloads tens of thousands of configs per night. It also facilitates easier development of device scripts and their parallel execution, deployment of OS upgrades to cisco gear (not difficult to extend to other devices), as well as automates interactive login. --phil On Jun 7, 2011, at 4:41 AM, Phil Regnauld wrote: > Ok, so based on what's been written here, here is the list of tools > mentioned so far -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4385 bytes Desc: not available URL: From Christopher.Palmer at microsoft.com Tue Jun 7 17:33:28 2011 From: Christopher.Palmer at microsoft.com (Christopher Palmer) Date: Tue, 7 Jun 2011 22:33:28 +0000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <4DE81ADA.3010806@jima.tk> References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> <4DE81ADA.3010806@jima.tk> Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CE3F67C@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> We're very concerned about permanently configuring hosts into a non-standard state. That is one reason our World IPv6 Day fix is only a temporary modification of the Windows sorting order and isn't being pushed through Windows Update. Permanently disabling IPv6 as a solution to the "IPv6 brokenness" issue is NOT recommended. Turning a transitory problem (hosts on broken networks) into a permanent problem (hosts that don't use IPv6 correctly) - risks creating a serious long-term headache. ---------------------------- Christopher.Palmer at Microsoft.com Program Manager IPv6 @ Windows -----Original Message----- From: Jima [mailto:nanog at jima.tk] Sent: Thursday, June 02, 2011 4:21 PM To: nanog at nanog.org Subject: Re: Microsoft's participation in World IPv6 day On 2011-06-02 17:26, Bill Woodcock wrote: > http://support.microsoft.com/kb/2533454/ > > Uh... While I'm far from a Microsoft apologist (not really even a fan, TBH), it's worth pointing out that they're not pushing this out via Windows Update or anything. It's intended only as a remedy for the (as they themselves claim) <0.1% of users who may encounter issues next Wednesday: http://blogs.technet.com/b/ipv6/archive/2011/02/11/ipv6-day.aspx Fun as it might be to take it out of context, at least they're not telling people to disable IPv6 entirely (like some organizations still are). Jima From simon.allard at team.orcon.net.nz Tue Jun 7 18:00:58 2011 From: simon.allard at team.orcon.net.nz (Simon Allard) Date: Wed, 8 Jun 2011 11:00:58 +1200 Subject: Spare part handling in the LA area Message-ID: <87EBACEAA871304B8AED4B52D96B3E94293DC81E16@exmbx01.hosted.orcon.net.nz> Hi Nanog We are an ISP/ASP in New Zealand, but we have a presence in Equinix LA1. We are looking for a services company that can store spare router/mux parts in the LA area, and who can deliver with a good SLA to the Equinix LA1 site. We will eventually be looking for the same type of service in the San Jose area, so a company that has a wide presence would be preferred. Please contact me off list if you have suggestions/recommendations Happy ipv6 day! J Regards Simon Allard Head of Networks Orcon From iljitsch at muada.com Tue Jun 7 18:13:54 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 8 Jun 2011 01:13:54 +0200 Subject: IPv6 day fun is beginning! Message-ID: www.juniper.net is on IPv6 www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though www.level3.com works fine over v4 but shows a 404 over IPv6 www.simobil.si is temporarily unavailable over IPv6 but works fine over IPv4 From jared at puck.nether.net Tue Jun 7 18:15:16 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 7 Jun 2011 19:15:16 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: > www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though If you go to www.v6.facebook.com it works, but it seems they have some problem on their main site. I am seeing some issues reaching them over IPv6. - Jared From jbates at brightok.net Tue Jun 7 18:16:17 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 07 Jun 2011 18:16:17 -0500 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110607091733.GA24602@vacation.karoshi.com.> <20110607150549.GH20444@hezmatt.org> Message-ID: <4DEEB141.9090808@brightok.net> On 6/7/2011 11:38 AM, Jon Lewis wrote: > Additionally, we share at least one common transit provider, so we'd > be trading <1ms for 1-2ms. Obviously, if we were talking about a > leased line with any MRC, the answer would be hell no. Since we're > able to utilize fiber inside the building with no MRC, the answer is > more of a "why bother?" It's not going to save either of us any > meaningful amount of transit bandwidth $/capacity. That's what it really boils down to. How much money can be saved versus performance. If I'm doing a lot of throughput to a specific network, it makes sense that I might want to connect to them, especially if that connection either 1) saves me money or 2) gives me superior QOS/load balancing without a cost increase. Anything less than 200mbit of traffic isn't even worth me considering these days, and as I grow, I'm sure that number will increase. Content providers generally won't peer unless you meet certain traffic requirements for the same reason. Jack From jbates at brightok.net Tue Jun 7 18:19:02 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 07 Jun 2011 18:19:02 -0500 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: <4DEEB1E6.5040008@brightok.net> On 6/7/2011 6:15 PM, Jared Mauch wrote: > On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: > >> www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though > If you go to www.v6.facebook.com it works, but it seems they have some problem on their main site. I am seeing some issues reaching them over IPv6. > > - Jared > > At this second, I don't see the AAAA, though they may only be providing it to v6 dns servers? Jack From John.Herbert at usc-bt.com Tue Jun 7 18:22:58 2011 From: John.Herbert at usc-bt.com (John.Herbert at usc-bt.com) Date: Tue, 7 Jun 2011 23:22:58 +0000 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: No issues connecting to FB for me on IPv6 (both to www.v6.facebook.com and to the AAAA returned by www.facebook.com now). Interesting (perhaps) side note - www.facebook.com has a AAAA, but "facebook.com" does not. Google / Youtube records are up and running nicely also. J. -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Tuesday, June 07, 2011 7:15 PM To: Iljitsch van Beijnum Cc: NANOG list Subject: Re: IPv6 day fun is beginning! On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: > www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though If you go to www.v6.facebook.com it works, but it seems they have some problem on their main site. I am seeing some issues reaching them over IPv6. - Jared From jared at puck.nether.net Tue Jun 7 18:22:38 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 7 Jun 2011 19:22:38 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: <4DEEB1E6.5040008@brightok.net> References: <4DEEB1E6.5040008@brightok.net> Message-ID: <915CBEFC-E774-4A5D-B8A2-C2D126DD7E16@puck.nether.net> On Jun 7, 2011, at 7:19 PM, Jack Bates wrote: > On 6/7/2011 6:15 PM, Jared Mauch wrote: >> On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: >> >>> www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though >> If you go to www.v6.facebook.com it works, but it seems they have some problem on their main site. I am seeing some issues reaching them over IPv6. >> >> - Jared >> >> > At this second, I don't see the AAAA, though they may only be providing it to v6 dns servers? They were serving up 2620:0:1cff:ff01::23 from my universe, but it was not accepting tcp/80 requests. They also may have pulled the trigger a bit earlier than expected.. This may explain the problem if people confused 2300 with 0000 due to daylight savings time or something else. - Jared From jra at baylink.com Tue Jun 7 18:22:04 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 7 Jun 2011 19:22:04 -0400 (EDT) Subject: IPv6 day fun is beginning! In-Reply-To: Message-ID: <6135154.138.1307488924447.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Herbert" > No issues connecting to FB for me on IPv6 (both to www.v6.facebook.com > and to the AAAA returned by www.facebook.com now). > > Interesting (perhaps) side note - www.facebook.com has a AAAA, but > "facebook.com" does not. And "thefacebook.com"? :-) Cheers, -- jr 'Yes; that's operational. How many obscure aliases do *you* have?' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jerome at ceriz.fr Tue Jun 7 18:39:16 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Wed, 8 Jun 2011 01:39:16 +0200 Subject: Why don't ISPs peer with everyone? In-Reply-To: <4DEEB141.9090808@brightok.net> References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110607091733.GA24602@vacation.karoshi.com.> <20110607150549.GH20444@hezmatt.org> <4DEEB141.9090808@brightok.net> Message-ID: 2011/6/8 Jack Bates : > That's what it really boils down to. How much money can be saved versus > performance. If I'm doing a lot of throughput to a specific network, it > makes sense that I might want to connect to them, especially if that > connection either 1) saves me money or 2) gives me superior QOS/load > balancing without a cost increase. > > Anything less than 200mbit of traffic isn't even worth me considering these > days, and as I grow, I'm sure that number will increase. Content providers > generally won't peer unless you meet certain traffic requirements for the > same reason. That's certainly a valid approach for direct (private) peering, it's not applicable to IXPs offering route servers. -- J?r?me Nicolle From jbates at brightok.net Tue Jun 7 18:47:28 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 07 Jun 2011 18:47:28 -0500 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> <20110607091733.GA24602@vacation.karoshi.com.> <20110607150549.GH20444@hezmatt.org> <4DEEB141.9090808@brightok.net> Message-ID: <4DEEB890.6010805@brightok.net> On 6/7/2011 6:39 PM, J?r?me Nicolle wrote: > > That's certainly a valid approach for direct (private) peering, it's > not applicable to IXPs offering route servers. > > In my case, I have to justify the long haul to an IXP as appropriate cost savings, and given that haul often costs more than I pay for transit, it still hasn't justified. Perhaps when I get to multiple 10GE traffic loads and justify leasing a 600 mile dark fiber ring to DFW. Jack From jared at puck.nether.net Tue Jun 7 18:47:59 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 7 Jun 2011 19:47:59 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> yahoo is already serving up the AAAA as well. Thanks Igor! Looking forward to seeing the traffic spike today :) - Jared On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: > www.juniper.net is on IPv6 > > www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though > > www.level3.com works fine over v4 but shows a 404 over IPv6 > > www.simobil.si is temporarily unavailable over IPv6 but works fine over IPv4 From pete at altadena.net Tue Jun 7 18:56:36 2011 From: pete at altadena.net (Pete Carah) Date: Tue, 07 Jun 2011 19:56:36 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: <4DEEBAB4.9000507@altadena.net> On 06/07/2011 07:22 PM, John.Herbert at usc-bt.com wrote: > No issues connecting to FB for me on IPv6 (both to www.v6.facebook.com and to the AAAA returned by www.facebook.com now). > > Interesting (perhaps) side note - www.facebook.com has a AAAA, but "facebook.com" does not. > > Google / Youtube records are up and running nicely also. > > J. > > > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Tuesday, June 07, 2011 7:15 PM > To: Iljitsch van Beijnum > Cc: NANOG list > Subject: Re: IPv6 day fun is beginning! > > > On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: > >> www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though > If you go to www.v6.facebook.com it works, but it seems they have some problem on their main site. I am seeing some issues reaching them over IPv6. > > - Jared Here I don't see any v6 for either facebook.com or www.facebook.com (I run my own resolver from within comcast, and the resolver and my boxes are all v6 enabled and dual-stacked, have been for over a year). I did see a cute pair of puns in cisco's v6-day address: cisco.v6day.akadns.net has IPv6 address 2001:420:80:1:c:15c0:d06:f00d (check the last 32 bits, and the 32 before...) -- Pete From pete at altadena.net Tue Jun 7 19:02:13 2011 From: pete at altadena.net (Pete Carah) Date: Tue, 07 Jun 2011 20:02:13 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: <4DEEBAB4.9000507@altadena.net> References: <4DEEBAB4.9000507@altadena.net> Message-ID: <4DEEBC05.10100@altadena.net> On 06/07/2011 07:56 PM, Pete Carah wrote: > On 06/07/2011 07:22 PM, John.Herbert at usc-bt.com wrote: >> No issues connecting to FB for me on IPv6 (both to www.v6.facebook.com and to the AAAA returned by www.facebook.com now). >> >> Interesting (perhaps) side note - www.facebook.com has a AAAA, but "facebook.com" does not. >> >> Google / Youtube records are up and running nicely also. .... > Here I don't see any v6 for either facebook.com or www.facebook.com (I > run my own resolver from within comcast, and the resolver and my boxes > are all v6 enabled and dual-stacked, have been for over a year). > Google must be exercising very fine control over their dns; it turned v6 on at 19:58 exactly. Yahoo's is still not on as seen from here. www.facebook.com (but not facebook.com) just turned on here too (after google). another hex-speak spelling... -- Pete From fredan-nanog at fredan.se Tue Jun 7 19:04:33 2011 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Wed, 8 Jun 2011 02:04:33 +0200 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: <201106080204.34356.fredan-nanog@fredan.se> This is from Sweden. $ dig any www.facebook.com @ns1.facebook.com ; <<>> DiG 9.7.3 <<>> any www.facebook.com @ns1.facebook.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61742 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.facebook.com. IN ANY ;; AUTHORITY SECTION: www.facebook.com. 86400 IN NS glb1.facebook.com. www.facebook.com. 86400 IN NS glb2.facebook.com. ;; ADDITIONAL SECTION: glb1.facebook.com. 3600 IN A 69.171.239.10 glb2.facebook.com. 3600 IN A 69.171.255.10 ;; Query time: 58 msec ;; SERVER: 204.74.66.132#53(204.74.66.132) ;; WHEN: Wed Jun 8 02:01:37 2011 ;; MSG SIZE rcvd: 104 No AAAA records at the moment. Checked alll their nameservers. -- //fredan From lstewart at superb.net Tue Jun 7 19:08:26 2011 From: lstewart at superb.net (Landon Stewart) Date: Tue, 7 Jun 2011 17:08:26 -0700 Subject: IPv6 day fun is beginning! In-Reply-To: <201106080204.34356.fredan-nanog@fredan.se> References: <201106080204.34356.fredan-nanog@fredan.se> Message-ID: I'll be watching this page probably. http://www.worldipv6day.org/participants/ From iljitsch at muada.com Tue Jun 7 19:08:57 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 8 Jun 2011 02:08:57 +0200 Subject: IPv6 day fun is beginning! In-Reply-To: <4DEEBC05.10100@altadena.net> References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> Message-ID: On 8 jun 2011, at 2:02, Pete Carah wrote: > www.facebook.com (but not facebook.com) just turned on here too (after > google). another hex-speak spelling... I'm using my iPhone as the IPv6-only canary. www.facebook.com now seems to work, but it redirects to m.facebook.com which doesn't have IPv6. This seems to be a trend, yahoo and cnn do the same thing. Annoying. From bill at herrin.us Tue Jun 7 19:10:55 2011 From: bill at herrin.us (William Herrin) Date: Tue, 7 Jun 2011 20:10:55 -0400 Subject: Why don't ISPs peer with everyone? In-Reply-To: <20110606221937.B362C6F437@smtp.hushmail.com> References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: On Mon, Jun 6, 2011 at 6:19 PM, wrote: > why don't ISPs peer with every other ISP? 1. For those who can pull it off, getting paid twice for each packet is better than getting paid once. 2. Your service has a value per byte and a cost per byte. If your value is less than your cost, you go out of business. Open peering facilitates greater consumption on the part of your customers. Unless you're structured to charge them more for that increased consumption, it reduces the value of each byte you pass. Unless you're peering with someone in the same or higher tier (who you'd otherwise have to pay for transit) the odds are you're reducing the value of your bytes faster than you're reducing your cost. Personally, I'd love to see 95th percentile billing applied universally with everybody getting a large pipe the same way everybody gets a 200 amp electrical service. The problem with that notion is that A) consumers are hooked on "unlimited," and B) your toaster doesn't get hacked and start consuming 200 amps all day without your knowledge. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sethm at rollernet.us Tue Jun 7 19:13:22 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 07 Jun 2011 17:13:22 -0700 Subject: IPv6 day fun is beginning! In-Reply-To: <201106080204.34356.fredan-nanog@fredan.se> References: <201106080204.34356.fredan-nanog@fredan.se> Message-ID: <4DEEBEA2.3060103@rollernet.us> On 6/7/2011 17:04, fredrik danerklint wrote: > This is from Sweden. > > $ dig any www.facebook.com @ns1.facebook.com > > ; <<>> DiG 9.7.3 <<>> any www.facebook.com @ns1.facebook.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61742 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.facebook.com. IN ANY > > ;; AUTHORITY SECTION: > www.facebook.com. 86400 IN NS glb1.facebook.com. > www.facebook.com. 86400 IN NS glb2.facebook.com. > > ;; ADDITIONAL SECTION: > glb1.facebook.com. 3600 IN A 69.171.239.10 > glb2.facebook.com. 3600 IN A 69.171.255.10 > > ;; Query time: 58 msec > ;; SERVER: 204.74.66.132#53(204.74.66.132) > ;; WHEN: Wed Jun 8 02:01:37 2011 > ;; MSG SIZE rcvd: 104 > > > No AAAA records at the moment. Checked alll their nameservers. > Same results here, western US. ~Seth From rcarpen at network1.net Tue Jun 7 19:13:20 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 07 Jun 2011 20:13:20 -0400 (EDT) Subject: IPv6 day fun is beginning! In-Reply-To: <201106080204.34356.fredan-nanog@fredan.se> Message-ID: <0c2b3dd6-5247-4682-8fd0-255814cc2c44@zimbra.network1.net> I'm getting v6 for facebook now. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > This is from Sweden. > > $ dig any www.facebook.com @ns1.facebook.com > > ; <<>> DiG 9.7.3 <<>> any www.facebook.com @ns1.facebook.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61742 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.facebook.com. IN ANY > > ;; AUTHORITY SECTION: > www.facebook.com. 86400 IN NS glb1.facebook.com. > www.facebook.com. 86400 IN NS glb2.facebook.com. > > ;; ADDITIONAL SECTION: > glb1.facebook.com. 3600 IN A 69.171.239.10 > glb2.facebook.com. 3600 IN A 69.171.255.10 > > ;; Query time: 58 msec > ;; SERVER: 204.74.66.132#53(204.74.66.132) > ;; WHEN: Wed Jun 8 02:01:37 2011 > ;; MSG SIZE rcvd: 104 > > > No AAAA records at the moment. Checked alll their nameservers. > > -- > //fredan > > > From jared at puck.nether.net Tue Jun 7 19:14:22 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 7 Jun 2011 20:14:22 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> Message-ID: <47F2C08A-E828-4C2A-8C3D-28C008517221@puck.nether.net> On Jun 7, 2011, at 8:08 PM, Iljitsch van Beijnum wrote: > On 8 jun 2011, at 2:02, Pete Carah wrote: > >> www.facebook.com (but not facebook.com) just turned on here too (after >> google). another hex-speak spelling... > > I'm using my iPhone as the IPv6-only canary. www.facebook.com now seems to work, but it redirects to m.facebook.com which doesn't have IPv6. This seems to be a trend, yahoo and cnn do the same thing. Annoying. Props to google for doing it right, e.g.: maps.googleapis.com AAAA gg.google.com AAAA safebrowsing.clients.google.com AAAA Thank you google! - Jared From jra at baylink.com Tue Jun 7 19:10:11 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 7 Jun 2011 20:10:11 -0400 (EDT) Subject: IPv6 day - Facebook announcements Message-ID: <29364062.140.1307491811238.JavaMail.root@benjamin.baylink.com> In addition to themselves announcing this, NASA.gov and Markertek.com have announced there that they're participating with their websites; I'll reply to this posting if I see any others (and if anyone better positioned to report on their success posts, I'll pass it along). Cheers, -- jr 'yes; just to prove I know the difference' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From scott at doc.net.au Tue Jun 7 19:16:00 2011 From: scott at doc.net.au (Scott Howard) Date: Tue, 7 Jun 2011 17:16:00 -0700 Subject: [v6z] Re: IPv6 day fun is beginning! In-Reply-To: <201106080204.34356.fredan-nanog@fredan.se> References: <201106080204.34356.fredan-nanog@fredan.se> Message-ID: That's because you're asking the wrong nameservers. The response you're getting is pointing you to the correct nameservers (glb1/glb2.facebook.com) which are defintely returning AAAA records for me : $ dig +short aaaa www.facebook.com @glb1.facebook.com 2620:0:1c08:4000:face:b00c:0:3 Scott. On Tue, Jun 7, 2011 at 5:04 PM, fredrik danerklint wrote: > This is from Sweden. > > $ dig any www.facebook.com @ns1.facebook.com > > ; <<>> DiG 9.7.3 <<>> any www.facebook.com @ns1.facebook.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61742 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.facebook.com. IN ANY > > ;; AUTHORITY SECTION: > www.facebook.com. 86400 IN NS glb1.facebook.com. > www.facebook.com. 86400 IN NS glb2.facebook.com. > > ;; ADDITIONAL SECTION: > glb1.facebook.com. 3600 IN A 69.171.239.10 > glb2.facebook.com. 3600 IN A 69.171.255.10 > > ;; Query time: 58 msec > ;; SERVER: 204.74.66.132#53(204.74.66.132) > ;; WHEN: Wed Jun 8 02:01:37 2011 > ;; MSG SIZE rcvd: 104 > > > No AAAA records at the moment. Checked alll their nameservers. > > -- > //fredan > > From pete at altadena.net Tue Jun 7 19:16:44 2011 From: pete at altadena.net (Pete Carah) Date: Tue, 07 Jun 2011 20:16:44 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> Message-ID: <4DEEBF6C.4050305@altadena.net> > On 8 jun 2011, at 2:02, Pete Carah wrote: > >> www.facebook.com (but not facebook.com) just turned on here too (after >> google). another hex-speak spelling... > I'm using my iPhone as the IPv6-only canary. www.facebook.com now seems to work, but it redirects to m.facebook.com which doesn't have IPv6. This seems to be a trend, yahoo and cnn do the same thing. Annoying. My iphone picks up a v6 address from our wireless network but not from AT&T as far as I can tell. google actually enabled a v6 address for at least part of their picture cdn along with the top page. I might try the iphone since it gets redirected to m.* a lot, though I'd presume (Cameron notwithstanding...) that very few of the participants are enabling their mobile infrastructure for v6 yet. OTOH, see: %host m.google.com m.google.com is an alias for mobile.l.google.com. mobile.l.google.com has address 72.14.204.193 mobile.l.google.com has IPv6 address 2001:4860:800f::c1 So far, looks like Google has done a good job. I don't know if they are doing any of their geolocation-based dns on the v6 stuff; my v6 address is from HE at ashburn... -- Pete From ryanczak at gmail.com Tue Jun 7 19:16:41 2011 From: ryanczak at gmail.com (Matt Ryanczak) Date: Tue, 07 Jun 2011 20:16:41 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> Message-ID: <4DEEBF69.2050805@gmail.com> On 06/07/2011 08:08 PM, Iljitsch van Beijnum wrote: > I'm using my iPhone as the IPv6-only canary. www.facebook.com now seems to work, but it redirects to m.facebook.com which doesn't have IPv6. This seems to be a trend, yahoo and cnn do the same thing. Annoying. Indeed. Verizon LTE is v6 enabled but the user-agent on my phone denies me an IPv6 experience. From jbates at brightok.net Tue Jun 7 19:20:06 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 07 Jun 2011 19:20:06 -0500 Subject: IPv6 day fun is beginning! In-Reply-To: <4DEEBEA2.3060103@rollernet.us> References: <201106080204.34356.fredan-nanog@fredan.se> <4DEEBEA2.3060103@rollernet.us> Message-ID: <4DEEC036.9020806@brightok.net> On 6/7/2011 7:13 PM, Seth Mattinen wrote: > On 6/7/2011 17:04, fredrik danerklint wrote: >> This is from Sweden. >> >> $ dig any www.facebook.com @ns1.facebook.com >> >> ;<<>> DiG 9.7.3<<>> any www.facebook.com @ns1.facebook.com >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61742 >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 >> ;; WARNING: recursion requested but not available >> >> ;; QUESTION SECTION: >> ;www.facebook.com. IN ANY >> >> ;; AUTHORITY SECTION: >> www.facebook.com. 86400 IN NS glb1.facebook.com. >> www.facebook.com. 86400 IN NS glb2.facebook.com. >> >> ;; ADDITIONAL SECTION: >> glb1.facebook.com. 3600 IN A 69.171.239.10 >> glb2.facebook.com. 3600 IN A 69.171.255.10 >> >> ;; Query time: 58 msec >> ;; SERVER: 204.74.66.132#53(204.74.66.132) >> ;; WHEN: Wed Jun 8 02:01:37 2011 >> ;; MSG SIZE rcvd: 104 >> >> >> No AAAA records at the moment. Checked alll their nameservers. >> > > Same results here, western US. > This appears to be normal, but check the authoritative servers it gives. ;; AUTHORITY SECTION: www.facebook.com. 86400 IN NS glb1.facebook.com. www.facebook.com. 86400 IN NS glb2.facebook.com. They respond with AAAA with aa bit set. From michael at rancid.berkeley.edu Tue Jun 7 19:23:57 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 7 Jun 2011 17:23:57 -0700 (PDT) Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: On Wed, 8 Jun 2011, Iljitsch van Beijnum wrote: > www.juniper.net is on IPv6 > > www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though Working great for me. Getting to it via HE. > www.level3.com works fine over v4 but shows a 404 over IPv6 Yes, I am seeing that too. Cute. michael From remy.sanchez at hyperthese.net Tue Jun 7 19:24:11 2011 From: remy.sanchez at hyperthese.net (=?UTF-8?B?UsOpbXkgU2FuY2hleg==?=) Date: Wed, 08 Jun 2011 02:24:11 +0200 Subject: IPv6 day fun is beginning! In-Reply-To: <0c2b3dd6-5247-4682-8fd0-255814cc2c44@zimbra.network1.net> References: <0c2b3dd6-5247-4682-8fd0-255814cc2c44@zimbra.network1.net> Message-ID: <4DEEC12B.90006@hyperthese.net> On 06/08/2011 02:13 AM, Randy Carpenter wrote: > I'm getting v6 for facebook now. www.facebook.com is v6 here, but I see no AAAA for the fbcdn.net subdomains. -- R?my Sanchez -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From jsw at inconcepts.biz Tue Jun 7 19:28:10 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 7 Jun 2011 20:28:10 -0400 Subject: v6 transit swaps harmful Message-ID: In case there are folks who missed this in the past few years, we will soon be past the point where IPv6 transit swaps and other incubation tools are acceptable to customers. How is it that Tiscali and Sprint can only get together via IIJ? Who is to blame? From my perspective, all three networks. I'll spare you the rest of my hand-waving and just paste the route: % host -t AAAA www.sprint.net www.sprint.net has IPv6 address 2600:: 2600::/29 AS path: 3257 2497 6175 1239 1239 1239 1239 1239 1239 1239 I % traceroute6 -q1 -f2 2600:: traceroute6 to 2600:: (2600::) from [redacted], 64 hops max, 12 byte packets Skipping 1 intermediate hops 2 xe-10-3-0.nyc20.ip6.tinet.net (2001:668:0:2::1:892) 10.896 ms 3 2001:504:1::a500:2497:1 (2001:504:1::a500:2497:1) 13.511 ms 4 sjc002bb01.iij.net (2001:48b0:bb00:8019::4008) 89.263 ms 5 sjc002ix02.iij.net (2001:48b0:bb03:f::4015) 87.075 ms 6 sl-bb1v6-sj-t-40.sprintv6.net (2001:440:eeee:ffcd::1) 92.491 ms 7 sl-crs2-sj-po0-1-4-0.v6.sprintlink.net (2600:0:2:1239:144:232:1:123) 89.333 ms 8 sl-crs1-sj-po0-9-5-0.v6.sprintlink.net (2600:0:2:1239:144:232:2:108) 95.966 ms 9 sl-crs2-ria-po0-3-5-0.v6.sprintlink.net (2600:0:2:1239:144:232:9:114) 97.788 ms 10 sl-crs2-fw-po0-13-2-0.v6.sprintlink.net (2600:0:2:1239:144:232:25:160) 173.331 ms 11 sl-crs1-fw-po0-12-0-0.v6.sprintlink.net (2600:0:2:1239:144:232:18:145) 165.577 ms 12 sl-crs3-fw-po0-7-0-0.v6.sprintlink.net (2600:0:2:1239:144:232:1:45) 167.203 ms 13 sl-crs3-atl-po0-2-0-0.v6.sprintlink.net (2600:0:2:1239:144:232:8:20) 169.195 ms 14 sl-crs1-atl-po0-11-0-0.v6.sprintlink.net (2600:0:2:1239:144:232:4:48) 170.922 ms 15 sl-crs1-ffx-po0-8-0-0.v6.sprintlink.net (2600:0:2:1239:144:232:18:119) 172.688 ms 16 sl-crs1-orl-po0-0-0-0.v6.sprintlink.net (2600:0:2:1239:144:232:19:251) 177.762 ms 17 sl-lkdstr2-p1-0.v6.sprintlink.net (2600:0:3:1239:144:223:33:32) 177.450 ms 18 www.sprint.net (2600::) 172.235 ms -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From trejrco at gmail.com Tue Jun 7 19:31:30 2011 From: trejrco at gmail.com (TJ) Date: Tue, 7 Jun 2011 20:31:30 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: <47F2C08A-E828-4C2A-8C3D-28C008517221@puck.nether.net> References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> <47F2C08A-E828-4C2A-8C3D-28C008517221@puck.nether.net> Message-ID: On Tue, Jun 7, 2011 at 20:14, Jared Mauch wrote: > > Props to google for doing it right, e.g.: > > maps.googleapis.com AAAA > gg.google.com AAAA > safebrowsing.clients.google.com AAAA > > Thank you google! > > - Jared > ... and Gmail, too ... /TJ From fredan-nanog at fredan.se Tue Jun 7 19:33:46 2011 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Wed, 8 Jun 2011 02:33:46 +0200 Subject: [v6z] Re: IPv6 day fun is beginning! Message-ID: <201106080233.46428.fredan-nanog@fredan.se> Sorry about this. When asked for the right thing it does resolv! $ dig aaaa www.facebook.com ;; QUESTION SECTION: ;www.facebook.com. IN AAAA ;; ANSWER SECTION: www.facebook.com. 30 IN AAAA 2620:0:1c08:4000:face:b00c:0:3 > That's because you're asking the wrong nameservers. The response you're > getting is pointing you to the correct nameservers (glb1/glb2.facebook.com) > which are defintely returning AAAA records for me : > > $ dig +short aaaa www.facebook.com @glb1.facebook.com > 2620:0:1c08:4000:face:b00c:0:3 > > Scott. > > > On Tue, Jun 7, 2011 at 5:04 PM, fredrik danerklint > > wrote: > > This is from Sweden. > > > > $ dig any www.facebook.com @ns1.facebook.com > > > > ; <<>> DiG 9.7.3 <<>> any www.facebook.com @ns1.facebook.com > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61742 > > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 > > ;; WARNING: recursion requested but not available > > > > ;; QUESTION SECTION: > > ;www.facebook.com. IN ANY > > > > ;; AUTHORITY SECTION: > > www.facebook.com. 86400 IN NS glb1.facebook.com. > > www.facebook.com. 86400 IN NS glb2.facebook.com. > > > > ;; ADDITIONAL SECTION: > > glb1.facebook.com. 3600 IN A 69.171.239.10 > > glb2.facebook.com. 3600 IN A 69.171.255.10 > > > > ;; Query time: 58 msec > > ;; SERVER: 204.74.66.132#53(204.74.66.132) > > ;; WHEN: Wed Jun 8 02:01:37 2011 > > ;; MSG SIZE rcvd: 104 > > > > > > No AAAA records at the moment. Checked alll their nameservers. > > > > -- > > //fredan -- //fredan From sethm at rollernet.us Tue Jun 7 19:36:18 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 07 Jun 2011 17:36:18 -0700 Subject: [v6z] Re: IPv6 day fun is beginning! In-Reply-To: References: <201106080204.34356.fredan-nanog@fredan.se> Message-ID: <4DEEC402.1060809@rollernet.us> On 6/7/2011 17:16, Scott Howard wrote: > That's because you're asking the wrong nameservers. The response you're > getting is pointing you to the correct nameservers (glb1/glb2.facebook.com) > which are defintely returning AAAA records for me : > > $ dig +short aaaa www.facebook.com @glb1.facebook.com > 2620:0:1c08:4000:face:b00c:0:3 > Now I'm seeing it. Quite the short TTL: ; <<>> DiG 9.6-ESV-R4 <<>> AAAA www.facebook.com @glb2.facebook.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34595 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.facebook.com. IN AAAA ;; ANSWER SECTION: www.facebook.com. 30 IN AAAA 2620:0:1c00:0:face:b00c:0:1 ;; Query time: 34 msec ;; SERVER: 69.171.255.10#53(69.171.255.10) ;; WHEN: Tue Jun 7 17:32:31 2011 ;; MSG SIZE rcvd: 62 Earlier I was getting no AAAA: ; <<>> DiG 9.6-ESV-R4 <<>> AAAA www.facebook.com @glb2.facebook.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32876 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.facebook.com. IN AAAA ;; AUTHORITY SECTION: www.facebook.com. 500 IN SOA glb01.sf2p.tfbnw.net. hostmaster.facebook.com. 2008102433 10800 3600 604800 86400 ;; Query time: 29 msec ;; SERVER: 69.171.255.10#53(69.171.255.10) ;; WHEN: Tue Jun 7 16:27:29 2011 ;; MSG SIZE rcvd: 101 From jra at baylink.com Tue Jun 7 19:31:23 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 7 Jun 2011 20:31:23 -0400 (EDT) Subject: IPv6 day fun is beginning! In-Reply-To: <47F2C08A-E828-4C2A-8C3D-28C008517221@puck.nether.net> Message-ID: <24956207.142.1307493083390.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Mauch" > Props to google for doing it right, e.g.: > > maps.googleapis.com AAAA > gg.google.com AAAA > safebrowsing.clients.google.com AAAA > > Thank you google! Funny you bring up "getting all the subsidiary sties right". I tried to comment on an NPR story last night, to find that their AJAX comment popup points to *an HTTPS* server... whose cert expired at 1752 on 6/6. I pointed that out to both @nprtechteam and @acarvin around 10pET when I noticed it... and got no reply from either, which is slightly unusual for them. Worst part: Unscrollable box, so I *couldn't* just bypass it even if I'd wanted to. Oops, Mozilla... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Tue Jun 7 19:32:42 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 7 Jun 2011 20:32:42 -0400 (EDT) Subject: IPv6 day fun is beginning! In-Reply-To: <4DEEBF69.2050805@gmail.com> Message-ID: <28102750.144.1307493162523.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matt Ryanczak" > Indeed. Verizon LTE is v6 enabled but the user-agent on my phone > denies me an IPv6 experience. I thought I'd heard that LTE transport was *IPv6 only*... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From mysidia at gmail.com Tue Jun 7 19:41:03 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 7 Jun 2011 19:41:03 -0500 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: On Tue, Jun 7, 2011 at 7:10 PM, William Herrin wrote: [snip] > gets a 200 amp electrical service. The problem with that notion is > that A) consumers are hooked on "unlimited," and B) your toaster Consumers aren't getting "unlimited right now". They're getting (unknown number of databytes)/month, before the ISP speed caps, throttles, rate limits them or turns them off for "excessive usage". > doesn't get hacked and start consuming 200 amps all day without your > knowledge. Your toaster is plugged into an outlet that probably has a 20 amp circuit breaker on it. If someone hacks it without your knowledge to eat 200 amps, it will get turned off. A similar mechanism could be built into network CPEs. -- -JH From diego.veca at fb.com Tue Jun 7 19:46:48 2011 From: diego.veca at fb.com (Diego Veca) Date: Wed, 8 Jun 2011 00:46:48 +0000 Subject: IPv6 day fun is beginning! In-Reply-To: <4DEEC12B.90006@hyperthese.net> Message-ID: That is expected, the CDN is not IPv6 enabled (yet) On 6/7/11 5:24 PM, "R?my Sanchez" wrote: >On 06/08/2011 02:13 AM, Randy Carpenter wrote: >> I'm getting v6 for facebook now. > >www.facebook.com is v6 here, but I see no AAAA for the fbcdn.net >subdomains. > >-- >R?my Sanchez > From blake at pfankuch.me Tue Jun 7 19:51:02 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Wed, 8 Jun 2011 00:51:02 +0000 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> <47F2C08A-E828-4C2A-8C3D-28C008517221@puck.nether.net> Message-ID: Anyone with native v6 want to help me test my content? I don't have any v6 access from anything except a few dedicated servers yet. Off list response is fine :) -----Original Message----- From: TJ [mailto:trejrco at gmail.com] Sent: Tuesday, June 07, 2011 6:32 PM To: NANOG Subject: Re: IPv6 day fun is beginning! On Tue, Jun 7, 2011 at 20:14, Jared Mauch wrote: > > Props to google for doing it right, e.g.: > > maps.googleapis.com AAAA > gg.google.com AAAA > safebrowsing.clients.google.com AAAA > > Thank you google! > > - Jared > ... and Gmail, too ... /TJ From iljitsch at muada.com Tue Jun 7 20:04:08 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 8 Jun 2011 03:04:08 +0200 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> <47F2C08A-E828-4C2A-8C3D-28C008517221@puck.nether.net> Message-ID: On 8 jun 2011, at 2:31, TJ wrote: > ... and Gmail, too ... imap.gmail.com only has IPv4, though. From kloch at kl.net Tue Jun 7 20:05:02 2011 From: kloch at kl.net (Kevin Loch) Date: Tue, 07 Jun 2011 21:05:02 -0400 Subject: Broken Teredo relay AS1101? Message-ID: <4DEECABE.6080902@kl.net> This path for 2001::/32 leads to a broken teredo relay: 3257 1103 1101 http://ip6.me was using this path and not working from my client. When I routing to prefer 6939's relays it started working. - Kevin From david at davidswafford.com Tue Jun 7 20:05:43 2011 From: david at davidswafford.com (David Swafford) Date: Tue, 7 Jun 2011 21:05:43 -0400 Subject: Facebook's IPv6 Addresses - LOL Message-ID: This is amusing: Tracing route to www.facebook.com [2620:0:1c00:0:*face:b00c*:0:2] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 2001:1938:2a7::1 2 88 ms 95 ms 88 ms gw-383.phx-01.us.sixxs.net[2001:1938:81:17e::1] 3 91 ms 86 ms 89 ms 2001:4de0:1000:a4::1 4 87 ms 128 ms 92 ms 1-3.ipv6.r1.ph.hwng.net[2001:4de0:1000:27::2] 5 87 ms 94 ms 85 ms 2001:478:186::20 6 100 ms 98 ms 100 ms 10gigabitethernet2-2.core1.lax1.he.net[2001:470:0:159::1] 7 117 ms 107 ms 116 ms 10gigabitethernet7-3.core1.fmt2.he.net[2001:470:0:18d::1] 8 112 ms 109 ms 114 ms 10gigabitethernet1-1.core1.sjc2.he.net[2001:470:0:31::2] 9 106 ms 108 ms 108 ms facebook.gige-g5-9.core1.sjc2.he.net[2001:470:0:14a::2] 10 105 ms 106 ms 107 ms ae0.bb01.sjc1.tfbnw.net [2620:0:1cff:* dead:beef*::9] 11 134 ms 132 ms 140 ms ae10.bb01.prn1.tfbnw.net[2620:0:1cff:dead:beef::119] 12 134 ms 133 ms 134 ms ae0.dr01.prn1.tfbnw.net[2620:0:1cff:dead:beef::19d] 13 132 ms 133 ms 133 ms po1023.csw01a.prn1.tfbnw.net[2620:0:1cff:dead:beef::381] ... In case the formatting get's lost, their initial address includes "face:booc" and one of the hops along the way is "dead:beef". :-) David :-D From trejrco at gmail.com Tue Jun 7 20:13:31 2011 From: trejrco at gmail.com (TJ) Date: Tue, 7 Jun 2011 21:13:31 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> <47F2C08A-E828-4C2A-8C3D-28C008517221@puck.nether.net> Message-ID: On Tue, Jun 7, 2011 at 21:04, Iljitsch van Beijnum wrote: > On 8 jun 2011, at 2:31, TJ wrote: > > > ... and Gmail, too ... > > imap.gmail.com only has IPv4, though. > Good catch, applies to pop & smtp as well. Baby steps, I guess? /TJ From lorenzo at colitti.com Tue Jun 7 21:01:21 2011 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Tue, 7 Jun 2011 19:01:21 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> Message-ID: On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong wrote: > Moving them to IPv6 and hoping that enough of the content providers > move forward fast enough to minimize the extent of the LSN deployment > required. The problem here is not content, it's access. Look at World IPv6 day. What percentage of web content is represented? Probably order of 10%. How about access? Our public stats still say 0.3% From jmamodio at gmail.com Tue Jun 7 21:09:07 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 7 Jun 2011 21:09:07 -0500 Subject: IPv6 day fun is beginning! In-Reply-To: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> Message-ID: Anybody keeping any realtime stats ? -J From bill at herrin.us Tue Jun 7 21:11:27 2011 From: bill at herrin.us (William Herrin) Date: Tue, 7 Jun 2011 22:11:27 -0400 Subject: Why don't ISPs peer with everyone? In-Reply-To: References: <20110606221937.B362C6F437@smtp.hushmail.com> Message-ID: On Tue, Jun 7, 2011 at 8:41 PM, Jimmy Hess wrote: > On Tue, Jun 7, 2011 at 7:10 PM, William Herrin wrote: > [snip] >> gets a 200 amp electrical service. The problem with that notion is >> that A) consumers are hooked on "unlimited," and B) your toaster > Consumers aren't getting "unlimited right now". > They're getting (unknown number of databytes)/month, before the ISP > speed caps, throttles, rate limits them or turns them off for "excessive usage". They're being told they're getting unlimited and for 99% of them it's true in the sense that their usage does not induce their ISP to impose its cap. Point is: they expect unlimited and a service which doesn't claim to be unlimited is, therefore, a non-starter. Back in the day I faced this problem at my dialup ISP. We had a 240 hour per month cap on dialup usage so that the 24/7 users would buy a 24/7 account or go elsewhere. We started losing business from folks using 30 and 40 hours a month because the other guy was "unlimited." So we did some fancy wordsmithing and came up with "unlimited _attended_ hours" meaning you had to be in front of your computer. How did we know? Because you sleep too so if you're online for 23+ hours per day every day, your usage isn't "attended." Our salesfolk tested the waters, but we couldn't sell a $5/month plus $0.10/hour product even though that would have resulted in most customers paying less. When I say consumers are hooked on unlimited, that's what I'm talking about. > Your toaster is plugged into ?an outlet that probably has a 20 amp > circuit breaker on it. > If someone hacks it without your knowledge to eat 200 amps, it will > get turned off. > > A similar mechanism could be built into network CPEs. A similar mechanism is built in to network CPEs. It's called the port speed and the choices are 10, 100 and 1000. The electrical company metaphor breaks down here. Wiring an appliance so it can consume your entire electrical service has no desirable traits. Wiring your computing equipment so they can communicate at higher speeds within the building than leaving the building is the opposite. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From santino.codispoti at gmail.com Tue Jun 7 21:13:09 2011 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Tue, 7 Jun 2011 22:13:09 -0400 Subject: Hotmail? Message-ID: Does anyone happen to know what Microsoft using to delivery Hotmail? Is it Exchange? Can anyone recommend a good system for developing web mail services? I need something that can easy support 400K users From ops.lists at gmail.com Tue Jun 7 21:23:34 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 8 Jun 2011 07:53:34 +0530 Subject: Hotmail? In-Reply-To: References: Message-ID: 400k is easy enough to do with either high end enterprise or low end carrier grade products. Or if you have the patience to do it, open source ftw. The MTA isn't the criterion here as much as all the other stuff - bandwidth, storage, directory services, security / antispam ... --srs On Wed, Jun 8, 2011 at 7:43 AM, Santino Codispoti wrote: > Does anyone happen to know what Microsoft using to delivery Hotmail? > Is it Exchange? ?Can anyone recommend a good system for developing web > mail services? ?I need something that can easy support 400K users > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jared at puck.nether.net Tue Jun 7 21:27:53 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 7 Jun 2011 22:27:53 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> Message-ID: <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> I'm observing our netflow of the ipv6 address-family from nodes where we're capable. It's not that interesting actually. I've seen larger spikes than what we're seeing [so far]. Akamai has a realtime IPv6 stats page as well here: http://www.akamai.com/ipv6 You can check out the hits/second peaks of what they're seeing. I do wonder if it will just taper off over time, or if we will see a big spike during the day in EU. I know for my "geeknet" here at home, I'm seeing all the ipv6 enabled properties flow through, mostly facebook and google, including the analytics site which actually is likely collecting the most interesting data of all. - Jared On Jun 7, 2011, at 10:09 PM, Jorge Amodio wrote: > Anybody keeping any realtime stats ? > > -J From waqqasahmed at gmail.com Tue Jun 7 21:28:51 2011 From: waqqasahmed at gmail.com (Syed Waqqas Ahmed) Date: Tue, 7 Jun 2011 22:28:51 -0400 Subject: Hotmail? In-Reply-To: References: Message-ID: If you already have MS Exchange just use OWA (outlook web access) feature to enable webaccess. but like suresh said its storage, directory services and mail traffic that matters most. regards syed. On Tue, Jun 7, 2011 at 10:23 PM, Suresh Ramasubramanian wrote: > 400k is easy enough to do with either high end enterprise or low end > carrier grade products. > > Or if you have the patience to do it, open source ftw. > > The MTA isn't the criterion here as much as all the other stuff - > bandwidth, storage, directory services, security / antispam ... > > --srs > > On Wed, Jun 8, 2011 at 7:43 AM, Santino Codispoti > wrote: >> Does anyone happen to know what Microsoft using to delivery Hotmail? >> Is it Exchange? ?Can anyone recommend a good system for developing web >> mail services? ?I need something that can easy support 400K users >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > From ryan.finnesey at HarrierInvestments.com Tue Jun 7 21:29:21 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 7 Jun 2011 19:29:21 -0700 Subject: Hotmail? In-Reply-To: References: Message-ID: <6EFFEFBAC68377459A2E972105C759EC03B250AC@EXVBE005-2.exch005intermedia.net> I would think licensing would be a large fee with any enterprise type product. I wonder what the bandwidth requirements would be. Cheers Ryan -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Tuesday, June 07, 2011 10:24 PM To: Santino Codispoti Cc: nanog at nanog.org Subject: Re: Hotmail? 400k is easy enough to do with either high end enterprise or low end carrier grade products. Or if you have the patience to do it, open source ftw. The MTA isn't the criterion here as much as all the other stuff - bandwidth, storage, directory services, security / antispam ... --srs On Wed, Jun 8, 2011 at 7:43 AM, Santino Codispoti wrote: > Does anyone happen to know what Microsoft using to delivery Hotmail? > Is it Exchange? ?Can anyone recommend a good system for developing web > mail services? ?I need something that can easy support 400K users > -- Suresh Ramasubramanian (ops.lists at gmail.com) From santino.codispoti at gmail.com Tue Jun 7 21:31:13 2011 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Tue, 7 Jun 2011 22:31:13 -0400 Subject: Hotmail? In-Reply-To: References: Message-ID: We do not have Exchange this would be for a consumer e-mail service that is ad supported. On Tue, Jun 7, 2011 at 10:28 PM, Syed Waqqas Ahmed wrote: > If you already have MS Exchange just use OWA (outlook web access) > feature to enable webaccess. but like suresh said its storage, > directory services and mail traffic that matters most. > > regards > syed. > > On Tue, Jun 7, 2011 at 10:23 PM, Suresh Ramasubramanian > wrote: >> 400k is easy enough to do with either high end enterprise or low end >> carrier grade products. >> >> Or if you have the patience to do it, open source ftw. >> >> The MTA isn't the criterion here as much as all the other stuff - >> bandwidth, storage, directory services, security / antispam ... >> >> --srs >> >> On Wed, Jun 8, 2011 at 7:43 AM, Santino Codispoti >> wrote: >>> Does anyone happen to know what Microsoft using to delivery Hotmail? >>> Is it Exchange? ?Can anyone recommend a good system for developing web >>> mail services? ?I need something that can easy support 400K users >>> >> >> >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) >> >> > From ops.lists at gmail.com Tue Jun 7 21:43:08 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 8 Jun 2011 08:13:08 +0530 Subject: Hotmail? In-Reply-To: References: Message-ID: In which case, your best bet is to hire some sort of consultant to build it for you Or to outsource it to one of several white label providers who will host it and run it for you. --srs On Wed, Jun 8, 2011 at 8:01 AM, Santino Codispoti wrote: > We do not have Exchange this would be for a consumer e-mail service > that is ad supported. -- Suresh Ramasubramanian (ops.lists at gmail.com) From ryan.finnesey at HarrierInvestments.com Tue Jun 7 22:04:34 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 7 Jun 2011 23:04:34 -0400 Subject: Hotmail? Message-ID: <588b01cc2588$eebcee7a$2a01fe0a@exch005intermedia.net> Microsoft had a product that try targeted to the service provider segment I do not know if they still offer it. Sent from my Windows Phone -----Original Message----- From: Santino Codispoti Sent: Tuesday, June 07, 2011 10:31 PM To: Syed Waqqas Ahmed Cc: nanog at nanog.org Subject: Re: Hotmail? We do not have Exchange this would be for a consumer e-mail service that is ad supported. On Tue, Jun 7, 2011 at 10:28 PM, Syed Waqqas Ahmed wrote: > If you already have MS Exchange just use OWA (outlook web access) > feature to enable webaccess. but like suresh said its storage, > directory services and mail traffic that matters most. > > regards > syed. > > On Tue, Jun 7, 2011 at 10:23 PM, Suresh Ramasubramanian > wrote: >> 400k is easy enough to do with either high end enterprise or low end >> carrier grade products. >> >> Or if you have the patience to do it, open source ftw. >> >> The MTA isn't the criterion here as much as all the other stuff - >> bandwidth, storage, directory services, security / antispam ... >> >> --srs >> >> On Wed, Jun 8, 2011 at 7:43 AM, Santino Codispoti >> wrote: >>> Does anyone happen to know what Microsoft using to delivery Hotmail? >>> Is it Exchange? Can anyone recommend a good system for developing web >>> mail services? I need something that can easy support 400K users >>> >> >> >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) >> >> > From jleq96 at gmail.com Tue Jun 7 22:14:22 2011 From: jleq96 at gmail.com (John LeCoque) Date: Tue, 7 Jun 2011 22:14:22 -0500 Subject: Hotmail? In-Reply-To: References: Message-ID: What about starting with Zimbra's Open Source edition, and building onto it? On Tue, Jun 7, 2011 at 9:13 PM, Santino Codispoti < santino.codispoti at gmail.com> wrote: > Does anyone happen to know what Microsoft using to delivery Hotmail? > Is it Exchange? Can anyone recommend a good system for developing web > mail services? I need something that can easy support 400K users > > From jbates at brightok.net Tue Jun 7 22:28:29 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 07 Jun 2011 22:28:29 -0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> Message-ID: <4DEEEC5D.6010404@brightok.net> On 6/7/2011 9:01 PM, Lorenzo Colitti wrote: > On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong wrote: > >> Moving them to IPv6 and hoping that enough of the content providers >> move forward fast enough to minimize the extent of the LSN deployment >> required. > > The problem here is not content, it's access. Look at World IPv6 day. > What percentage of web content is represented? Probably order of 10%. > How about access? Our public stats still say 0.3% 0.3% of access is fine, so long as the margin of broken stacks and deployments is low enough. If they find that keeping the content dual stacked has acceptable problems, then it's just a matter of access gearing up to match. The largest fear for content is to dual stack and have service levels go down. The only data we really get from this day is a better understanding of the service levels when dual stacked at major content sites. Some access providers may also determine mistakes in their networks, or isolation or MTU issues through transit providers. Jack From ryan.finnesey at HarrierInvestments.com Tue Jun 7 22:27:42 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 7 Jun 2011 23:27:42 -0400 Subject: Hotmail? Message-ID: <588e01cc258c$29d0f116$2a01fe0a@exch005intermedia.net> That's what Yahoo uses right? Sent from my Windows Phone -----Original Message----- From: John LeCoque Sent: Tuesday, June 07, 2011 11:14 PM To: Santino Codispoti Cc: nanog at nanog.org Subject: Re: Hotmail? What about starting with Zimbra's Open Source edition, and building onto it? On Tue, Jun 7, 2011 at 9:13 PM, Santino Codispoti < santino.codispoti at gmail.com> wrote: > Does anyone happen to know what Microsoft using to delivery Hotmail? > Is it Exchange? Can anyone recommend a good system for developing web > mail services? I need something that can easy support 400K users > > From ops.lists at gmail.com Tue Jun 7 22:30:42 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 8 Jun 2011 09:00:42 +0530 Subject: Hotmail? In-Reply-To: References: Message-ID: That still doesnt address the storage, security other than antispam / antivirus etc :) If he's got to ask how to build it .. On Wed, Jun 8, 2011 at 8:44 AM, John LeCoque wrote: > What about starting with Zimbra's Open Source edition, and building onto it? -- Suresh Ramasubramanian (ops.lists at gmail.com) From jmamodio at gmail.com Tue Jun 7 22:31:30 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 7 Jun 2011 22:31:30 -0500 Subject: IPv6 day fun is beginning! In-Reply-To: <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> Message-ID: Thanks for the link Jared. I wonder how many eye-balls are really enabled to reach the IPv6 sites. Akamai's site doesn't show very impressive numbers, trying to figure why 300ms latency and >4% packet loss ? -J From jleq96 at gmail.com Tue Jun 7 22:35:04 2011 From: jleq96 at gmail.com (John LeCoque) Date: Tue, 7 Jun 2011 22:35:04 -0500 Subject: Hotmail? In-Reply-To: <588e01cc258c$29d0f116$2a01fe0a@exch005intermedia.net> References: <588e01cc258c$29d0f116$2a01fe0a@exch005intermedia.net> Message-ID: I'd imagine that some technology from Zimbra made it into Yahoo Mail, and vice versa. For a while, Yahoo owned Zimbra, but it's a VMWare product right now. I know that Zimbra will scale well. How exactly you scale Zimbra would depend in part on whether you choose to go with the FOSS version, or with one of the commercial packages. On Tue, Jun 7, 2011 at 10:27 PM, Ryan Finnesey < ryan.finnesey at harrierinvestments.com> wrote: > That's what Yahoo uses right? > > Sent from my Windows Phone > > -----Original Message----- > From: John LeCoque > Sent: Tuesday, June 07, 2011 11:14 PM > To: Santino Codispoti > Cc: nanog at nanog.org > Subject: Re: Hotmail? > > What about starting with Zimbra's Open Source edition, and building onto > it? > > On Tue, Jun 7, 2011 at 9:13 PM, Santino Codispoti < > santino.codispoti at gmail.com> wrote: > > > Does anyone happen to know what Microsoft using to delivery Hotmail? > > Is it Exchange? Can anyone recommend a good system for developing web > > mail services? I need something that can easy support 400K users > > > > > From rpug at linux.com Tue Jun 7 22:40:05 2011 From: rpug at linux.com (Ryan Pugatch) Date: Tue, 7 Jun 2011 23:40:05 -0400 Subject: Hotmail? In-Reply-To: References: Message-ID: > What about starting with Zimbra's Open Source edition, and building onto > it? > Let me just step in here and say.. it's tough to build onto Zimbra. At work, we support ~1000 users on Zimbra (network edition), with hundreds of thousands of messages flowing through daily, and it doesn't like you tinkering with stuff under the hood. Most of your customizations get blown away when you upgrade. That said, I know of some organizations who customize it like crazy (I had heard that Lycos's free mail system is Zimbra-based, and Yahoo as well). Once you deviate, though, don't expect to stick to Zimbra's releases. It might be easier to just start fresh with postfix, amavis, spamassassin, dovecot, etc. We've also run into some pain in scaling it out (they want you to use Red Hat Clustering, but there's no great way to scale out the mail store regardless). Ryan From jared at puck.nether.net Tue Jun 7 22:46:25 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 7 Jun 2011 23:46:25 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> Message-ID: <0F22E467-EFAC-4435-BA6A-686BCED16CF2@puck.nether.net> On Jun 7, 2011, at 11:31 PM, Jorge Amodio wrote: > Thanks for the link Jared. > > I wonder how many eye-balls are really enabled to reach the IPv6 > sites. Akamai's site doesn't show very impressive numbers, trying to > figure why 300ms latency and >4% packet loss ? My guess is it's over the entire set of akamai properties hosted there, so cisco, bing, etc.. that all point to edgesuite and their related domains. The latency is likely due to suboptimal tunneling vs native. The density of IPv6 peering likely doesn't fully match the rest of the world either, sometimes you have to go across the country because someone can't do v6 on the local port. I do also find it interesting there's not a significant spike at the AMSIX IPv6 sFlow page either. http://www.ams-ix.net/sflow-stats/ipv6/ We have seen a traffic increase but nothing like what I was expecting, nay hoping to see. (i.e.: gigs and gigs of traffic - it does look like ~2x to me in an unscientific eye-look at a chart). Some of this may just be due to the methods used by the various sites to enable IPv6. (e.g.: main site only, not sub-sites, and not things like fbcdn etc). There are people listed on the ISOC site that are not serving up AAAA records either, so perhaps they are doing last minute testing and we will see an increase as a result. It's still early to measure a final result obviously, but the observation part is quite interesting for me now. I do hope to see more traffic over the next 12-24 hours. Maybe the "asia peak" time will be most interesting?. - Jared From jvanoppen at spectrumnet.us Tue Jun 7 22:47:37 2011 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Wed, 8 Jun 2011 03:47:37 +0000 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> Message-ID: I was wondering the same thing... we have v6 enabled to about 700 users in our native Ethernet to the home deployment here in Seattle. Unfortunately, user routers don't seem to often support v6 resulting in only about 2-8% of users in most buildings using it, and most of those are just people plugged directly into the wall jacks we provide without routers. I wonder how long it will take for everyone to upgrade their home routers. John -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Tuesday, June 07, 2011 8:32 PM To: Jared Mauch Cc: NANOG list Subject: Re: IPv6 day fun is beginning! Thanks for the link Jared. I wonder how many eye-balls are really enabled to reach the IPv6 sites. Akamai's site doesn't show very impressive numbers, trying to figure why 300ms latency and >4% packet loss ? -J From owen at delong.com Tue Jun 7 22:47:43 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 7 Jun 2011 20:47:43 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> Message-ID: <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> On Jun 7, 2011, at 7:01 PM, Lorenzo Colitti wrote: > On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong wrote: > Moving them to IPv6 and hoping that enough of the content providers > move forward fast enough to minimize the extent of the LSN deployment > required. > > The problem here is not content, it's access. Look at World IPv6 day. > What percentage of web content is represented? Probably order of 10%. > How about access? Our public stats still say 0.3% LSN won't be required by failure of access providers to migrate. LSN will be required by failure of content providers to turn on AAAA. LSN is required when access providers come across the following two combined constraints: 1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6. For all but the most inept of access providers, they will have some ability to put customers on IPv6 prior to the day they would have to deploy LSN. Owen From ryan.finnesey at HarrierInvestments.com Tue Jun 7 22:51:05 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 7 Jun 2011 23:51:05 -0400 Subject: Hotmail? Message-ID: <589101cc258f$6f4c2c35$2a01fe0a@exch005intermedia.net> Can you customize the interface of OWA that much? Sent from my Windows Phone -----Original Message----- From: Syed Waqqas Ahmed Sent: Tuesday, June 07, 2011 10:28 PM To: Suresh Ramasubramanian Cc: nanog at nanog.org Subject: Re: Hotmail? If you already have MS Exchange just use OWA (outlook web access) feature to enable webaccess. but like suresh said its storage, directory services and mail traffic that matters most. regards syed. On Tue, Jun 7, 2011 at 10:23 PM, Suresh Ramasubramanian wrote: > 400k is easy enough to do with either high end enterprise or low end > carrier grade products. > > Or if you have the patience to do it, open source ftw. > > The MTA isn't the criterion here as much as all the other stuff - > bandwidth, storage, directory services, security / antispam ... > > --srs > > On Wed, Jun 8, 2011 at 7:43 AM, Santino Codispoti > wrote: >> Does anyone happen to know what Microsoft using to delivery Hotmail? >> Is it Exchange? Can anyone recommend a good system for developing web >> mail services? I need something that can easy support 400K users >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > From marka at isc.org Tue Jun 7 23:15:03 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 08 Jun 2011 14:15:03 +1000 Subject: IPv6 day fun is beginning! In-Reply-To: Your message of "Wed, 08 Jun 2011 03:47:37 GMT." References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> Message-ID: <20110608041503.A4CFE1075035@drugs.dv.isc.org> In message , John van Oppen writes: > I was wondering the same thing... we have v6 enabled to about 700 users i= > n our native Ethernet to the home deployment here in Seattle. Unfortunat= > ely, user routers don't seem to often support v6 resulting in only about 2-= > 8% of users in most buildings using it, and most of those are just people p= > lugged directly into the wall jacks we provide without routers. I wonder = > how long it will take for everyone to upgrade their home routers. > > John If all the home CPE router vendors stopped shipping IPv4 only boxes, not that long. At the moment the price point for IPv6 CPE routers is still 2-3x the IPv4 only boxes when you can find one though not all of that difference is IPv6. The IPv6 boxes often have multiple radio and other extras. This shows that CPE vendors still see IPv6 as something *extra* and not something that should be *standard*. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From millnert at gmail.com Tue Jun 7 23:59:16 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 8 Jun 2011 00:59:16 -0400 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: Owen, On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong wrote: > LSN is required when access providers come across the following two > combined constraints: > > ? ? ? ?1. ? ? ?No more IPv4 addresses to give to customers. > ? ? ? ?2. ? ? ?No ability to deploy those customers on IPv6. 2 has little bearing on need of LSN to access v4. Insufficient amount of IPv4 addresses => LSN required. Regards, Martin From joly at punkcast.com Wed Jun 8 00:00:09 2011 From: joly at punkcast.com (Joly MacFie) Date: Wed, 8 Jun 2011 01:00:09 -0400 Subject: ISOC-HK Kickstart IPv6! webcast 0600UTC = 2am EDT Message-ID: ISOC Hong Kong has a great World IPv6 Day event ?- Kickstart IPv6! - starting at 2pm HKT = 0600UTC (around an hour from now)?and running 3 and a half hours. It will be webcast live via the ISOC Chapters Livestream Channel ?on the ISOC-HK site - http://isoc.hk Please take time to watch and make comments via twitter with the tags #worldipv6day and ?@ISOCHK or via ISOC-HK facebook page at http://www.facebook.com/pages/Internet-Society-Hong-Kong-ISOC-HK/338914790675 Program: KEYNOTE: Geoff Huston, Chief Scientist (APNIC) Topic: IPv4 address exhaustion, and why we should be worried? SPEAKERS: Kuo-Wei Wu, Board Member, ICANN Topic: Moving into v6 world in Taiwan Che-hoo Cheng, Convener, IPv6 Working Group of Internet Society Hong Kong; Associate Director (Infrastructure) of The Information Technology ?Services Centre of The Chinese University of Hong Kong Topic: Hong Kong, are you IPv6 ready? Katherine Kwan, Vice President, Product Development and Management, Consumer Group, PCCW, Hong Kong Topic: Are you ready for IPv6? Leading-edge High-speed Broadband Service from the Leading ISP Warren Kwok, Telecom Engineer, OFTA, Hong Kong Topic: Experience of Deploying IPv6 in the Office of the Telecommunications Authority MODERATOR: Charles Mok, Chairman, Internet Society Hong Kong The Hong Kong Government has issued a statement in support: http://www.info.gov.hk/gia/general/201106/06/P201106030200.htm -- --------------------------------------------------------------- Joly MacFie? 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com ?http://pinstand.com - http://punkcast.com ?VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - -- --------------------------------------------------------------- Joly MacFie? 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com ?http://pinstand.com - http://punkcast.com ?VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From dhill at mindcry.org Wed Jun 8 00:10:24 2011 From: dhill at mindcry.org (David Hill) Date: Wed, 8 Jun 2011 01:10:24 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: <20110608051024.GD25111@fig.mindcry.org> Some sites still require ipv4 to load properly (stylesheets, statics, etc) disable ipv4 on your machine and go to: http://www.facebook.com http://www.cnn.com/WORLD/ http://www.yahoo.com/ I guess it is a start though. From steve.spence at arkitechs.com Wed Jun 8 00:27:57 2011 From: steve.spence at arkitechs.com (Steve Spence) Date: Wed, 8 Jun 2011 01:27:57 -0400 Subject: Hotmail? In-Reply-To: References: Message-ID: <000601cc259c$d5b64580$8122d080$@arkitechs.com> That what I found with most the open source /Linux mail products that customizing and extending can be difficult and a lot of time and effort. The exchange is one of the easiest ways to roll out large scale web base email if just expensive in upfront costs. Interns of Hotmail they initially use to use Solaris for the MTA and storage and FreeBSD for the web services ( Apache ) they suppose of migrated windows by now using windows products Again I think this highly customize solution which may not be very useful http://en.wikipedia.org/wiki/Hotmail we went through a similar search for a high volume solution which we could customize and brand right now we using we high a hybrid of (exchange/Icewarp/Atmail/ two layers of spam filtering ) Steve -----Original Message----- From: Ryan Pugatch [mailto:rpug at linux.com] Sent: Tuesday, June 07, 2011 11:40 PM To: John LeCoque Cc: nanog at nanog.org Subject: Re: Hotmail? > What about starting with Zimbra's Open Source edition, and building > onto it? > Let me just step in here and say.. it's tough to build onto Zimbra. At work, we support ~1000 users on Zimbra (network edition), with hundreds of thousands of messages flowing through daily, and it doesn't like you tinkering with stuff under the hood. Most of your customizations get blown away when you upgrade. That said, I know of some organizations who customize it like crazy (I had heard that Lycos's free mail system is Zimbra-based, and Yahoo as well). Once you deviate, though, don't expect to stick to Zimbra's releases. It might be easier to just start fresh with postfix, amavis, spamassassin, dovecot, etc. We've also run into some pain in scaling it out (they want you to use Red Hat Clustering, but there's no great way to scale out the mail store regardless). Ryan From maxsec at gmail.com Wed Jun 8 00:38:43 2011 From: maxsec at gmail.com (Martin Hepworth) Date: Wed, 8 Jun 2011 06:38:43 +0100 Subject: Hotmail? In-Reply-To: <000601cc259c$d5b64580$8122d080$@arkitechs.com> References: <000601cc259c$d5b64580$8122d080$@arkitechs.com> Message-ID: Have a look at the Hermes mail system at cam.Ac.uk, built buy among people Philip Hazel of exam fame It will give you some insight into the challenges of building a scalable high perfomance mail system. Martin On Wednesday, 8 June 2011, Steve Spence wrote: > > > That ?what I found with most the open source /Linux ?mail ?products ?that > customizing ?and extending can be difficult and a lot of time and effort. > The ?exchange is one of the easiest ways to roll out large scale web base > email ?if just ?expensive in upfront ?costs. > > Interns of Hotmail ?they initially ?use to use ?Solaris for the MTA and > storage and FreeBSD for the web services ( Apache ) they suppose of migrated > windows by now using windows products Again I think this highly customize > solution which may not be very useful http://en.wikipedia.org/wiki/Hotmail > > we went through a similar ?search for a high volume ?solution which we could > customize and brand ?right now we using we high a hybrid of > (exchange/Icewarp/Atmail/ two layers ?of spam filtering ) > > Steve > > > > -----Original Message----- > From: Ryan Pugatch [mailto:rpug at linux.com] > Sent: Tuesday, June 07, 2011 11:40 PM > To: John LeCoque > Cc: nanog at nanog.org > Subject: Re: Hotmail? > >> What about starting with Zimbra's Open Source edition, and building >> onto it? >> > > Let me just step in here and say.. it's tough to build onto Zimbra. ?At > work, we support ~1000 users on Zimbra (network edition), with hundreds of > thousands of messages flowing through daily, and it doesn't like you > tinkering with stuff under the hood. ?Most of your customizations get blown > away when you upgrade. ?That said, I know of some organizations who > customize it like crazy (I had heard that Lycos's free mail system is > Zimbra-based, and Yahoo as well). ?Once you deviate, though, don't expect to > stick to Zimbra's releases. ?It might be easier to just start fresh with > postfix, amavis, spamassassin, dovecot, etc. ?We've also run into some pain > in scaling it out (they want you to use Red Hat Clustering, but there's no > great way to scale out the mail store regardless). > > Ryan > > > > > -- -- Martin Hepworth Oxford, UK From Christopher.Palmer at microsoft.com Wed Jun 8 00:42:31 2011 From: Christopher.Palmer at microsoft.com (Christopher Palmer) Date: Wed, 8 Jun 2011 05:42:31 +0000 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CE402D0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> The title of this ongoing thread is giving me heart palpitations. Content access over IPv6 may help "justify" ISPs investing in IPv6, but it in no means is a prerequisite technically. LSNs are "fine" when deployed in parallel with IPv6 IMHO. There has to be a pathway to "good" networking. To Lorenzo's point - I really think the next big hurdle in the transition is getting access numbers to something respectable. World IPv6 Day has only be going for a few hours, but things seem to be going fine, and it's our hope (currently) to keep www.xbox.com available over IPv6 indefinitely. I expect other participants will keep IPv6 enabled for some or all of their respective portfolios. This leads me to worry that in 6-18 months we'll be in a position where a lot of major content has permanently transitioned, and we're still at <1% access range. That will be awkward. I'm not an ISP - but I absolutely expect that IPv6 roll-outs have long time-horizons and are fairly complex. So I hope folks are looking at IPv6 NOW, and not simply waiting for Google/Bing/Yahoo/Interwebz to enable permanent content access and organizational justification. Christopher.Palmer at microsoft.com IPv6 @ Microsoft -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, June 07, 2011 8:48 PM To: Lorenzo Colitti Cc: nanog at nanog.org Subject: Re: Microsoft's participation in World IPv6 day On Jun 7, 2011, at 7:01 PM, Lorenzo Colitti wrote: > On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong wrote: > Moving them to IPv6 and hoping that enough of the content providers > move forward fast enough to minimize the extent of the LSN deployment > required. > > The problem here is not content, it's access. Look at World IPv6 day. > What percentage of web content is represented? Probably order of 10%. > How about access? Our public stats still say 0.3% LSN won't be required by failure of access providers to migrate. LSN will be required by failure of content providers to turn on AAAA. LSN is required when access providers come across the following two combined constraints: 1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6. For all but the most inept of access providers, they will have some ability to put customers on IPv6 prior to the day they would have to deploy LSN. Owen From ops.lists at gmail.com Wed Jun 8 00:54:05 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 8 Jun 2011 11:24:05 +0530 Subject: Hotmail? In-Reply-To: References: <000601cc259c$d5b64580$8122d080$@arkitechs.com> Message-ID: That's one of several classic papers - another by Yann Golanski from about a decade back, also using Exim On Wed, Jun 8, 2011 at 11:08 AM, Martin Hepworth wrote: > Have a look at the Hermes mail system at cam.Ac.uk, built buy among > people Philip Hazel of exam fame > > It will give you some insight into the challenges of building a > scalable high perfomance mail system. -- Suresh Ramasubramanian (ops.lists at gmail.com) From iljitsch at muada.com Wed Jun 8 00:59:24 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 8 Jun 2011 07:59:24 +0200 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CE402D0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> <0AB09EDBCD1C484EBE45978D62F3513C3CE402D0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <400A31EE-0EFC-4DE7-95D7-614F8A84A14A@muada.com> On 8 jun 2011, at 7:42, Christopher Palmer wrote: > I'm not an ISP - but I absolutely expect that IPv6 roll-outs have long time-horizons and are fairly complex. So I hope folks are looking at IPv6 NOW, and not simply waiting for Google/Bing/Yahoo/Interwebz to enable permanent content access and organizational justification. You have to remember that the content guys need few addresses and once they have them they rarely need more, and IPv6 or not is pretty much a binary thing: yes for everyone, no for everyone. It's the opposite for consumer ISPs: they need tons of addresses on an ongoing basis but they can (for instance) give IPv6 to new users while not changing anything for existing users. So once some hurdles such as the limited availability of IPv6-capable CPEs and a plan on how to provision IPv6 are taken the ISPs have a lot of incentive to roll out IPv6 while the content guys can conceivably stay on IPv4 for a long time. The fact that IPv6 client to IPv4 server is an easy problem but the other way around a very hard one also points in this direction. BTW, how are you guys dealing with path MTU discovery for IPv6? I've seen a few sites that have problems with this, such as www.nist.gov, but you guys seem ok. From gbonser at seven.com Wed Jun 8 01:06:22 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 7 Jun 2011 23:06:22 -0700 Subject: Hotmail? In-Reply-To: <589101cc258f$6f4c2c35$2a01fe0a@exch005intermedia.net> References: <589101cc258f$6f4c2c35$2a01fe0a@exch005intermedia.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E36E9@RWC-EX1.corp.seven.com> Anyone tried: http://www.zarafa.com/ ?? > -----Original Message----- > From: Ryan Finnesey [mailto:ryan.finnesey at HarrierInvestments.com] > Sent: Tuesday, June 07, 2011 8:51 PM > To: Syed Waqqas Ahmed; Suresh Ramasubramanian > Cc: nanog at nanog.org > Subject: RE: Hotmail? > > Can you customize the interface of OWA that much? > > Sent from my Windows Phone > > -----Original Message----- > From: Syed Waqqas Ahmed > Sent: Tuesday, June 07, 2011 10:28 PM > To: Suresh Ramasubramanian > Cc: nanog at nanog.org > Subject: Re: Hotmail? > > If you already have MS Exchange just use OWA (outlook web access) > feature to enable webaccess. but like suresh said its storage, > directory services and mail traffic that matters most. > > regards > syed. > > On Tue, Jun 7, 2011 at 10:23 PM, Suresh Ramasubramanian > wrote: > > 400k is easy enough to do with either high end enterprise or low end > > carrier grade products. > > > > Or if you have the patience to do it, open source ftw. > > > > The MTA isn't the criterion here as much as all the other stuff - > > bandwidth, storage, directory services, security / antispam ... > > > > --srs > > > > On Wed, Jun 8, 2011 at 7:43 AM, Santino Codispoti > > wrote: > >> Does anyone happen to know what Microsoft using to delivery Hotmail? > >> Is it Exchange? Can anyone recommend a good system for developing > web > >> mail services? I need something that can easy support 400K users > >> > > > > > > > > -- > > Suresh Ramasubramanian (ops.lists at gmail.com) > > > > > From andrew.koch at gawul.net Wed Jun 8 01:15:04 2011 From: andrew.koch at gawul.net (Andrew Koch) Date: Wed, 8 Jun 2011 01:15:04 -0500 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day Message-ID: On Wed, Jun 8, 2011 at 00:59, Iljitsch van Beijnum wrote: > BTW, how are you guys dealing with path MTU discovery for IPv6? I've seen a few sites that have problems with this, such as www.nist.gov, > Speaking of www.nist.gov, I am getting the front page to load, but all links are returning a 404 Not Found when browsing via v6 Andrew Koch andrew.koch at gawul.net From michael at rancid.berkeley.edu Wed Jun 8 01:26:40 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 07 Jun 2011 23:26:40 -0700 Subject: ISOC-HK Kickstart IPv6! webcast 0600UTC = 2am EDT In-Reply-To: References: Message-ID: <4DEF1620.5000507@rancid.berkeley.edu> On 06/07/11 22:00, Joly MacFie wrote: > ISOC Hong Kong has a great World IPv6 Day event - Kickstart IPv6! - > starting at 2pm HKT = 0600UTC (around an hour from now) and > running 3 and a half hours. > > It will be webcast live via the ISOC Chapters Livestream Channel on the > ISOC-HK site - http://isoc.hk I am watching now. Unfortunately, the website and video stream both appear to be IPv4-only. :( michael From joakim at aronius.se Wed Jun 8 01:31:56 2011 From: joakim at aronius.se (Joakim Aronius) Date: Wed, 8 Jun 2011 08:31:56 +0200 Subject: IPv6 day fun is beginning! In-Reply-To: <28102750.144.1307493162523.JavaMail.root@benjamin.baylink.com> References: <4DEEBF69.2050805@gmail.com> <28102750.144.1307493162523.JavaMail.root@benjamin.baylink.com> Message-ID: <20110608063156.GA24537@nike.aronius.se> * Jay Ashworth (jra at baylink.com) wrote: > ----- Original Message ----- > > From: "Matt Ryanczak" > > > Indeed. Verizon LTE is v6 enabled but the user-agent on my phone > > denies me an IPv6 experience. > > I thought I'd heard that LTE transport was *IPv6 only*... LTE supports both IPv4 and IPv6 (of course) but some operators deploy IPv6 only (with NAT64). (e.g. T-mobile, although their '4G' network is actually 3G with the latest high speed features, +1 for innovative marketing department) /Joakim From iljitsch at muada.com Wed Jun 8 01:39:44 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 8 Jun 2011 08:39:44 +0200 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: References: Message-ID: On 8 jun 2011, at 8:15, Andrew Koch wrote: > Speaking of www.nist.gov, I am getting the front page to load, but all > links are returning a 404 Not Found when browsing via v6 Right. They seem to have solved their PMTUD issues, though. From owen at delong.com Wed Jun 8 02:09:16 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 00:09:16 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote: > Owen, > > On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong wrote: >> LSN is required when access providers come across the following two >> combined constraints: >> >> 1. No more IPv4 addresses to give to customers. >> 2. No ability to deploy those customers on IPv6. > > 2 has little bearing on need of LSN to access v4. Insufficient amount > of IPv4 addresses => LSN required. > > Regards, > Martin No, if you have the option of deploying the customers on IPv6, you don't need LSN. The problem is that until the vast majority of content is dual-stack, you can't deploy customers on IPv6 without IPv4. Owen From owen at delong.com Wed Jun 8 02:07:26 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 00:07:26 -0700 Subject: IPv6 day fun is beginning! In-Reply-To: <20110608041503.A4CFE1075035@drugs.dv.isc.org> References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <20110608041503.A4CFE1075035@drugs.dv.isc.org> Message-ID: On Jun 7, 2011, at 9:15 PM, Mark Andrews wrote: > > In message .us>, John van Oppen writes: >> I was wondering the same thing... we have v6 enabled to about 700 users i= >> n our native Ethernet to the home deployment here in Seattle. Unfortunat= >> ely, user routers don't seem to often support v6 resulting in only about 2-= >> 8% of users in most buildings using it, and most of those are just people p= >> lugged directly into the wall jacks we provide without routers. I wonder = >> how long it will take for everyone to upgrade their home routers. >> >> John > > If all the home CPE router vendors stopped shipping IPv4 only boxes, > not that long. At the moment the price point for IPv6 CPE routers > is still 2-3x the IPv4 only boxes when you can find one though not > all of that difference is IPv6. The IPv6 boxes often have multiple > radio and other extras. This shows that CPE vendors still see IPv6 > as something *extra* and not something that should be *standard*. > The D-Link DIR series v6 capables are not actually more than about a 10% premium over the corresponding ipv4-only competition. I see them in computer stores fairly regularly these days. Owen From owen at delong.com Wed Jun 8 02:13:25 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 00:13:25 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CE402D0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> <0AB09EDBCD1C484EBE45978D62F3513C3CE402D0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <2398649D-0149-4E51-AE05-553E354001E2@delong.com> On Jun 7, 2011, at 10:42 PM, Christopher Palmer wrote: > The title of this ongoing thread is giving me heart palpitations. > > Content access over IPv6 may help "justify" ISPs investing in IPv6, but it in no means is a prerequisite technically. > > LSNs are "fine" when deployed in parallel with IPv6 IMHO. There has to be a pathway to "good" networking. > How many of them are you planning on maintaining? May I quote you on this after you've been doing so for a year and received 2 or three lovely FISA subpoenas for your LSN logs? > To Lorenzo's point - I really think the next big hurdle in the transition is getting access numbers to something respectable. World IPv6 Day has only be going for a few hours, but things seem to be going fine, and it's our hope (currently) to keep www.xbox.com available over IPv6 indefinitely. I expect other participants will keep IPv6 enabled for some or all of their respective portfolios. > I agree with Lorenzo to a point, but... Access will happen in due time by virtue of IPv4 runout. If content is available dual-stack ahead of that, it dramatically reduces the need for (and load on) LSN. If it is not, then, LSN is going to be a much much uglier situation to an extent that it might even have a catch-22 effect on IPv6 deployment in the eyeball networks. > This leads me to worry that in 6-18 months we'll be in a position where a lot of major content has permanently transitioned, and we're still at <1% access range. That will be awkward. > Not really. > I'm not an ISP - but I absolutely expect that IPv6 roll-outs have long time-horizons and are fairly complex. So I hope folks are looking at IPv6 NOW, and not simply waiting for Google/Bing/Yahoo/Interwebz to enable permanent content access and organizational justification. > I don't think any of them are really waiting for that. However, I do think getting to that point is actually more critical at this juncture than getting the eyeball networks fully deployed. Owen > Christopher.Palmer at microsoft.com > IPv6 @ Microsoft > > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, June 07, 2011 8:48 PM > To: Lorenzo Colitti > Cc: nanog at nanog.org > Subject: Re: Microsoft's participation in World IPv6 day > > > On Jun 7, 2011, at 7:01 PM, Lorenzo Colitti wrote: > >> On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong wrote: >> Moving them to IPv6 and hoping that enough of the content providers >> move forward fast enough to minimize the extent of the LSN deployment >> required. >> >> The problem here is not content, it's access. Look at World IPv6 day. >> What percentage of web content is represented? Probably order of 10%. >> How about access? Our public stats still say 0.3% > > LSN won't be required by failure of access providers to migrate. > > LSN will be required by failure of content providers to turn on AAAA. > > LSN is required when access providers come across the following two > combined constraints: > > 1. No more IPv4 addresses to give to customers. > 2. No ability to deploy those customers on IPv6. > > For all but the most inept of access providers, they will have some ability > to put customers on IPv6 prior to the day they would have to deploy LSN. > > Owen > From joly at punkcast.com Wed Jun 8 02:32:25 2011 From: joly at punkcast.com (Joly MacFie) Date: Wed, 8 Jun 2011 03:32:25 -0400 Subject: ISOC-HK Kickstart IPv6! webcast 0600UTC = 2am EDT In-Reply-To: <4DEF1620.5000507@rancid.berkeley.edu> References: <4DEF1620.5000507@rancid.berkeley.edu> Message-ID: Yes, livestream.com notably absent from the list of participating organizations. I'm guessing they use their own custom set up, but is there any reason flash media server wouldn't operate over v6 if the dns was there? j On Wed, Jun 8, 2011 at 2:26 AM, Michael Sinatra wrote: > On 06/07/11 22:00, Joly MacFie wrote: >> >> ISOC Hong Kong has a great World IPv6 Day event ?- Kickstart IPv6! - >> starting at 2pm HKT = 0600UTC (around an hour from now) and >> running 3 and a half hours. >> >> It will be webcast live via the ISOC Chapters Livestream Channel ?on the >> ISOC-HK site - http://isoc.hk > > I am watching now. ?Unfortunately, the website and video stream both appear > to be IPv4-only. ?:( > > michael > > -- --------------------------------------------------------------- Joly MacFie? 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com ?http://pinstand.com - http://punkcast.com ?VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From neil at cymru.com Wed Jun 8 03:29:40 2011 From: neil at cymru.com (Neil Long) Date: Wed, 8 Jun 2011 09:29:40 +0100 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> <47F2C08A-E828-4C2A-8C3D-28C008517221@puck.nether.net> Message-ID: On 8 Jun 2011, at 02:13, TJ wrote: > On Tue, Jun 7, 2011 at 21:04, Iljitsch van Beijnum > wrote: > >> On 8 jun 2011, at 2:31, TJ wrote: >> >>> ... and Gmail, too ... >> >> imap.gmail.com only has IPv4, though. >> > > Good catch, applies to pop & smtp as well. Baby steps, I guess? > /TJ > Sadly, although I can connect over IPv6 to Gmail an email sent from within the browser to an IPv6-only address (AAAA but also an MX) still gives the "DNS Error: DNS server returned answer with no data" message. Transport is one thing but getting applications working with an IPv6 world will take longer (not that it is that hard :-) ) Cheers Neil -- Neil Long, Team Cymru -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4138 bytes Desc: not available URL: From tjc at ecs.soton.ac.uk Wed Jun 8 03:32:28 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 8 Jun 2011 09:32:28 +0100 Subject: IPv6 day fun is beginning! In-Reply-To: <0F22E467-EFAC-4435-BA6A-686BCED16CF2@puck.nether.net> References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <0F22E467-EFAC-4435-BA6A-686BCED16CF2@puck.nether.net> <08BD27A3-1750-4D69-BC00-B5C3B7397251@ecs.soton.ac.uk> Message-ID: On 8 Jun 2011, at 04:46, Jared Mauch wrote: > > We have seen a traffic increase but nothing like what I was expecting, nay hoping to see. (i.e.: gigs and gigs of traffic - it does look like ~2x to me in an unscientific eye-look at a chart). Some of it may be down to client behaviour. Despite Facebook being a 30 second TTL, I had to flush my MacOS X DNS cache before I'd get the new AAAA record. Tim From tjc at ecs.soton.ac.uk Wed Jun 8 03:34:43 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 8 Jun 2011 09:34:43 +0100 Subject: Facebook's IPv6 Addresses - LOL In-Reply-To: References: <5E675827-099A-43E0-86C5-3C9C497A18AB@ecs.soton.ac.uk> Message-ID: On 8 Jun 2011, at 02:05, David Swafford wrote: > This is amusing: > > In case the formatting get's lost, their initial address includes > "face:booc" and one of the hops along the way is "dead:beef". :-) Cisco's is better... $ ping6 www.cisco.com PING6(56=40+8+8 bytes) 2001:630:d0:f103::c0:ffee --> 2001:420:80:1:c:15c0:d06:f00d 16 bytes from 2001:420:80:1:c:15c0:d06:f00d, icmp_seq=0 hlim=238 time=141.937 ms Tim From tim at pelican.org Wed Jun 8 04:13:10 2011 From: tim at pelican.org (Tim Franklin) Date: Wed, 08 Jun 2011 10:13:10 +0100 (BST) Subject: Hotmail? In-Reply-To: Message-ID: <6f1c0c87-f98e-43f1-8d69-ba84df3f6277@jennyfur.pelican.org> > Let me just step in here and say.. it's tough to build onto Zimbra. > At work, we support ~1000 users on Zimbra (network edition), with > hundreds of thousands of messages flowing through daily, and it > doesn't like you tinkering with stuff under the hood. Most of your > customizations get blown away when you upgrade. That said, I know > of some organizations who customize it like crazy (I had heard that > Lycos's free mail system is Zimbra-based, and Yahoo as well). > Once you deviate, though, don't expect to stick to Zimbra's > releases. Seconded. In terms of functionality and interface, I like Zimbra a lot, but they make Microsoft and Apple look like amateurs in the "our way, or not all" game. As a small friends-and-family installation, I can't afford to dedicate a whole box exclusively to Zimbra[0], and trying to make it play nice with anything else running on the same server is a pain. As you say, pretty much anything that they don't have a GUI setting for is a nightmare to keep working across upgrades. I'd imagine it's actually better if you're planning a bigger-scale deployment and can have the architecture a lot more in line with how they expect it to be from the start. Regards, Tim. [0] OK, I probably could now with a VM, but the virtualisation support on my hosting box wasn't really there when I started... From jeroen at unfix.org Wed Jun 8 04:28:40 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 08 Jun 2011 11:28:40 +0200 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... Message-ID: <4DEF40C8.3020502@unfix.org> It is really nice that folks where able to put AAAA records on their websites for only 24 hours, but they forgot to put in the glue on their nameservers. As such, for the folks testing IPv6-only, a lot of sites will fail unless they use a recursor that does the IPv4 for them. The root is there, .com does it mostly too (well, a+b have IPv6), but most sites don't. Thus maybe that can be done next year on the next IPv6 day? :) At least one step closer, now lets hope that sites also keep that IPv6 address there. Greets, Jeroen -- $ dig @d.gtld-servers.net ns1.google.com aaaa ; <<>> DiG 9.7.3 <<>> @d.gtld-servers.net ns1.google.com aaaa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16030 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.google.com. IN AAAA ;; AUTHORITY SECTION: google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns2.google.com. 172800 IN A 216.239.34.10 ns1.google.com. 172800 IN A 216.239.32.10 ns3.google.com. 172800 IN A 216.239.36.10 ns4.google.com. 172800 IN A 216.239.38.10 ;; Query time: 123 msec ;; SERVER: 192.31.80.30#53(192.31.80.30) ;; WHEN: Wed Jun 8 11:26:35 2011 ;; MSG SIZE rcvd: 164 $ dig @d.gtld-servers.net ns1.cisco.com aaaa ; <<>> DiG 9.7.3 <<>> @d.gtld-servers.net ns1.cisco.com aaaa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55271 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.cisco.com. IN AAAA ;; AUTHORITY SECTION: cisco.com. 172800 IN NS ns1.cisco.com. cisco.com. 172800 IN NS ns2.cisco.com. ;; ADDITIONAL SECTION: ns1.cisco.com. 172800 IN A 128.107.241.185 ns2.cisco.com. 172800 IN A 64.102.255.44 ;; Query time: 126 msec ;; SERVER: 192.31.80.30#53(192.31.80.30) ;; WHEN: Wed Jun 8 11:28:14 2011 ;; MSG SIZE rcvd: 95 From jerome at ceriz.fr Wed Jun 8 05:29:29 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Wed, 8 Jun 2011 12:29:29 +0200 Subject: Be aware of SLAAC adresses Message-ID: Hi ! To all contributors to this wonderful IPv6 day, juste a short notice : please avoid SLAAC adresses on your public servers ! First, in case of an hardware crash, the recovery will be done under presure and most will forget about forcing the new server's mac adress to the old one, wich will delay the recovery Second, it's beeing a little too transparent as the MAC adress may reveal the server's manufacturer, approximate manufacturing tdate, or the network controler model. Some may use it as a clue to design a proper exploit... Just a nightly thought while monitoring seen IPv6 adresses ;) -- J?r?me Nicolle From frnkblk at iname.com Wed Jun 8 05:33:23 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 8 Jun 2011 05:33:23 -0500 Subject: World of Warcraft may begin using IPv6 on Tuesday In-Reply-To: References: Message-ID: <000001cc25c7$7e7c3290$7b7497b0$@iname.com> More here: http://ipv6.blizzard.com/ To test IPv6 in World of Warcraft, you'll need to edit your config.wtf file and add the following line: SET unlockIPv6 "1" This will activate the IPv6 features. If your computer has a valid IPv6 address, you'll be able to check the "Enable IPv6" checkbox from the Network options in the World of Warcraft client. Once in the game, you'll be able to see which type of connection the client has made to the realms next to the latency information. Frank -----Original Message----- From: Kevin Day [mailto:toasty at dragondata.com] Sent: Saturday, April 23, 2011 1:10 PM To: NANOG list Subject: World of Warcraft may begin using IPv6 on Tuesday For those that don't know, World of Warcraft is currently the largest online role playing game, with somewhere over 12 million subscribers. Version 4.1 of the game is expected to be released this Tuesday, which will be automatically pushed to all clients. The current Beta version of 4.1 has full IPv6 support. In the beta, it's automatically enabled if you have native IPv6 (non-6to4, non-Teredo). While Blizzard has been pretty silent about this, barring a last minute revert or delay of this patch, there are suddenly going to be a bunch more users that can potentially use IPv6. And these users are the type who are going to be especially sensitive to latency, jitter and packet loss, since this is a real-time game platform. For those of you with Help Desks who have to support users like this, the associated setting in the game's Options menu is apparently called "Enable IPv6 when available". It's apparently grayed out if you do not have IPv6 at all, unchecked by default if you are on 6to4 or Teredo, and checked by default if you are on native v6. The tooltip says: "Enables the use of IPv6, the technology behind the next-generation Internet. Requires IPv6 connectivity to the internet. Checking this box without IPv6 connectivity may prevent you from playing WoW." Anyone from Activision/Blizzard who would like to chime in with more details? :) -- Kevin From david at davidswafford.com Wed Jun 8 05:33:38 2011 From: david at davidswafford.com (David Swafford) Date: Wed, 8 Jun 2011 06:33:38 -0400 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: References: Message-ID: Interesting, I'm having that same issue w/ www.nist.gov this morning. Front page loads fine, but all links return a 404. Here's my tracert if it helps: tracert www.nist.gov Tracing route to nist.gov [2610:20:6060:aa::a66b] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 2001:1938:2a7::1 2 85 ms 87 ms 84 ms gw-383.phx-01.us.sixxs.net[2001:1938:81:17e::1] 3 92 ms 99 ms 86 ms 2001:4de0:1000:a4::1 4 98 ms 87 ms 90 ms 1-3.ipv6.r1.ph.hwng.net[2001:4de0:1000:27::2] 5 136 ms 140 ms 131 ms 3-2.ipv6.r1.at.hwng.net[2001:4de0:1000:15::1] 6 167 ms 167 ms 175 ms 2-1.ipv6.r2.dc.hwng.net[2001:4de0:1000:7::1] 7 246 ms 253 ms 245 ms 5-4.ipv6.r2.am.hwng.net[2001:4de0:1000:5::1] 8 248 ms 247 ms 247 ms AMS-IX.v6.lambdanet.net[2001:7f8:1::a501:3237:1] 9 265 ms 267 ms 265 ms FRA-1-pos413.v6.lambdanet.net[2001:7f0:0:16::1] 10 275 ms 268 ms 268 ms 6b1.fft4.alter.net [2001:7f8::319e:0:1] 11 268 ms 304 ms 271 ms gw6.dca6.alter.net [2001:600:c:8::2] 12 271 ms 271 ms 270 ms 2600:803:22f::2 13 280 ms 272 ms 268 ms 2600:803:22f::2 14 270 ms 269 ms 273 ms 2610:20:6060:aa::a66b Trace complete. On a somewhat related note, anyone else notice that PING in Windows 7 reverts down to use only an IPv4 address when pinging a DNS name w/ options specified: ping www.nist.gov Pinging nist.gov [2610:20:6060:aa::a66b] with 32 bytes of data: Reply from 2610:20:6060:aa::a66b: time=274ms Reply from 2610:20:6060:aa::a66b: time=269ms Ping statistics for 2610:20:6060:aa::a66b: Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 269ms, Maximum = 274ms, Average = 271ms ping www.nist.gov -f Pinging nist.gov [129.6.13.45] with 32 bytes of data: Request timed out. David. On Wed, Jun 8, 2011 at 2:39 AM, Iljitsch van Beijnum wrote: > On 8 jun 2011, at 8:15, Andrew Koch wrote: > > > Speaking of www.nist.gov, I am getting the front page to load, but all > > links are returning a 404 Not Found when browsing via v6 > > Right. They seem to have solved their PMTUD issues, though. > > From joly at punkcast.com Wed Jun 8 05:58:15 2011 From: joly at punkcast.com (Joly MacFie) Date: Wed, 8 Jun 2011 06:58:15 -0400 Subject: ISOC-HK Kickstart IPv6! webcast 0600UTC = 2am EDT In-Reply-To: References: <4DEF1620.5000507@rancid.berkeley.edu> Message-ID: I pulled out this one quote from Geoff Huston http://isoc-ny.org/p2/?p=2210 entire archive is at http://www.livestream.com/internetsocietychapters/folder?dirId=d43f898a-0e06- 4f7b-a359-43b55a540aa1 j On Wed, Jun 8, 2011 at 3:32 AM, Joly MacFie wrote: > Yes, livestream.com notably absent from the list of participating > organizations. > > I'm guessing they use their own custom set up, but is there any reason > flash media server wouldn't operate over v6 if the dns was there? > > j > > On Wed, Jun 8, 2011 at 2:26 AM, Michael Sinatra > wrote: > > On 06/07/11 22:00, Joly MacFie wrote: > >> > >> ISOC Hong Kong has a great World IPv6 Day event - Kickstart IPv6! - > >> starting at 2pm HKT = 0600UTC (around an hour from now) and > >> running 3 and a half hours. > >> > >> It will be webcast live via the ISOC Chapters Livestream Channel on the > >> ISOC-HK site - http://isoc.hk > > > > I am watching now. Unfortunately, the website and video stream both > appear > > to be IPv4-only. :( > > > > michael > > > > > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org > -------------------------------------------------------------- > - > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From daniel at shunoshu.net Wed Jun 8 06:10:03 2011 From: daniel at shunoshu.net (Daniel Verlouw) Date: Wed, 8 Jun 2011 13:10:03 +0200 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: <4DEF40C8.3020502@unfix.org> References: <4DEF40C8.3020502@unfix.org> Message-ID: On Wed, Jun 8, 2011 at 11:28, Jeroen Massar wrote: > It is really nice that folks where able to put AAAA records on their > websites for only 24 hours, but they forgot to put in the glue on their > nameservers. agreed, but still better than juniper.net at the moment, glue seems to be completely gone at ultradns :P --Daniel. From dot at dotat.at Wed Jun 8 06:18:49 2011 From: dot at dotat.at (Tony Finch) Date: Wed, 8 Jun 2011 12:18:49 +0100 Subject: Hotmail? In-Reply-To: References: <000601cc259c$d5b64580$8122d080$@arkitechs.com> Message-ID: Martin Hepworth wrote: > Have a look at the Hermes mail system at cam.Ac.uk, built buy among > people Philip Hazel of exam fame Philip did not in fact have much to do with Hermes other than writing Exim. (I think he might have had a hand in early versions of our user administration scripts...) Our webmail software "Prayer" was written by David Carter. It's basically Pine for the web - it uses the UW-IMAP c-client library. We handle about 30K active / 5K concurrent users on one webmail server and it isn't breaking a sweat. David also did a lot of customization to Cyrus, mainly replication and undelete. These features are part of the standard Cyrus distribution now, and they hve been significantly improved by the guys at Fastmail.fm. I wrote a description of our setup several years ago. The architecture is still basically the same, though storage volumes are up by a few binary orders of magnitude. http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/talks/2004-02-ukuug/ Tony. -- f.anthony.n.finch http://dotat.at/ East Malin, East Hebrides: Variable 4, becoming westerly then southwesterly 5 to 7. Moderate or rough. Squally showers. Moderate or good. From frnkblk at iname.com Wed Jun 8 06:34:41 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 8 Jun 2011 06:34:41 -0500 Subject: IPv6 day fun is beginning! In-Reply-To: <20110608051024.GD25111@fig.mindcry.org> References: <20110608051024.GD25111@fig.mindcry.org> Message-ID: <000d01cc25d0$0ef1ba90$2cd52fb0$@iname.com> That is one of the issues that I believe RIPE is capturing -- how many dual-stacked sites have all their objects dual-stacked. Frank -----Original Message----- From: David Hill [mailto:dhill at mindcry.org] Sent: Wednesday, June 08, 2011 12:10 AM To: nanog at nanog.org Subject: Re: IPv6 day fun is beginning! Some sites still require ipv4 to load properly (stylesheets, statics, etc) disable ipv4 on your machine and go to: http://www.facebook.com http://www.cnn.com/WORLD/ http://www.yahoo.com/ I guess it is a start though. From frnkblk at iname.com Wed Jun 8 06:39:13 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 8 Jun 2011 06:39:13 -0500 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: References: <4DEF40C8.3020502@unfix.org> Message-ID: <001301cc25d0$b08ba9b0$11a2fd10$@iname.com> Ah...I saw the same thing at 6:01 Central. Lost DNS resolution of ipv6.juniper.net, and couldn't get A or NS records of juniper.net. Had to flush the cache on my DNS servers. Frank -----Original Message----- From: Daniel Verlouw [mailto:daniel at shunoshu.net] Sent: Wednesday, June 08, 2011 6:10 AM To: nanog Subject: Re: AAAA on various websites, but they all forgot to enable them on their nameservers.... On Wed, Jun 8, 2011 at 11:28, Jeroen Massar wrote: > It is really nice that folks where able to put AAAA records on their > websites for only 24 hours, but they forgot to put in the glue on their > nameservers. agreed, but still better than juniper.net at the moment, glue seems to be completely gone at ultradns :P --Daniel. From jared at puck.nether.net Wed Jun 8 06:42:10 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 8 Jun 2011 07:42:10 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <0F22E467-EFAC-4435-BA6A-686BCED16CF2@puck.nether.net> <08BD27A3-1750-4D69-BC00-B5C3B7397251@ecs.soton.ac.uk> Message-ID: On Jun 8, 2011, at 4:32 AM, Tim Chown wrote: > > On 8 Jun 2011, at 04:46, Jared Mauch wrote: > >> >> We have seen a traffic increase but nothing like what I was expecting, nay hoping to see. (i.e.: gigs and gigs of traffic - it does look like ~2x to me in an unscientific eye-look at a chart). > > Some of it may be down to client behaviour. Despite Facebook being a 30 second TTL, I had to flush my MacOS X DNS cache before I'd get the new AAAA record. My IPv4 is NATed but my IPv6 is not. I have a caching transparent cache for the IPv4 (squid) and watching the log made me notice similar behavior as well. Some systems were 'stuck' talking to the IPv4 address but were redirected to the v6 as a result of the squid proxy being dual-stacked. - Jared From jamie at photon.com Wed Jun 8 06:40:19 2011 From: jamie at photon.com (Jamie Bowden) Date: Wed, 8 Jun 2011 07:40:19 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> Thanks to HE's tunnel broker service, I've got fully functional dual stack at home (well, mostly, like most folks, VZ gives me a single address and I live behind that with NATv4, but otherwise, I loves me some FiOS) and yesterday went by for me without a hitch, including accessing Facebook (I'd hear from the wife and kid really quickly if they weren't working). For a working tunnel, I put my DIR-825 as the "DMZ" host behind the cheesy Actiontec router VZ requires, forward all traffic with zero firewalling to it, and let the D-Link appliance handle all my firewall needs (and it terminates my v6 tunnel obviously). The one thing I haven't quite figured out how to make it do (and maybe it's just not capable) is use the /48 HE routes to me. The box insists that the internal interface be on the same subnet as the external, and it hands out v6 addresses from that /64. Jamie -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Tuesday, June 07, 2011 7:15 PM To: Iljitsch van Beijnum Cc: NANOG list Subject: Re: IPv6 day fun is beginning! On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: > www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though If you go to www.v6.facebook.com it works, but it seems they have some problem on their main site. I am seeing some issues reaching them over IPv6. - Jared From frnkblk at iname.com Wed Jun 8 06:46:05 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 8 Jun 2011 06:46:05 -0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <4DEEEC5D.6010404@brightok.net> References: <20110606021449.402A2105A596@drugs.dv.isc.org> <4DEEEC5D.6010404@brightok.net> Message-ID: <001501cc25d1$a651c0f0$f2f542d0$@iname.com> As long % IPv6 content > % IPv6 eyeballs, I think the eyeball counts will naturally go up over time. As we're seeing today, content providers can add IPv6 access to a greater percentage of their content in a few months than what ISPs can do with a percentage of their customer base. Frank -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Tuesday, June 07, 2011 10:28 PM To: nanog at nanog.org Subject: Re: Microsoft's participation in World IPv6 day On 6/7/2011 9:01 PM, Lorenzo Colitti wrote: > On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong wrote: > >> Moving them to IPv6 and hoping that enough of the content providers >> move forward fast enough to minimize the extent of the LSN deployment >> required. > > The problem here is not content, it's access. Look at World IPv6 day. > What percentage of web content is represented? Probably order of 10%. > How about access? Our public stats still say 0.3% 0.3% of access is fine, so long as the margin of broken stacks and deployments is low enough. If they find that keeping the content dual stacked has acceptable problems, then it's just a matter of access gearing up to match. The largest fear for content is to dual stack and have service levels go down. The only data we really get from this day is a better understanding of the service levels when dual stacked at major content sites. Some access providers may also determine mistakes in their networks, or isolation or MTU issues through transit providers. Jack From jeroen at unfix.org Wed Jun 8 06:52:13 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 08 Jun 2011 13:52:13 +0200 Subject: IPv6 day fun is beginning! In-Reply-To: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> References: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> Message-ID: <4DEF626D.4070708@unfix.org> On 2011-Jun-08 13:40, Jamie Bowden wrote: > Thanks to HE's tunnel broker service, I've got fully functional dual > stack at home (well, mostly, like most folks, VZ gives me a single > address and I live behind that with NATv4, but otherwise, I loves me > some FiOS) and yesterday went by for me without a hitch, including Yesterday was 7th of June, World IPv6 day is happening now (since 00:00 UTC 8th of June) and still on for another 12 hours or so ;) But what you mention is something that has been seen a lot: people see the mention of IPv6 day and suddenly want IPv6 (which is a good thing btw and probably the most important thing) but instead of calling their ISP and asking it from them they get a tunnel. Getting IPv6 connectivity does not matter though as without IPv6 you'll just reach the IPv4 version of the site like you did yesterday and most likely tomorrow. As for your magic that you had to do to get a protocol 41 tunnel up and running, didn't HE.net have a PPTP trial for which they received a /15 or so from ARIN? Or did they actually not go on with it and are they now using that /15 for other services instead? Greets, Jeroen From hhoffman at ip-solutions.net Wed Jun 8 06:59:44 2011 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 8 Jun 2011 07:59:44 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> References: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> Message-ID: <001501cc25d3$91be5980$b53b0c80$@net> I have the same setup as you, except a Linux box that does the firewalling. The actiontec is pretty bad-ass, hardware-wise, and latest firmware versions give you a bit more freedom. Eth0 is the public addr and eth1 is the private addr. On Eth1 I've got a address from the routed /48 and then everything behind eth1 also gets addrs in that /48. (Maybe a firmware update is available for the Linksys? Or open/dd wrt). One thing to note, if you're not doing ipv6 filtering at the router. TCP/135 is open by default on a Windows 7 laptop here so if you're not filtering at the laptop then you're potentially allowing the world to access that port. Cheers, Harry -----Original Message----- From: Jamie Bowden [mailto:jamie at photon.com] Sent: Wednesday, June 08, 2011 7:40 AM To: NANOG list Subject: RE: IPv6 day fun is beginning! Thanks to HE's tunnel broker service, I've got fully functional dual stack at home (well, mostly, like most folks, VZ gives me a single address and I live behind that with NATv4, but otherwise, I loves me some FiOS) and yesterday went by for me without a hitch, including accessing Facebook (I'd hear from the wife and kid really quickly if they weren't working). For a working tunnel, I put my DIR-825 as the "DMZ" host behind the cheesy Actiontec router VZ requires, forward all traffic with zero firewalling to it, and let the D-Link appliance handle all my firewall needs (and it terminates my v6 tunnel obviously). The one thing I haven't quite figured out how to make it do (and maybe it's just not capable) is use the /48 HE routes to me. The box insists that the internal interface be on the same subnet as the external, and it hands out v6 addresses from that /64. Jamie -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Tuesday, June 07, 2011 7:15 PM To: Iljitsch van Beijnum Cc: NANOG list Subject: Re: IPv6 day fun is beginning! On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: > www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though If you go to www.v6.facebook.com it works, but it seems they have some problem on their main site. I am seeing some issues reaching them over IPv6. - Jared From jamie at photon.com Wed Jun 8 07:07:27 2011 From: jamie at photon.com (Jamie Bowden) Date: Wed, 8 Jun 2011 08:07:27 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: <4DEF626D.4070708@unfix.org> References: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> <4DEF626D.4070708@unfix.org> Message-ID: <275FEA2949B48341A3B46F424B613D857C59@WDC-MX.photon.com> If Verizon would offer v6 on FiOS, I'd already be there. They don't, so I've got a tunnel coming out of HE's Ashburn, VA POP. As far as me losing a day (or is it gaining?), blah...too early in the morning. It really is only Wednesday isn't it? Jamie -----Original Message----- From: Jeroen Massar [mailto:jeroen at unfix.org] Sent: Wednesday, June 08, 2011 7:52 AM To: Jamie Bowden Cc: NANOG list Subject: Re: IPv6 day fun is beginning! On 2011-Jun-08 13:40, Jamie Bowden wrote: > Thanks to HE's tunnel broker service, I've got fully functional dual > stack at home (well, mostly, like most folks, VZ gives me a single > address and I live behind that with NATv4, but otherwise, I loves me > some FiOS) and yesterday went by for me without a hitch, including Yesterday was 7th of June, World IPv6 day is happening now (since 00:00 UTC 8th of June) and still on for another 12 hours or so ;) But what you mention is something that has been seen a lot: people see the mention of IPv6 day and suddenly want IPv6 (which is a good thing btw and probably the most important thing) but instead of calling their ISP and asking it from them they get a tunnel. Getting IPv6 connectivity does not matter though as without IPv6 you'll just reach the IPv4 version of the site like you did yesterday and most likely tomorrow. As for your magic that you had to do to get a protocol 41 tunnel up and running, didn't HE.net have a PPTP trial for which they received a /15 or so from ARIN? Or did they actually not go on with it and are they now using that /15 for other services instead? Greets, Jeroen From jamie at photon.com Wed Jun 8 07:16:57 2011 From: jamie at photon.com (Jamie Bowden) Date: Wed, 8 Jun 2011 08:16:57 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: <001501cc25d3$91be5980$b53b0c80$@net> References: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> <001501cc25d3$91be5980$b53b0c80$@net> Message-ID: <275FEA2949B48341A3B46F424B613D857C5A@WDC-MX.photon.com> The Actiontec is underpowered and if you put too many hosts behind it will run out of memory for its NAT tables and your connectivity goes to hell. My router is a D-Link not a Linksys. When I last upgraded my home router, the D-Links were plainly v6 capable; the Linksys may or may not have been, but if so, it wasn't on the box and since my old router was suffering from hardware problems, I wasn't really in the mood to go out to Linksys' web site and dig around to hopefully find out. That and Cisco has irritated me with their abandonment issues. My old Linksys was still running draft N code and hadn't seen a firmware update in two plus years. Five minutes after getting the D-Link up and running, I did have my HE tunnel though, which is nifty. As far as the firewall goes, it is doing SPI on both v4 and v6 with a default deny rule for all unrequested traffic. Jamie -----Original Message----- From: Harry Hoffman [mailto:hhoffman at ip-solutions.net] Sent: Wednesday, June 08, 2011 8:00 AM To: Jamie Bowden; 'NANOG list' Subject: RE: IPv6 day fun is beginning! I have the same setup as you, except a Linux box that does the firewalling. The actiontec is pretty bad-ass, hardware-wise, and latest firmware versions give you a bit more freedom. Eth0 is the public addr and eth1 is the private addr. On Eth1 I've got a address from the routed /48 and then everything behind eth1 also gets addrs in that /48. (Maybe a firmware update is available for the Linksys? Or open/dd wrt). One thing to note, if you're not doing ipv6 filtering at the router. TCP/135 is open by default on a Windows 7 laptop here so if you're not filtering at the laptop then you're potentially allowing the world to access that port. Cheers, Harry -----Original Message----- From: Jamie Bowden [mailto:jamie at photon.com] Sent: Wednesday, June 08, 2011 7:40 AM To: NANOG list Subject: RE: IPv6 day fun is beginning! Thanks to HE's tunnel broker service, I've got fully functional dual stack at home (well, mostly, like most folks, VZ gives me a single address and I live behind that with NATv4, but otherwise, I loves me some FiOS) and yesterday went by for me without a hitch, including accessing Facebook (I'd hear from the wife and kid really quickly if they weren't working). For a working tunnel, I put my DIR-825 as the "DMZ" host behind the cheesy Actiontec router VZ requires, forward all traffic with zero firewalling to it, and let the D-Link appliance handle all my firewall needs (and it terminates my v6 tunnel obviously). The one thing I haven't quite figured out how to make it do (and maybe it's just not capable) is use the /48 HE routes to me. The box insists that the internal interface be on the same subnet as the external, and it hands out v6 addresses from that /64. Jamie -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Tuesday, June 07, 2011 7:15 PM To: Iljitsch van Beijnum Cc: NANOG list Subject: Re: IPv6 day fun is beginning! On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: > www.facebook.com has AAAA but doesn't load for me over IPv6, it does for others though If you go to www.v6.facebook.com it works, but it seems they have some problem on their main site. I am seeing some issues reaching them over IPv6. - Jared From dot at dotat.at Wed Jun 8 07:46:08 2011 From: dot at dotat.at (Tony Finch) Date: Wed, 8 Jun 2011 13:46:08 +0100 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> <47F2C08A-E828-4C2A-8C3D-28C008517221@puck.nether.net> Message-ID: TJ wrote: > > ... and Gmail, too ... Except they are not relaying mail over v6. Tony. -- f.anthony.n.finch http://dotat.at/ South Utsire: Variable 3 or 4, but in far southeast, easterly 5 at first and becoming westerly 5 to 7 later. Slight or moderate. Rain then showers. Poor, becoming good. From marka at isc.org Wed Jun 8 07:46:44 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 08 Jun 2011 22:46:44 +1000 Subject: IPv6 day fun is beginning! In-Reply-To: Your message of "Wed, 08 Jun 2011 00:07:26 MST." References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <20110608041503.A4CFE1075035@drugs.dv.isc.org> Message-ID: <20110608124644.9078B107F0E8@drugs.dv.isc.org> In message , Owen DeLong write s: > > On Jun 7, 2011, at 9:15 PM, Mark Andrews wrote: > > >=20 > > In message = > > .us>, John van Oppen writes: > >> I was wondering the same thing... we have v6 enabled to about 700 = > users i=3D > >> n our native Ethernet to the home deployment here in Seattle. = > Unfortunat=3D > >> ely, user routers don't seem to often support v6 resulting in only = > about 2-=3D > >> 8% of users in most buildings using it, and most of those are just = > people p=3D > >> lugged directly into the wall jacks we provide without routers. I = > wonder =3D > >> how long it will take for everyone to upgrade their home routers. > >>=20 > >> John > >=20 > > If all the home CPE router vendors stopped shipping IPv4 only boxes, > > not that long. At the moment the price point for IPv6 CPE routers > > is still 2-3x the IPv4 only boxes when you can find one though not > > all of that difference is IPv6. The IPv6 boxes often have multiple > > radio and other extras. This shows that CPE vendors still see IPv6 > > as something *extra* and not something that should be *standard*. > >=20 > The D-Link DIR series v6 capables are not actually more than about a 10% > premium over the corresponding ipv4-only competition. > > I see them in computer stores fairly regularly these days. > > Owen Wireless G Modem Router $79.00 v4 G N-150 $79.95 v4 G DIR-615 $129.00 v4/v6 G/N DIR-815 $199.95 v4/v6 G/N The IPv6 price point is still well above the IPv4 only price point. 1.00AUD = 1.06USD -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Wed Jun 8 07:47:32 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 8 Jun 2011 05:47:32 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong wrote: > > On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote: > >> Owen, >> >> On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong wrote: >>> LSN is required when access providers come across the following two >>> combined constraints: >>> >>> ? ? ? ?1. ? ? ?No more IPv4 addresses to give to customers. >>> ? ? ? ?2. ? ? ?No ability to deploy those customers on IPv6. >> >> 2 has little bearing on need of LSN to access v4. ?Insufficient amount >> of IPv4 addresses => LSN required. >> >> Regards, >> Martin > > No, if you have the option of deploying the customers on IPv6, you don't > need LSN. > > The problem is that until the vast majority of content is dual-stack, you can't > deploy customers on IPv6 without IPv4. > > cough cough NAT64/DNS64 ... Cameron > Owen > > > From cb.list6 at gmail.com Wed Jun 8 07:48:08 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 8 Jun 2011 05:48:08 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: On Wed, Jun 8, 2011 at 5:47 AM, Cameron Byrne wrote: > On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong wrote: >> >> On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote: >> >>> Owen, >>> >>> On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong wrote: >>>> LSN is required when access providers come across the following two >>>> combined constraints: >>>> >>>> ? ? ? ?1. ? ? ?No more IPv4 addresses to give to customers. >>>> ? ? ? ?2. ? ? ?No ability to deploy those customers on IPv6. >>> >>> 2 has little bearing on need of LSN to access v4. ?Insufficient amount >>> of IPv4 addresses => LSN required. >>> >>> Regards, >>> Martin >> >> No, if you have the option of deploying the customers on IPv6, you don't >> need LSN. >> >> The problem is that until the vast majority of content is dual-stack, you can't >> deploy customers on IPv6 without IPv4. >> >> > > cough cough NAT64/DNS64 ... > cough DS-lite. Cameron > Cameron > >> Owen >> >> >> > From millnert at gmail.com Wed Jun 8 07:51:42 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 8 Jun 2011 08:51:42 -0400 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: Cameron, On Wed, Jun 8, 2011 at 8:48 AM, Cameron Byrne wrote: > On Wed, Jun 8, 2011 at 5:47 AM, Cameron Byrne wrote: >> On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong wrote: >>> >>> On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote: >>> >>>> Owen, >>>> >>>> On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong wrote: >>>>> LSN is required when access providers come across the following two >>>>> combined constraints: >>>>> >>>>> ? ? ? ?1. ? ? ?No more IPv4 addresses to give to customers. >>>>> ? ? ? ?2. ? ? ?No ability to deploy those customers on IPv6. >>>> >>>> 2 has little bearing on need of LSN to access v4. ?Insufficient amount >>>> of IPv4 addresses => LSN required. >>>> >>>> Regards, >>>> Martin >>> >>> No, if you have the option of deploying the customers on IPv6, you don't >>> need LSN. >>> >>> The problem is that until the vast majority of content is dual-stack, you can't >>> deploy customers on IPv6 without IPv4. >>> >>> >> >> cough cough NAT64/DNS64 ... >> > > cough DS-lite. > > Cameron AF translators are in the same class of technology as LSN -- to me they are the same (_NAT_64). Someone who thinks you will be successful in selling an Internet with pure ipv6 only access today to consumers must be living on a different planet. Cheers, Martin From owen at delong.com Wed Jun 8 07:55:27 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 05:55:27 -0700 Subject: IPv6 day fun is beginning! In-Reply-To: <4DEF626D.4070708@unfix.org> References: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> <4DEF626D.4070708@unfix.org> Message-ID: On Jun 8, 2011, at 4:52 AM, Jeroen Massar wrote: > On 2011-Jun-08 13:40, Jamie Bowden wrote: >> Thanks to HE's tunnel broker service, I've got fully functional dual >> stack at home (well, mostly, like most folks, VZ gives me a single >> address and I live behind that with NATv4, but otherwise, I loves me >> some FiOS) and yesterday went by for me without a hitch, including > > Yesterday was 7th of June, World IPv6 day is happening now (since 00:00 > UTC 8th of June) and still on for another 12 hours or so ;) > > > But what you mention is something that has been seen a lot: people see > the mention of IPv6 day and suddenly want IPv6 (which is a good thing > btw and probably the most important thing) but instead of calling their > ISP and asking it from them they get a tunnel. > > Getting IPv6 connectivity does not matter though as without IPv6 you'll > just reach the IPv4 version of the site like you did yesterday and most > likely tomorrow. > > > As for your magic that you had to do to get a protocol 41 tunnel up and > running, didn't HE.net have a PPTP trial for which they received a /15 > or so from ARIN? Or did they actually not go on with it and are they now > using that /15 for other services instead? > > Greets, > Jeroen The PPTP trial is presently suspended pending resolution of certain performance issues we ran into with the PPTP servers. We are planning to move forward with it, but, I cannot provide any date information at this time. Owen From owen at delong.com Wed Jun 8 08:04:26 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 06:04:26 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: On Jun 8, 2011, at 5:47 AM, Cameron Byrne wrote: > On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong wrote: >> >> On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote: >> >>> Owen, >>> >>> On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong wrote: >>>> LSN is required when access providers come across the following two >>>> combined constraints: >>>> >>>> 1. No more IPv4 addresses to give to customers. >>>> 2. No ability to deploy those customers on IPv6. >>> >>> 2 has little bearing on need of LSN to access v4. Insufficient amount >>> of IPv4 addresses => LSN required. >>> >>> Regards, >>> Martin >> >> No, if you have the option of deploying the customers on IPv6, you don't >> need LSN. >> >> The problem is that until the vast majority of content is dual-stack, you can't >> deploy customers on IPv6 without IPv4. >> >> > > cough cough NAT64/DNS64 ... Doesn't solve the problem unless your users are all on cell-phone browsers that don't do a lot of the things most users do with real internet connections. Owen From owen at delong.com Wed Jun 8 08:03:31 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 06:03:31 -0700 Subject: IPv6 day fun is beginning! In-Reply-To: <20110608124644.9078B107F0E8@drugs.dv.isc.org> References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <20110608041503.A4CFE1075035@drugs.dv.isc.org> <20110608124644.9078B107F0E8@drugs.dv.isc.org> Message-ID: On Jun 8, 2011, at 5:46 AM, Mark Andrews wrote: > > In message , Owen DeLong write > s: >> >> On Jun 7, 2011, at 9:15 PM, Mark Andrews wrote: >> >>> =20 >>> In message = >> >> .us>, John van Oppen writes: >>>> I was wondering the same thing... we have v6 enabled to about 700 = >> users i=3D >>>> n our native Ethernet to the home deployment here in Seattle. = >> Unfortunat=3D >>>> ely, user routers don't seem to often support v6 resulting in only = >> about 2-=3D >>>> 8% of users in most buildings using it, and most of those are just = >> people p=3D >>>> lugged directly into the wall jacks we provide without routers. I = >> wonder =3D >>>> how long it will take for everyone to upgrade their home routers. >>>> =20 >>>> John >>> =20 >>> If all the home CPE router vendors stopped shipping IPv4 only boxes, >>> not that long. At the moment the price point for IPv6 CPE routers >>> is still 2-3x the IPv4 only boxes when you can find one though not >>> all of that difference is IPv6. The IPv6 boxes often have multiple >>> radio and other extras. This shows that CPE vendors still see IPv6 >>> as something *extra* and not something that should be *standard*. >>> =20 >> The D-Link DIR series v6 capables are not actually more than about a 10% >> premium over the corresponding ipv4-only competition. >> >> I see them in computer stores fairly regularly these days. >> >> Owen > > Wireless G Modem Router $79.00 v4 G > N-150 $79.95 v4 G > DIR-615 $129.00 v4/v6 G/N > DIR-815 $199.95 v4/v6 G/N > Interesting... In the US, it's more like: N-150 $35 v4/-- G DIR-615 $44 v4/v6 A/N(5) or B/G/N(2.4) DIR-815 $79 v4/v6 A/N(5) and B/G/N(2.4) The jump in price from the 615 to 815 is likely more related to the dual-radio vs. dual-band single radio. The jump between the N-150 and DIR-615 could be similarly attributed to the single-band radio vs. dual-band radio As such, it doesn't look like a huge jump in price for IPv6 to me. It looks comparable. > The IPv6 price point is still well above the IPv4 only price point. > > 1.00AUD = 1.06USD Perhaps that's an accurate exchange rate, but, apparently there is a bigger difference in pricing than just the exchange point. Prices above obtained by google search a few minutes ago. Owen From cb.list6 at gmail.com Wed Jun 8 08:09:07 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 8 Jun 2011 06:09:07 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: On Wed, Jun 8, 2011 at 6:04 AM, Owen DeLong wrote: > > On Jun 8, 2011, at 5:47 AM, Cameron Byrne wrote: > >> On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong wrote: >>> >>> On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote: >>> >>>> Owen, >>>> >>>> On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong wrote: >>>>> LSN is required when access providers come across the following two >>>>> combined constraints: >>>>> >>>>> ? ? ? ?1. ? ? ?No more IPv4 addresses to give to customers. >>>>> ? ? ? ?2. ? ? ?No ability to deploy those customers on IPv6. >>>> >>>> 2 has little bearing on need of LSN to access v4. ?Insufficient amount >>>> of IPv4 addresses => LSN required. >>>> >>>> Regards, >>>> Martin >>> >>> No, if you have the option of deploying the customers on IPv6, you don't >>> need LSN. >>> >>> The problem is that until the vast majority of content is dual-stack, you can't >>> deploy customers on IPv6 without IPv4. >>> >>> >> >> cough cough NAT64/DNS64 ... > > Doesn't solve the problem unless your users are all on cell-phone browsers > that don't do a lot of the things most users do with real internet connections. > Most of my users are on cell phone browsers :) Furthermore, i can choose which ones get ipv4-only NAT44 and which get ipv6-only + NAT64 Now, only if there was major cell phone OEM support .... Also, i would like to extend the idea that as IPv6 becomes dominant in the next few years (pending access networks), the need for IPv4 access will wane and LSN for the IPv4 will become more acceptable as IPv4 is just the long tail. Cameron From owen at delong.com Wed Jun 8 08:05:23 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 06:05:23 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: <21C0FAC4-B2C4-4261-9862-426138910067@delong.com> On Jun 8, 2011, at 5:48 AM, Cameron Byrne wrote: > On Wed, Jun 8, 2011 at 5:47 AM, Cameron Byrne wrote: >> On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong wrote: >>> >>> On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote: >>> >>>> Owen, >>>> >>>> On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong wrote: >>>>> LSN is required when access providers come across the following two >>>>> combined constraints: >>>>> >>>>> 1. No more IPv4 addresses to give to customers. >>>>> 2. No ability to deploy those customers on IPv6. >>>> >>>> 2 has little bearing on need of LSN to access v4. Insufficient amount >>>> of IPv4 addresses => LSN required. >>>> >>>> Regards, >>>> Martin >>> >>> No, if you have the option of deploying the customers on IPv6, you don't >>> need LSN. >>> >>> The problem is that until the vast majority of content is dual-stack, you can't >>> deploy customers on IPv6 without IPv4. >>> >>> >> >> cough cough NAT64/DNS64 ... >> > > cough DS-lite. DS-lite is a slightly less pathological form of LSN. It's still LSN, it just removes the second NAT at the CPE. Owen From trejrco at gmail.com Wed Jun 8 08:07:18 2011 From: trejrco at gmail.com (TJ) Date: Wed, 8 Jun 2011 09:07:18 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: <20110608124644.9078B107F0E8@drugs.dv.isc.org> References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <20110608041503.A4CFE1075035@drugs.dv.isc.org> <20110608124644.9078B107F0E8@drugs.dv.isc.org> Message-ID: Just FWIW: US, Amazon, Dlink, DIR615, $35.45 ... /TJ On Wed, Jun 8, 2011 at 08:46, Mark Andrews wrote: > > In message , Owen DeLong > write > s: > > > > On Jun 7, 2011, at 9:15 PM, Mark Andrews wrote: > > > > >=20 > > > In message = > > > > .us>, John van Oppen writes: > > >> I was wondering the same thing... we have v6 enabled to about 700 = > > users i=3D > > >> n our native Ethernet to the home deployment here in Seattle. = > > Unfortunat=3D > > >> ely, user routers don't seem to often support v6 resulting in only = > > about 2-=3D > > >> 8% of users in most buildings using it, and most of those are just = > > people p=3D > > >> lugged directly into the wall jacks we provide without routers. I = > > wonder =3D > > >> how long it will take for everyone to upgrade their home routers. > > >>=20 > > >> John > > >=20 > > > If all the home CPE router vendors stopped shipping IPv4 only boxes, > > > not that long. At the moment the price point for IPv6 CPE routers > > > is still 2-3x the IPv4 only boxes when you can find one though not > > > all of that difference is IPv6. The IPv6 boxes often have multiple > > > radio and other extras. This shows that CPE vendors still see IPv6 > > > as something *extra* and not something that should be *standard*. > > >=20 > > The D-Link DIR series v6 capables are not actually more than about a 10% > > premium over the corresponding ipv4-only competition. > > > > I see them in computer stores fairly regularly these days. > > > > Owen > > Wireless G Modem Router $79.00 v4 G > N-150 $79.95 v4 G > DIR-615 $129.00 v4/v6 G/N > DIR-815 $199.95 v4/v6 G/N > > The IPv6 price point is still well above the IPv4 only price point. > > 1.00AUD = 1.06USD > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From owen at delong.com Wed Jun 8 08:30:55 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 06:30:55 -0700 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: <43E0C491-0792-49FE-AC1E-539B5B775890@delong.com> On Jun 8, 2011, at 6:09 AM, Cameron Byrne wrote: > On Wed, Jun 8, 2011 at 6:04 AM, Owen DeLong wrote: >> >> On Jun 8, 2011, at 5:47 AM, Cameron Byrne wrote: >> >>> On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong wrote: >>>> >>>> On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote: >>>> >>>>> Owen, >>>>> >>>>> On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong wrote: >>>>>> LSN is required when access providers come across the following two >>>>>> combined constraints: >>>>>> >>>>>> 1. No more IPv4 addresses to give to customers. >>>>>> 2. No ability to deploy those customers on IPv6. >>>>> >>>>> 2 has little bearing on need of LSN to access v4. Insufficient amount >>>>> of IPv4 addresses => LSN required. >>>>> >>>>> Regards, >>>>> Martin >>>> >>>> No, if you have the option of deploying the customers on IPv6, you don't >>>> need LSN. >>>> >>>> The problem is that until the vast majority of content is dual-stack, you can't >>>> deploy customers on IPv6 without IPv4. >>>> >>>> >>> >>> cough cough NAT64/DNS64 ... >> >> Doesn't solve the problem unless your users are all on cell-phone browsers >> that don't do a lot of the things most users do with real internet connections. >> > > Most of my users are on cell phone browsers :) > > Furthermore, i can choose which ones get ipv4-only NAT44 and which get > ipv6-only + NAT64 > > Now, only if there was major cell phone OEM support .... > > > Also, i would like to extend the idea that as IPv6 becomes dominant in > the next few years (pending access networks), the need for IPv4 access > will wane and LSN for the IPv4 will become more acceptable as IPv4 is > just the long tail. > Agreed... However, where I differ is that I believe it is content and services which will drive the ability for IPv4 to be considered long tail. If all of the content and services were IPv6-capable today, the need for LSN would be very near zero (limited to the consumer devices that need to be upgraded/replaced to understand IPv6.) However, as it stands currently, a consumer would not consider an IPv6 connection with NAT64 or other LSN to be equivalent to what they expect today (unless they're on a cell-phone where they already expect the internet experience to be completely degraded). Owen From marka at isc.org Wed Jun 8 08:41:52 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 08 Jun 2011 23:41:52 +1000 Subject: IPv6 day fun is beginning! In-Reply-To: Your message of "Wed, 08 Jun 2011 06:03:31 MST." References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <20110608041503.A4CFE1075035@drugs.dv.isc.org> <20110608124644.9078B107F0E8@drugs.dv.isc.org> Message-ID: <20110608134152.58256107FE7F@drugs.dv.isc.org> In message , Owen DeLong writes: > > On Jun 8, 2011, at 5:46 AM, Mark Andrews wrote: > > >=20 > > In message , Owen = > DeLong write > > s: > >>=20 > >> On Jun 7, 2011, at 9:15 PM, Mark Andrews wrote: > >>=20 > >>> =3D20 > >>> In message =3D > >> >>> .us>, John van Oppen writes: > >>>> I was wondering the same thing... we have v6 enabled to about 700 = > =3D > >> users i=3D3D > >>>> n our native Ethernet to the home deployment here in Seattle. =3D > >> Unfortunat=3D3D > >>>> ely, user routers don't seem to often support v6 resulting in only = > =3D > >> about 2-=3D3D > >>>> 8% of users in most buildings using it, and most of those are just = > =3D > >> people p=3D3D > >>>> lugged directly into the wall jacks we provide without routers. I = > =3D > >> wonder =3D3D > >>>> how long it will take for everyone to upgrade their home routers. > >>>> =3D20 > >>>> John > >>> =3D20 > >>> If all the home CPE router vendors stopped shipping IPv4 only boxes, > >>> not that long. At the moment the price point for IPv6 CPE routers > >>> is still 2-3x the IPv4 only boxes when you can find one though not > >>> all of that difference is IPv6. The IPv6 boxes often have multiple > >>> radio and other extras. This shows that CPE vendors still see IPv6 > >>> as something *extra* and not something that should be *standard*. > >>> =3D20 > >> The D-Link DIR series v6 capables are not actually more than about a = > 10% > >> premium over the corresponding ipv4-only competition. > >>=20 > >> I see them in computer stores fairly regularly these days. > >>=20 > >> Owen > >=20 > > Wireless G Modem Router $79.00 v4 G > > N-150 $79.95 v4 G > > DIR-615 $129.00 v4/v6 G/N > > DIR-815 $199.95 v4/v6 G/N > >=20 > Interesting... In the US, it's more like: > > N-150 $35 v4/-- G > DIR-615 $44 v4/v6 A/N(5) or B/G/N(2.4) > DIR-815 $79 v4/v6 A/N(5) and B/G/N(2.4) > > The jump in price from the 615 to 815 is likely more related > to the dual-radio vs. dual-band single radio. > > The jump between the N-150 and DIR-615 could be similarly > attributed to the single-band radio vs. dual-band radio > > As such, it doesn't look like a huge jump in price for IPv6 to me. > It looks comparable. > > > The IPv6 price point is still well above the IPv4 only price point. > >=20 > > 1.00AUD =3D 1.06USD > > Perhaps that's an accurate exchange rate, but, apparently there is > a bigger difference in pricing than just the exchange point. Prices > above obtained by google search a few minutes ago. The AUD prices include all taxes. That being said one can still buy retail in the states including taxes, add shipping and come out in front for a identical product. 3x markup is a rip-off. > Owen > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Marcus.Williams at ed.gov Wed Jun 8 08:46:23 2011 From: Marcus.Williams at ed.gov (Williams, Marcus (Contractor)) Date: Wed, 8 Jun 2011 08:46:23 -0500 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <0F22E467-EFAC-4435-BA6A-686BCED16CF2@puck.nether.net> <08BD27A3-1750-4D69-BC00-B5C3B7397251@ecs.soton.ac.uk> Message-ID: > -----Original Message----- > From: Tim Chown [mailto:tjc at ecs.soton.ac.uk] > Sent: Wednesday, June 08, 2011 4:32 AM > I had to flush my MacOS X DNS cache before I'd get the > new AAAA record. World IPv6 Day will be tomorrow. Marcus Williams From nick at flhsi.com Wed Jun 8 08:51:21 2011 From: nick at flhsi.com (Nick Olsen) Date: Wed, 8 Jun 2011 09:51:21 -0400 Subject: Cogent IPv6 Message-ID: <6ac5bc37$45ab67ae$73965090$@com> I'm sure someone here is doing IPv6 peering with cogent. We've got a Gig with them, So they don't do that dual peering thing with us. (They do it on another 100Mb/s circuit we have... I despise it.) Just kind of curious how they go about it. Do they issue you a small IPv6 block for your interface, just like they do for IPv4? Is it a separate session? Any things to be aware of before pulling the trigger on it? (Other then them not having connectivity to HE's IPv6 side of things, Wish they would fix that already...) Nick Olsen Network Operations (855) FLSPEED x106 From swmike at swm.pp.se Wed Jun 8 08:54:40 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 8 Jun 2011 15:54:40 +0200 (CEST) Subject: IPv6 day fun is beginning! In-Reply-To: <20110608134152.58256107FE7F@drugs.dv.isc.org> References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <20110608041503.A4CFE1075035@drugs.dv.isc.org> <20110608124644.9078B107F0E8@drugs.dv.isc.org> <20110608134152.58256107FE7F@drugs.dv.isc.org> Message-ID: On Wed, 8 Jun 2011, Mark Andrews wrote: > The AUD prices include all taxes. That being said one can still buy > retail in the states including taxes, add shipping and come out in front > for a identical product. 3x markup is a rip-off. Swedish prices are approximately equivalent of 110USD for the 815, 60USD for the 615, that's including 25% VAT. Either you have high customs on these devices, or your retailer is ripping you off. -- Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Wed Jun 8 09:09:21 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 07:09:21 -0700 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <0F22E467-EFAC-4435-BA6A-686BCED16CF2@puck.nether.net> <08BD27A3-1750-4D69-BC00-B5C3B7397251@ecs.soton.ac.uk> Message-ID: <1AC42D4F-4046-481C-A5D8-A3CFAEC93138@delong.com> On Jun 8, 2011, at 6:46 AM, Williams, Marcus (Contractor) wrote: >> -----Original Message----- >> From: Tim Chown [mailto:tjc at ecs.soton.ac.uk] >> Sent: Wednesday, June 08, 2011 4:32 AM >> I had to flush my MacOS X DNS cache before I'd get the >> new AAAA record. > > > World IPv6 Day will be tomorrow. > > Marcus Williams > > World IPv6 day is today. It started at 0000 UTC June 8 and goes to just before 0000 UTC June 9. As I write this, there are approximately 10 hours remaining in world IPv6 day. Owen From owen at delong.com Wed Jun 8 09:08:12 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 07:08:12 -0700 Subject: IPv6 day fun is beginning! In-Reply-To: <20110608134152.58256107FE7F@drugs.dv.isc.org> References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <20110608041503.A4CFE1075035@drugs.dv.isc.org> <20110608124644.9078B107F0E8@drugs.dv.isc.org> <20110608134152.58256107FE7F@drugs.dv.isc.org> Message-ID: <812713B8-4B78-4C23-AB97-7B9AFA0B9A62@delong.com> > > The AUD prices include all taxes. That being said one can still > buy retail in the states including taxes, add shipping and come out > in front for a identical product. 3x markup is a rip-off. > No argument here, but, as I'm in the states... The worst tax rate I know in the US is California (where I live) at 9.25%, but, if you order on-line (at least for a few more weeks), there's usually no sales tax. (California thinks their legislature can somehow pass a law that will affect out-of-state retailers, but, I'm not sure how they hope to enforce it). Owen From mark at amplex.net Wed Jun 8 09:12:19 2011 From: mark at amplex.net (Mark Radabaugh) Date: Wed, 08 Jun 2011 10:12:19 -0400 Subject: Cogent IPv6 In-Reply-To: <6ac5bc37$45ab67ae$73965090$@com> References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: <4DEF8343.1030003@amplex.net> On 6/8/11 9:51 AM, Nick Olsen wrote: > I'm sure someone here is doing IPv6 peering with cogent. We've got a Gig > with them, So they don't do that dual peering thing with us. (They do it on > another 100Mb/s circuit we have... I despise it.) > Just kind of curious how they go about it. > Do they issue you a small IPv6 block for your interface, just like they do > for IPv4? Is it a separate session? Any things to be aware of before > pulling the trigger on it? (Other then them not having connectivity to HE's > IPv6 side of things, Wish they would fix that already...) > > Nick Olsen > Network Operations (855) FLSPEED x106 > > For our peering with Cogent they assigned us a /112 from 2001:550. When we turned this up they dropped the old 'dual peering' thing for IPv4. Said they did not need that arrangement any longer. IPv6 seems to work fine with Cogent. Mark -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From jeroen at unfix.org Wed Jun 8 09:14:57 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 08 Jun 2011 16:14:57 +0200 Subject: IPv6 day fun is beginning! In-Reply-To: <1AC42D4F-4046-481C-A5D8-A3CFAEC93138@delong.com> References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <0F22E467-EFAC-4435-BA6A-686BCED16CF2@puck.nether.net> <08BD27A3-1750-4D69-BC00-B5C3B7397251@ecs.soton.ac.uk> <1AC42D4F-4046-481C-A5D8-A3CFAEC93138@delong.com> Message-ID: <4DEF83E1.8040100@unfix.org> On 2011-Jun-08 16:09, Owen DeLong wrote: [..] > World IPv6 day is today. It started at 0000 UTC June 8 and goes to > just before 0000 UTC June 9. As I write this, there are approximately > 10 hours remaining in world IPv6 day. I think it is quite obvious that nothing serious broke anywhere ;) (read: not many users started whining that things didn't work) So folks, who are doing the 24-hour AAAA-on-your-site thing, maybe you can start pondering on keeping those records there, or are we afraid that the proxies set up lose too much of the oh-so-useful IP logs? Greets, Jeroen From millnert at gmail.com Wed Jun 8 09:17:39 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 8 Jun 2011 10:17:39 -0400 Subject: Cogent IPv6 In-Reply-To: <6ac5bc37$45ab67ae$73965090$@com> References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: Nick, On Wed, Jun 8, 2011 at 9:51 AM, Nick Olsen wrote: > I'm sure someone here is doing IPv6 peering with cogent. (snip) > Any things to be aware of before > pulling the trigger on it? (Other then them not having connectivity to HE's > IPv6 side of things, Wish they would fix that already...) Not just HE's prefixes you miss with Cogent. Lack of full table means they can't be considered a full transit, ie, you need something like minimum 2 full transits + cogent to do v6 properly. They're more like a private peering. Cheers, Martin From ryan at u13.net Wed Jun 8 09:18:37 2011 From: ryan at u13.net (ryan at u13.net) Date: Wed, 08 Jun 2011 10:18:37 -0400 Subject: Cogent IPv6 In-Reply-To: <6ac5bc37$45ab67ae$73965090$@com> References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: On Wed, 8 Jun 2011 09:51:21 -0400, Nick Olsen wrote: > I'm sure someone here is doing IPv6 peering with cogent. We've got a > Gig > > with them, So they don't do that dual peering thing with us. (They do > it > on > another 100Mb/s circuit we have... I despise it.) > Just kind of curious how they go about it. > Do they issue you a small IPv6 block for your interface, just like > they > do > for IPv4? Is it a separate session? Any things to be aware of before > pulling the trigger on it? (Other then them not having connectivity > to > HE's > IPv6 side of things, Wish they would fix that already...) > > Nick Olsen > Network Operations (855) FLSPEED x106 We have separate v4 and v6 sessions with them on the same dual-stack interface (a v4 /29 and v6 /112 on the interface). One session is between our v4 address and theirs, and carries v4 prefixes only. Then another session between v6 addresses that carries v6 prefixes only. From chris at nifry.com Wed Jun 8 09:20:31 2011 From: chris at nifry.com (Chris Russell) Date: Wed, 08 Jun 2011 15:20:31 +0100 Subject: Cogent IPv6 In-Reply-To: <6ac5bc37$45ab67ae$73965090$@com> References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: <3747bab66b8e538ed534737b1f864973@localhost> > Do they issue you a small IPv6 block for your interface, just like they do > for IPv4? Is it a separate session? Any things to be aware of before > pulling the trigger on it? (Other then them not having connectivity to Hi Nick, They issued a /112 for our interface with a separate BGP session. (In the UK) No real issues with kicking things off (** from the technical side anyway) Thanks Chris From jra at baylink.com Wed Jun 8 09:40:56 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 8 Jun 2011 10:40:56 -0400 (EDT) Subject: So... is it time to do IPv6 day monthy yet? Message-ID: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> It certainly sounds like it might be. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jbates at brightok.net Wed Jun 8 09:53:02 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 08 Jun 2011 09:53:02 -0500 Subject: Microsoft's participation in World IPv6 day In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CE402D0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> <0AB09EDBCD1C484EBE45978D62F3513C3CE402D0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <4DEF8CCE.5090106@brightok.net> On 6/8/2011 12:42 AM, Christopher Palmer wrote: > I'm not an ISP - but I absolutely expect that IPv6 roll-outs have > long time-horizons and are fairly complex. So I hope folks are > looking at IPv6 NOW, and not simply waiting for > Google/Bing/Yahoo/Interwebz to enable permanent content access and > organizational justification. To be fair, I think any ISP worth it's salt is working on IPv6 access roll-outs, but there are a lot of considerations. A content provider generally doesn't want to hurt their own connectivity and service quality, which is why using IPv6 on the main sites has generally been frowned upon. An ISP has to deal with customers when these problems arise and actually absorbs the costs of dealing with them. As such, it's not unreasonable for many ISPs to delay rollouts to all customers. It's my honest belief that we have natural progression. The peering arrangements are getting sorted out, IPv6 pathing is slowly reaching par with IPv4 pathing in the largest networks. Content providers are testing and verifying service levels with dual stack. Access networks are deploying IPv6 up to the edge and in some cases releasing it to the customers. ARIN is fixing their policies. It could be better, but I think everyone is on the right track. Jack From Marcus.Williams at ed.gov Wed Jun 8 09:55:35 2011 From: Marcus.Williams at ed.gov (Williams, Marcus (Contractor)) Date: Wed, 8 Jun 2011 09:55:35 -0500 Subject: IPv6 day fun is beginning! In-Reply-To: <1AC42D4F-4046-481C-A5D8-A3CFAEC93138@delong.com> References: <4D13A16A-A9DD-4B6B-A4EF-10458DE236B1@puck.nether.net> <94714E54-C19E-4BEA-82E6-E512700E7541@puck.nether.net> <0F22E467-EFAC-4435-BA6A-686BCED16CF2@puck.nether.net> <08BD27A3-1750-4D69-BC00-B5C3B7397251@ecs.soton.ac.uk> <1AC42D4F-4046-481C-A5D8-A3CFAEC93138@delong.com> Message-ID: Please pardon my sarcasm. My point was these AAAA records may linger in dns cache tomorrow, even if the corresponding IPv6 web site is turned off 0000 UTC June 9, and the records are removed. Marcus Williams > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, June 08, 2011 10:09 AM > To: Williams, Marcus (Contractor) > Cc: Tim Chown; NANOG list > Subject: Re: IPv6 day fun is beginning! > > > On Jun 8, 2011, at 6:46 AM, Williams, Marcus (Contractor) wrote: > > >> -----Original Message----- > >> From: Tim Chown [mailto:tjc at ecs.soton.ac.uk] > >> Sent: Wednesday, June 08, 2011 4:32 AM > >> I had to flush my MacOS X DNS cache before I'd get the > >> new AAAA record. > > > > > > World IPv6 Day will be tomorrow. > > > > Marcus Williams > > > > > > World IPv6 day is today. It started at 0000 UTC June 8 and goes to > just before 0000 UTC June 9. As I write this, there are approximately > 10 hours remaining in world IPv6 day. > > Owen From paradox at nac.net Wed Jun 8 10:07:51 2011 From: paradox at nac.net (Ryan Pavely) Date: Wed, 08 Jun 2011 11:07:51 -0400 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> Message-ID: <4DEF9047.5090404@nac.net> I was thinking the same thing. Good call :) Ryan Pavely Net Access Corporation http://www.nac.net/ On 6/8/2011 10:40 AM, Jay Ashworth wrote: > It certainly sounds like it might be. > > Cheers, > -- jra > From xleonzhao at gmail.com Wed Jun 8 10:13:52 2011 From: xleonzhao at gmail.com (Xiaoliang Zhao) Date: Wed, 8 Jun 2011 11:13:52 -0400 Subject: IPv6 to China (Was: Re: IPv6 day fun is beginning!) Message-ID: I have a similar setting as Jamie, VZ Fios plus HE tunnel, except I am running a FreeBSD VM to terminate tunnel and to run rtadvd. everything works nicely, so I thought I could do some tests on IPv6 connectivity and speed to China. There is a single-stack IPv6 website (bt.neu6.edu.cn) hosted by a chinese university providing torrents files. It is a single-stack because most chinese universities do not need pay for v6 traffic at this moment. I have no problem to open the website through v6 and i started a utorrent downloading with about 29 v6 peers and 5 v4 peers. my peak download speed reached 22Mbps... Best, Leon On Wed, Jun 8, 2011 at 7:40 AM, Jamie Bowden wrote: > Thanks to HE's tunnel broker service, I've got fully functional dual > stack at home (well, mostly, like most folks, VZ gives me a single > address and I live behind that with NATv4, but otherwise, I loves me > some FiOS) and yesterday went by for me without a hitch, including > accessing Facebook (I'd hear from the wife and kid really quickly if > they weren't working). ?For a working tunnel, I put my DIR-825 as the > "DMZ" host behind the cheesy Actiontec router VZ requires, forward all > traffic with zero firewalling to it, and let the D-Link appliance handle > all my firewall needs (and it terminates my v6 tunnel obviously). ?The > one thing I haven't quite figured out how to make it do (and maybe it's > just not capable) is use the /48 HE routes to me. ?The box insists that > the internal interface be on the same subnet as the external, and it > hands out v6 addresses from that /64. > > Jamie > From morrowc.lists at gmail.com Wed Jun 8 10:19:07 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 8 Jun 2011 11:19:07 -0400 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 6:33 AM, David Swafford wrote: > Interesting, I'm having that same issue w/ www.nist.gov this morning. ?Front > page loads fine, but all links return a 404. ? Here's my tracert if it > helps: > > tracert www.nist.gov > Tracing route to nist.gov [2610:20:6060:aa::a66b] > over a maximum of 30 hops: > ?1 ? ?<1 ms ? ?<1 ms ? ?<1 ms ?2001:1938:2a7::1 > ?2 ? ?85 ms ? ?87 ms ? ?84 ms ?gw-383.phx-01.us.sixxs.net[2001:1938:81:17e::1] phoenix, az,us > ?3 ? ?92 ms ? ?99 ms ? ?86 ms ?2001:4de0:1000:a4::1 > ?4 ? ?98 ms ? ?87 ms ? ?90 ms ?1-3.ipv6.r1.ph.hwng.net[2001:4de0:1000:27::2] > ?5 ? 136 ms ? 140 ms ? 131 ms ?3-2.ipv6.r1.at.hwng.net[2001:4de0:1000:15::1] > ?6 ? 167 ms ? 167 ms ? 175 ms ?2-1.ipv6.r2.dc.hwng.net[2001:4de0:1000:7::1] wash-dc, usa > ?7 ? 246 ms ? 253 ms ? 245 ms ?5-4.ipv6.r2.am.hwng.net[2001:4de0:1000:5::1] amsterdam, nl! (you seem to have bypassed NIST here...) > ?8 ? 248 ms ? 247 ms ? 247 ms ?AMS-IX.v6.lambdanet.net[2001:7f8:1::a501:3237:1] > ?9 ? 265 ms ? 267 ms ? 265 ms ?FRA-1-pos413.v6.lambdanet.net[2001:7f0:0:16::1] Frankfurt, DE > ?10 ? 275 ms ? 268 ms ? 268 ms ?6b1.fft4.alter.net [2001:7f8::319e:0:1] w00t! 12702! - 'lab ipv6 network in EMEA' > ?11 ? 268 ms ? 304 ms ? 271 ms ?gw6.dca6.alter.net [2001:600:c:8::2] back to DC. > ?12 ? 271 ms ? 271 ms ? 270 ms ?2600:803:22f::2 > ?13 ? 280 ms ? 272 ms ? 268 ms ?2600:803:22f::2 2 more hops and home in bethesda... whooo! long trip! > ?14 ? 270 ms ? 269 ms ? 273 ms ?2610:20:6060:aa::a66b > Trace complete. > > From neil at cymru.com Wed Jun 8 10:24:12 2011 From: neil at cymru.com (Neil Long) Date: Wed, 8 Jun 2011 16:24:12 +0100 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: References: Message-ID: On 8 Jun 2011, at 07:15, Andrew Koch wrote: > On Wed, Jun 8, 2011 at 00:59, Iljitsch van Beijnum > wrote: >> BTW, how are you guys dealing with path MTU discovery for IPv6? >> I've seen a few sites that have problems with this, such as www.nist.gov >> , > > > > Speaking of www.nist.gov, I am getting the front page to load, but all > links are returning a 404 Not Found when browsing via v6 > > Andrew Koch > andrew.koch at gawul.net > Top of the page it says (now, may have been added) "Note: This top level web page has been setup to test IPv6 capabilities and to participate in World IPv6 Day on June 8, 2011. This IPv6 web page will be disabled after the end of World IPv6 Day. Links on this page do not work. This is a copy of the NIST website, www.nist.gov , and is only reachable using the IPv6 network protocol. To access the entire NIST website, you must use the IPv4 network protocol." Cheers Neil -- Neil Long, Team Cymru http://www.cymru.com | +1 630 230 5422 | neil at cymru.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4138 bytes Desc: not available URL: From Curtis.Starnes at granburyisd.org Wed Jun 8 10:26:39 2011 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Wed, 8 Jun 2011 10:26:39 -0500 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: References: Message-ID: Typical long trip via a sixxs.net tunnel. Unlike Hurricane Electric (tunnelbroker.net), Sixxs has no US peering that I know of so everything has to hit overseas before returning back. Curtis. -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Wednesday, June 08, 2011 10:19 AM To: David Swafford Cc: nanog at nanog.org; DO-webmaster at nist.gov Subject: Re: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day On Wed, Jun 8, 2011 at 6:33 AM, David Swafford wrote: > Interesting, I'm having that same issue w/ www.nist.gov this morning. ? > Front page loads fine, but all links return a 404. ? Here's my tracert > if it > helps: > > tracert www.nist.gov > Tracing route to nist.gov [2610:20:6060:aa::a66b] over a maximum of 30 > hops: > ?1 ? ?<1 ms ? ?<1 ms ? ?<1 ms ?2001:1938:2a7::1 > ?2 ? ?85 ms ? ?87 ms ? ?84 ms ? > gw-383.phx-01.us.sixxs.net[2001:1938:81:17e::1] phoenix, az,us > ?3 ? ?92 ms ? ?99 ms ? ?86 ms ?2001:4de0:1000:a4::1 > ?4 ? ?98 ms ? ?87 ms ? ?90 ms ? > 1-3.ipv6.r1.ph.hwng.net[2001:4de0:1000:27::2] > ?5 ? 136 ms ? 140 ms ? 131 ms ? > 3-2.ipv6.r1.at.hwng.net[2001:4de0:1000:15::1] > ?6 ? 167 ms ? 167 ms ? 175 ms ? > 2-1.ipv6.r2.dc.hwng.net[2001:4de0:1000:7::1] wash-dc, usa > ?7 ? 246 ms ? 253 ms ? 245 ms ? > 5-4.ipv6.r2.am.hwng.net[2001:4de0:1000:5::1] amsterdam, nl! (you seem to have bypassed NIST here...) > ?8 ? 248 ms ? 247 ms ? 247 ms ? > AMS-IX.v6.lambdanet.net[2001:7f8:1::a501:3237:1] > ?9 ? 265 ms ? 267 ms ? 265 ms ? > FRA-1-pos413.v6.lambdanet.net[2001:7f0:0:16::1] Frankfurt, DE > ?10 ? 275 ms ? 268 ms ? 268 ms ?6b1.fft4.alter.net > [2001:7f8::319e:0:1] w00t! 12702! - 'lab ipv6 network in EMEA' > ?11 ? 268 ms ? 304 ms ? 271 ms ?gw6.dca6.alter.net [2001:600:c:8::2] back to DC. > ?12 ? 271 ms ? 271 ms ? 270 ms ?2600:803:22f::2 > ?13 ? 280 ms ? 272 ms ? 268 ms ?2600:803:22f::2 2 more hops and home in bethesda... whooo! long trip! > ?14 ? 270 ms ? 269 ms ? 273 ms ?2610:20:6060:aa::a66b Trace complete. > > From jay-ford at uiowa.edu Wed Jun 8 10:30:08 2011 From: jay-ford at uiowa.edu (Jay Ford) Date: Wed, 8 Jun 2011 10:30:08 -0500 (CDT) Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: References: Message-ID: On Wed, 8 Jun 2011, Neil Long wrote: > Top of the page it says (now, may have been added) > "Note: This top level web page has been setup to test IPv6 capabilities and > to participate in World IPv6 Day on June 8, 2011. This IPv6 web page will be > disabled after the end of World IPv6 Day. Links on this page do not work. > This is a copy of the NIST website, www.nist.gov, and is only reachable using > the IPv6 network protocol. To access the entire NIST website, you must use > the IPv4 network protocol." Yeah, at least they said what they did, but they seem to have a misunderstanding of how dual-stack clients will use the www.nist.gov AAAA record. The result is that they've broken access to their content. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From rob at ipninja.net Wed Jun 8 10:34:22 2011 From: rob at ipninja.net (Rob V) Date: Wed, 8 Jun 2011 11:34:22 -0400 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: References: Message-ID: <00c301cc25f1$8d179220$a746b660$@net> Interesting ... I seem to stay in North America ... I guess it depends what POP you connect to? traceroute6 to nist.gov (2610:20:6060:aa::a66b) from 2001:4978::fe67:cafa, 64 hops max, 12 byte packets 1 2001:::1 1.147 ms 0.461 ms 0.413 ms 2 gw-525.chi-02.us.sixxs.net 30.235 ms 30.380 ms 30.256 ms 3 sixxs.ge-0.0.0-30.core1.chi.bb6.your.org 109.226 ms 29.622 ms 30.270 ms 4 gige-g2-19.core1.chi1.he.net 31.716 ms 31.157 ms 40.147 ms 5 10gigabitethernet7-2.core1.nyc4.he.net 47.923 ms 56.877 ms 48.230 ms 6 2001:504:f::64 49.124 ms 51.467 ms 50.701 ms 7 2600:803:22f::2 63.797 ms 73.429 ms 63.938 ms 8 2600:803:22f::2 62.129 ms 68.801 ms 62.511 ms 9 2610:20:6060:aa::a66b 59.465 ms 76.910 ms 70.083 ms -----Original Message----- From: STARNES, CURTIS [mailto:Curtis.Starnes at granburyisd.org] Sent: June-08-11 11:27 AM To: Christopher Morrow; David Swafford Cc: nanog at nanog.org; DO-webmaster at nist.gov Subject: RE: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day Typical long trip via a sixxs.net tunnel. Unlike Hurricane Electric (tunnelbroker.net), Sixxs has no US peering that I know of so everything has to hit overseas before returning back. Curtis. -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Wednesday, June 08, 2011 10:19 AM To: David Swafford Cc: nanog at nanog.org; DO-webmaster at nist.gov Subject: Re: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day On Wed, Jun 8, 2011 at 6:33 AM, David Swafford wrote: > Interesting, I'm having that same issue w/ www.nist.gov this morning. ? > Front page loads fine, but all links return a 404. ? Here's my tracert > if it > helps: > > tracert www.nist.gov > Tracing route to nist.gov [2610:20:6060:aa::a66b] over a maximum of 30 > hops: > ?1 ? ?<1 ms ? ?<1 ms ? ?<1 ms ?2001:1938:2a7::1 > ?2 ? ?85 ms ? ?87 ms ? ?84 ms ? > gw-383.phx-01.us.sixxs.net[2001:1938:81:17e::1] phoenix, az,us > ?3 ? ?92 ms ? ?99 ms ? ?86 ms ?2001:4de0:1000:a4::1 > ?4 ? ?98 ms ? ?87 ms ? ?90 ms ? > 1-3.ipv6.r1.ph.hwng.net[2001:4de0:1000:27::2] > ?5 ? 136 ms ? 140 ms ? 131 ms ? > 3-2.ipv6.r1.at.hwng.net[2001:4de0:1000:15::1] > ?6 ? 167 ms ? 167 ms ? 175 ms ? > 2-1.ipv6.r2.dc.hwng.net[2001:4de0:1000:7::1] wash-dc, usa > ?7 ? 246 ms ? 253 ms ? 245 ms ? > 5-4.ipv6.r2.am.hwng.net[2001:4de0:1000:5::1] amsterdam, nl! (you seem to have bypassed NIST here...) > ?8 ? 248 ms ? 247 ms ? 247 ms ? > AMS-IX.v6.lambdanet.net[2001:7f8:1::a501:3237:1] > ?9 ? 265 ms ? 267 ms ? 265 ms ? > FRA-1-pos413.v6.lambdanet.net[2001:7f0:0:16::1] Frankfurt, DE > ?10 ? 275 ms ? 268 ms ? 268 ms ?6b1.fft4.alter.net > [2001:7f8::319e:0:1] w00t! 12702! - 'lab ipv6 network in EMEA' > ?11 ? 268 ms ? 304 ms ? 271 ms ?gw6.dca6.alter.net [2001:600:c:8::2] back to DC. > ?12 ? 271 ms ? 271 ms ? 270 ms ?2600:803:22f::2 > ?13 ? 280 ms ? 272 ms ? 268 ms ?2600:803:22f::2 2 more hops and home in bethesda... whooo! long trip! > ?14 ? 270 ms ? 269 ms ? 273 ms ?2610:20:6060:aa::a66b Trace complete. > > From david at davidswafford.com Wed Jun 8 10:38:54 2011 From: david at davidswafford.com (David Swafford) Date: Wed, 08 Jun 2011 11:38:54 -0400 (EDT) Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: Message-ID: <2f646047-7598-4ed6-957c-6ae0523291dd@WIN7_GOLD_6> Good catch -- I traveled the world and back today on v6! Overall though the day seems to be going well, I've sparked a lot of enthusiasm at work by bragging this event (I even made a shirt to promote it :-), and I'd love to see this become a regular occurrence. David. ----- Original Message ----- From: "Christopher Morrow" To: "David Swafford" Cc: "Iljitsch van Beijnum" , nanog at nanog.org, DO-webmaster at nist.gov Sent: Wednesday, June 8, 2011 11:19:07 AM Subject: Re: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day On Wed, Jun 8, 2011 at 6:33 AM, David Swafford wrote: > Interesting, I'm having that same issue w/ www.nist.gov this morning. ?Front > page loads fine, but all links return a 404. ? Here's my tracert if it > helps: > > tracert www.nist.gov > Tracing route to nist.gov [2610:20:6060:aa::a66b] > over a maximum of 30 hops: > ?1 ? ?<1 ms ? ?<1 ms ? ?<1 ms ?2001:1938:2a7::1 > ?2 ? ?85 ms ? ?87 ms ? ?84 ms ?gw-383.phx-01.us.sixxs.net[2001:1938:81:17e::1] phoenix, az,us > ?3 ? ?92 ms ? ?99 ms ? ?86 ms ?2001:4de0:1000:a4::1 > ?4 ? ?98 ms ? ?87 ms ? ?90 ms ?1-3.ipv6.r1.ph.hwng.net[2001:4de0:1000:27::2] > ?5 ? 136 ms ? 140 ms ? 131 ms ?3-2.ipv6.r1.at.hwng.net[2001:4de0:1000:15::1] > ?6 ? 167 ms ? 167 ms ? 175 ms ?2-1.ipv6.r2.dc.hwng.net[2001:4de0:1000:7::1] wash-dc, usa > ?7 ? 246 ms ? 253 ms ? 245 ms ?5-4.ipv6.r2.am.hwng.net[2001:4de0:1000:5::1] amsterdam, nl! (you seem to have bypassed NIST here...) > ?8 ? 248 ms ? 247 ms ? 247 ms ?AMS-IX.v6.lambdanet.net[2001:7f8:1::a501:3237:1] > ?9 ? 265 ms ? 267 ms ? 265 ms ?FRA-1-pos413.v6.lambdanet.net[2001:7f0:0:16::1] Frankfurt, DE > ?10 ? 275 ms ? 268 ms ? 268 ms ?6b1.fft4.alter.net [2001:7f8::319e:0:1] w00t! 12702! - 'lab ipv6 network in EMEA' > ?11 ? 268 ms ? 304 ms ? 271 ms ?gw6.dca6.alter.net [2001:600:c:8::2] back to DC. > ?12 ? 271 ms ? 271 ms ? 270 ms ?2600:803:22f::2 > ?13 ? 280 ms ? 272 ms ? 268 ms ?2600:803:22f::2 2 more hops and home in bethesda... whooo! long trip! > ?14 ? 270 ms ? 269 ms ? 273 ms ?2610:20:6060:aa::a66b > Trace complete. > > From patrick.sumby at sohonet.co.uk Wed Jun 8 10:38:24 2011 From: patrick.sumby at sohonet.co.uk (Patrick Sumby) Date: Wed, 08 Jun 2011 16:38:24 +0100 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <4DEF9047.5090404@nac.net> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> Message-ID: <4DEF9770.2090106@sohonet.co.uk> +1 I've enjoyed it so far! On 08/06/2011 16:07, Ryan Pavely wrote: > I was thinking the same thing. Good call :) > > Ryan Pavely > Net Access Corporation > http://www.nac.net/ > > > On 6/8/2011 10:40 AM, Jay Ashworth wrote: >> It certainly sounds like it might be. >> >> Cheers, >> -- jra >> > From morrowc.lists at gmail.com Wed Jun 8 10:38:33 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 8 Jun 2011 11:38:33 -0400 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: <00c301cc25f1$8d179220$a746b660$@net> References: <00c301cc25f1$8d179220$a746b660$@net> Message-ID: On Wed, Jun 8, 2011 at 11:34 AM, Rob V wrote: > Interesting ... I seem to stay in North America ... I guess it depends what > POP you connect to? > > traceroute6 to nist.gov (2610:20:6060:aa::a66b) from > 2001:4978::fe67:cafa, 64 hops max, 12 byte packets > ?1 ?2001:::1 ?1.147 ms ?0.461 ms ?0.413 ms > ?2 ?gw-525.chi-02.us.sixxs.net ?30.235 ms ?30.380 ms ?30.256 ms > ?3 ?sixxs.ge-0.0.0-30.core1.chi.bb6.your.org ?109.226 ms ?29.622 ms ?30.270 > ms > ?4 ?gige-g2-19.core1.chi1.he.net ?31.716 ms ?31.157 ms ?40.147 ms > ?5 ?10gigabitethernet7-2.core1.nyc4.he.net ?47.923 ms ?56.877 ms ?48.230 ms > ?6 ?2001:504:f::64 ?49.124 ms ?51.467 ms ?50.701 ms > ?7 ?2600:803:22f::2 ?63.797 ms ?73.429 ms ?63.938 ms > ?8 ?2600:803:22f::2 ?62.129 ms ?68.801 ms ?62.511 ms > ?9 ?2610:20:6060:aa::a66b ?59.465 ms ?76.910 ms ?70.083 ms 3 gige-g4-12.core1.ash1.he.net (2001:470:0:90::1) 12.26 ms 6.847 ms 14.985 ms 4 eqx.br6.iad8.verizonbusiness.com (2001:504:0:2::701:1) 7.385 ms 7.783 ms 7.463 ms he and 701 seem to peer? (judging by hostname on the PTR at least) so HE, probably does better than sixxs at least for 701 destinations. (of which nist appears to be one) > > -----Original Message----- > From: STARNES, CURTIS [mailto:Curtis.Starnes at granburyisd.org] > Sent: June-08-11 11:27 AM > To: Christopher Morrow; David Swafford > Cc: nanog at nanog.org; DO-webmaster at nist.gov > Subject: RE: www.nist.gov over v6 trouble Was: Microsoft's participation in > World IPv6 day > > Typical long trip via a sixxs.net tunnel. > Unlike Hurricane Electric (tunnelbroker.net), Sixxs has no US peering that I > know of so everything has to hit overseas before returning back. > > Curtis. > > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Wednesday, June 08, 2011 10:19 AM > To: David Swafford > Cc: nanog at nanog.org; DO-webmaster at nist.gov > Subject: Re: www.nist.gov over v6 trouble Was: Microsoft's participation in > World IPv6 day > > On Wed, Jun 8, 2011 at 6:33 AM, David Swafford > wrote: >> Interesting, I'm having that same issue w/ www.nist.gov this morning. >> Front page loads fine, but all links return a 404. ? Here's my tracert >> if it >> helps: >> >> tracert www.nist.gov >> Tracing route to nist.gov [2610:20:6060:aa::a66b] over a maximum of 30 >> hops: >> ?1 ? ?<1 ms ? ?<1 ms ? ?<1 ms ?2001:1938:2a7::1 >> ?2 ? ?85 ms ? ?87 ms ? ?84 ms >> gw-383.phx-01.us.sixxs.net[2001:1938:81:17e::1] > > phoenix, az,us > >> ?3 ? ?92 ms ? ?99 ms ? ?86 ms ?2001:4de0:1000:a4::1 >> ?4 ? ?98 ms ? ?87 ms ? ?90 ms >> 1-3.ipv6.r1.ph.hwng.net[2001:4de0:1000:27::2] >> ?5 ? 136 ms ? 140 ms ? 131 ms >> 3-2.ipv6.r1.at.hwng.net[2001:4de0:1000:15::1] >> ?6 ? 167 ms ? 167 ms ? 175 ms >> 2-1.ipv6.r2.dc.hwng.net[2001:4de0:1000:7::1] > > wash-dc, usa > >> ?7 ? 246 ms ? 253 ms ? 245 ms >> 5-4.ipv6.r2.am.hwng.net[2001:4de0:1000:5::1] > > amsterdam, nl! (you seem to have bypassed NIST here...) > >> ?8 ? 248 ms ? 247 ms ? 247 ms >> AMS-IX.v6.lambdanet.net[2001:7f8:1::a501:3237:1] >> ?9 ? 265 ms ? 267 ms ? 265 ms >> FRA-1-pos413.v6.lambdanet.net[2001:7f0:0:16::1] > > Frankfurt, DE > >> ?10 ? 275 ms ? 268 ms ? 268 ms ?6b1.fft4.alter.net >> [2001:7f8::319e:0:1] > > w00t! 12702! - 'lab ipv6 network in EMEA' > >> ?11 ? 268 ms ? 304 ms ? 271 ms ?gw6.dca6.alter.net [2001:600:c:8::2] > > back to DC. > >> ?12 ? 271 ms ? 271 ms ? 270 ms ?2600:803:22f::2 >> ?13 ? 280 ms ? 272 ms ? 268 ms ?2600:803:22f::2 > > 2 more hops and home in bethesda... whooo! long trip! > >> ?14 ? 270 ms ? 269 ms ? 273 ms ?2610:20:6060:aa::a66b Trace complete. >> >> > > > > From neil at cymru.com Wed Jun 8 10:38:39 2011 From: neil at cymru.com (Neil Long) Date: Wed, 8 Jun 2011 16:38:39 +0100 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: References: Message-ID: On 8 Jun 2011, at 16:30, Jay Ford wrote: > On Wed, 8 Jun 2011, Neil Long wrote: >> Top of the page it says (now, may have been added) >> "Note: This top level web page has been setup to test IPv6 >> capabilities and to participate in World IPv6 Day on June 8, 2011. >> This IPv6 web page will be disabled after the end of World IPv6 >> Day. Links on this page do not work. This is a copy of the NIST >> website, www.nist.gov, and is only reachable using the IPv6 network >> protocol. To access the entire NIST website, you must use the IPv4 >> network protocol." > > Yeah, at least they said what they did, but they seem to have a > misunderstanding of how dual-stack clients will use the www.nist.gov > AAAA > record. The result is that they've broken access to their content. > > ________________________________________________________________________ > Jay Ford, Network Engineering Group, Information Technology Services > University of Iowa, Iowa City, IA 52242 > email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 > Oh yes. I fail to see the logic and usefulness of doing that to a web site but it is a scientific experiment :-) Cheers Neil. -- Neil Long, Team Cymru http://www.cymru.com | +1 630 230 5422 | neil at cymru.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4138 bytes Desc: not available URL: From bicknell at ufp.org Wed Jun 8 10:45:54 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 8 Jun 2011 08:45:54 -0700 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> Message-ID: <20110608154554.GA9438@ussenterprise.ufp.org> In a message written on Wed, Jun 08, 2011 at 10:40:56AM -0400, Jay Ashworth wrote: > It certainly sounds like it might be. Why not just leave it on? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From daniel.unam.ipv6 at gmail.com Wed Jun 8 10:50:02 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Wed, 8 Jun 2011 10:50:02 -0500 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... Message-ID: Hi. The main objective for today is to access the web services, that's why you can't reach a AAAA record for a DNS query for a given NS server. ; <<>> DiG 9.5.1-P3 <<>> www.google.com aaaa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40029 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;www.google.com. IN AAAA ;; ANSWER SECTION: www.google.com. 532907 IN CNAME www.l.google.com. www.l.google.com. 150 IN AAAA 2001:4860:4002:802::1010 ; <<>> DiG 9.5.1-P3 <<>> www.yahoo.com aaaa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60816 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.yahoo.com. IN AAAA ;; ANSWER SECTION: www.yahoo.com. 284 IN CNAME fpfd.wa1.b.yahoo.com. fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00c:1fe::3001 fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f011:1fe::3001 fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f011:1fe::3000 fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00d:1fe::3001 fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00d:1fe::3000 fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00c:1fe::3000 ; <<>> DiG 9.5.1-P3 <<>> www.facebook.com aaaa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12079 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.facebook.com. IN AAAA ;; ANSWER SECTION: www.facebook.com. 8 IN AAAA 2620:0:1c00:0:face:b00c:0:1 ; <<>> DiG 9.5.1-P3 <<>> www.unam.mx aaaa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42381 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ;www.unam.mx. IN AAAA ;; ANSWER SECTION: www.unam.mx. 6031 IN AAAA 2001:1218:1:6:d685:64ff:fec4:720b You see? there's a lot of IPv6 activity since a few weeks ago. xD ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 08 Jun 2011 11:28:40 +0200 > From: Jeroen Massar > Subject: AAAA on various websites, but they all forgot to enable them > on their nameservers.... > To: nanog > Message-ID: <4DEF40C8.3020502 at unfix.org> > Content-Type: text/plain; charset=ISO-8859-1 > > It is really nice that folks where able to put AAAA records on their > websites for only 24 hours, but they forgot to put in the glue on their > nameservers. > > As such, for the folks testing IPv6-only, a lot of sites will fail > unless they use a recursor that does the IPv4 for them. > > The root is there, .com does it mostly too (well, a+b have IPv6), but > most sites don't. Thus maybe that can be done next year on the next IPv6 > day? :) > > At least one step closer, now lets hope that sites also keep that IPv6 > address there. > > Greets, > Jeroen > > -- > > $ dig @d.gtld-servers.net ns1.google.com aaaa > > ; <<>> DiG 9.7.3 <<>> @d.gtld-servers.net ns1.google.com aaaa > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16030 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;ns1.google.com. IN AAAA > > ;; AUTHORITY SECTION: > google.com. 172800 IN NS ns2.google.com. > google.com. 172800 IN NS ns1.google.com. > google.com. 172800 IN NS ns3.google.com. > google.com. 172800 IN NS ns4.google.com. > > ;; ADDITIONAL SECTION: > ns2.google.com. 172800 IN A 216.239.34.10 > ns1.google.com. 172800 IN A 216.239.32.10 > ns3.google.com. 172800 IN A 216.239.36.10 > ns4.google.com. 172800 IN A 216.239.38.10 > > ;; Query time: 123 msec > ;; SERVER: 192.31.80.30#53(192.31.80.30) > ;; WHEN: Wed Jun 8 11:26:35 2011 > ;; MSG SIZE rcvd: 164 > > $ dig @d.gtld-servers.net ns1.cisco.com aaaa > > ; <<>> DiG 9.7.3 <<>> @d.gtld-servers.net ns1.cisco.com aaaa > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55271 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;ns1.cisco.com. IN AAAA > > ;; AUTHORITY SECTION: > cisco.com. 172800 IN NS ns1.cisco.com. > cisco.com. 172800 IN NS ns2.cisco.com. > > ;; ADDITIONAL SECTION: > ns1.cisco.com. 172800 IN A 128.107.241.185 > ns2.cisco.com. 172800 IN A 64.102.255.44 > > ;; Query time: 126 msec > ;; SERVER: 192.31.80.30#53(192.31.80.30) > ;; WHEN: Wed Jun 8 11:28:14 2011 > ;; MSG SIZE rcvd: 95 > > > > ------------------------------ > -- *Daniel Espejel P?rez Universidad Nacional Aut?noma de M?xico. Direcci?n General de C?mputo y Tecnolog?as de la Informaci?n y Comunicaci?n. Laboratorio de Tecnolog?as Emergentes de Red (NetLab). GT - IPv6 UNAM , GT - IPv6 CLARA http://www.netlab.unam.mx/* From james.harr at gmail.com Wed Jun 8 10:59:41 2011 From: james.harr at gmail.com (James Harr) Date: Wed, 8 Jun 2011 10:59:41 -0500 Subject: IPv6 day non-participants Message-ID: I noticed that one of our vendors wasn't actually participating when they very publicly put on their home page that they would. So I queried the IPv6 day participation list to see who didn't have AAAA's for their listed website. It turned out to be around 9.5% Before you read the list, here's me shedding responsibility with a list of caveats: - The crappy perl script I am using might be broken. IE - it doesn't think about "foo.com" vs "www.foo.com", HTTP redirection, or any of that. - The organizations in this list may have withdrawn because they found out something was terribly broken. - DNS caching may be skewing the results if the TTLs are long. ==== SNIP ==== www.xiphiastec.com Xiphiastec www.pir.org Public Interest Registry www.exactabacus.com Exact Abacus www.comcast.net Comcast www.shazzlemail.com Shazzle, LLC www.bangzoom.com Bangzoom Software Inc www.mihostcgi.com mihostcgi www.unclesamnames.com American Domain Names opendns.com OpenDNS www.mutali.rw Mutali townnews.com TownNews www.infoblox.com Infoblox www.ripplecom.net Ripple Communications www.agame.com Spil Games www.alexville.com Alexville Games www.hkirc.hk Hong Kong Internet Registration Corporation www.hkdnr.hk Hong Kong Domain Name Registration www.buffalo.feb.gov United States Office of Personnel Management www.cyberport.hk Hong Kong Cyberport Management Ltd www.catnix.com CATNIX sucomo.com Sucomo OHG www.mybrighthouse.com BrightHouse Networks www.it-in.ru it-in ivancorp.net Ivanhoe-IT www.forestdaleinc.org Forestdale Inc www.towerstream.com Towerstream www.intuix.com Intuix LLC suse.org Novell Inc. www.IronNails.com IronNails Consultancy www.orbitdiensten.com Orbit-Diensten madonnaradio.com Voila www.gov.bc.ca Government of British Columbia www.zte.com.cn ZTE Corporation www.tamagawa.jp Tamagawa Academy & University -- ^[:wq^M From jmamodio at gmail.com Wed Jun 8 11:04:42 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 8 Jun 2011 11:04:42 -0500 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: References: Message-ID: > The main objective for today is to access the web services, that's why you > can't reach a AAAA record for a DNS query for a given NS server. So if there are no AAAA records from where we ftp6 the HOSTSV6.TXT file ? -J From llynch at civil-tongue.net Wed Jun 8 11:05:38 2011 From: llynch at civil-tongue.net (Lucy Lynch) Date: Wed, 8 Jun 2011 09:05:38 -0700 (PDT) Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: References: Message-ID: On Wed, 8 Jun 2011, Daniel Espejel wrote: > Hi. > > The main objective for today is to access the web services, that's why you > can't reach a AAAA record for a DNS query for a given NS server. exactly - this site provides a nice service snapshot: http://www.mrp.net/IPv6Day.html > > ; <<>> DiG 9.5.1-P3 <<>> www.google.com aaaa > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40029 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4 > > ;; QUESTION SECTION: > ;www.google.com. IN AAAA > > ;; ANSWER SECTION: > www.google.com. 532907 IN CNAME www.l.google.com. > www.l.google.com. 150 IN AAAA 2001:4860:4002:802::1010 > > ; <<>> DiG 9.5.1-P3 <<>> www.yahoo.com aaaa > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60816 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 2 > > ;; QUESTION SECTION: > ;www.yahoo.com. IN AAAA > > ;; ANSWER SECTION: > www.yahoo.com. 284 IN CNAME fpfd.wa1.b.yahoo.com. > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00c:1fe::3001 > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f011:1fe::3001 > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f011:1fe::3000 > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00d:1fe::3001 > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00d:1fe::3000 > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00c:1fe::3000 > ; <<>> DiG 9.5.1-P3 <<>> www.facebook.com aaaa > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12079 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 > > ;; QUESTION SECTION: > ;www.facebook.com. IN AAAA > > ;; ANSWER SECTION: > www.facebook.com. 8 IN AAAA 2620:0:1c00:0:face:b00c:0:1 > > > > ; <<>> DiG 9.5.1-P3 <<>> www.unam.mx aaaa > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42381 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 > > ;; QUESTION SECTION: > ;www.unam.mx. IN AAAA > > ;; ANSWER SECTION: > www.unam.mx. 6031 IN AAAA 2001:1218:1:6:d685:64ff:fec4:720b > > You see? there's a lot of IPv6 activity since a few weeks ago. xD > > > > > ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 08 Jun 2011 11:28:40 +0200 >> From: Jeroen Massar >> Subject: AAAA on various websites, but they all forgot to enable them >> on their nameservers.... >> To: nanog >> Message-ID: <4DEF40C8.3020502 at unfix.org> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> It is really nice that folks where able to put AAAA records on their >> websites for only 24 hours, but they forgot to put in the glue on their >> nameservers. >> >> As such, for the folks testing IPv6-only, a lot of sites will fail >> unless they use a recursor that does the IPv4 for them. >> >> The root is there, .com does it mostly too (well, a+b have IPv6), but >> most sites don't. Thus maybe that can be done next year on the next IPv6 >> day? :) >> >> At least one step closer, now lets hope that sites also keep that IPv6 >> address there. >> >> Greets, >> Jeroen >> >> -- >> >> $ dig @d.gtld-servers.net ns1.google.com aaaa >> >> ; <<>> DiG 9.7.3 <<>> @d.gtld-servers.net ns1.google.com aaaa >> ; (1 server found) >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16030 >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 >> ;; WARNING: recursion requested but not available >> >> ;; QUESTION SECTION: >> ;ns1.google.com. IN AAAA >> >> ;; AUTHORITY SECTION: >> google.com. 172800 IN NS ns2.google.com. >> google.com. 172800 IN NS ns1.google.com. >> google.com. 172800 IN NS ns3.google.com. >> google.com. 172800 IN NS ns4.google.com. >> >> ;; ADDITIONAL SECTION: >> ns2.google.com. 172800 IN A 216.239.34.10 >> ns1.google.com. 172800 IN A 216.239.32.10 >> ns3.google.com. 172800 IN A 216.239.36.10 >> ns4.google.com. 172800 IN A 216.239.38.10 >> >> ;; Query time: 123 msec >> ;; SERVER: 192.31.80.30#53(192.31.80.30) >> ;; WHEN: Wed Jun 8 11:26:35 2011 >> ;; MSG SIZE rcvd: 164 >> >> $ dig @d.gtld-servers.net ns1.cisco.com aaaa >> >> ; <<>> DiG 9.7.3 <<>> @d.gtld-servers.net ns1.cisco.com aaaa >> ; (1 server found) >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55271 >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 >> ;; WARNING: recursion requested but not available >> >> ;; QUESTION SECTION: >> ;ns1.cisco.com. IN AAAA >> >> ;; AUTHORITY SECTION: >> cisco.com. 172800 IN NS ns1.cisco.com. >> cisco.com. 172800 IN NS ns2.cisco.com. >> >> ;; ADDITIONAL SECTION: >> ns1.cisco.com. 172800 IN A 128.107.241.185 >> ns2.cisco.com. 172800 IN A 64.102.255.44 >> >> ;; Query time: 126 msec >> ;; SERVER: 192.31.80.30#53(192.31.80.30) >> ;; WHEN: Wed Jun 8 11:28:14 2011 >> ;; MSG SIZE rcvd: 95 >> >> >> >> ------------------------------ >> > From Valdis.Kletnieks at vt.edu Wed Jun 8 11:09:58 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 08 Jun 2011 12:09:58 -0400 Subject: Microsoft's participation in World IPv6 day In-Reply-To: Your message of "Tue, 07 Jun 2011 20:47:43 PDT." <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> References: <20110606021449.402A2105A596@drugs.dv.isc.org> <3A963CEF-5FEF-44BF-A3ED-1324C10FAAD7@delong.com> Message-ID: <11980.1307549398@turing-police.cc.vt.edu> On Tue, 07 Jun 2011 20:47:43 PDT, Owen DeLong said: > For all but the most inept of access providers, they will have some ability > to put customers on IPv6 prior to the day they would have to deploy LSN. The cynic in me says that guarantees widespread deployment of LSN. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jmamodio at gmail.com Wed Jun 8 11:12:41 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 8 Jun 2011 11:12:41 -0500 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: References: Message-ID: > http://www.mrp.net/IPv6Day.html The web access column reflects access to internal content or just the home page ? -J From dmburgess at linktechs.net Wed Jun 8 11:14:35 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Wed, 8 Jun 2011 11:14:35 -0500 Subject: So... is it time to do IPv6 day monthy yet? References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <20110608154554.GA9438@ussenterprise.ufp.org> Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50547C0EE@ltiserver.lti.local> Sounds good to me. ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Wednesday, June 08, 2011 10:46 AM To: NANOG Subject: Re: So... is it time to do IPv6 day monthy yet? In a message written on Wed, Jun 08, 2011 at 10:40:56AM -0400, Jay Ashworth wrote: > It certainly sounds like it might be. Why not just leave it on? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From cgrundemann at gmail.com Wed Jun 8 11:16:51 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 8 Jun 2011 10:16:51 -0600 Subject: IPv6 day non-participants In-Reply-To: References: Message-ID: ISOC has a red/green dashboard of individual (non)participants: http://www.worldipv6day.org/participant-websites/index.html Cheers, ~Chris On Wed, Jun 8, 2011 at 09:59, James Harr wrote: > I noticed that one of our vendors wasn't actually participating when > they very publicly put on their home page that they would. So I > queried the IPv6 day participation list to see who didn't have AAAA's > for their listed website. It turned out to be around 9.5% > > Before you read the list, here's me shedding responsibility with a > list of caveats: > - The crappy perl script I am using might be broken. IE - it doesn't > think about "foo.com" vs "www.foo.com", HTTP redirection, or any of > that. > - The organizations in this list may have withdrawn because they found > out something was terribly broken. > - DNS caching may be skewing the results if the TTLs are long. > > ==== SNIP ==== > www.xiphiastec.com ? ? ? ? ? ? Xiphiastec > www.pir.org ? ? ? ? ? ? ? ? ? ?Public Interest Registry > www.exactabacus.com ? ? ? ? ? ?Exact Abacus > www.comcast.net ? ? ? ? ? ? ? ?Comcast > www.shazzlemail.com ? ? ? ? ? ?Shazzle, LLC > www.bangzoom.com ? ? ? ? ? ? ? Bangzoom Software Inc > www.mihostcgi.com ? ? ? ? ? ? ?mihostcgi > www.unclesamnames.com ? ? ? ? ?American Domain Names > opendns.com ? ? ? ? ? ? ? ? ? ?OpenDNS > www.mutali.rw ? ? ? ? ? ? ? ? ?Mutali > townnews.com ? ? ? ? ? ? ? ? ? TownNews > www.infoblox.com ? ? ? ? ? ? ? Infoblox > www.ripplecom.net ? ? ? ? ? ? ?Ripple Communications > www.agame.com ? ? ? ? ? ? ? ? ?Spil Games > www.alexville.com ? ? ? ? ? ? ?Alexville Games > www.hkirc.hk ? ? ? ? ? ? ? ? ? Hong Kong Internet Registration Corporation > www.hkdnr.hk ? ? ? ? ? ? ? ? ? Hong Kong Domain Name Registration > www.buffalo.feb.gov ? ? ? ? ? ?United States Office of Personnel Management > www.cyberport.hk ? ? ? ? ? ? ? Hong Kong Cyberport Management Ltd > www.catnix.com ? ? ? ? ? ? ? ? CATNIX > sucomo.com ? ? ? ? ? ? ? ? ? ? Sucomo OHG > www.mybrighthouse.com ? ? ? ? ?BrightHouse Networks > www.it-in.ru ? ? ? ? ? ? ? ? ? it-in > ivancorp.net ? ? ? ? ? ? ? ? ? Ivanhoe-IT > www.forestdaleinc.org ? ? ? ? ?Forestdale Inc > www.towerstream.com ? ? ? ? ? ?Towerstream > www.intuix.com ? ? ? ? ? ? ? ? Intuix LLC > suse.org ? ? ? ? ? ? ? ? ? ? ? Novell Inc. > www.IronNails.com ? ? ? ? ? ? ?IronNails Consultancy > www.orbitdiensten.com ? ? ? ? ?Orbit-Diensten > madonnaradio.com ? ? ? ? ? ? ? Voila > www.gov.bc.ca ? ? ? ? ? ? ? ? ?Government of British Columbia > www.zte.com.cn ? ? ? ? ? ? ? ? ZTE Corporation > www.tamagawa.jp ? ? ? ? ? ? ? ?Tamagawa Academy & University > > > -- > ^[:wq^M > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From llynch at civil-tongue.net Wed Jun 8 11:21:37 2011 From: llynch at civil-tongue.net (Lucy Lynch) Date: Wed, 8 Jun 2011 09:21:37 -0700 (PDT) Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: References: Message-ID: On Wed, 8 Jun 2011, Jorge Amodio wrote: >> http://www.mrp.net/IPv6Day.html > > The web access column reflects access to internal content or just the > home page ? Mark's notes explain what he tested and clicking on any link shows the result of his diagnostics: http://www.mrp.net//IPv6Day_files/diagnostics/aol.com.html guessing he didn't do depth probes. Maybe you want to set something up? - Lucy > -J > From jeroen at unfix.org Wed Jun 8 11:22:40 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 08 Jun 2011 18:22:40 +0200 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: References: Message-ID: <4DEFA1D0.5030709@unfix.org> On 2011-Jun-08 17:26, STARNES, CURTIS wrote: > Typical long trip via a sixxs.net tunnel. Unlike Hurricane Electric > (tunnelbroker.net), Sixxs has no US peering that I know of so > everything has to hit overseas before returning back. psst.. there is no such thing as "SixXS peering". Each PoP (http://www.sixxs.net/pops/) is provided by an ISP and that ISP arranges all the routing. As such, it depends on that ISP how the routing goes. But it is always a pleasure to see that people think that SixXS is equivalent to a full commercial ISP with 24/7 staffing instead of the two-man hobby project that it truly is ;) Of course, in case of problems etc don't hesitate to use http://www.sixxs.net/contact/ and provide the appropriate details so that they can be relayed to the relevant people. Yes, there is a mail queue, unfortunately there is also real work to be done, thus can't resolve the complaint of every single person. Greets, Jeroen From mfrazer at townnews.com Wed Jun 8 11:26:59 2011 From: mfrazer at townnews.com (Matt Frazer) Date: Wed, 8 Jun 2011 12:26:59 -0400 Subject: IPv6 day non-participants In-Reply-To: References: Message-ID: <001101cc25f8$e622cfe0$b2686fa0$@com> The list of TownNews domains participating can be found here: http://www.townnews365.com/ipv6/ -mjf -----Original Message----- From: James Harr [mailto:james.harr at gmail.com] Sent: Wednesday, June 08, 2011 12:00 PM To: nanog Subject: IPv6 day non-participants I noticed that one of our vendors wasn't actually participating when they very publicly put on their home page that they would. So I queried the IPv6 day participation list to see who didn't have AAAA's for their listed website. It turned out to be around 9.5% Before you read the list, here's me shedding responsibility with a list of caveats: - The crappy perl script I am using might be broken. IE - it doesn't think about "foo.com" vs "www.foo.com", HTTP redirection, or any of that. - The organizations in this list may have withdrawn because they found out something was terribly broken. - DNS caching may be skewing the results if the TTLs are long. ==== SNIP ==== From mfrazer at townnews.com Wed Jun 8 11:31:22 2011 From: mfrazer at townnews.com (Matt Frazer) Date: Wed, 8 Jun 2011 12:31:22 -0400 Subject: IPv6 day non-participants References: Message-ID: <001201cc25f9$82a72be0$87f583a0$@com> The list of TownNews domains participating can be found here: http://www.townnews365.com/ipv6/ > ahwatukee.com > alpineavalanche.com > anchoragepress.com > aransaspassprogress.com > argus-press.com > auburnpub.com > azdailysun.com > banderabulletin.com > beatricedailysun.com > belgrade-news.com > bigbeargrizzly.net > billingsgazette.com > bismarcktribune.com > bloxcms-ny1.com > bloxcms.com > boernestar.com > bonnercountydailybee.com > bonnersferryherald.com > bozemandailychronicle.com > breezejmu.org > cameronherald.com > camplejeuneglobe.com > carrollcountytimes.com > casperjournal.com > cdapress.com > cdapressextra.com > chetekalert.com > chieftain.com > chippewa.com > citizen.com > coastreportonline.com > codyenterprise.com > colletontoday.com > coloradocountycitizen.com > columbiabasinherald.com > columbustelegram.com > coronadonewsca.com > cumberlink.com > dailyjournalonline.com > dailyleader.com > dailyrecordnews.com > dailytoreador.com > democratherald.com > doaneline.com > douglas-budget.com > eastvalleytribune.com > elgincourier.com > elkodaily.com > enterprise-journal.com > explorernews.com > farmandranchguide.com > flatheadnewsgroup.com > florala.net > fltimes.com > forest-blade.com > fortcampbellcourier.com > fortstocktonpioneer.com > fremonttribune.com > fromthevine.info > ftleetraveller.com > gazettetimes.com > gettysburgtimes.com > glendalestar.com > globegazette.com > goac.com > gonzalesinquirer.com > gvnews.com > hanfordsentinel.com > helenair.com > herald-review.com > heraldextra.com > hillcountrynews.com > hmbreview.com > houstonherald.com > huskerextra.com > huskerfootball.com > iberianet.com > idahopress.com > illelections.com > imperialbeachnewsca.com > indianapolisrecorder.com > insidetucsonbusiness.com > iowastatedaily.com > jg-tc.com > journalnet.com > journalreview.com > journalstar.com > journaltimes.com > katytimes.com > keepmecurrent.com > kokomoperspective.com > lacrossetribune.com > lakeexpo.com > leaderadvertiser.com > leadertelegram.com > lebanon-express.com > leecmstraining.com > leetemplates.com > livingstonparishnews.com > lodinews.com > lompocrecord.com > lonepeaklookout.com > loyolaphoenix.com > madisonvillemeteor.com > magiccitymagazine.com > magicvalley.com > magnoliareporter.com > marlindemocrat.com > maysville-online.com > messenger-index.com > midwestproducer.com > minnesotafarmguide.com > mississippilink.com > missoulian.com > mountain-news.com > mtstandard.com > murrayledger.com > muscatinejournal.com > mycaldwellcounty.com > mycarrollcountynews.com > mynwmo.com > napavalleyregister.com > navasotaexaminer.com > nctimes.com > newjerseyhills.com > news-expressky.com > news-graphic.com > norfolknavyflagship.com > nwitimes.com > nwmissourinews.com > ourcoloradonews.com > outdoornews.com > ozarkcountytimes.com > pantagraph.com > peoriatimes.com > portlavacawave.com > poststar.com > pressofatlanticcity.com > priestrivertimes.com > qctimes.com > rapidcityjournal.com > ravallirepublic.com > riverfloodwatch.com > rrdailyherald.com > rrobserver.com > salamancapress.com > santamariatimes.com > savvyshopperdeals.com > scene262.com > sealynews.com > seasidesignal.com > shoshonenewspress.com > siouxcityjournal.com > statehornet.com > syvnews.com > taylordailypress.net > tdn.com > terrelltribune.com > tetonvalleynews.net > the-standard.org > thechiefleader.com > thecountrytoday.com > theeaglepost.us > thegardenisland.com > thehuttonews.com > theorion.com > theprairiestar.com > therandolphleader.com > theroyalregister.com > thesouthern.com > thetandd.com > thevindicator.com > thewesternnews.com > thewetumpkaherald.com > theworldlink.com > tipofyourfingers.com > townnews-cms.com > townnews365.com > trib.com > tristate-media.com > tristateneighbor.com > utownnews.com > uvaldeleadernews.com > voiceoftheironrange.com > vp-mi.com > wcfcourier.com > wereadnatrona.com > westyellowstonenews.com > winonadailynews.com > yourwestvalley.com -mjf -----Original Message----- From: James Harr [mailto:james.harr at gmail.com] Sent: Wednesday, June 08, 2011 12:00 PM To: nanog Subject: IPv6 day non-participants I noticed that one of our vendors wasn't actually participating when they very publicly put on their home page that they would. So I queried the IPv6 day participation list to see who didn't have AAAA's for their listed website. It turned out to be around 9.5% Before you read the list, here's me shedding responsibility with a list of caveats: - The crappy perl script I am using might be broken. IE - it doesn't think about "foo.com" vs "www.foo.com", HTTP redirection, or any of that. - The organizations in this list may have withdrawn because they found out something was terribly broken. - DNS caching may be skewing the results if the TTLs are long. ==== SNIP ==== From georgeb at gmail.com Wed Jun 8 11:49:17 2011 From: georgeb at gmail.com (George B.) Date: Wed, 8 Jun 2011 09:49:17 -0700 Subject: IPv6 day non-participants In-Reply-To: <001201cc25f9$82a72be0$87f583a0$@com> References: <001201cc25f9$82a72be0$87f583a0$@com> Message-ID: Was participating until we hit a rather nasty load balancer bug that took out the entire unit if clients with a short MTU connected and it needed to fragment packets (Citrix Netscaler running latest code). No fix is available for it yet, so we had to shut it down. Ran for about 9 hours before the "magic" client that blew it up connected. So if you are using a Netscaler with SLB-PT (IPv6 VIP balancing to IPv4 servers), the entire LB is subject to stop working until they get this fixed. From jmamodio at gmail.com Wed Jun 8 12:00:30 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 8 Jun 2011 12:00:30 -0500 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: References: Message-ID: >>> http://www.mrp.net/IPv6Day.html >> >> The web access column reflects access to internal content or just the >> home page ? > > Mark's notes explain what he tested and clicking on any link shows > the result of his diagnostics: > > http://www.mrp.net//IPv6Day_files/diagnostics/aol.com.html > > guessing he didn't do depth probes. Maybe you want to set something up? Thanks for the follow up. I noticed that the test only looks for the html survey file. Just curious since other folks reported that some content providers are serving the home page via IPv6 but other content goes via IPv4. Still surprised that Akamai's numbers feel very low, 300+ hits per sec (worldwide) for one of the major CDN is not that much IHMO, we really need more IPv6 eye-balls connecting. -J From rps at maine.edu Wed Jun 8 12:18:35 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 8 Jun 2011 13:18:35 -0400 Subject: World of Warcraft may begin using IPv6 on Tuesday In-Reply-To: <000001cc25c7$7e7c3290$7b7497b0$@iname.com> References: <000001cc25c7$7e7c3290$7b7497b0$@iname.com> Message-ID: Just grabbed the Trial and tested it. Verified that IPv6 is used for World of Warcraft on the Antonidas server. It works pretty well actually. I see they replicated their practice of dropping all ICMP traffic for IPv6. Not sure that's the best idea. Anyone know if they plan to leave it working now and possibly expand it too all their servers? Ray On Wed, Jun 8, 2011 at 6:33 AM, Frank Bulk wrote: > More here: http://ipv6.blizzard.com/ > > ? ? ? ?To test IPv6 in World of Warcraft, you'll need to edit your > ? ? ? ?config.wtf file and add the following line: > > ? ? ? ? ? ? ? ?SET unlockIPv6 "1" > > ? ? ? ?This will activate the IPv6 features. If your computer has > ? ? ? ?a valid IPv6 address, you'll be able to check the "Enable > ? ? ? ?IPv6" checkbox from the Network options in the World of > ? ? ? ?Warcraft client. Once in the game, you'll be able to see > ? ? ? ?which type of connection the client has made to the realms > ? ? ? ?next to the latency information. > > Frank > > -----Original Message----- > From: Kevin Day [mailto:toasty at dragondata.com] > Sent: Saturday, April 23, 2011 1:10 PM > To: NANOG list > Subject: World of Warcraft may begin using IPv6 on Tuesday > > > For those that don't know, World of Warcraft is currently the largest online > role playing game, with somewhere over 12 million subscribers. > > Version 4.1 of the game is expected to be released this Tuesday, which will > be automatically pushed to all clients. The current Beta version of 4.1 has > full IPv6 support. In the beta, it's automatically enabled if you have > native IPv6 (non-6to4, non-Teredo). While Blizzard has been pretty silent > about this, barring a last minute revert or delay of this patch, there are > suddenly going to be a bunch more users that can potentially use IPv6. And > these users are the type who are going to be especially sensitive to > latency, jitter and packet loss, since this is a real-time game platform. > > For those of you with Help Desks who have to support users like this, the > associated setting in the game's Options menu is apparently called "Enable > IPv6 when available". It's apparently grayed out if you do not have IPv6 at > all, unchecked by default if you are on 6to4 or Teredo, and checked by > default if you are on native v6. The tooltip says: "Enables the use of IPv6, > the technology behind the next-generation Internet. Requires IPv6 > connectivity to the internet. Checking this box without IPv6 connectivity > may prevent you from playing WoW." > > Anyone from Activision/Blizzard who would like to chime in with more > details? :) > > -- Kevin > > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From sethm at rollernet.us Wed Jun 8 12:22:07 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 08 Jun 2011 10:22:07 -0700 Subject: IPv6 day fun is beginning! In-Reply-To: References: <4DEEBAB4.9000507@altadena.net> <4DEEBC05.10100@altadena.net> <47F2C08A-E828-4C2A-8C3D-28C008517221@puck.nether.net> Message-ID: <4DEFAFBF.7060702@rollernet.us> On 6/8/11 1:29 AM, Neil Long wrote: > > On 8 Jun 2011, at 02:13, TJ wrote: > >> On Tue, Jun 7, 2011 at 21:04, Iljitsch van Beijnum >> wrote: >> >>> On 8 jun 2011, at 2:31, TJ wrote: >>> >>>> ... and Gmail, too ... >>> >>> imap.gmail.com only has IPv4, though. >>> >> >> Good catch, applies to pop & smtp as well. Baby steps, I guess? >> /TJ >> > > Sadly, although I can connect over IPv6 to Gmail an email sent from > within the browser to an IPv6-only address (AAAA but also an MX) still > gives the "DNS Error: DNS server returned answer with no data" message. > > Transport is one thing but getting applications working with an IPv6 > world will take longer (not that it is that hard :-) ) > I've been doing IPv6 with SMTP and POP3/IMAP for quite a while now without any magic tricks. In fact, I've found SMTP to be a far better test in the early days since it's non-interactive and invisible to the customer if it took time to fall back to IPv4. ~Seth From daniel.unam.ipv6 at gmail.com Wed Jun 8 12:37:54 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Wed, 8 Jun 2011 12:37:54 -0500 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.. (Jorge Amodio)(Lucy Lynch) Message-ID: > > > You shouldn't. The matter of the fact is that for al leats 24 hours users > like you and me ... all we can reach the main Webpages for each participant > in the ipv6 day. > > The idea is that this must be all in a transparent manner for the final > users. If you have an IPv6 supported insfrastructure, then you can try > http://ipv6.google.com and feel the "power" of IPv6. > > A HOSTSV6.TXT file is not prepared for today (nor as actually I know). > > The results for this day are expected to be a reference for further IPv6 > deployment and implementation in the near future. > > Best regards xD. > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 8 Jun 2011 11:04:42 -0500 > From: Jorge Amodio > Subject: Re: AAAA on various websites, but they all forgot to enable > them on their nameservers.... > To: Daniel Espejel > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > > The main objective for today is to access the web services, that's why > you > > can't reach a AAAA record for a DNS query for a given NS server. > > So if there are no AAAA records from where we ftp6 the HOSTSV6.TXT file ? > > -J > > > > ------------------------------ > > Message: 2 > Date: Wed, 8 Jun 2011 09:05:38 -0700 (PDT) > From: Lucy Lynch > Subject: Re: AAAA on various websites, but they all forgot to enable > them on their nameservers.... > To: Daniel Espejel > Cc: nanog at nanog.org > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Wed, 8 Jun 2011, Daniel Espejel wrote: > > > Hi. > > > > The main objective for today is to access the web services, that's why > you > > can't reach a AAAA record for a DNS query for a given NS server. > > exactly - this site provides a nice service snapshot: > > http://www.mrp.net/IPv6Day.html > > > > > ; <<>> DiG 9.5.1-P3 <<>> www.google.com aaaa > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40029 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4 > > > > ;; QUESTION SECTION: > > ;www.google.com. IN AAAA > > > > ;; ANSWER SECTION: > > www.google.com. 532907 IN CNAME www.l.google.com. > > www.l.google.com. 150 IN AAAA 2001:4860:4002:802::1010 > > > > ; <<>> DiG 9.5.1-P3 <<>> www.yahoo.com aaaa > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60816 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 2 > > > > ;; QUESTION SECTION: > > ;www.yahoo.com. IN AAAA > > > > ;; ANSWER SECTION: > > www.yahoo.com. 284 IN CNAME fpfd.wa1.b.yahoo.com. > > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00c:1fe::3001 > > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f011:1fe::3001 > > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f011:1fe::3000 > > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00d:1fe::3001 > > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00d:1fe::3000 > > fpfd.wa1.b.yahoo.com. 6 IN AAAA 2001:4998:f00c:1fe::3000 > > ; <<>> DiG 9.5.1-P3 <<>> www.facebook.com aaaa > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12079 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 > > > > ;; QUESTION SECTION: > > ;www.facebook.com. IN AAAA > > > > ;; ANSWER SECTION: > > www.facebook.com. 8 IN AAAA 2620:0:1c00:0:face:b00c:0:1 > > > > > > > > ; <<>> DiG 9.5.1-P3 <<>> www.unam.mx aaaa > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42381 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 > > > > ;; QUESTION SECTION: > > ;www.unam.mx. IN AAAA > > > > ;; ANSWER SECTION: > > www.unam.mx. 6031 IN AAAA > 2001:1218:1:6:d685:64ff:fec4:720b > > > > You see? there's a lot of IPv6 activity since a few weeks ago. xD > > > -- *Daniel Espejel P?rez * From dr at cluenet.de Wed Jun 8 12:46:01 2011 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 8 Jun 2011 19:46:01 +0200 Subject: Microsoft's participation in World IPv6 day In-Reply-To: References: <73BD36F2-86B7-4E6F-9E5E-012F08F6A2B8@pch.net> Message-ID: <20110608174601.GB27714@srv03.cluenet.de> On Tue, Jun 07, 2011 at 08:25:59PM +0000, John.Herbert at usc-bt.com wrote: > Bill Woodcock [mailto:woody at pch.net] spake: > >http://support.microsoft.com/kb/2533454/ > >Uh... > > This does rather assume that users can access Google/Bing (both IPv6 > day participants) to search for a solution to the problems they are > experiencing, and then that they can actually access the KB article... Given that support.microsoft.com is v4-only, the latter isn't the problem. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From joly at punkcast.com Wed Jun 8 12:55:24 2011 From: joly at punkcast.com (Joly MacFie) Date: Wed, 8 Jun 2011 13:55:24 -0400 Subject: IPv6 day non-participants In-Reply-To: References: Message-ID: I notice that that page currently lists as http://www.bbc.co.uk/ as unreachable via IPv4 ! ? j On Wed, Jun 8, 2011 at 12:16 PM, Chris Grundemann wrote: > ISOC has a red/green dashboard of individual (non)participants: > http://www.worldipv6day.org/participant-websites/index.html > > Cheers, > ~Chris > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From heather.schiller at verizonbusiness.com Wed Jun 8 13:15:26 2011 From: heather.schiller at verizonbusiness.com (Schiller, Heather A) Date: Wed, 08 Jun 2011 18:15:26 +0000 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: References: Message-ID: -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Wednesday, June 08, 2011 1:01 PM To: Lucy Lynch Cc: nanog at nanog.org Subject: Re: AAAA on various websites, but they all forgot to enable them on their nameservers.... >>> http://www.mrp.net/IPv6Day.html >> >> The web access column reflects access to internal content or just the >> home page ? > > Mark's notes explain what he tested and clicking on any link shows the > result of his diagnostics: > > http://www.mrp.net//IPv6Day_files/diagnostics/aol.com.html > > guessing he didn't do depth probes. Maybe you want to set something up? Thanks for the follow up. I noticed that the test only looks for the html survey file. Just curious since other folks reported that some content providers are serving the home page via IPv6 but other content goes via IPv4. Still surprised that Akamai's numbers feel very low, 300+ hits per sec (worldwide) for one of the major CDN is not that much IHMO, we really need more IPv6 eye-balls connecting. -J ...yes, there is a serious lack of v6 enabled eyeballs. But it's also not clear to me from Akamai's stats just how many of the sites they host are v6 enabled. 2? 12? 500? --heather From paul at paulgraydon.co.uk Wed Jun 8 23:19:35 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Wed, 08 Jun 2011 18:19:35 -1000 Subject: IPv6 day fun is beginning! In-Reply-To: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> References: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> Message-ID: <4DF049D7.3020009@paulgraydon.co.uk> I've done the same at home, HE tunnel for IPv6. I've got a Linksys WRT54GL running DD-WRT so getting it set up was relatively straight forward though I really need to fix the automatic startup script that's misbehaving. Work was another matter, one big headache, to the point where I'm wondering if something is interfering. OpenBSD box running pf acts as a router for us, HE tunnel comes up easily and works fine from box. rtadvd starts advertising the network range and every machine in the office picked it up. Briefly those workstations running Windows 7 in the office were able to use the tunnel (5 mins give or take). From then on I could see outbound and inbound IPv6 traffic on the BSD box, but it never seemed to reach the workstations. Tearing down, reconfiguring, checking out every guide under the sun, nothing worked :) Gave up in the end, I'll tackle it later when I've got time to waste. Would be nice if my $isp would sort out an IPv6 address range for us to use properly. Paul On 6/8/2011 1:40 AM, Jamie Bowden wrote: > Thanks to HE's tunnel broker service, I've got fully functional dual > stack at home (well, mostly, like most folks, VZ gives me a single > address and I live behind that with NATv4, but otherwise, I loves me > some FiOS) and yesterday went by for me without a hitch, including > accessing Facebook (I'd hear from the wife and kid really quickly if > they weren't working). For a working tunnel, I put my DIR-825 as the > "DMZ" host behind the cheesy Actiontec router VZ requires, forward all > traffic with zero firewalling to it, and let the D-Link appliance handle > all my firewall needs (and it terminates my v6 tunnel obviously). The > one thing I haven't quite figured out how to make it do (and maybe it's > just not capable) is use the /48 HE routes to me. The box insists that > the internal interface be on the same subnet as the external, and it > hands out v6 addresses from that /64. > > Jamie > > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Tuesday, June 07, 2011 7:15 PM > To: Iljitsch van Beijnum > Cc: NANOG list > Subject: Re: IPv6 day fun is beginning! > > > On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: > >> www.facebook.com has AAAA but doesn't load for me over IPv6, it does > for others though > > If you go to www.v6.facebook.com it works, but it seems they have some > problem on their main site. I am seeing some issues reaching them over > IPv6. > > - Jared > > > > From smb at cs.columbia.edu Wed Jun 8 13:50:41 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 8 Jun 2011 14:50:41 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: On Jun 7, 2011, at 7:22 58PM, wrote: > No issues connecting to FB for me on IPv6 (both to www.v6.facebook.com and to the AAAA returned by www.facebook.com now). > > Interesting (perhaps) side note - www.facebook.com has a AAAA, but "facebook.com" does not. > > Google / Youtube records are up and running nicely also. > > J. I was hoping for a v6 Google logo.... --Steve Bellovin, https://www.cs.columbia.edu/~smb From jmamodio at gmail.com Wed Jun 8 14:01:03 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 8 Jun 2011 14:01:03 -0500 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: References: Message-ID: > ...yes, there is a serious lack of v6 enabled eyeballs. ?But it's also > not clear to me from Akamai's stats just how many of the sites they host > are v6 enabled. 2? 12? 500? True. I'll go back to their site and dig for more detailed info about what those "hits" are actually hitting. Regards Jorge From Chris_Griffiths at Cable.Comcast.com Wed Jun 8 14:18:45 2011 From: Chris_Griffiths at Cable.Comcast.com (Griffiths, Chris) Date: Wed, 8 Jun 2011 19:18:45 +0000 Subject: IPv6 day non-participants In-Reply-To: Message-ID: The ISOC dashboard that Chris mentions is indeed accurate and up to date from our perspective. Comcast is definitely an active participant with our website http://xfinity.comcast.net, which is live with a published AAAA and is IPv6 reachable. Thanks -- Chris Griffiths Comcast Cable Communications, Inc. On 6/8/11 12:16 PM, "Chris Grundemann" wrote: >ISOC has a red/green dashboard of individual (non)participants: >http://www.worldipv6day.org/participant-websites/index.html > >Cheers, >~Chris > >On Wed, Jun 8, 2011 at 09:59, James Harr wrote: >> I noticed that one of our vendors wasn't actually participating when >> they very publicly put on their home page that they would. So I >> queried the IPv6 day participation list to see who didn't have AAAA's >> for their listed website. It turned out to be around 9.5% >> >> Before you read the list, here's me shedding responsibility with a >> list of caveats: >> - The crappy perl script I am using might be broken. IE - it doesn't >> think about "foo.com" vs "www.foo.com", HTTP redirection, or any of >> that. >> - The organizations in this list may have withdrawn because they found >> out something was terribly broken. >> - DNS caching may be skewing the results if the TTLs are long. >> >> ==== SNIP ==== >> www.xiphiastec.com Xiphiastec >> www.pir.org Public Interest Registry >> www.exactabacus.com Exact Abacus >> www.comcast.net Comcast >> www.shazzlemail.com Shazzle, LLC >> www.bangzoom.com Bangzoom Software Inc >> www.mihostcgi.com mihostcgi >> www.unclesamnames.com American Domain Names >> opendns.com OpenDNS >> www.mutali.rw Mutali >> townnews.com TownNews >> www.infoblox.com Infoblox >> www.ripplecom.net Ripple Communications >> www.agame.com Spil Games >> www.alexville.com Alexville Games >> www.hkirc.hk Hong Kong Internet Registration >>Corporation >> www.hkdnr.hk Hong Kong Domain Name Registration >> www.buffalo.feb.gov United States Office of Personnel >>Management >> www.cyberport.hk Hong Kong Cyberport Management Ltd >> www.catnix.com CATNIX >> sucomo.com Sucomo OHG >> www.mybrighthouse.com BrightHouse Networks >> www.it-in.ru it-in >> ivancorp.net Ivanhoe-IT >> www.forestdaleinc.org Forestdale Inc >> www.towerstream.com Towerstream >> www.intuix.com Intuix LLC >> suse.org Novell Inc. >> www.IronNails.com IronNails Consultancy >> www.orbitdiensten.com Orbit-Diensten >> madonnaradio.com Voila >> www.gov.bc.ca Government of British Columbia >> www.zte.com.cn ZTE Corporation >> www.tamagawa.jp Tamagawa Academy & University >> >> >> -- >> ^[:wq^M >> >> > > > >-- >@ChrisGrundemann >weblog.chrisgrundemann.com >www.burningwiththebush.com >www.theIPv6experts.net >www.coisoc.org > From paradox at nac.net Wed Jun 8 14:41:18 2011 From: paradox at nac.net (Ryan Pavely) Date: Wed, 08 Jun 2011 15:41:18 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: <4DF049D7.3020009@paulgraydon.co.uk> References: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> <4DF049D7.3020009@paulgraydon.co.uk> Message-ID: <4DEFD05E.3090306@nac.net> Are you really on Cook Island in the Pacific or is your email headers date timezone string set incorrectly -1000. Your message won't be read by me until tonight shortly after 12:19 am. Sadly you'll miss IPv6 day :( Ryan Pavely Net Access Corporation http://www.nac.net/ On 6/9/2011 12:19 AM, Paul Graydon wrote: > I've done the same at home, HE tunnel for IPv6. I've got a Linksys > WRT54GL running DD-WRT so getting it set up was relatively straight > forward though I really need to fix the automatic startup script > that's misbehaving. > Work was another matter, one big headache, to the point where I'm > wondering if something is interfering. OpenBSD box running pf acts as > a router for us, HE tunnel comes up easily and works fine from box. > rtadvd starts advertising the network range and every machine in the > office picked it up. Briefly those workstations running Windows 7 in > the office were able to use the tunnel (5 mins give or take). From > then on I could see outbound and inbound IPv6 traffic on the BSD box, > but it never seemed to reach the workstations. Tearing down, > reconfiguring, checking out every guide under the sun, nothing worked > :) Gave up in the end, I'll tackle it later when I've got time to waste. > Would be nice if my $isp would sort out an IPv6 address range for us > to use properly. > > Paul > > > On 6/8/2011 1:40 AM, Jamie Bowden wrote: >> Thanks to HE's tunnel broker service, I've got fully functional dual >> stack at home (well, mostly, like most folks, VZ gives me a single >> address and I live behind that with NATv4, but otherwise, I loves me >> some FiOS) and yesterday went by for me without a hitch, including >> accessing Facebook (I'd hear from the wife and kid really quickly if >> they weren't working). For a working tunnel, I put my DIR-825 as the >> "DMZ" host behind the cheesy Actiontec router VZ requires, forward all >> traffic with zero firewalling to it, and let the D-Link appliance handle >> all my firewall needs (and it terminates my v6 tunnel obviously). The >> one thing I haven't quite figured out how to make it do (and maybe it's >> just not capable) is use the /48 HE routes to me. The box insists that >> the internal interface be on the same subnet as the external, and it >> hands out v6 addresses from that /64. >> >> Jamie >> >> -----Original Message----- >> From: Jared Mauch [mailto:jared at puck.nether.net] >> Sent: Tuesday, June 07, 2011 7:15 PM >> To: Iljitsch van Beijnum >> Cc: NANOG list >> Subject: Re: IPv6 day fun is beginning! >> >> >> On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: >> >>> www.facebook.com has AAAA but doesn't load for me over IPv6, it does >> for others though >> >> If you go to www.v6.facebook.com it works, but it seems they have some >> problem on their main site. I am seeing some issues reaching them over >> IPv6. >> >> - Jared >> >> >> >> From dmburgess at linktechs.net Wed Jun 8 14:43:23 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Wed, 8 Jun 2011 14:43:23 -0500 Subject: Cogent & HE Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50547C104@ltiserver.lti.local> Just noted that cogent does not have a IPv6 route to any subnet in HE, and HE does not have any routes to Cogent! Looks like we have different Global IPv6 tables? Or does Cogent just NOT peer IPv6 peer with anyone else! Dennis From sethm at rollernet.us Wed Jun 8 14:48:27 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 08 Jun 2011 12:48:27 -0700 Subject: Cogent & HE In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50547C104@ltiserver.lti.local> References: <13175F96BDC3B34AB1425BAE905B3CE50547C104@ltiserver.lti.local> Message-ID: <4DEFD20B.1070902@rollernet.us> On 6/8/2011 12:43, Dennis Burgess wrote: > Just noted that cogent does not have a IPv6 route to any subnet in HE, > and HE does not have any routes to Cogent! > > Looks like we have different Global IPv6 tables? Or does Cogent just > NOT peer IPv6 peer with anyone else! > Cogent and HE don't talk anymore, so yeah, you're living in a partitioned world if you only have Cogent. It's been this way for a while. ~Seth From bruns at 2mbit.com Wed Jun 8 14:48:42 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 8 Jun 2011 19:48:42 +0000 Subject: Cogent & HE Message-ID: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> Has been going on for a long while now. HE even made a cake for Cogent (IIRC), to no avail. But, this is not surprising. A lot of public/major peering issues with v4 over the past few years has been cogent vs. someone else. Brielle ------Original Message------ From: Dennis Burgess To: nanog at nanog.org Subject: Cogent & HE Sent: Jun 8, 2011 1:43 PM Just noted that cogent does not have a IPv6 route to any subnet in HE, and HE does not have any routes to Cogent! Looks like we have different Global IPv6 tables? Or does Cogent just NOT peer IPv6 peer with anyone else! Dennis -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From joly at punkcast.com Wed Jun 8 14:48:52 2011 From: joly at punkcast.com (Joly MacFie) Date: Wed, 8 Jun 2011 15:48:52 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: What seems evident, looking at http://asert.arbornetworks.com/2011/06/monitoring-world-ipv6-day/ is that a lot of folks switched it on - and then switched it off again pretty damn quick! -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From igor at gashinsky.net Wed Jun 8 14:49:25 2011 From: igor at gashinsky.net (Igor Gashinsky) Date: Wed, 8 Jun 2011 15:49:25 -0400 (EDT) Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: <4DEF40C8.3020502@unfix.org> References: <4DEF40C8.3020502@unfix.org> Message-ID: On Wed, 8 Jun 2011, Jeroen Massar wrote: :: It is really nice that folks where able to put AAAA records on their :: websites for only 24 hours, but they forgot to put in the glue on their :: nameservers. :: :: As such, for the folks testing IPv6-only, a lot of sites will fail :: unless they use a recursor that does the IPv4 for them. Speaking strictly for myself, we didn't "forget". First of all, that's not what World IPv6 Day was supposed to be about -- it's not about ipv6-only users, it's about dual-stacking content (if your ISP doesn't have enough ip's to dual-stack their recursive resolvers, you have bigger problems right now :) ).. Also, and more importantly, our data shows that 0.5% of the users can't resolve hostnames if we enabled AAAA glue on all resolvers... And, before somebody asks, I don't have any data on what happends if you enable v6-glue to only 1 of your NS's though :) -igor From nick at flhsi.com Wed Jun 8 14:55:42 2011 From: nick at flhsi.com (Nick Olsen) Date: Wed, 8 Jun 2011 15:55:42 -0400 Subject: Cogent & HE Message-ID: <3aff7ff$486ffb3d$e648d98$@com> Correct, The only way around this currently is to peer with both cogent and HE. If you have cogent, You can 6to4 w/BGP with HE. I would consider that just a patch for the problem. I would do it just for the reachablility. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Dennis Burgess" Sent: Wednesday, June 08, 2011 3:45 PM To: nanog at nanog.org Subject: Cogent & HE Just noted that cogent does not have a IPv6 route to any subnet in HE, and HE does not have any routes to Cogent! Looks like we have different Global IPv6 tables? Or does Cogent just NOT peer IPv6 peer with anyone else! Dennis From fredrik at i2b.se Wed Jun 8 14:55:18 2011 From: fredrik at i2b.se (Fredrik Holmqvist / I2B) Date: Wed, 08 Jun 2011 21:55:18 +0200 Subject: Cogent & HE Message-ID: <0afa25cbaa8d62fc3a517e291dbe1cbe@imap> On Wed, 8 Jun 2011 14:43:23 -0500, "Dennis Burgess" wrote: > Just noted that cogent does not have a IPv6 route to any subnet in HE, > and HE does not have any routes to Cogent! > > Looks like we have different Global IPv6 tables? Or does Cogent just > NOT peer IPv6 peer with anyone else! > > Dennis Hi. There is some difference in prefix count between the two: AS6939 6074 AS174 4787 These are prefixes announced to transitcustomer of both HE and Cogent. -- Fredrik Holmqvist I2B (Internet 2 Business) 070-740 5033 From mhernand1 at comcast.net Wed Jun 8 15:01:56 2011 From: mhernand1 at comcast.net (manny) Date: Wed, 08 Jun 2011 16:01:56 -0400 Subject: Cogent & HE In-Reply-To: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> Message-ID: <4DEFD534.7080702@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/8/11 3:48 PM, Brielle Bruns wrote: > Has been going on for a long while now. HE even made a cake for Cogent (IIRC), to no avail. > > But, this is not surprising. A lot of public/major peering issues with v4 over the past few years has been cogent vs. someone else. > > Brielle > ------Original Message------ > From: Dennis Burgess > To: nanog at nanog.org > Subject: Cogent & HE > Sent: Jun 8, 2011 1:43 PM > > Just noted that cogent does not have a IPv6 route to any subnet in HE, > and HE does not have any routes to Cogent! > > Looks like we have different Global IPv6 tables? Or does Cogent just > NOT peer IPv6 peer with anyone else! > > Dennis > > > You get what you pay for with Cogent.... YMMV -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN79U0AAoJEOcnyWxdB1Iro1IIAKxSFxPFbzQ3oTGwr6FR6MQ1 KIf0plsRJstmWmhygvXAwC3C9PUlBlaPqEc+KcI1frrMHNGb1fSmmQLRsxdQ22XX KIrIHhaYf9W/03twyp5iVNmZLcYKLkDO8SvaW4K0z0KRbMrrIgCkvOeekE28hz7n q/HTOpvvx+A1npS+wbvl3siIfrUSeXNVOhMm1/noA/VboFbaIhRQmRFh6ypHeZWg u7hk32DsotWlzJOocSbDda3+MPF4HCCWCN8tKC2WMUybaz2Wp/YRMUeca4fkckmk w37RVkuglrA3DwhfM+DihOQXoXYRFLMhiT4qb3+uwveolhyPA8q2YOdgLUo+qXA= =h0uX -----END PGP SIGNATURE----- From nathan at atlasnetworks.us Wed Jun 8 15:02:14 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 8 Jun 2011 20:02:14 +0000 Subject: Cogent & HE In-Reply-To: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B4890B7@ex-mb-1.corp.atlasnetworks.us> > Has been going on for a long while now. HE even made a cake for Cogent > (IIRC), to no avail. http://www.flickr.com/photos/77519640 at N00/4031195041/ From ras at e-gerbil.net Wed Jun 8 15:05:05 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 8 Jun 2011 15:05:05 -0500 Subject: Cogent & HE In-Reply-To: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> Message-ID: <20110608200505.GD18302@gerbil.cluepon.net> On Wed, Jun 08, 2011 at 07:48:42PM +0000, Brielle Bruns wrote: > Has been going on for a long while now. HE even made a cake for > Cogent (IIRC), to no avail. > > But, this is not surprising. A lot of public/major peering issues > with v4 over the past few years has been cogent vs. someone else. When two networks are not able to reach each other like this, it usually requires the active willing participation of both parties to allow the situation to continue. In this case, HE is doing *PRECISELY* the same thing that Cogent is doing. They're refusing to purchase transit, and making the decision to intentionally not carry a full table or have global reachability, in the hopes that it will strengthen their strategic position for peering in the long term (i.e. they both want to be an "IPv6 Tier 1"). I'm not making a judgement call about the rightness or wrongness of the strategy (and after all, it clearly hasn't been THAT big of an issue considering that it has been this way for MANY months), but to attempt to "blame" one party for this issue is the height of absurdity. PR stunts and cake baking not withstanding, they're both equally complicit. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From ken at sizone.org Wed Jun 8 15:07:37 2011 From: ken at sizone.org (Ken Chase) Date: Wed, 8 Jun 2011 16:07:37 -0400 Subject: Cogent & HE In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B4890B7@ex-mb-1.corp.atlasnetworks.us> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <8C26A4FDAE599041A13EB499117D3C286B4890B7@ex-mb-1.corp.atlasnetworks.us> Message-ID: <20110608200737.GB19328@sizone.org> On Wed, Jun 08, 2011 at 08:02:14PM +0000, Nathan Eisenberg said: >> Has been going on for a long while now. HE even made a cake for Cogent >> (IIRC), to no avail. > >http://www.flickr.com/photos/77519640 at N00/4031195041/ ObMeme[tm]: cake was a lie? /kc -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From ken at sizone.org Wed Jun 8 15:10:27 2011 From: ken at sizone.org (Ken Chase) Date: Wed, 8 Jun 2011 16:10:27 -0400 Subject: Cogent & HE In-Reply-To: <20110608200505.GD18302@gerbil.cluepon.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> Message-ID: <20110608201027.GC19328@sizone.org> On Wed, Jun 08, 2011 at 03:05:05PM -0500, Richard A Steenbergen said: >global reachability, in the hopes that it will strengthen their >strategic position for peering in the long term (i.e. they both want to >be an "IPv6 Tier 1"). > >I'm not making a judgement call about the rightness or wrongness of the >strategy (and after all, it clearly hasn't been THAT big of an issue >considering that it has been this way for MANY months), but to attempt >to "blame" one party for this issue is the height of absurdity. PR >stunts and cake baking not withstanding, they're both equally complicit. So we have to buy from BOTH HE and Cogent?! Sounds like market fixing to me! :/ Guess if we do we can advertise that on our webpage... "now with BOTH halves of the ipv6 internets!" /kc -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From georgeb at gmail.com Wed Jun 8 15:10:49 2011 From: georgeb at gmail.com (George B.) Date: Wed, 8 Jun 2011 13:10:49 -0700 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 12:48 PM, Joly MacFie wrote: > What seems evident, looking at > http://asert.arbornetworks.com/2011/06/monitoring-world-ipv6-day/ is that a > lot of folks switched it on - and then switched it off again pretty damn > quick! Or ... folks switched it on and then it switched itself off again pretty damn fast when their hardware blew up. Either way would, though, match my experience. From jbates at brightok.net Wed Jun 8 15:11:14 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 08 Jun 2011 15:11:14 -0500 Subject: Cogent & HE In-Reply-To: <20110608200505.GD18302@gerbil.cluepon.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> Message-ID: <4DEFD762.7080407@brightok.net> On 6/8/2011 3:05 PM, Richard A Steenbergen wrote: > I'm not making a judgement call about the rightness or wrongness of the > strategy (and after all, it clearly hasn't been THAT big of an issue > considering that it has been this way for MANY months), but to attempt > to "blame" one party for this issue is the height of absurdity. PR > stunts and cake baking not withstanding, they're both equally complicit. +1 Also looks like Level3 still hasn't peered with HE, though they have fixed their peering to google at least. Jack From paul at paulstewart.org Wed Jun 8 15:16:15 2011 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 8 Jun 2011 16:16:15 -0400 Subject: Cogent & HE In-Reply-To: <20110608200505.GD18302@gerbil.cluepon.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> Message-ID: <003401cc2618$ef26a6a0$cd73f3e0$@org> Agree 100% - to make it simple and they can both achieve this "IPv6 Tier1 Status" why don't they just peer and then it's win/win. I know I'm oversimplifying it but nobody is winning in my opinion today. The "peeing contest" could probably be settled in a short period of time and move on. My two cents worth... -p -----Original Message----- From: Richard A Steenbergen [mailto:ras at e-gerbil.net] Sent: June-08-11 4:05 PM To: Brielle Bruns Cc: nanog at nanog.org Subject: Re: Cogent & HE On Wed, Jun 08, 2011 at 07:48:42PM +0000, Brielle Bruns wrote: > Has been going on for a long while now. HE even made a cake for > Cogent (IIRC), to no avail. > > But, this is not surprising. A lot of public/major peering issues > with v4 over the past few years has been cogent vs. someone else. When two networks are not able to reach each other like this, it usually requires the active willing participation of both parties to allow the situation to continue. In this case, HE is doing *PRECISELY* the same thing that Cogent is doing. They're refusing to purchase transit, and making the decision to intentionally not carry a full table or have global reachability, in the hopes that it will strengthen their strategic position for peering in the long term (i.e. they both want to be an "IPv6 Tier 1"). I'm not making a judgement call about the rightness or wrongness of the strategy (and after all, it clearly hasn't been THAT big of an issue considering that it has been this way for MANY months), but to attempt to "blame" one party for this issue is the height of absurdity. PR stunts and cake baking not withstanding, they're both equally complicit. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jared at puck.nether.net Wed Jun 8 15:17:45 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 8 Jun 2011 16:17:45 -0400 Subject: Cogent & HE In-Reply-To: <20110608201027.GC19328@sizone.org> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110608201027.GC19328@sizone.org> Message-ID: On Jun 8, 2011, at 4:10 PM, Ken Chase wrote: > So we have to buy from BOTH HE and Cogent?! Sounds like market fixing to me! :/ > > Guess if we do we can advertise that on our webpage... "now with BOTH halves > of the ipv6 internets!" Or neither. There are other networks that carry a full IPv6 table. If you are behind 174 or 6939 for IPv6 and have other transits, make sure you can use those ports as well for your IPv6 activities, even if you're just doing an internal trial. - Jared From paul at paulstewart.org Wed Jun 8 15:19:39 2011 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 8 Jun 2011 16:19:39 -0400 Subject: Cogent & HE In-Reply-To: <20110608201027.GC19328@sizone.org> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110608201027.GC19328@sizone.org> Message-ID: <003501cc2619$7a1a8ce0$6e4fa6a0$@org> Or peer with HE and buy transit from Cogent (or someone on Cogent's friendly list) - this is where I think their strategy is going to go after a while with a lot of folks (if they have the option - that's the key). HE will peer with anyone I believe - Cogent has much more stringent "tier1" rules on peering. -p -----Original Message----- From: Ken Chase [mailto:ken at sizone.org] Sent: June-08-11 4:10 PM To: nanog at nanog.org Subject: Re: Cogent & HE On Wed, Jun 08, 2011 at 03:05:05PM -0500, Richard A Steenbergen said: >global reachability, in the hopes that it will strengthen their >strategic position for peering in the long term (i.e. they both want to >be an "IPv6 Tier 1"). > >I'm not making a judgement call about the rightness or wrongness of the >strategy (and after all, it clearly hasn't been THAT big of an issue >considering that it has been this way for MANY months), but to attempt >to "blame" one party for this issue is the height of absurdity. PR >stunts and cake baking not withstanding, they're both equally complicit. So we have to buy from BOTH HE and Cogent?! Sounds like market fixing to me! :/ Guess if we do we can advertise that on our webpage... "now with BOTH halves of the ipv6 internets!" /kc -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From jbates at brightok.net Wed Jun 8 15:27:28 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 08 Jun 2011 15:27:28 -0500 Subject: Cogent & HE In-Reply-To: <20110608201027.GC19328@sizone.org> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110608201027.GC19328@sizone.org> Message-ID: <4DEFDB30.7070604@brightok.net> On 6/8/2011 3:10 PM, Ken Chase wrote: > So we have to buy from BOTH HE and Cogent?! Sounds like market fixing to me! :/ > > Guess if we do we can advertise that on our webpage... "now with BOTH halves > of the ipv6 internets!" > No, you buy from the provider who doesn't get in disputes and peers with both of them. :) Jack From alvarezp at alvarezp.ods.org Wed Jun 8 15:34:48 2011 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Wed, 08 Jun 2011 13:34:48 -0700 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: <4DEF40C8.3020502@unfix.org> References: <4DEF40C8.3020502@unfix.org> Message-ID: On Wed, 08 Jun 2011 02:28:40 -0700, Jeroen Massar wrote: > It is really nice that folks where able to put AAAA records on their > websites for only 24 hours, but they forgot to put in the glue on their > nameservers. > > As such, for the folks testing IPv6-only, a lot of sites will fail > unless they use a recursor that does the IPv4 for them. In fact. Although a website of mine worked flawlessly in a dual-stack but it did NOT in an IPv6-only environment. Unfortunately, the problem has to be fixed in the DNS provider, which though supporting AAAA records was enough to "support IPv6". dig -6 +trace is our friend here. -- Octavio. From jay.hanke at mankatonetworks.com Wed Jun 8 15:47:09 2011 From: jay.hanke at mankatonetworks.com (Jay Hanke) Date: Wed, 8 Jun 2011 15:47:09 -0500 Subject: Cogent & HE In-Reply-To: <003501cc2619$7a1a8ce0$6e4fa6a0$@org> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110608201027.GC19328@sizone.org> <003501cc2619$7a1a8ce0$6e4fa6a0$@org> Message-ID: On Wed, Jun 8, 2011 at 3:19 PM, Paul Stewart wrote: > Or peer with HE and buy transit from Cogent (or someone on Cogent's friendly > list) - this is where I think their strategy is going to go after a while > with a lot of folks (if they have the option - that's the key). ?HE will > peer with anyone I believe - Cogent has much more stringent "tier1" rules on > peering. How divided is the table? I see about 98 routes transiting Cogent ASN via a HE connection. Customer has only has HE as v6 upstream. An previous post listed about a 1300 prefix difference. That's pretty significant unless it's due to aggregation or something. I'd also be interested to see the size of the other major carriers v6 tables so I can patch a whole until the other upstream is ready. Jay From hank at efes.iucc.ac.il Wed Jun 8 15:47:11 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 8 Jun 2011 23:47:11 +0300 (IDT) Subject: Youtube? Message-ID: I am having issues with Youtube getting stuck in i2.ytimg.com - the page comes up, a black box for the video but then hangs on i1 or i2.ytimg.com on in Firefox - not IE). IPv6 related? I have tried via 2 different ISPs and all show the same black box. -Hank From dr at cluenet.de Wed Jun 8 15:58:48 2011 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 8 Jun 2011 22:58:48 +0200 Subject: IPv6 day fun is beginning! In-Reply-To: References: Message-ID: <20110608205848.GB31133@srv03.cluenet.de> On Wed, Jun 08, 2011 at 03:48:52PM -0400, Joly MacFie wrote: > What seems evident, looking at > http://asert.arbornetworks.com/2011/06/monitoring-world-ipv6-day/ is that a > lot of folks switched it on - and then switched it off again pretty damn > quick! I'd attribute that spike to "people actively testing around for all those participants actually working". It was 2am +/- in the night in central europe (which has probably the biggest IPv6 enabled eyeball population)... what do you expect? Those who stayed up that late (I didn't) probably poked around at a few sites, noticed nothing's blowing up in gross colors, and went to bed. :-) I'm not surprised at all about the pattern. I would have expected higher amplitudes though, but given that major sites seem to deliver only index.html via IPv6, not much of a surprise there as well. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jra at baylink.com Wed Jun 8 15:53:17 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 8 Jun 2011 16:53:17 -0400 (EDT) Subject: Be aware of SLAAC adresses In-Reply-To: Message-ID: <36412.180.1307566397426.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "J?r?me Nicolle" > Second, it's beeing a little too transparent as the MAC adress may > reveal the server's manufacturer, approximate manufacturing tdate, or > the network controler model. Some may use it as a clue to design a > proper exploit... Security by obscurity isn't *bad*, it's just one small component of a Defense in Depth, still worth using if you can. Necessary, but not sufficient. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From joelja at bogus.com Wed Jun 8 04:09:27 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 8 Jun 2011 02:09:27 -0700 Subject: IPv6 day fun is beginning! In-Reply-To: <28102750.144.1307493162523.JavaMail.root@benjamin.baylink.com> References: <28102750.144.1307493162523.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 7, 2011, at 5:32 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Matt Ryanczak" > >> Indeed. Verizon LTE is v6 enabled but the user-agent on my phone >> denies me an IPv6 experience. > > I thought I'd heard that LTE transport was *IPv6 only*... you may have but it's wrong. lte supports ipv4 ipv6 and dual stack contexts. > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > From paul at paulstewart.org Wed Jun 8 16:23:18 2011 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 8 Jun 2011 17:23:18 -0400 Subject: Cogent & HE In-Reply-To: References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110608201027.GC19328@sizone.org> <003501cc2619$7a1a8ce0$6e4fa6a0$@org> Message-ID: <006b01cc2622$4d61a450$e824ecf0$@org> For what it's worth, we have a number of IPv6 peers in place plus IPv6 transit from Level(3), HE, and TiNet. For downstream customers, we are currently exporting them 6250 prefixes on IPv6. >From TiNet we are getting 6168 prefixes >From Level(3) we are getting 4933 prefixes >From HE we are getting 5990 prefixes Hope this helps a bit ;) -p -----Original Message----- From: jayhanke at gmail.com [mailto:jayhanke at gmail.com] On Behalf Of Jay Hanke Sent: June-08-11 4:47 PM To: Paul Stewart Cc: Ken Chase; nanog at nanog.org Subject: Re: Cogent & HE On Wed, Jun 8, 2011 at 3:19 PM, Paul Stewart wrote: > Or peer with HE and buy transit from Cogent (or someone on Cogent's friendly > list) - this is where I think their strategy is going to go after a while > with a lot of folks (if they have the option - that's the key). ?HE will > peer with anyone I believe - Cogent has much more stringent "tier1" rules on > peering. How divided is the table? I see about 98 routes transiting Cogent ASN via a HE connection. Customer has only has HE as v6 upstream. An previous post listed about a 1300 prefix difference. That's pretty significant unless it's due to aggregation or something. I'd also be interested to see the size of the other major carriers v6 tables so I can patch a whole until the other upstream is ready. Jay From marka at isc.org Wed Jun 8 17:05:18 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Jun 2011 08:05:18 +1000 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: Your message of "Wed, 08 Jun 2011 10:40:56 -0400." <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> Message-ID: <20110608220518.426791082F53@drugs.dv.isc.org> In message <24415722.168.1307544055966.JavaMail.root at benjamin.baylink.com>, Jay Ashworth writes: > It certainly sounds like it might be. > > Cheers, > -- jra I would do perhaps do one more then do "IPv6 TURN ON DAY" with the intent to *leave* the IPv6 enabled. The longer the content providers take to switch it on the bigger the switch on load will be. We still have a opportunity to ramp up IPv6 for the very big content providers. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From patrick at ianai.net Wed Jun 8 17:18:56 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 8 Jun 2011 18:18:56 -0400 Subject: IPv6 day non-participants In-Reply-To: References: <001201cc25f9$82a72be0$87f583a0$@com> Message-ID: On Jun 8, 2011, at 12:49 PM, George B. wrote: > Was participating until we hit a rather nasty load balancer bug that > took out the entire unit if clients with a short MTU connected and it > needed to fragment packets (Citrix Netscaler running latest code). No > fix is available for it yet, so we had to shut it down. Ran for about > 9 hours before the "magic" client that blew it up connected. > > So if you are using a Netscaler with SLB-PT (IPv6 VIP balancing to > IPv4 servers), the entire LB is subject to stop working until they get > this fixed. And this is EXACTLY why we needed World IPv6 Day. Thank you for participating. -- TTFN, patrick From davei at otd.com Wed Jun 8 17:24:41 2011 From: davei at otd.com (David Israel) Date: Wed, 08 Jun 2011 18:24:41 -0400 Subject: IPv6 day non-participants In-Reply-To: References: <001201cc25f9$82a72be0$87f583a0$@com> Message-ID: <4DEFF6A9.3040100@otd.com> On 6/8/2011 6:18 PM, Patrick W. Gilmore wrote: > On Jun 8, 2011, at 12:49 PM, George B. wrote: > >> Was participating until we hit a rather nasty load balancer bug that >> took out the entire unit if clients with a short MTU connected and it >> needed to fragment packets (Citrix Netscaler running latest code). No >> fix is available for it yet, so we had to shut it down. Ran for about >> 9 hours before the "magic" client that blew it up connected. >> >> So if you are using a Netscaler with SLB-PT (IPv6 VIP balancing to >> IPv4 servers), the entire LB is subject to stop working until they get >> this fixed. > And this is EXACTLY why we needed World IPv6 Day. It is also probably why doing it again next month is too aggressive, and why we probably should have started doing them earlier. I wonder how many bug reports got filed today? -Dave From jra at baylink.com Wed Jun 8 17:18:46 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 8 Jun 2011 18:18:46 -0400 (EDT) Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <20110608220518.426791082F53@drugs.dv.isc.org> Message-ID: <13265444.192.1307571526628.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" > > It certainly sounds like it might be. > > I would do perhaps do one more then do "IPv6 TURN ON DAY" with the > intent to *leave* the IPv6 enabled. The longer the content providers > take to switch it on the bigger the switch on load will be. We > still have a opportunity to ramp up IPv6 for the very big content > providers. I dunno; I can see why doing it in 24 hours chunks is useful, still. But I think that doing them substantially more frequently than annually increases markedly the chance that the people who Learned the Lessons will still be there to *implement*. And the responses so far suggest that this interim step might be a Pretty Neat Idea. Cheers, -- jr 'shame Towel Day has passed already' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From fredan-nanog at fredan.se Wed Jun 8 17:31:32 2011 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Thu, 9 Jun 2011 00:31:32 +0200 Subject: World IPv6 Only Day. Message-ID: <201106090031.32321.fredan-nanog@fredan.se> How about that one? (Please reply to the mailing list only) -- //fredan From patrick at ianai.net Wed Jun 8 17:39:02 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 8 Jun 2011 18:39:02 -0400 Subject: Cogent & HE In-Reply-To: <20110608200505.GD18302@gerbil.cluepon.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> Message-ID: On Jun 8, 2011, at 4:05 PM, Richard A Steenbergen wrote: > On Wed, Jun 08, 2011 at 07:48:42PM +0000, Brielle Bruns wrote: >> Has been going on for a long while now. HE even made a cake for >> Cogent (IIRC), to no avail. >> >> But, this is not surprising. A lot of public/major peering issues >> with v4 over the past few years has been cogent vs. someone else. > > When two networks are not able to reach each other like this, it usually > requires the active willing participation of both parties to allow the > situation to continue. In this case, HE is doing *PRECISELY* the same > thing that Cogent is doing. You are incorrect. Yes, both refuse to buy transit, yes. But HE is able, willing, and even begging to peer; Cogent is not. These are not "the same thing". Also, Cogent does not peer with Google either last time I checked. There may be others for all I know. (I don't buy transit from Cogent.) These are not the only two networks on the v6 Internet who are bifurcated. There are some in Europe I know of (e.g. Telecom Italia refuses to buy v6 transit and refuses to peer with some networks), and probably others. The v6 'Net is _not_ ready for prime time, and won't be until there is a financial incentive to stop the stupidity & ego stroking. The Internet is a business. Vote with your wallet. I prefer to buy from people who do things that are in MY best interest. Giving money to Cogent will not put pressure on them peer with HE & Google & everyone else - just the opposite. On the flip side, HE is an open peer, even to their own customers, and _gives away_ free v6 transit. Taking their free transit & complaining that they do not buy capacity to Cogent seems more than silly. Plus, they are doing that I think is in my best interest as a customer - open peering. Trying to make them the bad guy here seems counter intuitive. -- TTFN, patrick > They're refusing to purchase transit, and > making the decision to intentionally not carry a full table or have > global reachability, in the hopes that it will strengthen their > strategic position for peering in the long term (i.e. they both want to > be an "IPv6 Tier 1"). > > I'm not making a judgement call about the rightness or wrongness of the > strategy (and after all, it clearly hasn't been THAT big of an issue > considering that it has been this way for MANY months), but to attempt > to "blame" one party for this issue is the height of absurdity. PR > stunts and cake baking not withstanding, they're both equally complicit. > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > From jeffw at he.net Wed Jun 8 17:44:52 2011 From: jeffw at he.net (Jeff Walter) Date: Wed, 08 Jun 2011 15:44:52 -0700 Subject: World IPv6 Only Day. In-Reply-To: <201106090031.32321.fredan-nanog@fredan.se> References: <201106090031.32321.fredan-nanog@fredan.se> Message-ID: <4DEFFB64.2090105@he.net> On 6/8/2011 3:31 PM, fredrik danerklint wrote: > How about that one? > > (Please reply to the mailing list only) You wouldn't be posting to the list... :-) Received: from [77.105.232.43] (port=53699 helo=fredan-pc.localnet) by mail.fredan.se with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.71) (envelope-from) id 1QURHg-0004ZJ-4d for nanog at nanog.org; Thu, 09 Jun 2011 00:31:32 +0200 -------------- next part -------------- A non-text attachment was scrubbed... Name: jeffw.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From ras at e-gerbil.net Wed Jun 8 18:05:17 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 8 Jun 2011 18:05:17 -0500 Subject: Cogent & HE In-Reply-To: References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> Message-ID: <20110608230517.GL18302@gerbil.cluepon.net> On Wed, Jun 08, 2011 at 06:39:02PM -0400, Patrick W. Gilmore wrote: > > Yes, both refuse to buy transit, yes. But HE is able, willing, and > even begging to peer; Cogent is not. These are not "the same thing". I'm ready, willing, and lets say for the purposes of this discussion begging to peer with every Tier 1, but some of them aren't willing to peer with me. Does that mean I should stop buying transit and blame them for my resulting lack of global reachability? If I could convince my customers to accept that line of bullshit it would certainly reduce my transit costs, but I have a sneaking suspicion they wouldn't. :) Ultimately it is the responsibility of everyone who connects to the Internet to make sure they are, you know, actually connected to the Internet. Choosing not to do so and then throwing up your hands and saying "oh I can't help it, they won't peer with me" is not a valid excuse, at least not in my book or the book of anyone who pays me money to deliver their packets. And this isn't even a case of not being ABLE to buy sufficient capacity via a transit path (ala Comcast), this is just two networks who have mutually decided two remain partitioned from each other in the pursuit of long term strategic advantage. Ultimately both parties share responsibility for this issue, and you can't escape that just because you have a tube of icing and some spare time. :) > These are not the only two networks on the v6 Internet who are > bifurcated. There are some in Europe I know of (e.g. Telecom Italia > refuses to buy v6 transit and refuses to peer with some networks), and > probably others. The v6 'Net is _not_ ready for prime time, and won't > be until there is a financial incentive to stop the stupidity & ego > stroking. > > The Internet is a business. Vote with your wallet. I prefer to buy > from people who do things that are in MY best interest. Giving money > to Cogent will not put pressure on them peer with HE & Google & > everyone else - just the opposite. Absolutely. This is just like any other IPv4 peering dispute, the only difference is IPv6 is so unimportant in the grand scheme of the Internet that there hasn't been enough external pressure from customers on either side to force a settlement. Shockingly, HE manages to buy plenty of IPv4 transit to reach Cogent and many other networks, no doubt because they wouldn't have any (paying) customers if they didn't. :) > On the flip side, HE is an open peer, even to their own customers, and > _gives away_ free v6 transit. Taking their free transit & complaining > that they do not buy capacity to Cogent seems more than silly. Plus, > they are doing that I think is in my best interest as a customer - > open peering. Trying to make them the bad guy here seems counter > intuitive. I know you're not naive enough to think that HE is giving away free IPv6 transit purely out of the kindness of their heart. They're doing it to bulk up their IPv6 customer base, so they can compete with larger networks like Cogent, and make a play for Tier 1-dom in exactly the same way that Cogent has done with IPv4. And more power to them for it, it may well be a smart long term strategic move on their part, but with every wannabe Tier 1 network comes partitioning and peering disputes, as they try to trade short term customer pain for long term advantages. Sorry to all the HE guys, but trying to simultaniously complain about your treatment at the hands of other networks and their peering disputes while emulating their actions is bullshit and you know it. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From fredan-nanog at fredan.se Wed Jun 8 18:08:26 2011 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Thu, 9 Jun 2011 01:08:26 +0200 Subject: World IPv6 Only Day. In-Reply-To: <4DEFFB64.2090105@he.net> References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> Message-ID: <201106090108.27224.fredan-nanog@fredan.se> Well, that's another problem. To make a long story short, the network (not mine and I don't have any kind of control over that either) that my customers (including me) are using, did put in new equipment (a switch) over a year ago and after that I lost my IPv6 connection that I had previously. That switch does not support IPv6 it turns out. This is exactly the things that the customers really need to better understand and why it's not gonna work for them. You did miss a thing: $ dig mx fredan.se ;; ANSWER SECTION: fredan.se. 3597 IN MX 10 mail.fredan.se. ;; ADDITIONAL SECTION: mail.fredan.se. 3597 IN A 77.105.235.102 mail.fredan.se. 3597 IN AAAA 2001:4db8:e001:ffff:2::17 So I do have a IPv6 connection but not to my customers. > > How about that one? > > > > (Please reply to the mailing list only) > > You wouldn't be posting to the list... :-) > > Received: from [77.105.232.43] (port=53699 helo=fredan-pc.localnet) > by mail.fredan.se with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) > (Exim 4.71) (envelope-from) > id 1QURHg-0004ZJ-4d > for nanog at nanog.org; Thu, 09 Jun 2011 00:31:32 +0200 -- //fredan From vinny at abellohome.net Wed Jun 8 18:13:24 2011 From: vinny at abellohome.net (Vinny Abello) Date: Wed, 08 Jun 2011 19:13:24 -0400 Subject: =?UTF-8?Q?Hotmail=3F?= In-Reply-To: <000601cc259c$d5b64580$8122d080$@arkitechs.com> References: "" <000601cc259c$d5b64580$8122d080$@arkitechs.com> Message-ID: <76b270f386175d8d6768fd326c5ddb26@mail.abellohome.net> On Wed, 8 Jun 2011 01:27:57 -0400, Steve Spence wrote: > That what I found with most the open source /Linux mail products > that > customizing and extending can be difficult and a lot of time and > effort. > The exchange is one of the easiest ways to roll out large scale web > base > email if just expensive in upfront costs. > > Interns of Hotmail they initially use to use Solaris for the MTA > and > storage and FreeBSD for the web services ( Apache ) they suppose of > migrated > windows by now using windows products Again I think this highly > customize > solution which may not be very useful > http://en.wikipedia.org/wiki/Hotmail > > we went through a similar search for a high volume solution which > we could > customize and brand right now we using we high a hybrid of > (exchange/Icewarp/Atmail/ two layers of spam filtering ) As far as commercial packages go, Surgemail is worth a look. Very affordable and insanely powerful and customizable. The support team is the development team. It's not uncommon for bugs to be fixed in hours to day and even new features requests to be added in days to weeks. Runs on practically any major OS you prefer... -Vinny From ask at develooper.com Wed Jun 8 18:17:33 2011 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Wed, 8 Jun 2011 16:17:33 -0700 Subject: Cogent IPv6 In-Reply-To: <6ac5bc37$45ab67ae$73965090$@com> References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: On Jun 8, 2011, at 6:51, Nick Olsen wrote: > I'm sure someone here is doing IPv6 peering with cogent. We've got a Gig > with them, So they don't do that dual peering thing with us. (They do it on > another 100Mb/s circuit we have... I despise it.) > Just kind of curious how they go about it. > Do they issue you a small IPv6 block for your interface, just like they do > for IPv4? Is it a separate session? Like Mark described, for us too they dropped the goofy dual-session thing for IPv4 so we just have an IPv4 and an IPv6 session now. > Any things to be aware of before pulling the trigger on it? (Other then them not having connectivity to HE's IPv6 side of things, Wish they would fix that already...) Yeah, there's that ... (We have a couple other providers, too, so we don't really care but it's goofy). Worse, for us, is that their router doesn't respond to neighbor discovery requests, so I had to make a static neighbor entry on our router for the session to come up. Not very pretty. I spent more than an hour on the phone with them and they didn't have any ideas (we have plenty other IPv6 sessions for transit and peering on the same router that are working fine). Somewhere on the internets someone anecdotally told they had a Cisco router that did the same thing until it was rebooted. Didn't bother calling them to tell them to reboot the router we are on. :-) Anyway, I guess the lesson is that they (like most providers, I am sure) don't have that much IPv6 experience and they didn't care that much that it didn't work right. Hopefully that attitude will change over the next months. - ask From jmamodio at gmail.com Wed Jun 8 18:31:52 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 8 Jun 2011 18:31:52 -0500 Subject: IPv6 day non-participants In-Reply-To: References: <001201cc25f9$82a72be0$87f583a0$@com> Message-ID: >> So if you are using a Netscaler with SLB-PT (IPv6 VIP balancing to >> IPv4 servers), the entire LB is subject to stop working until they get >> this fixed. > > And this is EXACTLY why we needed World IPv6 Day. Agreed, right on the money !! Traffic stats may not say a lot yet due to tunnels and lack of native IPv6 connectivity but finding this type of bugs is a major reason to do live tests, even if the test fails. Next one ? a month seems to be too soon, I guess there is a lot of useful data to crunch and analyze and fixes to do, but sure we need more live IPv6 activity. I think it would be cool if for the next one, some major broadband access providers take IPv6 down to the end customer, and not just commercial customers. I know that CPE could be an issue but we need to reach that layer. It does not help that the test says that my machine and browser are ready when in the middle I've a brick that won't work.. Cheers Jorge From bzeeb-lists at lists.zabbadoz.net Wed Jun 8 19:11:45 2011 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu, 9 Jun 2011 00:11:45 +0000 Subject: FreeBSD is initiating IPv6-only validation work [IPv6-only Systems] In-Reply-To: References: Message-ID: <325C6E55-573B-4F7E-9996-08DABDB53F4B@lists.zabbadoz.net> On Jun 6, 2011, at 4:14 PM, Cameron Byrne wrote: Hi, I wrote that reply the hour your email came in, but didn't want to send this out earlier to not distract people too much. > FreeBSD is initiating IPv6-only validation work I think that's a less scary topic to some readers so I put it into subject. I hope you don't mind. > http://www.prweb.com/releases/2011/6/prweb8529718.htm > > My own testing of the Windows 7 shows that, at it's core, it works > well as IPv6-only for most "web & email" functions. Layering on > applications like Skype, things start to fall apart. Well, that really depends on what you are doing and targeting. I have seen plugins crash a browser if there was no IPv4 anymore, I have seen timekeeping software to log me an error every few minutes, I have seen "v6ready certified" multifunction devices to force me to pretend to print before being able to scan, I have seen content scanners falling over, network monitoring tools, web servers not being ready, yadda yadda yadda. I have seen a lot of confusing error messages when v4 was tried after v6 and that hid the actual error messages making debugging a hell. As an open source person, for example, I could imagine to see every out of the almost 300k open source projects sf.net is hosting and which do networking to eventually just work .. well say the more common ones of them. I'd love to see soooo much perl stuff to just work with IPv6, I'd love software updates of my backup software, that worked well without IPv4, not to break because the new major version *oops* is still missing parts of the IPv6 code, jdk to not trouble anymore, .... It's the software that runs in enterprises, SMBs, at ISPs, that is used with the little tools that if failing put you into blind flying and ruin your week, ... I have spent some good time the last 6 months chasing some of these things and not unsurprisingly some other things worked fairly great out of the box. But I also have a list of things to fix still and I am sure we'll find more the more people are actually looking. Note well -- this is different to "just no IPv4 address" which still allows you to still do certain things on AF_INET sockets. This is returning "Protocol not supported" in that case instead and that really triggers another series of problems. Also note well that all these things worked in dual-stack (almost) flawlessly and we don't want to motivate end users to go IPv6-only at this point (the much fun it would be;). It's you people who'll force them to eventually. It's embedded folks that want it already in addition to your mobile world. Once you stop targeting the top-100 websites and what your parents or children do and forget about that single voice/chat/file sharing program, but look at things that run the world these days it's getting more interesting;-) I am sure we'll get there, as we are trying to get users and content onto dual-stack currently, but I don't want us to be there in only another 15 years. Thus starting early, as you and others have done, is the key. Given the huge number of FreeBSD based things that ``run the Internet'', and unsurprisingly end users, I hope that it'll help the commercial vendors, protocol developers, app writers, QA, ... as well to have their or rather your gear, the daemons, upper layer protocols, etc. working flawlessly w/o legacy-IP for when the time comes that others want to reduce mgmt costs and complexity and be able to say "no inet4" as well. This is the beginning of the journey, and we'll hopefully continue to head straight into the direction of "done, just works" to be able to tick that checkbox off soon;) Regards, Bjoern -- A lot of the this June 8th World IPv6 Day verbiage was about picking the right color, not so much for the bikeshed of finally putting IPv6 into use, but it was hopefully a redpill day for some bluepill people. /bz From georgeb at gmail.com Wed Jun 8 19:16:09 2011 From: georgeb at gmail.com (George B.) Date: Wed, 8 Jun 2011 17:16:09 -0700 Subject: IPv6 day non-participants In-Reply-To: References: <001201cc25f9$82a72be0$87f583a0$@com> Message-ID: On Wed, Jun 8, 2011 at 4:31 PM, Jorge Amodio wrote: >>> So if you are using a Netscaler with SLB-PT (IPv6 VIP balancing to >>> IPv4 servers), the entire LB is subject to stop working until they get >>> this fixed. >> >> And this is EXACTLY why we needed World IPv6 Day. > > Agreed, right on the money !! > > Traffic stats may not say a lot yet due to tunnels and lack of native > IPv6 connectivity but finding this type of bugs is a major reason to > do live tests, even if the test fails. Well, we are still attempting to recreate the problem. It isn't something as simple as someone coming in over a tunnel with a small MTU with a larger advertised MSS. There is some "magic" that must happen to actually put the unit in this state. We ran for 9 hours before and 9 hours after the hiccup without any problems. So it is going to take a while before we are ready to test this again live. The sooner I can recreate the problem, the better, though. From packetgrrl at gmail.com Wed Jun 8 19:34:00 2011 From: packetgrrl at gmail.com (cja@daydream.com) Date: Wed, 8 Jun 2011 18:34:00 -0600 Subject: IPv6 day fun is beginning! In-Reply-To: References: <28102750.144.1307493162523.JavaMail.root@benjamin.baylink.com> Message-ID: > > Leslie Daigle and Vint Cerf are on the News Hour tonight about World IPv6 > Day. Watch it if you get a chance. They did a great job! > ----CJ From patrick at ianai.net Wed Jun 8 19:41:54 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 8 Jun 2011 20:41:54 -0400 Subject: Cogent & HE In-Reply-To: <20110608230517.GL18302@gerbil.cluepon.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110608230517.GL18302@gerbil.cluepon.net> Message-ID: <92CE4876-C6DB-4C9B-81FF-2F68FEC94306@ianai.net> On Jun 8, 2011, at 7:05 PM, Richard A Steenbergen wrote: > On Wed, Jun 08, 2011 at 06:39:02PM -0400, Patrick W. Gilmore wrote: >> >> Yes, both refuse to buy transit, yes. But HE is able, willing, and >> even begging to peer; Cogent is not. These are not "the same thing". > > I'm ready, willing, and lets say for the purposes of this discussion > begging to peer with every Tier 1, but some of them aren't willing to > peer with me. Does that mean I should stop buying transit and blame them > for my resulting lack of global reachability? If I could convince my > customers to accept that line of bullshit it would certainly reduce my > transit costs, but I have a sneaking suspicion they wouldn't. :) Your statement and mine are not in contradiction. I did not say anywhere that HE was perfect, only that they are not the same thing. I stand by what I said. You care to argue the point? Also, HE is _giving away_ v6 transit. You don't like it, stop paying your bill. :) Put another way, you don't like how both are acting, then don't buy from either. Why not just peer with both. Oh, wait, that's right, you can't peer with Cogent, but HE is happy to bring up sessions for the cost of a single e-mail, and dump (their version of) full v6 routes to you. Yeah, Richard, totally the same thing.... > Ultimately it is the responsibility of everyone who connects to the > Internet to make sure they are, you know, actually connected to the > Internet. Choosing not to do so and then throwing up your hands and > saying "oh I can't help it, they won't peer with me" is not a valid > excuse, at least not in my book or the book of anyone who pays me money > to deliver their packets. And this isn't even a case of not being ABLE > to buy sufficient capacity via a transit path (ala Comcast), this is > just two networks who have mutually decided two remain partitioned from > each other in the pursuit of long term strategic advantage. Ultimately > both parties share responsibility for this issue, and you can't escape > that just because you have a tube of icing and some spare time. :) Things are a bit more complex than that. You can't simply say "if someone won't peer with you, you must buy transit". Otherwise, Cogent would be the only tier one left, since they care about their customers less than anyone else. This is not good for me or the Internet, and I refuse to support it. >> On the flip side, HE is an open peer, even to their own customers, and >> _gives away_ free v6 transit. Taking their free transit & complaining >> that they do not buy capacity to Cogent seems more than silly. Plus, >> they are doing that I think is in my best interest as a customer - >> open peering. Trying to make them the bad guy here seems counter >> intuitive. > > I know you're not naive enough to think that HE is giving away free IPv6 > transit purely out of the kindness of their heart. They're doing it to > bulk up their IPv6 customer base, so they can compete with larger > networks like Cogent, and make a play for Tier 1-dom in exactly the same > way that Cogent has done with IPv4. And more power to them for it, it > may well be a smart long term strategic move on their part, but with > every wannabe Tier 1 network comes partitioning and peering disputes, as > they try to trade short term customer pain for long term advantages. Of course. The question is not: "Is $COMPANY acting in $COMPANY's best interest?" The answer to that is: Duh. The question is: "Which $COMPANY's best interests more closely align with mine?" If you have the slightest doubt here, you are highly confused. > Sorry to all the HE guys, but trying to simultaniously complain about > your treatment at the hands of other networks and their peering disputes > while emulating their actions is bullshit and you know it. :) We disagree. See the first paragraph in this post, HE is not emulating Cogent, Telecom Italia, etc. You are bitching about both HE & Cogent. If I were paying either for v6 transit, I would bitch too. But I am not paying HE - no one is! - and they _are_ doing things differently than Cogent. So why not support the one whose long term interests both best fit mine and the Internet's? (Plus, to be honest, I have a lot more faith in Mike & Martin to continue doing what's best for me & the Internet than Dave. And by "a lot more", I mean something on the order of "more than 50%" vs. "less than 0.01%".) -- TTFN, patrick From victor.kuarsingh at gmail.com Wed Jun 8 19:44:53 2011 From: victor.kuarsingh at gmail.com (Victor Kuarsingh) Date: Wed, 8 Jun 2011 20:44:53 -0400 Subject: IPv6 day fun is beginning! In-Reply-To: References: <28102750.144.1307493162523.JavaMail.root@benjamin.baylink.com> Message-ID: <7FAC1AC3-7786-47F1-8986-2CF843924D6A@gmail.com> Sent from my iPad On 2011-06-08, at 5:09 AM, Joel Jaeggli wrote: > > On Jun 7, 2011, at 5:32 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Matt Ryanczak" >> >>> Indeed. Verizon LTE is v6 enabled but the user-agent on my phone >>> denies me an IPv6 experience. >> >> I thought I'd heard that LTE transport was *IPv6 only*... > > you may have but it's wrong. lte supports ipv4 ipv6 and dual stack contexts. > Correct. The bearer service (connection perceived by user) can be IPv4-only, IPv6-only or dual stack for LTE (more correctly - the Evolved Packet System). The actual transport (mobile nodes talking to each other conducting signaling and tunneling customer traffic) can be IPv4 and/or IPv6. Regards, Victor K >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink jra at baylink.com >> Designer The Things I Think RFC 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII >> St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 >> > > From owen at delong.com Wed Jun 8 19:51:38 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jun 2011 17:51:38 -0700 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: <676F2443-83EC-4626-BA50-9225C3E26A32@delong.com> On Jun 8, 2011, at 7:18 AM, ryan at u13.net wrote: > On Wed, 8 Jun 2011 09:51:21 -0400, Nick Olsen wrote: > >> I'm sure someone here is doing IPv6 peering with cogent. We've got a Gig >> >> with them, So they don't do that dual peering thing with us. (They do it >> on >> another 100Mb/s circuit we have... I despise it.) >> Just kind of curious how they go about it. >> Do they issue you a small IPv6 block for your interface, just like they >> do >> for IPv4? Is it a separate session? Any things to be aware of before >> pulling the trigger on it? (Other then them not having connectivity to >> HE's >> IPv6 side of things, Wish they would fix that already...) >> >> Nick Olsen >> Network Operations (855) FLSPEED x106 > > We have separate v4 and v6 sessions with them on the same dual-stack interface (a v4 /29 and v6 /112 on the interface). One session is between our v4 address and theirs, and carries v4 prefixes only. Then another session between v6 addresses that carries v6 prefixes only. That's really the best way to do dual stack peering anyway. Keeps things much cleaner. Owen From sshafi at gmail.com Wed Jun 8 20:09:46 2011 From: sshafi at gmail.com (Shahid Shafi) Date: Wed, 8 Jun 2011 18:09:46 -0700 Subject: IPv6 day non-participants In-Reply-To: References: <001201cc25f9$82a72be0$87f583a0$@com> Message-ID: I dont think ISOC dashboard is updating any more. Google is no longer advertising AAAA but dashboard still shows green and TTLs were short on those records. \\ ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.google.com in AAAA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15535 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN AAAA ;; ANSWER SECTION: www.google.com. 588628 IN CNAME www.l.google.com. ;; Query time: 191 msec ;; SERVER: 2620:0:ccc::2#53(2620:0:ccc::2) ;; WHEN: Wed Jun 8 18:08:38 2011 ;; MSG SIZE rcvd: 52 On Wed, Jun 8, 2011 at 5:16 PM, George B. wrote: > On Wed, Jun 8, 2011 at 4:31 PM, Jorge Amodio wrote: > >>> So if you are using a Netscaler with SLB-PT (IPv6 VIP balancing to > >>> IPv4 servers), the entire LB is subject to stop working until they get > >>> this fixed. > >> > >> And this is EXACTLY why we needed World IPv6 Day. > > > > Agreed, right on the money !! > > > > Traffic stats may not say a lot yet due to tunnels and lack of native > > IPv6 connectivity but finding this type of bugs is a major reason to > > do live tests, even if the test fails. > > Well, we are still attempting to recreate the problem. It isn't > something as simple as someone coming in over a tunnel with a small > MTU with a larger advertised MSS. There is some "magic" that must > happen to actually put the unit in this state. We ran for 9 hours > before and 9 hours after the hiccup without any problems. > > So it is going to take a while before we are ready to test this again > live. The sooner I can recreate the problem, the better, though. > > From kloch at kl.net Wed Jun 8 20:18:24 2011 From: kloch at kl.net (Kevin Loch) Date: Wed, 08 Jun 2011 21:18:24 -0400 Subject: Cogent & HE In-Reply-To: <20110608230517.GL18302@gerbil.cluepon.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110608230517.GL18302@gerbil.cluepon.net> Message-ID: <4DF01F60.7030206@kl.net> Richard A Steenbergen wrote: > On Wed, Jun 08, 2011 at 06:39:02PM -0400, Patrick W. Gilmore wrote: >> Yes, both refuse to buy transit, yes. But HE is able, willing, and >> even begging to peer; Cogent is not. These are not "the same thing". > > I'm ready, willing, and lets say for the purposes of this discussion > begging to peer with every Tier 1, but some of them aren't willing to > peer with me. Does that mean I should stop buying transit and blame them > for my resulting lack of global reachability? Do you have half the routing table as your customer base? - Kevin From jared at puck.nether.net Wed Jun 8 20:20:12 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 8 Jun 2011 21:20:12 -0400 Subject: Thank you Microsoft (and others) In-Reply-To: References: <001201cc25f9$82a72be0$87f583a0$@com> Message-ID: <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> I think it's important to thank Microsoft for leaving sites like xbox IPv6 enabled. Hope many other participants leave it on as well. I think it's a certain sign of the maturity of the protocol and networks at this stage of the game. I have observed some traffic step-down in the network, but it's not entirely clear if it's lowered to levels pre-v6-day. Looking forward to those sharing data at NANOG next week. (I'm not convinced the data I have is worth sharing, but will send it over to the nanogpc soon enough..) - Jared On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: > I dont think ISOC dashboard is updating any more. Google is no longer > advertising AAAA but dashboard still shows green and TTLs were short on > those records. From marka at isc.org Wed Jun 8 20:20:39 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Jun 2011 11:20:39 +1000 Subject: World of Warcraft may begin using IPv6 on Tuesday In-Reply-To: Your message of "Wed, 08 Jun 2011 13:18:35 -0400." References: <000001cc25c7$7e7c3290$7b7497b0$@iname.com> Message-ID: <20110609012039.57692108BD88@drugs.dv.isc.org> In message , Ray Soucy writes: > Just grabbed the Trial and tested it. > > Verified that IPv6 is used for World of Warcraft on the Antonidas > server. It works pretty well actually. > > I see they replicated their practice of dropping all ICMP traffic for > IPv6. Not sure that's the best idea. It's *never* been a good idea let alone a best idea however it was the only solution to a problem in the last millinium and really should only be deploy to protect those 20 year old boxes that still have that problem. Way to much of security so called "best practice" isn't and actually has deterimental effects that outweigh any benifits. Mark > Anyone know if they plan to leave it working now and possibly expand > it too all their servers? > > Ray > > On Wed, Jun 8, 2011 at 6:33 AM, Frank Bulk wrote: > > More here: http://ipv6.blizzard.com/ > > > > =A0 =A0 =A0 =A0To test IPv6 in World of Warcraft, you'll need to edit you= > r > > =A0 =A0 =A0 =A0config.wtf file and add the following line: > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SET unlockIPv6 "1" > > > > =A0 =A0 =A0 =A0This will activate the IPv6 features. If your computer has > > =A0 =A0 =A0 =A0a valid IPv6 address, you'll be able to check the "Enable > > =A0 =A0 =A0 =A0IPv6" checkbox from the Network options in the World of > > =A0 =A0 =A0 =A0Warcraft client. Once in the game, you'll be able to see > > =A0 =A0 =A0 =A0which type of connection the client has made to the realms > > =A0 =A0 =A0 =A0next to the latency information. > > > > Frank > > > > -----Original Message----- > > From: Kevin Day [mailto:toasty at dragondata.com] > > Sent: Saturday, April 23, 2011 1:10 PM > > To: NANOG list > > Subject: World of Warcraft may begin using IPv6 on Tuesday > > > > > > For those that don't know, World of Warcraft is currently the largest onl= > ine > > role playing game, with somewhere over 12 million subscribers. > > > > Version 4.1 of the game is expected to be released this Tuesday, which wi= > ll > > be automatically pushed to all clients. The current Beta version of 4.1 h= > as > > full IPv6 support. In the beta, it's automatically enabled if you have > > native IPv6 (non-6to4, non-Teredo). While Blizzard has been pretty silent > > about this, barring a last minute revert or delay of this patch, there ar= > e > > suddenly going to be a bunch more users that can potentially use IPv6. An= > d > > these users are the type who are going to be especially sensitive to > > latency, jitter and packet loss, since this is a real-time game platform. > > > > For those of you with Help Desks who have to support users like this, the > > associated setting in the game's Options menu is apparently called "Enabl= > e > > IPv6 when available". It's apparently grayed out if you do not have IPv6 = > at > > all, unchecked by default if you are on 6to4 or Teredo, and checked by > > default if you are on native v6. The tooltip says: "Enables the use of IP= > v6, > > the technology behind the next-generation Internet. Requires IPv6 > > connectivity to the internet. Checking this box without IPv6 connectivity > > may prevent you from playing WoW." > > > > Anyone from Activision/Blizzard who would like to chime in with more > > details? :) > > > > -- Kevin > > > > > > > > > > > > --=20 > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From patrick at ianai.net Wed Jun 8 20:22:55 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 8 Jun 2011 21:22:55 -0400 Subject: Cogent & HE In-Reply-To: <4DF01F60.7030206@kl.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110608230517.GL18302@gerbil.cluepon.net> <4DF01F60.7030206@kl.net> Message-ID: <916115CF-72AC-43DC-93AC-F65DA55E124E@ianai.net> On Jun 8, 2011, at 9:18 PM, Kevin Loch wrote: > Richard A Steenbergen wrote: >> On Wed, Jun 08, 2011 at 06:39:02PM -0400, Patrick W. Gilmore wrote: >>> Yes, both refuse to buy transit, yes. But HE is able, willing, and even begging to peer; Cogent is not. These are not "the same thing". >> I'm ready, willing, and lets say for the purposes of this discussion begging to peer with every Tier 1, but some of them aren't willing to peer with me. Does that mean I should stop buying transit and blame them for my resulting lack of global reachability? > > Do you have half the routing table as your customer base? No one does, most especially neither 174 nor 6369. (Although GBL3 will be able to make a good stab at it if they don't shed too many customers post-integration.) -- TTFN, patrick From jared at puck.nether.net Wed Jun 8 20:32:20 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 8 Jun 2011 21:32:20 -0400 Subject: Retraining "IT" on networking myths (the cloud to the rescue!) In-Reply-To: <20110609012039.57692108BD88@drugs.dv.isc.org> References: <000001cc25c7$7e7c3290$7b7497b0$@iname.com> <20110609012039.57692108BD88@drugs.dv.isc.org> Message-ID: On Jun 8, 2011, at 9:20 PM, Mark Andrews wrote: > It's *never* been a good idea let alone a best idea however it was > the only solution to a problem in the last millinium and really > should only be deploy to protect those 20 year old boxes that still > have that problem. > > Way to much of security so called "best practice" isn't and actually > has deterimental effects that outweigh any benifits. I'm not sure the best way to fix this as there's all these common misconceptions about technology out there. MYTHS: TCP/53 is only for zone transfers ICMP is a security risk/ddos avenue Internal networks must be secured with NAT A firewall is the only way to secure the perimiter In fact for IPv6, ICMP is more important vs less. Firewalls frequently harm and don't block data going out. TCP/53 is needed for EDNS. IPv6 doesn't have the concept of NAT, or at least not in the same way as people use 1918 space at home and in IT networks... I'm not sure the best way to deal with this. There's a lot of netadmins (perhaps myself included) that operate in a universe where they treat these items as fact, real and even on an audit-checklist. When it comes to enabling IPv6 on your NOC or corporate network, how will they respond? "Wait, they will have a globally routed IP address? How do I NAT that?" It does alter the environment of enforcing a security policy. Then again with all this "cloud" stuff (should that read return to mainframe processing days?), it may not matter as much since what you're securing will be "in the cloud", a remote location that has a pre-existing security policy that meets whatever your standards are (FIPS, FISMA, the auditors, etc..) - Jared From cb.list6 at gmail.com Wed Jun 8 20:37:55 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 8 Jun 2011 18:37:55 -0700 Subject: Thank you Microsoft (and others) In-Reply-To: <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> References: <001201cc25f9$82a72be0$87f583a0$@com> <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> Message-ID: Thanks to all the v6day participants on all sides of the net. This has been a great effort that will eventually be a precedent for all a major sites to go dual stack with confidence as bugs are shaken out, access networks are enabled, and meaningful data is collected and processed. Cb PS. Special thanks to isoc and the core group that stuck their neck out to make this happen. From ravi at cow.org Wed Jun 8 20:45:25 2011 From: ravi at cow.org (Ravi Pina) Date: Wed, 8 Jun 2011 21:45:25 -0400 Subject: Thank you Microsoft (and others) In-Reply-To: <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> References: <001201cc25f9$82a72be0$87f583a0$@com> <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> Message-ID: <20110609014525.GU71792@neu.cow.org> We (Mozilla) intend to keep the properties[1] we enabled online and will continue to roll out to our entire infrastructure as it permits. We hit some vendor issues which prevented us from having a larger showing, sadly. -r [1] http://www.mozilla.com/ http://www.mozilla.org/ http://wiki.mozilla.org/ https://addons.mozilla.org/ On Wed, Jun 08, 2011 at 09:20:12PM -0400, Jared Mauch wrote: > I think it's important to thank Microsoft for leaving sites like xbox IPv6 enabled. Hope many other participants leave it on as well. > > I think it's a certain sign of the maturity of the protocol and networks at this stage of the game. > > I have observed some traffic step-down in the network, but it's not entirely clear if it's lowered to levels pre-v6-day. > > Looking forward to those sharing data at NANOG next week. (I'm not convinced the data I have is worth sharing, but will send it over to the nanogpc soon enough..) > > - Jared > > On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: > > > I dont think ISOC dashboard is updating any more. Google is no longer > > advertising AAAA but dashboard still shows green and TTLs were short on > > those records. > From michael at rancid.berkeley.edu Wed Jun 8 20:54:34 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 08 Jun 2011 18:54:34 -0700 Subject: Retraining "IT" on networking myths (the cloud to the rescue!) In-Reply-To: References: <000001cc25c7$7e7c3290$7b7497b0$@iname.com> <20110609012039.57692108BD88@drugs.dv.isc.org> Message-ID: <4DF027DA.1070809@rancid.berkeley.edu> On 06/08/11 18:32, Jared Mauch wrote: > MYTHS: > > TCP/53 is only for zone transfers ICMP is a security risk/ddos > avenue Internal networks must be secured with NAT A firewall is the > only way to secure the perimiter > > In fact for IPv6, ICMP is more important vs less. Firewalls > frequently harm and don't block data going out. TCP/53 is needed for > EDNS. tcp/53 is needed when EDNS is _not_ available and DNS message size exceeds 512 bytes. UDP fragments are (sometimes) necessary for EDNS. So, that adds to your MYTHS section: Fragmented packets (like ICMP) are always a security risk and DDoS vector michael From Kelly.Setzer at wnco.com Wed Jun 8 20:58:18 2011 From: Kelly.Setzer at wnco.com (Kelly Setzer) Date: Wed, 8 Jun 2011 20:58:18 -0500 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: > -----Original Message----- > From: ryan at u13.net [mailto:ryan at u13.net] > Sent: Wednesday, June 08, 2011 9:19 AM > To: nanog at nanog.org > Subject: Re: Cogent IPv6 > > On Wed, 8 Jun 2011 09:51:21 -0400, Nick Olsen wrote: > > > I'm sure someone here is doing IPv6 peering with cogent. We've got a > > Gig [SNIP] > We have separate v4 and v6 sessions with them on the same dual-stack > interface (a v4 /29 and v6 /112 on the interface). One session is > between our v4 address and theirs, and carries v4 prefixes only. Then > another session between v6 addresses that carries v6 prefixes only. IPv6 newbie alert! I thought the maximum prefix length for IPv6 was 64 bits, so the comment about a v6 /112 for peering vexed me. I have Googled so much that Larry Page called me and asked me to stop. Can someone please point me to a resource that explains how IPv6 subnets larger than 64 bits function and how they would typically be used? thanks, Kelly ******* CONFIDENTIALITY NOTICE ******* This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. From bill at herrin.us Wed Jun 8 21:24:31 2011 From: bill at herrin.us (William Herrin) Date: Wed, 8 Jun 2011 22:24:31 -0400 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: On Wed, Jun 8, 2011 at 9:58 PM, Kelly Setzer wrote: > IPv6 newbie alert! > > I thought the maximum prefix length for IPv6 was 64 bits, > so the comment about a v6 /112 for peering vexed me. ?I > have Googled so much that Larry Page called me and > asked me to stop. > > Can someone please point me to a resource that explains >how IPv6 subnets larger than 64 bits function and how >they would typically be used? Hi Kelly, IPv6 netmasks work exactly like IPv4 netmasks. You can even route /128's if you want. Two major caveats: 1. SLAAC (stateless autoconfiguration, the more or less replacement for DHCP) only works if the subnet on your LAN is exactly /64. So unless you're manually configuring the IPv6 address on every machine on your subnet, you're using a /64. 2. Reverse DNS delegates every 4 bits (in IPv4 its every 8 bits). And when you write the address, every 4 bits is one digit. So unless you want to make things needlessly hard, you're also going to choose 4-bit boundaries for everything. I.e. a /56 or a /60 but never a /57. Now, as to why they'd choose a /112 (65k addresses) for the interface between customer and ISP, that's a complete mystery to me. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Wed Jun 8 22:03:31 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 8 Jun 2011 23:03:31 -0400 (EDT) Subject: Facebook Engineering, on WIPv6D: Message-ID: <27106265.214.1307588611631.JavaMail.root@benjamin.baylink.com> """ World IPv6 Day came to an end earlier today. We successfully enabled IPv6 on our site for 24 hours, with great results. We saw over 1 million users reach us over IPv6. We?re pleased that we did not see any increase in the number of users seeking help from our Help Center. The estimated 0.03% of users who may have been affected would have experienced slow page loads during the test. Based on the encouraging results, we?ve decided to leave our Developer site dual-stacked, supporting both IPv4 and IPv6. And we will continue to adapt our entire code base and tools to support IPv6. We are glad to have joined with the Internet Society, major Web companies, and other industry players to enable IPv6 for this test day. It was a great opportunity to test our infrastructure and IPv6 readiness. IPv6 is vital to the continued growth of the Internet, and World IPv6 Day was a great step in the advancement of the protocol. We hope the overall success of the 24 hour test will encourage others in the industry to establish reliable IPv6 connectivity and develop robust IPv6 products. Donn is glad the Internet didn't break today. """ That last was in italics... :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From cmadams at hiwaay.net Wed Jun 8 22:33:29 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 8 Jun 2011 22:33:29 -0500 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: <20110609033329.GE24907@hiwaay.net> Once upon a time, William Herrin said: > Now, as to why they'd choose a /112 (65k addresses) for the interface > between customer and ISP, that's a complete mystery to me. I had to ask this here a while back, so I can now share. :-) IPv6 addresses are written as 8 16-bit chunk separated by colons (optionally with the longest consecutive set of :0 sections replaced with ::). A /112 means the prefix is 7 of the 8 chunks, which means you can use ::1 and ::2 for every connection. Of course, just because you allocate a /112 (or shorter) in your database doesn't mean you have to use it. You could also allocate a /112 for a point-to-point link and use a /127 (e.g. addresses ::a and ::b). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From paul at paulgraydon.co.uk Wed Jun 8 22:34:07 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Wed, 08 Jun 2011 17:34:07 -1000 Subject: IPv6 day fun is beginning! In-Reply-To: <4DEFD05E.3090306@nac.net> References: <275FEA2949B48341A3B46F424B613D857C58@WDC-MX.photon.com> <4DF049D7.3020009@paulgraydon.co.uk> <4DEFD05E.3090306@nac.net> Message-ID: <4DF03F2F.8060109@paulgraydon.co.uk> Not cook islands. I am in Hawaii though so not a huge distance away. I'd got dual boot debian/windows and I had the tzlocation set wrong under Debian (GMT instead of local time). Boot back into Windows to test something and sent a few e-mails without noticing the time stamp was wrong. Paul On 6/8/2011 9:41 AM, Ryan Pavely wrote: > Are you really on Cook Island in the Pacific or is your email headers > date timezone string set incorrectly -1000. Your message won't be > read by me until tonight shortly after 12:19 am. Sadly you'll miss > IPv6 day :( > > > > > Ryan Pavely > Net Access Corporation > http://www.nac.net/ > > > On 6/9/2011 12:19 AM, Paul Graydon wrote: >> I've done the same at home, HE tunnel for IPv6. I've got a Linksys >> WRT54GL running DD-WRT so getting it set up was relatively straight >> forward though I really need to fix the automatic startup script >> that's misbehaving. >> Work was another matter, one big headache, to the point where I'm >> wondering if something is interfering. OpenBSD box running pf acts >> as a router for us, HE tunnel comes up easily and works fine from >> box. rtadvd starts advertising the network range and every machine in >> the office picked it up. Briefly those workstations running Windows >> 7 in the office were able to use the tunnel (5 mins give or take). >> From then on I could see outbound and inbound IPv6 traffic on the BSD >> box, but it never seemed to reach the workstations. Tearing down, >> reconfiguring, checking out every guide under the sun, nothing worked >> :) Gave up in the end, I'll tackle it later when I've got time to >> waste. >> Would be nice if my $isp would sort out an IPv6 address range for us >> to use properly. >> >> Paul >> >> >> On 6/8/2011 1:40 AM, Jamie Bowden wrote: >>> Thanks to HE's tunnel broker service, I've got fully functional dual >>> stack at home (well, mostly, like most folks, VZ gives me a single >>> address and I live behind that with NATv4, but otherwise, I loves me >>> some FiOS) and yesterday went by for me without a hitch, including >>> accessing Facebook (I'd hear from the wife and kid really quickly if >>> they weren't working). For a working tunnel, I put my DIR-825 as the >>> "DMZ" host behind the cheesy Actiontec router VZ requires, forward all >>> traffic with zero firewalling to it, and let the D-Link appliance >>> handle >>> all my firewall needs (and it terminates my v6 tunnel obviously). The >>> one thing I haven't quite figured out how to make it do (and maybe it's >>> just not capable) is use the /48 HE routes to me. The box insists that >>> the internal interface be on the same subnet as the external, and it >>> hands out v6 addresses from that /64. >>> >>> Jamie >>> >>> -----Original Message----- >>> From: Jared Mauch [mailto:jared at puck.nether.net] >>> Sent: Tuesday, June 07, 2011 7:15 PM >>> To: Iljitsch van Beijnum >>> Cc: NANOG list >>> Subject: Re: IPv6 day fun is beginning! >>> >>> >>> On Jun 7, 2011, at 7:13 PM, Iljitsch van Beijnum wrote: >>> >>>> www.facebook.com has AAAA but doesn't load for me over IPv6, it does >>> for others though >>> >>> If you go to www.v6.facebook.com it works, but it seems they have some >>> problem on their main site. I am seeing some issues reaching them over >>> IPv6. >>> >>> - Jared >>> >>> >>> >>> > From paul at paulgraydon.co.uk Wed Jun 8 22:37:30 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Wed, 08 Jun 2011 17:37:30 -1000 Subject: World IPv6 Only Day. In-Reply-To: <201106090108.27224.fredan-nanog@fredan.se> References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> Message-ID: <4DF03FFA.4070900@paulgraydon.co.uk> Dumb question.. what does the switch (L2) have to do with IPv6 (L3), or is it one of those 'somewhere in between the two' things? Paul On 6/8/2011 1:08 PM, fredrik danerklint wrote: > Well, that's another problem. > > To make a long story short, the network (not mine and I don't have any kind of > control over that either) that my customers (including me) are using, did put > in new equipment (a switch) over a year ago and after that I lost my IPv6 > connection that I had previously. That switch does not support IPv6 it turns > out. > > This is exactly the things that the customers really need to better understand > and why it's not gonna work for them. > > > You did miss a thing: > > $ dig mx fredan.se > > ;; ANSWER SECTION: > fredan.se. 3597 IN MX 10 mail.fredan.se. > > ;; ADDITIONAL SECTION: > mail.fredan.se. 3597 IN A 77.105.235.102 > mail.fredan.se. 3597 IN AAAA 2001:4db8:e001:ffff:2::17 > > So I do have a IPv6 connection but not to my customers. > >>> How about that one? >>> >>> (Please reply to the mailing list only) >> You wouldn't be posting to the list... :-) >> >> Received: from [77.105.232.43] (port=53699 helo=fredan-pc.localnet) >> by mail.fredan.se with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) >> (Exim 4.71) (envelope-from) >> id 1QURHg-0004ZJ-4d >> for nanog at nanog.org; Thu, 09 Jun 2011 00:31:32 +0200 From ml at kenweb.org Wed Jun 8 22:39:22 2011 From: ml at kenweb.org (ML) Date: Wed, 08 Jun 2011 23:39:22 -0400 Subject: Cogent IPv6 In-Reply-To: <6ac5bc37$45ab67ae$73965090$@com> References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: <4DF0406A.9030609@kenweb.org> On 6/8/2011 9:51 AM, Nick Olsen wrote: > I'm sure someone here is doing IPv6 peering with cogent. We've got a Gig > with them, So they don't do that dual peering thing with us. (They do it on > another 100Mb/s circuit we have... I despise it.) > Just kind of curious how they go about it. > Do they issue you a small IPv6 block for your interface, just like they do > for IPv4? Is it a separate session? Any things to be aware of before > pulling the trigger on it? (Other then them not having connectivity to HE's > IPv6 side of things, Wish they would fix that already...) > > Nick Olsen > Network Operations (855) FLSPEED x106 Did Cogent have the gumption to charge you more for IPv6 too? From richard at helix.net.nz Wed Jun 8 22:56:26 2011 From: richard at helix.net.nz (Richard Patterson) Date: Thu, 09 Jun 2011 15:56:26 +1200 Subject: World IPv6 Only Day. In-Reply-To: <4DF03FFA.4070900@paulgraydon.co.uk> References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> Message-ID: <4DF0446A.2010405@helix.net.nz> IPv6 has its own ethertype. (0x86DD) see the list: http://en.wikipedia.org/wiki/EtherType We've also encountered old IOSes that didn't forward Ethernet frames that contained IPv6 payload. On 06/09/2011 03:37 PM, Paul Graydon wrote: > Dumb question.. what does the switch (L2) have to do with IPv6 (L3), > or is it one of those 'somewhere in between the two' things? > > Paul > > On 6/8/2011 1:08 PM, fredrik danerklint wrote: >> Well, that's another problem. >> >> To make a long story short, the network (not mine and I don't have >> any kind of >> control over that either) that my customers (including me) are using, >> did put >> in new equipment (a switch) over a year ago and after that I lost my >> IPv6 >> connection that I had previously. That switch does not support IPv6 >> it turns >> out. >> > > From graham at apolix.co.za Wed Jun 8 23:09:18 2011 From: graham at apolix.co.za (Graham Beneke) Date: Thu, 09 Jun 2011 06:09:18 +0200 Subject: IPv6 day fun is beginning! In-Reply-To: <20110608205848.GB31133@srv03.cluenet.de> References: <20110608205848.GB31133@srv03.cluenet.de> Message-ID: <4DF0476E.3010602@apolix.co.za> On 08/06/2011 22:58, Daniel Roesen wrote: > On Wed, Jun 08, 2011 at 03:48:52PM -0400, Joly MacFie wrote: >> What seems evident, looking at >> http://asert.arbornetworks.com/2011/06/monitoring-world-ipv6-day/ is that a >> lot of folks switched it on - and then switched it off again pretty damn >> quick! > > I'd attribute that spike to "people actively testing around for all > those participants actually working". I agree. It appears to be mainly the 'native' traffic that spiked - native typically isn't the mom 'n pops at home. I know that when I woke up and found that my Youtube content was coming over v6, I used the opportunity to load test my infrastructure. ;-) -- Graham Beneke From kauer at biplane.com.au Wed Jun 8 23:36:15 2011 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 09 Jun 2011 14:36:15 +1000 Subject: World IPv6 Only Day. In-Reply-To: <4DF03FFA.4070900@paulgraydon.co.uk> References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> Message-ID: <1307594175.3760.44.camel@karl> On Wed, 2011-06-08 at 17:37 -1000, Paul Graydon wrote: > Dumb question.. what does the switch (L2) have to do with IPv6 (L3), or > is it one of those 'somewhere in between the two' things? Well, a modern switch should work fine, even if not directly IPv6 aware, but it won't understand multicast and will generally flood multicast frames to all interfaces. So definitely stipulate IPv6 capability, even for switches.... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From nanog-poster at axu.tm Thu Jun 9 00:01:30 2011 From: nanog-poster at axu.tm (Aleksi Suhonen) Date: Thu, 09 Jun 2011 08:01:30 +0300 Subject: Quick comparison of LSNs and NAT64 Message-ID: <4DF053AA.50400@axu.tm> Hello, Some people were talking about Large Scale NATs (LSN) or Carrier Grade NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are basically LSNs and they suffer from all the same problems. I don't think that NAT64 is as bad as other LSNs and here's why: NAT64 scales much better than NAT44 and NAT444(*) The trick is with its companion DNS64. If you need more NAT64 capacity, you can just add more NAT64 boxes with unique /96 prefixes around your network and have your DNS64 load-balance traffic to those boxes. You can also map one A record into two AAAA records of different NAT64 boxes, in case that works better with some application protocols. The smallest granularity of load-balancing easily available with NAT444 is per customer or per customer group. DNS64 allows per flow granularity for load-balancing without even breaking a sweat. I've been testing NAT64 at home using a public NAT64 trial and generally I've been very happy with it: http://www.trex.fi/2011/dns64.html A neat feature I've liked is that I don't have to pass all my traffic via the NAT64 box, and so it doesn't have to be between me and the Internet. NAT44 usually acts as a fuse between me and my Internet. The biggest downsides I've encountered are: I. Some streaming websites use IP addresses in their video stream URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. Thankfully these are a minority. II. Networked games usually use some sort of a tracker to help clients find games to connect to, and those only use plain IP addresses too. And some games only query for A records, and thus can't benefit from DNS64 either. So I guess the optimal way to stretch the lifetime of IPv4 while still moving toward IPv6 all the time would be to dual-stack customers and deploy both NAT64/DNS64 and some other LSN which can handle the two downsides above. All the traffic that you can shift to NAT64 means that your other LSN (which doesn't scale as well) can handle that much more traffic before becoming a bottleneck. And naturally, you'll want to shift all that youtube/facebook/whatever traffic to native IPv6 to help both NAT boxes cope. My 2 cents delivered, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail (*) NAT44 means the normal NAT from private IPv4 addresses to public IPv4 addresses. NAT444 means that there are two layers of NAT boxes: usually one at customer premises and the other at the ISP, doing LSN. From seth.mos at dds.nl Thu Jun 9 00:35:51 2011 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 9 Jun 2011 07:35:51 +0200 Subject: Facebook Engineering, on WIPv6D: In-Reply-To: <27106265.214.1307588611631.JavaMail.root@benjamin.baylink.com> References: <27106265.214.1307588611631.JavaMail.root@benjamin.baylink.com> Message-ID: <7F034F63-7167-47C0-A7E0-2596E9C59DC6@dds.nl> Hi Jay, Can you correlate the user from the access logs and send them a email that their IPv6 internet is not working correctly? Regards, Seth Op 9 jun 2011, om 05:03 heeft Jay Ashworth het volgende geschreven: > """ > World IPv6 Day came to an end earlier today. We successfully enabled IPv6 on our site for 24 hours, with great results. We saw over 1 million users reach us over IPv6. > > We?re pleased that we did not see any increase in the number of users seeking help from our Help Center. The estimated 0.03% of users who may have been affected would have experienced slow page loads during the test. > > Based on the encouraging results, we?ve decided to leave our Developer site dual-stacked, supporting both IPv4 and IPv6. And we will continue to adapt our entire code base and tools to support IPv6. > > We are glad to have joined with the Internet Society, major Web companies, and other industry players to enable IPv6 for this test day. It was a great opportunity to test our infrastructure and IPv6 readiness. > > IPv6 is vital to the continued growth of the Internet, and World IPv6 Day was a great step in the advancement of the protocol. We hope the overall success of the 24 hour test will encourage others in the industry to establish reliable IPv6 connectivity and develop robust IPv6 products. > > Donn is glad the Internet didn't break today. > """ > > That last was in italics... :-) > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > From tjc at ecs.soton.ac.uk Thu Jun 9 01:55:40 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 9 Jun 2011 07:55:40 +0100 Subject: World IPv6 Only Day. In-Reply-To: <1307594175.3760.44.camel@karl> References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> <1307594175.3760.44.camel@karl> <49635A35-6C5D-4745-B5EA-5C9E86ED191C@ecs.soton.ac.uk> Message-ID: On 9 Jun 2011, at 05:36, Karl Auer wrote: > On Wed, 2011-06-08 at 17:37 -1000, Paul Graydon wrote: >> Dumb question.. what does the switch (L2) have to do with IPv6 (L3), or >> is it one of those 'somewhere in between the two' things? > > Well, a modern switch should work fine, even if not directly IPv6 aware, > but it won't understand multicast and will generally flood multicast > frames to all interfaces. So definitely stipulate IPv6 capability, even > for switches.... And it won't have DHCPv6 snooping, or tools to mitigate rogue RAs. Tim From aftab.siddiqui at gmail.com Thu Jun 9 01:58:56 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Thu, 9 Jun 2011 11:58:56 +0500 Subject: Cogent IPv6 In-Reply-To: <20110609033329.GE24907@hiwaay.net> References: <6ac5bc37$45ab67ae$73965090$@com> <20110609033329.GE24907@hiwaay.net> Message-ID: > I had to ask this here a while back, so I can now share. :-) > > IPv6 addresses are written as 8 16-bit chunk separated by colons > (optionally with the longest consecutive set of :0 sections replaced > with ::). A /112 means the prefix is 7 of the 8 chunks, which means you > can use ::1 and ::2 for every connection. > > Of course, just because you allocate a /112 (or shorter) in your > database doesn't mean you have to use it. You could also allocate a > /112 for a point-to-point link and use a /127 (e.g. addresses ::a and > ::b). > Still that doesn't give any reason to provide /112 for point to point connectivitiy. Seriously, I'm peering with a transit provider with /126 and when I asked for a reason they said, ease of management. How come Subnetting /32 to /126 is ease of management??.... thats quite difficult to understand. This debate is there fore quite a long time but everytime it pops up I feel so uncomfortable with this granular subnetting. Regards, Aftab A. Siddiqui From linkconnect at googlemail.com Thu Jun 9 02:34:18 2011 From: linkconnect at googlemail.com (Wayne Lee) Date: Thu, 9 Jun 2011 08:34:18 +0100 Subject: Hotmail? In-Reply-To: <76b270f386175d8d6768fd326c5ddb26@mail.abellohome.net> References: <000601cc259c$d5b64580$8122d080$@arkitechs.com> <76b270f386175d8d6768fd326c5ddb26@mail.abellohome.net> Message-ID: > As far as commercial packages go, Surgemail is worth a look. Very affordable > and insanely powerful and customizable. The support team is the development > team. It's not uncommon for bugs to be fixed in hours to day and even new > features requests to be added in days to weeks. Runs on practically any > major OS you prefer... > > -Vinny +1 for Surgemail Have been running it for years and it's rock solid. Wayne From owen at delong.com Thu Jun 9 02:56:37 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jun 2011 00:56:37 -0700 Subject: Cogent & HE In-Reply-To: <20110608201027.GC19328@sizone.org> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110608201027.GC19328@sizone.org> Message-ID: <18E74D68-DF04-4DA2-BF53-CB48FE0EBC1E@delong.com> On Jun 8, 2011, at 1:10 PM, Ken Chase wrote: > On Wed, Jun 08, 2011 at 03:05:05PM -0500, Richard A Steenbergen said: >> global reachability, in the hopes that it will strengthen their >> strategic position for peering in the long term (i.e. they both want to >> be an "IPv6 Tier 1"). >> >> I'm not making a judgement call about the rightness or wrongness of the >> strategy (and after all, it clearly hasn't been THAT big of an issue >> considering that it has been this way for MANY months), but to attempt >> to "blame" one party for this issue is the height of absurdity. PR >> stunts and cake baking not withstanding, they're both equally complicit. > > So we have to buy from BOTH HE and Cogent?! Sounds like market fixing to me! :/ > Not at all... You can peer with HE. Try that with Cogent and then tell me it's the same. Owen From owen at delong.com Thu Jun 9 02:55:44 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jun 2011 00:55:44 -0700 Subject: Cogent & HE In-Reply-To: <20110608200505.GD18302@gerbil.cluepon.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> Message-ID: On Jun 8, 2011, at 1:05 PM, Richard A Steenbergen wrote: > On Wed, Jun 08, 2011 at 07:48:42PM +0000, Brielle Bruns wrote: >> Has been going on for a long while now. HE even made a cake for >> Cogent (IIRC), to no avail. >> >> But, this is not surprising. A lot of public/major peering issues >> with v4 over the past few years has been cogent vs. someone else. > > When two networks are not able to reach each other like this, it usually > requires the active willing participation of both parties to allow the > situation to continue. In this case, HE is doing *PRECISELY* the same > thing that Cogent is doing. They're refusing to purchase transit, and > making the decision to intentionally not carry a full table or have > global reachability, in the hopes that it will strengthen their > strategic position for peering in the long term (i.e. they both want to > be an "IPv6 Tier 1"). > Not exactly. We are perfectly willing to peer with Cogent. They are not only refusing to purchase transit, they are refusing to peer. To me, that's a pretty big difference. To be an IPv6 TIer 1, one has to peer with other IPv6 Tier 1s. HE has aggressively tried to improve the situation through promiscuous peering in every way possible. If you are interested in peering with HE and you have a presence at any of the exchange points we are at, send an email to peering at HE.NET and we will peer. I'd say that's pretty different from what Cogent is doing. > I'm not making a judgement call about the rightness or wrongness of the > strategy (and after all, it clearly hasn't been THAT big of an issue > considering that it has been this way for MANY months), but to attempt > to "blame" one party for this issue is the height of absurdity. PR > stunts and cake baking not withstanding, they're both equally complicit. > Respectfully, RAS, I disagree. I think there's a big difference between being utterly unwilling to resolve the situation by peering and merely refusing to purchase transit to a network that appears to offer little or no value to the purchaser or their customers. Owen From mcn4 at leicester.ac.uk Thu Jun 9 03:05:43 2011 From: mcn4 at leicester.ac.uk (Matthew Newton) Date: Thu, 9 Jun 2011 09:05:43 +0100 Subject: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day In-Reply-To: <2f646047-7598-4ed6-957c-6ae0523291dd@WIN7_GOLD_6> References: <2f646047-7598-4ed6-957c-6ae0523291dd@WIN7_GOLD_6> Message-ID: <20110609080543.GA14951@rootmail.cc.le.ac.uk> On Wed, Jun 08, 2011 at 11:38:54AM -0400, David Swafford wrote: > Overall though the day seems to be going well, I've sparked a > lot of enthusiasm at work by bragging this event (I even made a > shirt to promote it :-), and I'd love to see this become a > regular occurrence. In fact, daily would be good... ;) Matthew -- Matthew Newton, Ph.D. Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, From marka at isc.org Thu Jun 9 03:31:43 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 09 Jun 2011 18:31:43 +1000 Subject: Quick comparison of LSNs and NAT64 In-Reply-To: Your message of "Thu, 09 Jun 2011 08:01:30 +0300." <4DF053AA.50400@axu.tm> References: <4DF053AA.50400@axu.tm> Message-ID: <20110609083143.E9A9910A34C8@drugs.dv.isc.org> In message <4DF053AA.50400 at axu.tm>, Aleksi Suhonen writes: > Hello, > > Some people were talking about Large Scale NATs (LSN) or Carrier Grade > NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are > basically LSNs and they suffer from all the same problems. I don't think > that NAT64 is as bad as other LSNs and here's why: > > NAT64 scales much better than NAT44 and NAT444(*) > > The trick is with its companion DNS64. If you need more NAT64 capacity, > you can just add more NAT64 boxes with unique /96 prefixes around your > network and have your DNS64 load-balance traffic to those boxes. You can > also map one A record into two AAAA records of different NAT64 boxes, in > case that works better with some application protocols. You can add more capacity with DS-Lite as well though it does take a while for the DHCP option to be refreshed without push support. > The smallest granularity of load-balancing easily available with NAT444 > is per customer or per customer group. DNS64 allows per flow granularity > for load-balancing without even breaking a sweat. > > I've been testing NAT64 at home using a public NAT64 trial and generally > I've been very happy with it: > > http://www.trex.fi/2011/dns64.html > > A neat feature I've liked is that I don't have to pass all my traffic > via the NAT64 box, and so it doesn't have to be between me and the > Internet. NAT44 usually acts as a fuse between me and my Internet. You don't have to pass all the traffic through the AFTR box or the LSN when dual stacked either. The AFTR box can be on the other side of the world or out sourced if you want it to be. The same can be done with NAT64. > The biggest downsides I've encountered are: > > I. Some streaming websites use IP addresses in their video stream > URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. > Thankfully these are a minority. Not a problem with DS-Lite or NAT444. > II. Networked games usually use some sort of a tracker to help clients > find games to connect to, and those only use plain IP addresses too. And > some games only query for A records, and thus can't benefit from DNS64 > either. Not a problem with DS-Lite or NAT444 > So I guess the optimal way to stretch the lifetime of IPv4 while still > moving toward IPv6 all the time would be to dual-stack customers and > deploy both NAT64/DNS64 and some other LSN which can handle the two > downsides above. All the traffic that you can shift to NAT64 means that > your other LSN (which doesn't scale as well) can handle that much more > traffic before becoming a bottleneck. And naturally, you'll want to > shift all that youtube/facebook/whatever traffic to native IPv6 to help > both NAT boxes cope. > > My 2 cents delivered, > > -- > Aleksi Suhonen > > () ascii ribbon campaign > /\ support plain text e-mail > > (*) NAT44 means the normal NAT from private IPv4 addresses to public > IPv4 addresses. NAT444 means that there are two layers of NAT boxes: > usually one at customer premises and the other at the ISP, doing LSN. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Thu Jun 9 03:32:58 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jun 2011 01:32:58 -0700 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: On Jun 8, 2011, at 7:24 PM, William Herrin wrote: > On Wed, Jun 8, 2011 at 9:58 PM, Kelly Setzer wrote: >> IPv6 newbie alert! >> >> I thought the maximum prefix length for IPv6 was 64 bits, >> so the comment about a v6 /112 for peering vexed me. I >> have Googled so much that Larry Page called me and >> asked me to stop. >> >> Can someone please point me to a resource that explains >> how IPv6 subnets larger than 64 bits function and how >> they would typically be used? > > Hi Kelly, > > IPv6 netmasks work exactly like IPv4 netmasks. You can even route > /128's if you want. Two major caveats: > > 1. SLAAC (stateless autoconfiguration, the more or less replacement > for DHCP) only works if the subnet on your LAN is exactly /64. So > unless you're manually configuring the IPv6 address on every machine > on your subnet, you're using a /64. > You can actually use DHCPv6 to assign addresses to hosts dynamically on longer than /64 networks. However, you may have to go to some effort to add DHCPv6 support to those hosts first. Owen From tom at ninjabadger.net Thu Jun 9 03:39:42 2011 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 09 Jun 2011 09:39:42 +0100 Subject: Cogent IPv6 In-Reply-To: <4DF0406A.9030609@kenweb.org> References: <6ac5bc37$45ab67ae$73965090$@com> <4DF0406A.9030609@kenweb.org> Message-ID: <1307608785.2039.4.camel@teh-desktop> On Wed, 2011-06-08 at 23:39 -0400, ML wrote: > Did Cogent have the gumption to charge you more for IPv6 too? We have a bit of transit from them (~20Mbit or so) to stay connected to their customers. Getting IPv6 setup was really simple. No extra charges. It's been easier than via our existing L3 reseller (Adapt). Tom From saku at ytti.fi Thu Jun 9 03:39:46 2011 From: saku at ytti.fi (Saku Ytti) Date: Thu, 9 Jun 2011 11:39:46 +0300 Subject: Cogent & HE In-Reply-To: References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> Message-ID: <20110609083946.GA18430@pob.ytti.fi> On (2011-06-09 00:55 -0700), Owen DeLong wrote: > To be an IPv6 TIer 1, one has to peer with other IPv6 Tier 1s. HE has > aggressively tried to improve the situation through promiscuous peering > in every way possible. If you are interested in peering with HE and > you have a presence at any of the exchange points we are at, send > an email to peering at HE.NET and we will peer. I look forward for IPv4 to go away, as in future I can have full free connectivity through HE to every other shop who all have full free connectivity to HE. Something went terribly wrong in IPv4 land, where we're being unfairly forced to pay to access other networks through them. As a gesture of good faith, when I get this 100% free Internet, I vouche to return the favor by sending all my downstream customers 5USD gift card to iTunes, you're welcome. -- ++ytti From patrick at ianai.net Thu Jun 9 04:03:03 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 9 Jun 2011 18:03:03 +0900 Subject: Cogent & HE In-Reply-To: <20110609083946.GA18430@pob.ytti.fi> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609083946.GA18430@pob.ytti.fi> Message-ID: Composed on a virtual keyboard, please forgive typos. On Jun 9, 2011, at 17:39, Saku Ytti wrote: > On (2011-06-09 00:55 -0700), Owen DeLong wrote: > >> To be an IPv6 TIer 1, one has to peer with other IPv6 Tier 1s. HE has >> aggressively tried to improve the situation through promiscuous peering >> in every way possible. If you are interested in peering with HE and >> you have a presence at any of the exchange points we are at, send >> an email to peering at HE.NET and we will peer. > > I look forward for IPv4 to go away, as in future I can have full free > connectivity through HE to every other shop who all have full free connectivity > to HE. Something went terribly wrong in IPv4 land, where we're being unfairly > forced to pay to access other networks through them. Non sequitor. Even though HE gives away free transit now, Owen said nothing about free transit. As for free peering, LOTS of networks freely peer and make money, including my current employer. (Actually, I think more open peering networks make money than closed peering networks. :-) -- TTFN, patrick From jeroen at unfix.org Thu Jun 9 04:06:42 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 09 Jun 2011 11:06:42 +0200 Subject: Cogent & HE In-Reply-To: <20110609083946.GA18430@pob.ytti.fi> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609083946.GA18430@pob.ytti.fi> Message-ID: <4DF08D22.8060408@unfix.org> On 2011-Jun-09 10:39, Saku Ytti wrote: > On (2011-06-09 00:55 -0700), Owen DeLong wrote: > >> To be an IPv6 TIer 1, one has to peer with other IPv6 Tier 1s. HE has >> aggressively tried to improve the situation through promiscuous peering >> in every way possible. If you are interested in peering with HE and >> you have a presence at any of the exchange points we are at, send >> an email to peering at HE.NET and we will peer. > > I look forward for IPv4 to go away, as in future I can have full free > connectivity through HE to every other shop who all have full free connectivity > to HE. Something went terribly wrong in IPv4 land, where we're being unfairly > forced to pay to access other networks through them. You could, today, setup a IPv6 over IPv4 tunnel and HE will pay for the IPv4 transit at the cost of a little smaller lower MTU ;) Just need to find folks on the other side to terminate those tunnels who find also that using a free service is a good idea for a commercial setup. I guess all this free IPv6 transit has a perfect SLA of course with quick resolution for problems and of course a proper clean prefix feed with properly aggregated prefixes. Greets, Jeroen From saku at ytti.fi Thu Jun 9 04:10:23 2011 From: saku at ytti.fi (Saku Ytti) Date: Thu, 9 Jun 2011 12:10:23 +0300 Subject: Cogent & HE In-Reply-To: References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609083946.GA18430@pob.ytti.fi> Message-ID: <20110609091023.GA18450@pob.ytti.fi> On (2011-06-09 18:03 +0900), Patrick W. Gilmore wrote: > Even though HE gives away free transit now, Owen said nothing about free transit. Yes there might be that some networks are unable physically to connect to HE. But I'm sure within time HE will have global presence to reach all networks directly. -- ++ytti From leigh.porter at ukbroadband.com Thu Jun 9 04:35:47 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 9 Jun 2011 09:35:47 +0000 Subject: Hotmail? In-Reply-To: References: <000601cc259c$d5b64580$8122d080$@arkitechs.com> , Message-ID: On Wed, Jun 8, 2011 at 11:08 AM, Martin Hepworth wrote: > Have a look at the Hermes mail system at cam.Ac.uk, built buy among > people Philip Hazel of exam fame > > It will give you some insight into the challenges of building a > scalable high perfomance mail system. I rolled postfix, OpenLDAP, MySQL and @mail on a bunch of blades and NetApp storage which ran about 200K users for years without any problems. We had Alteons for load balancing. For spam/virus/etc I used the IronPort boxes (before they were Cisco). We very rarely had any problems with this, OpenLDAP broke once, but since the LDAP front ends were behind Alteons nobody ever noticed it. The whole thing cost less than the licenses for most commercial systems we looked at. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From cra at WPI.EDU Thu Jun 9 07:01:47 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 9 Jun 2011 08:01:47 -0400 Subject: Cogent IPv6 In-Reply-To: <20110609033329.GE24907@hiwaay.net> References: <6ac5bc37$45ab67ae$73965090$@com> <20110609033329.GE24907@hiwaay.net> Message-ID: <20110609120147.GV25373@angus.ind.WPI.EDU> On Wed, Jun 08, 2011 at 10:33:29PM -0500, Chris Adams wrote: > Once upon a time, William Herrin said: > > Now, as to why they'd choose a /112 (65k addresses) for the interface > > between customer and ISP, that's a complete mystery to me. > > I had to ask this here a while back, so I can now share. :-) > > IPv6 addresses are written as 8 16-bit chunk separated by colons > (optionally with the longest consecutive set of :0 sections replaced > with ::). A /112 means the prefix is 7 of the 8 chunks, which means you > can use ::1 and ::2 for every connection. > > Of course, just because you allocate a /112 (or shorter) in your > database doesn't mean you have to use it. You could also allocate a > /112 for a point-to-point link and use a /127 (e.g. addresses ::a and > ::b). Please don't use /127: Use of /127 Prefix Length Between Routers Considered Harmful http://tools.ietf.org/html/rfc3627 More below on use of various prefix lengths. You need to watch out for the EUI-64 'u' and 'g' bits, as well as subnet anycast addresses (top 127 addresses of every subnet): IPv6 Addressing Considerations: http://tools.ietf.org/html/rfc5375 IPv6 Address Assignment to End Sites: http://tools.ietf.org/html/rfc6177 Emerging Service Provider Scenarios for IPv6 Deployment: http://tools.ietf.org/html/rfc6036 IPv6 Optimal Address Plan and Allocation Tool: http://www.ipv6book.ca/allocation.html ARIN Wiki: http://www.getipv6.info/index.php/IPv6_Addressing_Plans (but some of the ARIN-related concepts here are obsolete, such as references to the HD Ratio and non-nibble-boundary allocations) From cra at WPI.EDU Thu Jun 9 07:09:23 2011 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 9 Jun 2011 08:09:23 -0400 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: <20110609120923.GW25373@angus.ind.WPI.EDU> On Thu, Jun 09, 2011 at 01:32:58AM -0700, Owen DeLong wrote: > > IPv6 netmasks work exactly like IPv4 netmasks. You can even route > > /128's if you want. Two major caveats: > > > > 1. SLAAC (stateless autoconfiguration, the more or less replacement > > for DHCP) only works if the subnet on your LAN is exactly /64. So > > unless you're manually configuring the IPv6 address on every machine > > on your subnet, you're using a /64. > > > You can actually use DHCPv6 to assign addresses to hosts dynamically > on longer than /64 networks. > > However, you may have to go to some effort to add DHCPv6 support to > those hosts first. Also, there is no prefix-length (or default router) option in DHCPv6, so you have to configure the Router Advertisements with the longer prefix length in this case. From internetplumber at gmail.com Thu Jun 9 07:12:39 2011 From: internetplumber at gmail.com (Rob Evans) Date: Thu, 9 Jun 2011 13:12:39 +0100 Subject: Cogent IPv6 In-Reply-To: <20110609120147.GV25373@angus.ind.WPI.EDU> References: <6ac5bc37$45ab67ae$73965090$@com> <20110609033329.GE24907@hiwaay.net> <20110609120147.GV25373@angus.ind.WPI.EDU> Message-ID: > Please don't use /127: > > Use of /127 Prefix Length Between Routers Considered Harmful > ? ?http://tools.ietf.org/html/rfc3627 Do keep up. :-) Rob From Grzegorz at Janoszka.pl Thu Jun 9 07:15:14 2011 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Thu, 09 Jun 2011 14:15:14 +0200 Subject: Cogent IPv6 In-Reply-To: <20110609120147.GV25373@angus.ind.WPI.EDU> References: <6ac5bc37$45ab67ae$73965090$@com> <20110609033329.GE24907@hiwaay.net> <20110609120147.GV25373@angus.ind.WPI.EDU> Message-ID: <4DF0B952.5090800@Janoszka.pl> On 09-06-11 14:01, Chuck Anderson wrote: > Please don't use /127: > > Use of /127 Prefix Length Between Routers Considered Harmful > http://tools.ietf.org/html/rfc3627 Well, this RFC says not to use PREFIX::/127. You are safe to use other /127's within your prefix. -- Grzegorz Janoszka From sthaug at nethelp.no Thu Jun 9 07:19:45 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 09 Jun 2011 14:19:45 +0200 (CEST) Subject: Cogent IPv6 In-Reply-To: <20110609120923.GW25373@angus.ind.WPI.EDU> References: <20110609120923.GW25373@angus.ind.WPI.EDU> Message-ID: <20110609.141945.74661869.sthaug@nethelp.no> > > You can actually use DHCPv6 to assign addresses to hosts dynamically > > on longer than /64 networks. > > > > However, you may have to go to some effort to add DHCPv6 support to > > those hosts first. > > Also, there is no prefix-length (or default router) option in DHCPv6, > so you have to configure the Router Advertisements with the longer > prefix length in this case. It is perfectly possible to use RA *only* for the default router, and not announce any prefix at all. This implies a link-local next hop. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From sthaug at nethelp.no Thu Jun 9 07:26:23 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 09 Jun 2011 14:26:23 +0200 (CEST) Subject: Cogent IPv6 In-Reply-To: <20110609120147.GV25373@angus.ind.WPI.EDU> References: <20110609033329.GE24907@hiwaay.net> <20110609120147.GV25373@angus.ind.WPI.EDU> Message-ID: <20110609.142623.41715402.sthaug@nethelp.no> > > Of course, just because you allocate a /112 (or shorter) in your > > database doesn't mean you have to use it. You could also allocate a > > /112 for a point-to-point link and use a /127 (e.g. addresses ::a and > > ::b). > > Please don't use /127: > > Use of /127 Prefix Length Between Routers Considered Harmful > http://tools.ietf.org/html/rfc3627 Please *do* consider using /127 on "real" point-to-point links (e.g. SDH/SONET, serial) - especially if you have internet facing links and are using a hardware based forwarding platform from vendors like Cisco or Juniper. This may be your simplest choice if you want to avoid the "ping-pong" problem which is very real (on some platforms). See http://tools.ietf.org/html/rfc6164 Steinar Haug, Nethelp consulting, sthaug at nethelp.no From ml at kenweb.org Thu Jun 9 07:50:49 2011 From: ml at kenweb.org (ML) Date: Thu, 09 Jun 2011 08:50:49 -0400 Subject: Cogent IPv6 In-Reply-To: <1307608785.2039.4.camel@teh-desktop> References: <6ac5bc37$45ab67ae$73965090$@com> <4DF0406A.9030609@kenweb.org> <1307608785.2039.4.camel@teh-desktop> Message-ID: <4DF0C1A9.9010000@kenweb.org> On 6/9/2011 4:39 AM, Tom Hill wrote: > On Wed, 2011-06-08 at 23:39 -0400, ML wrote: >> Did Cogent have the gumption to charge you more for IPv6 too? > > We have a bit of transit from them (~20Mbit or so) to stay connected to > their customers. > > Getting IPv6 setup was really simple. No extra charges. It's been easier > than via our existing L3 reseller (Adapt). > > Tom > > I guess someone with a >1 Gb commit in a not so small city deserves to be charged extra for a few Mbps of IPv6... For a not so full table at that. From mysidia at gmail.com Thu Jun 9 07:56:18 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 9 Jun 2011 07:56:18 -0500 Subject: Cogent & HE In-Reply-To: <20110609083946.GA18430@pob.ytti.fi> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609083946.GA18430@pob.ytti.fi> Message-ID: On Thu, Jun 9, 2011 at 3:39 AM, Saku Ytti wrote: > On (2011-06-09 00:55 -0700), Owen DeLong wrote: > I look forward for IPv4 to go away, as in future I can have full free > connectivity through HE to every other shop who all have full free connectivity > to HE. Something went terribly wrong in IPv4 land, where we're being unfairly > forced to pay to access other networks through them. The existence of free IPv6 transit from one peer to another is clearly a temporary situation; when IPv6 traffic picks up, expect to see the end of free transit, or a new rule like "free transit only to our paying customers' networks", or "Pay an extra port fee, get first XX megs transit for free". It's obvious HE wishes to get positioning as Tier1 on the IPv6 network. Once the amount of IPv6 traffic increases, $$ required for HE to provide transit between free peers will increase, and at some amount of traffic free transit will no longer be sustainable, due to additional network upgrades, ports, etc, required to carry additional transit. So they either lose massive $$, become a non-profit organization, and get sufficient donations from peers to fund upgrades, or at some point, limit the amount of (or type) of transit that is free, or stop adding peers. An assumption is that there will be such a thing as a Tier1 on the IPv6 network. Perhaps, the fact there are ISPs larger than all the others and the IP protocol suite tends to form a hierarchical structure logically, BUT There exists a possibility that no IPv6 network will be able to achieve transit-free status through peering; evidently, it just takes one large arrogant network operator to demand everyone else buy transit, in order to prevent any Tier1s from completely becoming Tier1 (and ironically -- preventing themselves from being classified Tier1, due to refusing to peer with HE). Unless you know... the operational definition of Tier1 is relaxed greatly to allow for partial connectivity; reaching 50% of the networks without transit does not make one Tier1. -- -JH From dmburgess at linktechs.net Thu Jun 9 08:09:16 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 9 Jun 2011 08:09:16 -0500 Subject: Cogent & HE References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry><20110608200505.GD18302@gerbil.cluepon.net><20110609083946.GA18430@pob.ytti.fi> Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50547C11E@ltiserver.lti.local> Does Cogent participate in the meetings/shows like the one coming up next week ? Would that not be a good place for NANOGers to voice their opinion? ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: June 09, 2011 7:56 AM To: Saku Ytti Cc: nanog at nanog.org Subject: Re: Cogent & HE On Thu, Jun 9, 2011 at 3:39 AM, Saku Ytti wrote: > On (2011-06-09 00:55 -0700), Owen DeLong wrote: > I look forward for IPv4 to go away, as in future I can have full free > connectivity through HE to every other shop who all have full free > connectivity to HE. Something went terribly wrong in IPv4 land, where > we're being unfairly forced to pay to access other networks through them. The existence of free IPv6 transit from one peer to another is clearly a temporary situation; when IPv6 traffic picks up, expect to see the end of free transit, or a new rule like "free transit only to our paying customers' networks", or "Pay an extra port fee, get first XX megs transit for free". It's obvious HE wishes to get positioning as Tier1 on the IPv6 network. Once the amount of IPv6 traffic increases, $$ required for HE to provide transit between free peers will increase, and at some amount of traffic free transit will no longer be sustainable, due to additional network upgrades, ports, etc, required to carry additional transit. So they either lose massive $$, become a non-profit organization, and get sufficient donations from peers to fund upgrades, or at some point, limit the amount of (or type) of transit that is free, or stop adding peers. An assumption is that there will be such a thing as a Tier1 on the IPv6 network. Perhaps, the fact there are ISPs larger than all the others and the IP protocol suite tends to form a hierarchical structure logically, BUT There exists a possibility that no IPv6 network will be able to achieve transit-free status through peering; evidently, it just takes one large arrogant network operator to demand everyone else buy transit, in order to prevent any Tier1s from completely becoming Tier1 (and ironically -- preventing themselves from being classified Tier1, due to refusing to peer with HE). Unless you know... the operational definition of Tier1 is relaxed greatly to allow for partial connectivity; reaching 50% of the networks without transit does not make one Tier1. -- -JH From wjhns61 at hardakers.net Thu Jun 9 08:34:04 2011 From: wjhns61 at hardakers.net (Wes Hardaker) Date: Thu, 09 Jun 2011 06:34:04 -0700 Subject: IPv6 day non-participants In-Reply-To: (James Harr's message of "Wed, 8 Jun 2011 10:59:41 -0500") References: Message-ID: >>>>> On Wed, 8 Jun 2011 10:59:41 -0500, James Harr said: JH> I noticed that one of our vendors wasn't actually participating when JH> they very publicly put on their home page that they would. So I JH> queried the IPv6 day participation list to see who didn't have AAAA's JH> for their listed website. It turned out to be around 9.5% IMHO, it's worse than that. Most sites only added a AAAA record for their website, and frequently didn't for their DNS server. So they weren't *really* doing a complete IPv6 test, IMHO. I actually ended up documenting my full results of testing for a number of things (including DNSSEC, just because I could) at: http://pontifications.hardakers.net/computers/celebrating-world-ipv6-day-by-testing-the-candidates/ -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From owen at delong.com Thu Jun 9 08:37:05 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jun 2011 06:37:05 -0700 Subject: Cogent & HE In-Reply-To: <4DF08D22.8060408@unfix.org> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609083946.GA18430@pob.ytti.fi> <4DF08D22.8060408@unfix.org> Message-ID: <610E58DD-03EA-4457-AE60-45762C611B37@delong.com> On Jun 9, 2011, at 2:06 AM, Jeroen Massar wrote: > On 2011-Jun-09 10:39, Saku Ytti wrote: >> On (2011-06-09 00:55 -0700), Owen DeLong wrote: >> >>> To be an IPv6 TIer 1, one has to peer with other IPv6 Tier 1s. HE has >>> aggressively tried to improve the situation through promiscuous peering >>> in every way possible. If you are interested in peering with HE and >>> you have a presence at any of the exchange points we are at, send >>> an email to peering at HE.NET and we will peer. >> >> I look forward for IPv4 to go away, as in future I can have full free >> connectivity through HE to every other shop who all have full free connectivity >> to HE. Something went terribly wrong in IPv4 land, where we're being unfairly >> forced to pay to access other networks through them. > > You could, today, setup a IPv6 over IPv4 tunnel and HE will pay for the > IPv4 transit at the cost of a little smaller lower MTU ;) > > Just need to find folks on the other side to terminate those tunnels who > find also that using a free service is a good idea for a commercial > setup. I guess all this free IPv6 transit has a perfect SLA of course > with quick resolution for problems and of course a proper clean prefix > feed with properly aggregated prefixes. > I was an HE Tunnel users long before I joined the company. In my experience, our free tunnel service is quite reliable and provides excellent connectivity. HE has been happily exchanging BGP and routing my /48 for several years. The high quality of this service and the quick resolution to my (very few) problems even on a free service is one of the things that attracted me to join the company. However, for those that want production-grade business-class tunnels, we have launched a paid tunnel service as well. Owen From jbates at brightok.net Thu Jun 9 09:02:06 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 09 Jun 2011 09:02:06 -0500 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> <20110609033329.GE24907@hiwaay.net> Message-ID: <4DF0D25E.9080903@brightok.net> On 6/9/2011 1:58 AM, Aftab Siddiqui wrote: > Still that doesn't give any reason to provide /112 for point to point > connectivitiy. Seriously, I'm peering with a transit provider with /126 and > when I asked for a reason they said, ease of management. How come Subnetting > /32 to /126 is ease of management??.... thats quite difficult to understand. > This debate is there fore quite a long time but everytime it pops up I > feel so uncomfortable with this granular subnetting. Some networks prefer a uniform numbering scheme. /112 allows for reasonable addressing needs on a circuit. In addition, while Ethernet is often used in a point-to-point access circuit, such layouts may change and renumbering would be annoying. Finally, having chunks 4-7 define the circuit and chunk 8 provide the circuit addressing makes it more human readable and is prone to less mistakes by those who suck at math. Jack From cb.list6 at gmail.com Thu Jun 9 09:39:17 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 9 Jun 2011 07:39:17 -0700 Subject: Quick comparison of LSNs and NAT64 In-Reply-To: <20110609083143.E9A9910A34C8@drugs.dv.isc.org> References: <4DF053AA.50400@axu.tm> <20110609083143.E9A9910A34C8@drugs.dv.isc.org> Message-ID: On Jun 9, 2011 1:32 AM, "Mark Andrews" wrote: > > > In message <4DF053AA.50400 at axu.tm>, Aleksi Suhonen writes: > > Hello, > > > > Some people were talking about Large Scale NATs (LSN) or Carrier Grade > > NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are > > basically LSNs and they suffer from all the same problems. I don't think > > that NAT64 is as bad as other LSNs and here's why: > > > > NAT64 scales much better than NAT44 and NAT444(*) > > > > The trick is with its companion DNS64. If you need more NAT64 capacity, > > you can just add more NAT64 boxes with unique /96 prefixes around your > > network and have your DNS64 load-balance traffic to those boxes. You can > > also map one A record into two AAAA records of different NAT64 boxes, in > > case that works better with some application protocols. > > You can add more capacity with DS-Lite as well though it does take a while > for the DHCP option to be refreshed without push support. > > > The smallest granularity of load-balancing easily available with NAT444 > > is per customer or per customer group. DNS64 allows per flow granularity > > for load-balancing without even breaking a sweat. > > > > I've been testing NAT64 at home using a public NAT64 trial and generally > > I've been very happy with it: > > > > http://www.trex.fi/2011/dns64.html > > > > A neat feature I've liked is that I don't have to pass all my traffic > > via the NAT64 box, and so it doesn't have to be between me and the > > Internet. NAT44 usually acts as a fuse between me and my Internet. > > You don't have to pass all the traffic through the AFTR box or the > LSN when dual stacked either. The AFTR box can be on the other > side of the world or out sourced if you want it to be. The same > can be done with NAT64. > > > The biggest downsides I've encountered are: > > > > I. Some streaming websites use IP addresses in their video stream > > URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. > > Thankfully these are a minority. > > Not a problem with DS-Lite or NAT444. > > > II. Networked games usually use some sort of a tracker to help clients > > find games to connect to, and those only use plain IP addresses too. And > > some games only query for A records, and thus can't benefit from DNS64 > > either. > > Not a problem with DS-Lite or NAT444 > > > So I guess the optimal way to stretch the lifetime of IPv4 while still > > moving toward IPv6 all the time would be to dual-stack customers and > > deploy both NAT64/DNS64 and some other LSN which can handle the two > > downsides above. All the traffic that you can shift to NAT64 means that > > your other LSN (which doesn't scale as well) can handle that much more > > traffic before becoming a bottleneck. And naturally, you'll want to > > shift all that youtube/facebook/whatever traffic to native IPv6 to help > > both NAT boxes cope. > > > > My 2 cents delivered, > > > > -- > > Aleksi Suhonen > > > > () ascii ribbon campaign > > /\ support plain text e-mail > > > > (*) NAT44 means the normal NAT from private IPv4 addresses to public > > IPv4 addresses. NAT444 means that there are two layers of NAT boxes: > > usually one at customer premises and the other at the ISP, doing LSN. > > All good and accurate info. I would just restate that nat64 unlike nat444 does not need to be "on path", this is what drives its improved scaling over nat444. Also, unlike ds-lite, nat64 works without any special client, such as the b4 function in the ds-lite architecture. Any fully functional ipv6 system such as win7 can work out of the box (ipv4 only apps being the exception) Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by making ipv6 end to end and forcing applications to be AF agnostic .... as where the others enable ipv4 without any backpressure. Each solution fits well for some set of constraints and objectives Cb > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From bill at herrin.us Thu Jun 9 10:02:26 2011 From: bill at herrin.us (William Herrin) Date: Thu, 9 Jun 2011 11:02:26 -0400 Subject: Cogent IPv6 In-Reply-To: <4DF0D25E.9080903@brightok.net> References: <6ac5bc37$45ab67ae$73965090$@com> <20110609033329.GE24907@hiwaay.net> <4DF0D25E.9080903@brightok.net> Message-ID: On Thu, Jun 9, 2011 at 10:02 AM, Jack Bates wrote: > Some networks prefer a uniform numbering scheme. /112 allows for reasonable > addressing needs on a circuit. In addition, while Ethernet is often used in > a point-to-point access circuit, such layouts may change and renumbering > would be annoying. > > Finally, having chunks 4-7 define the circuit and chunk 8 provide the > circuit addressing makes it more human readable and is prone to less > mistakes by those who suck at math. Hi Jack, I follow the reasoning, but unless you attach undue importance to the colons you get basically the same result with a /124. I guess choosing /112 for a point to point link is one of the weird side-effects of placing :'s in the address at fixed locations instead of arbitrary locations that serve the writer's mnemonic convenience. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Thu Jun 9 10:07:23 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 9 Jun 2011 08:07:23 -0700 Subject: Cogent IPv6 In-Reply-To: <4DF0D25E.9080903@brightok.net> References: <6ac5bc37$45ab67ae$73965090$@com> <20110609033329.GE24907@hiwaay.net> <4DF0D25E.9080903@brightok.net> Message-ID: <4C43AC78-BA28-4F36-BB87-18EB73509062@bogus.com> On Jun 9, 2011, at 7:02 AM, Jack Bates wrote: > On 6/9/2011 1:58 AM, Aftab Siddiqui wrote: >> Still that doesn't give any reason to provide /112 for point to point >> connectivitiy. Seriously, I'm peering with a transit provider with /126 and >> when I asked for a reason they said, ease of management. How come Subnetting >> /32 to /126 is ease of management??.... thats quite difficult to understand. >> This debate is there fore quite a long time but everytime it pops up I >> feel so uncomfortable with this granular subnetting. > > Some networks prefer a uniform numbering scheme. /112 allows for reasonable addressing needs on a circuit. In addition, while Ethernet is often used in a point-to-point access circuit, such layouts may change and renumbering would be annoying. > > Finally, having chunks 4-7 define the circuit and chunk 8 provide the circuit addressing makes it more human readable and is prone to less mistakes by those who suck at math. not to disagree how from my vantage point, it's fairly straight forward to assign a /64 and then deploy as a /127. that might be considered wasteful on the other hand a subnet is a subnet. > > Jack > From intensifysecurity at gmail.com Thu Jun 9 10:18:23 2011 From: intensifysecurity at gmail.com (Jeff Hartley) Date: Thu, 9 Jun 2011 11:18:23 -0400 Subject: Quick comparison of LSNs and NAT64 In-Reply-To: References: <4DF053AA.50400@axu.tm> <20110609083143.E9A9910A34C8@drugs.dv.isc.org> Message-ID: On Thu, Jun 9, 2011 at 10:39 AM, Cameron Byrne wrote: > On Jun 9, 2011 1:32 AM, "Mark Andrews" wrote: >> >> >> In message <4DF053AA.50400 at axu.tm>, Aleksi Suhonen writes: >> > Hello, >> > >> > Some people were talking about Large Scale NATs (LSN) or Carrier Grade >> > NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are >> > basically LSNs and they suffer from all the same problems. I don't think >> > that NAT64 is as bad as other LSNs and here's why: >> > >> > NAT64 scales much better than NAT44 and NAT444(*) >> > >> > The trick is with its companion DNS64. If you need more NAT64 capacity, >> > you can just add more NAT64 boxes with unique /96 prefixes around your >> > network and have your DNS64 load-balance traffic to those boxes. You can >> > also map one A record into two AAAA records of different NAT64 boxes, in >> > case that works better with some application protocols. >> >> You can add more capacity with DS-Lite as well though it does take a while >> for the DHCP option to be refreshed without push support. >> >> > The smallest granularity of load-balancing easily available with NAT444 >> > is per customer or per customer group. DNS64 allows per flow granularity >> > for load-balancing without even breaking a sweat. >> > >> > I've been testing NAT64 at home using a public NAT64 trial and generally >> > I've been very happy with it: >> > >> > http://www.trex.fi/2011/dns64.html >> > >> > A neat feature I've liked is that I don't have to pass all my traffic >> > via the NAT64 box, and so it doesn't have to be between me and the >> > Internet. NAT44 usually acts as a fuse between me and my Internet. >> >> You don't have to pass all the traffic through the AFTR box or the >> LSN when dual stacked either. ?The AFTR box can be on the other >> side of the world or out sourced if you want it to be. ?The same >> can be done with NAT64. >> >> > The biggest downsides I've encountered are: >> > >> > I. ? Some streaming websites use IP addresses in their video stream >> > URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. >> > Thankfully these are a minority. >> >> Not a problem with DS-Lite or NAT444. >> >> > II. ?Networked games usually use some sort of a tracker to help clients >> > find games to connect to, and those only use plain IP addresses too. And >> > some games only query for A records, and thus can't benefit from DNS64 >> > either. >> >> Not a problem with DS-Lite or NAT444 >> >> > So I guess the optimal way to stretch the lifetime of IPv4 while still >> > moving toward IPv6 all the time would be to dual-stack customers and >> > deploy both NAT64/DNS64 and some other LSN which can handle the two >> > downsides above. All the traffic that you can shift to NAT64 means that >> > your other LSN (which doesn't scale as well) can handle that much more >> > traffic before becoming a bottleneck. And naturally, you'll want to >> > shift all that youtube/facebook/whatever traffic to native IPv6 to help >> > both NAT boxes cope. >> > >> > My 2 cents delivered, >> > >> > -- >> > ? ? ? ? ?Aleksi Suhonen >> > >> > ? ? ? () ascii ribbon campaign >> > ? ? ? /\ support plain text e-mail >> > >> > (*) NAT44 means the normal NAT from private IPv4 addresses to public >> > IPv4 addresses. NAT444 means that there are two layers of NAT boxes: >> > usually one at customer premises and the other at the ISP, doing LSN. >> > > > All good and accurate info. I would just restate that nat64 unlike nat444 > does not need to be "on path", this is what drives its improved scaling over > nat444. > > Also, unlike ds-lite, nat64 works without any special client, such as the b4 > function in the ds-lite architecture. Any fully functional ipv6 system such > as win7 can work out of the box (ipv4 only apps being the exception) > > Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by > making ipv6 end to end and forcing applications to be AF agnostic .... as > where the others enable ipv4 without any backpressure. > > Each solution fits well for some set of constraints and objectives > > Cb > >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 ? ? ? ? ? ? ? ? INTERNET: marka at isc.org >> > A handy/succinct phrase I often use for that (in total agreement, of course) is: "NAT444 is NOT an IPv6 Transition Technology". Using an "anycast"-flavored model, where all DNS64 servers synthesize using the same prefix[es] and all NAT64 gateways are otherwise out of the critical path (injecting said prefix[es]), is indeed a highly scalable methodology. I've been deploying as such for the last ~6mo with great success. What was surprising was how Enterprise-applicable this has been in "v6-only access client" trials. The lack of need for gaming, streaming radio/media (i.e., "hard-coded IPv4 literals"), and desktop VoIP/P2P apps have turned out exceedingly well. -Jeff From joelja at bogus.com Thu Jun 9 10:27:53 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 9 Jun 2011 08:27:53 -0700 Subject: Cogent & HE In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50547C11E@ltiserver.lti.local> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry><20110608200505.GD18302@gerbil.cluepon.net><20110609083946.GA18430@pob.ytti.fi> <13175F96BDC3B34AB1425BAE905B3CE50547C11E@ltiserver.lti.local> Message-ID: On Jun 9, 2011, at 6:09 AM, Dennis Burgess wrote: > Does Cogent participate in the meetings/shows like the one coming up > next week ? Would that not be a good place for NANOGers to voice their > opinion? generally telling another party how to run their business in specific is considered poor taste... e.g. I dont buy transit from them and I don't much care if they choose to carry full routes or not. If I were a customer I imagine I'd be rather unhappy with the quality of their ipv6 transit product, but I'm not. > ----------------------------------------------------------- > Dennis Burgess, Mikrotik Certified Trainer > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270 Website: http://www.linktechs.net > LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > > > -----Original Message----- > From: Jimmy Hess [mailto:mysidia at gmail.com] > Sent: June 09, 2011 7:56 AM > To: Saku Ytti > Cc: nanog at nanog.org > Subject: Re: Cogent & HE > > On Thu, Jun 9, 2011 at 3:39 AM, Saku Ytti wrote: >> On (2011-06-09 00:55 -0700), Owen DeLong wrote: > >> I look forward for IPv4 to go away, as in future I can have full free >> connectivity through HE to every other shop who all have full free >> connectivity to HE. Something went terribly wrong in IPv4 land, where >> we're being unfairly forced to pay to access other networks through > them. > > The existence of free IPv6 transit from one peer to another is clearly a > temporary situation; when IPv6 traffic picks up, expect to see the end > of free transit, or a new rule like "free transit only to our paying > customers' networks", or "Pay an extra port fee, get first XX megs > transit for free". > > It's obvious HE wishes to get positioning as > Tier1 on the IPv6 network. Once the amount of IPv6 traffic increases, > $$ required for HE to provide transit between free peers will increase, > and at some amount of traffic free transit will no longer be > sustainable, due to additional network upgrades, ports, etc, required to > carry additional transit. > > So they either lose massive $$, become a non-profit organization, and > get sufficient donations from peers to fund upgrades, or at some point, > limit the amount of (or type) of transit that is free, or stop adding > peers. > > > An assumption is that there will be such a thing as a Tier1 on the IPv6 > network. > Perhaps, the fact there are ISPs larger than all the others and the IP > protocol suite tends to form a hierarchical structure logically, BUT > > There exists a possibility that no IPv6 network will be able to achieve > transit-free status through peering; evidently, it just takes one large > arrogant network operator to demand everyone else buy transit, in order > to prevent any Tier1s from completely becoming Tier1 > > (and ironically -- preventing themselves from being classified Tier1, > due to refusing to peer with HE). > > Unless you know... the operational definition of Tier1 is relaxed > greatly to allow for partial connectivity; reaching 50% of the networks > without transit does not make one Tier1. > > -- > -JH > > > From millnert at gmail.com Thu Jun 9 10:21:38 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 9 Jun 2011 11:21:38 -0400 Subject: Quick comparison of LSNs and NAT64 In-Reply-To: References: <4DF053AA.50400@axu.tm> <20110609083143.E9A9910A34C8@drugs.dv.isc.org> Message-ID: Hi, On Thu, Jun 9, 2011 at 10:39 AM, Cameron Byrne wrote: >> In message <4DF053AA.50400 at axu.tm>, Aleksi Suhonen writes: >> > Some people were talking about Large Scale NATs (LSN) or Carrier Grade >> > NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are >> > basically LSNs and they suffer from all the same problems. I don't think >> > that NAT64 is as bad as other LSNs and here's why: My statement is that a *pure* ipv6-only network, in the sense you have 0 NAT:ed reachability to the IPv4 Internet, will only attract people like me. :) > All good and accurate info. I would just restate that nat64 unlike nat444 > does not need to be "on path", this is what drives its improved scaling over > nat444. > > Also, unlike ds-lite, nat64 works without any special client, such as the b4 > function in the ds-lite architecture. Any fully functional ipv6 system such > as win7 can work out of the box (ipv4 only apps being the exception) > > Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by > making ipv6 end to end and forcing applications to be AF agnostic .... as > where the others enable ipv4 without any backpressure. You are absolutely correct here. The proper solution is indeed to backtrack from the end-goal, which is to have only one stack in the network. Thanks, Martin From millnert at gmail.com Thu Jun 9 10:37:56 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 9 Jun 2011 11:37:56 -0400 Subject: Cogent & HE In-Reply-To: <20110608201027.GC19328@sizone.org> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110608201027.GC19328@sizone.org> Message-ID: On Wed, Jun 8, 2011 at 4:10 PM, Ken Chase wrote: > So we have to buy from BOTH HE and Cogent?! Sounds like market fixing to me! :/ > > Guess if we do we can advertise that on our webpage... "now with BOTH halves > of the ipv6 internets!" Or just buy from someone who have sessions with both, who IOW can offer a full IPv6 Internet. Regards, Martin From jbates at brightok.net Thu Jun 9 10:43:00 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 09 Jun 2011 10:43:00 -0500 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> <20110609033329.GE24907@hiwaay.net> <4DF0D25E.9080903@brightok.net> Message-ID: <4DF0EA04.5040901@brightok.net> On 6/9/2011 10:02 AM, William Herrin wrote: > I follow the reasoning, but unless you attach undue importance to the > colons you get basically the same result with a /124. > > I guess choosing /112 for a point to point link is one of the weird > side-effects of placing :'s in the address at fixed locations instead > of arbitrary locations that serve the writer's mnemonic convenience. > For the most part, you are correct. I generally run a :town:router:linkid:linkaddresses format out of a single /64 per regional area. While I could shorten the number of linkaddresses more, I'm not sure of the need. Even if I assigned it as a /124, I'd still allocate it as a /112 and just set the first 2 nibblets as 0. My reluctance to do so has more to do with uniformity, especially when providing support. It's much easier to rattle off the standard length than to have to look it up. There are cases where a /124 wouldn't be enough. Honestly, it's all a matter of preference. There are technical issues against using /127 and there's pros and cons to using longer than /64. There are interoperability issues as well as ping pong handling issues. It was just my opinion that 16 bits was more than enough for each branch of allocation that I wanted. Jack From rps at maine.edu Thu Jun 9 10:43:55 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 9 Jun 2011 11:43:55 -0400 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: > IPv6 newbie alert! > > I thought the maximum prefix length for IPv6 was 64 bits, so the comment about a v6 /112 for peering vexed me. ?I have Googled so much that Larry Page called me and asked me to stop. > > Can someone please point me to a resource that explains how IPv6 subnets larger than 64 bits function and how they would typically be used? > > thanks, > Kelly The use of a 64-bit prefix is a requirement if using Stateless addressing, nothing more. Allocation of a 64-bit prefix for every host network means you won't need to play games with subnetting based on the number of current or potential hosts, and keeps things clean; you SHOULD allocate a 64-bit prefix for every host network, though extending this logic to everything is a bit ignorant. There is a denial of service attack vector that exists on most current production IPv6 routers: IPv6 Neighbor Table Exhaustion. Writing a quick program to sweep through every IPv6 address within a 64-bit prefix is enough to cause most routers to drop neighbor entries for known hosts once the table is full. This attack is specifically targeted against routers, which makes it more troubling. Note that I was a naysayer of this vector being a problem until I actually wrote an implementation of it in a lab. I was able to kill all IPv6 traffic within seconds from a single server. Because of this, I strongly encourage you to make use of smaller prefixes for link networks. We use 126-bit prefixes (see http://tools.ietf.org/rfc/rfc3627.txt for why we avoid 127). We also don't consider Stateless desirable for the majority of our host networks. If you enable stateless on a network, every host with an IPv6 stack will start making use of it. If you use DHCPv6 you can enable global IPv6 on a per-host basis. This makes it much, much, easier to get buy-in on rolling out IPv6 everywhere, and while IPv6 is nice, it's not required yet, so you have time for the non-DHCPv6 hosts to be upgraded over the next few years (Mac OS X Lion will actually introduce a full DHCPv6 client implementation, for example). If you don't require stateless, then using prefixes longer than 64 is an option. Our current practice is to allocate a full 64-bit prefix in the schema, but only use what is currently required for actual implementation. Most of our IPv6 prefixes are actually 119 or 120-bit prefixes. Once better protection against neighbor table exhaustion is available we plan to migrate to 64. Also very strongly recommend enabling IPv6 on all your networks even if you disable RA or don't hand out addresses. This provides you with viability of IPv6 traffic on your IPv4 networks (e.g. the ability to check for rogue IPv6 routers). Finally, until RA Guard is available, use of L3 switches that support IPv6 PACL's is highly desirable as they allow you to apply a port-level traffic filter to drop RA from unauthorized ports (we do this system-wide at this point, and network stability has improved dramatically as a result). MLD snooping still needs work; the current Cisco implementation is bugged to the point where it drops ND traffic. I'm strongly looking forward to support for things like DHCPv6 snooping, I was hoping that we'd see it by now but vendors are slow to come around. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From recourse at gmail.com Thu Jun 9 10:56:31 2011 From: recourse at gmail.com (Joseph Jackson) Date: Thu, 9 Jun 2011 10:56:31 -0500 Subject: World IPv6 Only Day. In-Reply-To: References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> <49635A35-6C5D-4745-B5EA-5C9E86ED191C@ecs.soton.ac.uk> <1307594175.3760.44.camel@karl> Message-ID: Wouldn't the multicast flooding be just like broadcasts tho? Some of my sites don't have switches that will be upgraded or upgradeable to software that will support IPv6 directly (at least not for a few years). Is that going to cause major headaches? I under stand the RA risks but the DHCPv6 snooping I'm not too clear on. On Thu, Jun 9, 2011 at 1:55 AM, Tim Chown wrote: > > On 9 Jun 2011, at 05:36, Karl Auer wrote: > >> On Wed, 2011-06-08 at 17:37 -1000, Paul Graydon wrote: >>> Dumb question.. what does the switch (L2) have to do with IPv6 (L3), or >>> is it one of those 'somewhere in between the two' things? >> >> Well, a modern switch should work fine, even if not directly IPv6 aware, >> but it won't understand multicast and will generally flood multicast >> frames to all interfaces. So definitely stipulate IPv6 capability, even >> for switches.... > > And it won't have DHCPv6 snooping, or tools to mitigate rogue RAs. > > Tim > > From bruns at 2mbit.com Thu Jun 9 10:56:46 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 09 Jun 2011 09:56:46 -0600 Subject: Cogent & HE In-Reply-To: <4DF08D22.8060408@unfix.org> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609083946.GA18430@pob.ytti.fi> <4DF08D22.8060408@unfix.org> Message-ID: <4DF0ED3E.60700@2mbit.com> On 6/9/11 3:06 AM, Jeroen Massar wrote: > You could, today, setup a IPv6 over IPv4 tunnel and HE will pay for the > IPv4 transit at the cost of a little smaller lower MTU;) > > Just need to find folks on the other side to terminate those tunnels who > find also that using a free service is a good idea for a commercial > setup. I guess all this free IPv6 transit has a perfect SLA of course > with quick resolution for problems and of course a proper clean prefix > feed with properly aggregated prefixes. If you need that guarantee and SLA, I'm pretty sure HE won't turn down a paying customer. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Thu Jun 9 11:10:53 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 09 Jun 2011 10:10:53 -0600 Subject: Cogent & HE In-Reply-To: <610E58DD-03EA-4457-AE60-45762C611B37@delong.com> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609083946.GA18430@pob.ytti.fi> <4DF08D22.8060408@unfix.org> <610E58DD-03EA-4457-AE60-45762C611B37@delong.com> Message-ID: <4DF0F08D.2090306@2mbit.com> On 6/9/11 7:37 AM, Owen DeLong wrote: > I was an HE Tunnel users long before I joined the company. In my experience, > our free tunnel service is quite reliable and provides excellent connectivity. > HE has been happily exchanging BGP and routing my /48 for several > years. The high quality of this service and the quick resolution to my > (very few) problems even on a free service is one of the things that attracted > me to join the company. > > However, for those that want production-grade business-class tunnels, > we have launched a paid tunnel service as well. > For a while we were in a similar setup with HE - free BGP tunnel for our /48 to our provider who didn't have native IPv6 at the time. Turnaround time for issues was a few hours at most (if even that), and their knowledgeable BGP people helped us with some annoying/aggravating ARIN policies that initially prevented us from getting an AS number. So, maybe I'm biased in singing their praises. Its the little things that make all the difference, IMHO. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From daniel.unam.ipv6 at gmail.com Thu Jun 9 11:29:17 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Thu, 9 Jun 2011 11:29:17 -0500 Subject: Cogent IPv6 [IPv6 newbie alert!] Message-ID: As a matter of fact, an IPv6 address has a maximum (but not restricted) fixed lenght of 64 bits for the network and subnetwork definition, and 64bit for the interface identifier. The most left 64 bit in that address contains information about type of address, scope, network and subnetwork and another "useful" information. But the fixed restricted lenght is not mandatory, and if locally managed IPv6 addresses anre created, you can design routes via routing protocols to follow the same rules as in CIDR. Best regards xD. ------------------------------ > > Message: 2 > Date: Wed, 8 Jun 2011 20:58:18 -0500 > From: Kelly Setzer > Subject: RE: Cogent IPv6 > To: "nanog at nanog.org" > Message-ID: > < > FC8ABE0E5D384A489CDB16C4A8EB77839B3E9C6995 at MSMAIL01.LUV.AD.SWACORP.COM> > > Content-Type: text/plain; charset="utf-8" > > > > -----Original Message----- > > From: ryan at u13.net [mailto:ryan at u13.net] > > Sent: Wednesday, June 08, 2011 9:19 AM > > To: nanog at nanog.org > > Subject: Re: Cogent IPv6 > > > > On Wed, 8 Jun 2011 09:51:21 -0400, Nick Olsen wrote: > > > > > I'm sure someone here is doing IPv6 peering with cogent. We've got a > > > Gig > [SNIP] > > We have separate v4 and v6 sessions with them on the same dual-stack > > interface (a v4 /29 and v6 /112 on the interface). One session is > > between our v4 address and theirs, and carries v4 prefixes only. Then > > another session between v6 addresses that carries v6 prefixes only. > > IPv6 newbie alert! > > I thought the maximum prefix length for IPv6 was 64 bits, so the comment > about a v6 /112 for peering vexed me. I have Googled so much that Larry > Page called me and asked me to stop. > > Can someone please point me to a resource that explains how IPv6 subnets > larger than 64 bits function and how they would typically be used? > > thanks, > Kelly > > -- *Daniel Espejel Perez * From iljitsch at muada.com Thu Jun 9 11:49:57 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 9 Jun 2011 18:49:57 +0200 Subject: World IPv6 Only Day. In-Reply-To: <1307594175.3760.44.camel@karl> References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> <1307594175.3760.44.camel@karl> Message-ID: <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> On 9 jun 2011, at 6:36, Karl Auer wrote: > Well, a modern switch should work fine, even if not directly IPv6 aware, > but it won't understand multicast and will generally flood multicast > frames to all interfaces. So definitely stipulate IPv6 capability, even > for switches.... Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts? From joelja at bogus.com Thu Jun 9 11:55:25 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 9 Jun 2011 09:55:25 -0700 Subject: World IPv6 Only Day. In-Reply-To: <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> <1307594175.3760.44.camel@karl> <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> Message-ID: <18D360E2-DF0C-4519-BB42-8E22257E7464@bogus.com> yes http://www.google.com/search?q=mld+snooping+switch On Jun 9, 2011, at 9:49 AM, Iljitsch van Beijnum wrote: > On 9 jun 2011, at 6:36, Karl Auer wrote: > >> Well, a modern switch should work fine, even if not directly IPv6 aware, >> but it won't understand multicast and will generally flood multicast >> frames to all interfaces. So definitely stipulate IPv6 capability, even >> for switches.... > > Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts? > > > From iljitsch at muada.com Thu Jun 9 11:56:05 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 9 Jun 2011 18:56:05 +0200 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> Message-ID: <957672C2-3DB4-466D-9513-4E1529B6B2E6@muada.com> On 9 jun 2011, at 10:32, Owen DeLong wrote: > You can actually use DHCPv6 to assign addresses to hosts dynamically > on longer than /64 networks. The trouble is that DHCPv6 can't tell you the prefix length for your address, so either set up the routers to advertise this prefix (but without the autonomous autoconfiguration flag set) or prepare for surprising results. I say: life is too short to fiddle with this kind of stuff, just use /64, at least for everything that isn't a point-to-point link or loopback address. From iljitsch at muada.com Thu Jun 9 11:59:13 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 9 Jun 2011 18:59:13 +0200 Subject: Cogent IPv6 In-Reply-To: <20110609.141945.74661869.sthaug@nethelp.no> References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> Message-ID: On 9 jun 2011, at 14:19, sthaug at nethelp.no wrote: > It is perfectly possible to use RA *only* for the default router, and > not announce any prefix at all. This implies a link-local next hop. Router advertisements always use the router's link local address, you can't get a router's global address from this. IPv6 routing protocols also pretty much only use link locals, so link local next hop and default routes are completely routine. From jsw at inconcepts.biz Thu Jun 9 12:14:09 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 9 Jun 2011 13:14:09 -0400 Subject: Cogent IPv6 In-Reply-To: <4DF0C1A9.9010000@kenweb.org> References: <6ac5bc37$45ab67ae$73965090$@com> <4DF0406A.9030609@kenweb.org> <1307608785.2039.4.camel@teh-desktop> <4DF0C1A9.9010000@kenweb.org> Message-ID: On Thu, Jun 9, 2011 at 8:50 AM, ML wrote: > I guess someone with a >1 Gb commit in a not so small city deserves to be > charged extra for a few Mbps of IPv6... > > For a not so full table at that. We canceled some 10GbE Cogent circuits because of Cogent's refusal to provision IPv6 without adding extra fees, and I expressed my reasoning well in advance of canceling the first one. I have been told that they have now eliminated the special fee for North American customers, but just two weeks ago I heard about this IPv6 surcharge stupidity still being applied to Cogent's customers in Europe. If you want to change your vendor, sometimes you have to change your vendor. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From rps at maine.edu Thu Jun 9 12:19:17 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 9 Jun 2011 13:19:17 -0400 Subject: Cogent IPv6 In-Reply-To: References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> Message-ID: Don't assume that DHCPv6 is the same as DHCP. DHCPv6 does not provide route information because this task is handled by RA in IPv6. An IPv6 RA has flags for Managed (M), Other (O), and Autonomous (A) address configuration. None of these flags are exclusive. While most routers have the A flag set by default (which enables stateless addressing) it can be disabled, and hosts will not pick up a stateless address as a result. The M flag tells hosts to make use of DHCPv6 for an address, and the O flag tells hosts to make use of DHCPv6 for additional configuration, such as DNS. Most popular configurations: You can use the A and O flag for stateless addressing with DHCPv6 for DNS. You can use A, M, and O flags if you want every host to have a stateless address, but want to use DHCPv6 to also give some hosts a predictable address (e.g. for servers), and have them use DHCPv6 for DNS information. You can have only the M and O flags set and hosts will only use DHCPv6 for configuration. Most routers also support relaying of DHCPv6 information to a central server. For those who speak "Cisco" here is an example interface configuration for DHCPv6 only. ipv6 address 2001:DB8:100::1/64 no ipv6 unreachables ipv6 nd reachable-time 900000 ipv6 nd prefix default 900 300 no-autoconfig ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 nd router-preference High ipv6 nd ra interval 300 ipv6 nd ra lifetime 300 no ipv6 redirects ipv6 verify unicast source reachable-via rx ipv6 dhcp relay destination 2001:DB8:200::2 ipv6 dhcp relay destination 2001:DB8:200::3 Leaving out the "no-autoconfig" will also allow stateless if your prefix-length is 64. If you don't have a 64-bit prefix stateless won't work regardless of whether the A flag is set or not. Also note, if using DHCPv6, a DUID is used instead of the MAC address, though 2 out of 3 valid DUID formats include a MAC address of the host and I haven't actually seen the 3rd implemented. DUIDs are stored after the first time they get generated, so if you're imaging hosts you'll need to included deleting the DUID as part of your imaging process, or you'll have conflicts. Ray On Thu, Jun 9, 2011 at 12:59 PM, Iljitsch van Beijnum wrote: > On 9 jun 2011, at 14:19, sthaug at nethelp.no wrote: > >> It is perfectly possible to use RA *only* for the default router, and >> not announce any prefix at all. This implies a link-local next hop. > > Router advertisements always use the router's link local address, you can't get a router's global address from this. IPv6 routing protocols also pretty much only use link locals, so link local next hop and default routes are completely routine. > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From nick at foobar.org Thu Jun 9 12:21:05 2011 From: nick at foobar.org (Nick Hilliard) Date: Thu, 09 Jun 2011 18:21:05 +0100 Subject: Cogent IPv6 In-Reply-To: References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> Message-ID: <4DF10101.4010407@foobar.org> On 09/06/2011 17:59, Iljitsch van Beijnum wrote: > can't get a router's global address from this. IPv6 routing protocols > also pretty much only use link locals Really? I guess my eyes must be playing tricks on me then. Nick From dmburgess at linktechs.net Thu Jun 9 12:22:18 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 9 Jun 2011 12:22:18 -0500 Subject: Cogent IPv6 References: <6ac5bc37$45ab67ae$73965090$@com> <4DF0406A.9030609@kenweb.org><1307608785.2039.4.camel@teh-desktop> <4DF0C1A9.9010000@kenweb.org> Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50547C14B@ltiserver.lti.local> We have a IPv6 peer with Cogent, in St. Louis, no extra fees were charged. Just a FYI. ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Jeff Wheeler [mailto:jsw at inconcepts.biz] Sent: June 09, 2011 12:14 PM To: nanog at nanog.org Subject: Re: Cogent IPv6 On Thu, Jun 9, 2011 at 8:50 AM, ML wrote: > I guess someone with a >1 Gb commit in a not so small city deserves to > be charged extra for a few Mbps of IPv6... > > For a not so full table at that. We canceled some 10GbE Cogent circuits because of Cogent's refusal to provision IPv6 without adding extra fees, and I expressed my reasoning well in advance of canceling the first one. I have been told that they have now eliminated the special fee for North American customers, but just two weeks ago I heard about this IPv6 surcharge stupidity still being applied to Cogent's customers in Europe. If you want to change your vendor, sometimes you have to change your vendor. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From rps at maine.edu Thu Jun 9 12:26:11 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 9 Jun 2011 13:26:11 -0400 Subject: Cogent IPv6 In-Reply-To: <4DF10101.4010407@foobar.org> References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF10101.4010407@foobar.org> Message-ID: On Thu, Jun 9, 2011 at 1:21 PM, Nick Hilliard wrote: > On 09/06/2011 17:59, Iljitsch van Beijnum wrote: >> >> can't get a router's global address from this. IPv6 routing protocols >> also pretty much only use link locals > > Really? ?I guess my eyes must be playing tricks on me then. > > Nick What OS? The system could determine the global address for the prefix provided with a little work, but the implementation for RA is to set the default route to the link-local address. This is the behavior on Windows and Linux. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From ebais at A2B-Internet.com Thu Jun 9 12:32:52 2011 From: ebais at A2B-Internet.com (Erik Bais) Date: Thu, 9 Jun 2011 19:32:52 +0200 Subject: World IPv6 Only Day. In-Reply-To: <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> <1307594175.3760.44.camel@karl> <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> Message-ID: Hi Iljitsch, The switches from Extreme Networks do MLD and MLD snooping, I know for sure on the x450's and up, probably below that line as well. Erik Bais Verstuurd vanaf mijn iPad Op Jun 9, 2011 om 18:49 heeft Iljitsch van Beijnum het volgende geschreven: > On 9 jun 2011, at 6:36, Karl Auer wrote: > >> Well, a modern switch should work fine, even if not directly IPv6 aware, >> but it won't understand multicast and will generally flood multicast >> frames to all interfaces. So definitely stipulate IPv6 capability, even >> for switches.... > > Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts? > > From rps at maine.edu Thu Jun 9 12:34:25 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 9 Jun 2011 13:34:25 -0400 Subject: World IPv6 Only Day. In-Reply-To: <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> <1307594175.3760.44.camel@karl> <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> Message-ID: Cisco has had MLD snooping support for some time. But they seem to have broken it in a recent release, so it drops ND traffic and breaks IPv6; been after them to fix it, but doesn't look like it's been resolved yet. But you're correct that without MLD snooping IPv6 ND traffic is on par with IPv4 broadcast traffic and not a major problem. It does mean, however, that a large IPv6 multicast stream, like video or system imaging, would be about as bad as doing so on IPv4 without IGMP snooping. On Thu, Jun 9, 2011 at 12:49 PM, Iljitsch van Beijnum wrote: > On 9 jun 2011, at 6:36, Karl Auer wrote: > >> Well, a modern switch should work fine, even if not directly IPv6 aware, >> but it won't understand multicast and will generally flood multicast >> frames to all interfaces. So definitely stipulate IPv6 capability, even >> for switches.... > > Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts? > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From nick at foobar.org Thu Jun 9 12:37:08 2011 From: nick at foobar.org (Nick Hilliard) Date: Thu, 09 Jun 2011 18:37:08 +0100 Subject: Cogent IPv6 In-Reply-To: References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> Message-ID: <4DF104C4.8050107@foobar.org> On 09/06/2011 18:19, Ray Soucy wrote: > DHCPv6 does not provide route information because this task is handled > by RA in IPv6. Thankfully this silliness is in the process of being fixed, along with prefix delegation - so in future, there will be no requirement for either RA or cartloads of per-interface configuration on routers. Nick From nick at foobar.org Thu Jun 9 12:41:44 2011 From: nick at foobar.org (Nick Hilliard) Date: Thu, 09 Jun 2011 18:41:44 +0100 Subject: Cogent IPv6 In-Reply-To: References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF10101.4010407@foobar.org> Message-ID: <4DF105D8.7050300@foobar.org> On 09/06/2011 18:26, Ray Soucy wrote: > What OS? IOS, for example (as opposed to iOS which is just freebsd from that point of view). JunOS uses link-locals. Iljitsch noted: "IPv6 routing protocols also pretty much only use link locals". This is not true in the general case. Nick From millnert at gmail.com Thu Jun 9 12:43:04 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 9 Jun 2011 13:43:04 -0400 Subject: World IPv6 Only Day. In-Reply-To: <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> <1307594175.3760.44.camel@karl> <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> Message-ID: Iljitsch, On Thu, Jun 9, 2011 at 12:49 PM, Iljitsch van Beijnum wrote: > Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts? Something as enterprisey as even HP Procurve (!) has been doing this for years. Regards, Martin From Valdis.Kletnieks at vt.edu Thu Jun 9 12:47:48 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 09 Jun 2011 13:47:48 -0400 Subject: Thank you Microsoft (and others) In-Reply-To: Your message of "Wed, 08 Jun 2011 21:45:25 EDT." <20110609014525.GU71792@neu.cow.org> References: <001201cc25f9$82a72be0$87f583a0$@com> <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> <20110609014525.GU71792@neu.cow.org> Message-ID: <23807.1307641668@turing-police.cc.vt.edu> On Wed, 08 Jun 2011 21:45:25 EDT, Ravi Pina said: > We hit some vendor issues which prevented us from having a larger > showing, sadly. Sorry you weren't able to deploy more. But the *important* question is: Did you get enough packet traces/logs/etc of the issue so the vendor is able to take some sort of action? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ravi at cow.org Thu Jun 9 12:51:50 2011 From: ravi at cow.org (Ravi Pina) Date: Thu, 9 Jun 2011 13:51:50 -0400 Subject: Thank you Microsoft (and others) In-Reply-To: <23807.1307641668@turing-police.cc.vt.edu> References: <001201cc25f9$82a72be0$87f583a0$@com> <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> <20110609014525.GU71792@neu.cow.org> <23807.1307641668@turing-police.cc.vt.edu> Message-ID: <20110609175149.GV71792@neu.cow.org> On Thu, Jun 09, 2011 at 01:47:48PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Wed, 08 Jun 2011 21:45:25 EDT, Ravi Pina said: > > > We hit some vendor issues which prevented us from having a larger > > showing, sadly. > > Sorry you weren't able to deploy more. But the *important* question is: > > Did you get enough packet traces/logs/etc of the issue so the vendor is able to > take some sort of action? > The issue was specific to a version of the code and a working version was provided. We were reluctant to rush out the upgrade without due diligence. One could argue we should have upgraded a while ago. I'm not one of those people ;) -r From rps at maine.edu Thu Jun 9 13:00:57 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 9 Jun 2011 14:00:57 -0400 Subject: Cogent IPv6 In-Reply-To: <4DF104C4.8050107@foobar.org> References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF104C4.8050107@foobar.org> Message-ID: Discussion has been had on-list before, suffice to say I respectfully disagree that there is a problem with the current design. On Thu, Jun 9, 2011 at 1:37 PM, Nick Hilliard wrote: > On 09/06/2011 18:19, Ray Soucy wrote: >> >> DHCPv6 does not provide route information because this task is handled >> by RA in IPv6. > > Thankfully this silliness is in the process of being fixed, along with > prefix delegation - so in future, there will be no requirement for either RA > or cartloads of per-interface configuration on routers. > > Nick > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From John_Brzozowski at Cable.Comcast.com Thu Jun 9 13:01:16 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Thu, 9 Jun 2011 18:01:16 +0000 Subject: Thank you Microsoft (and others) In-Reply-To: <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> Message-ID: +1 Jared. Big thanks to all the participants and the ISOC. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 6/8/11 9:20 PM, "Jared Mauch" wrote: >I think it's important to thank Microsoft for leaving sites like xbox >IPv6 enabled. Hope many other participants leave it on as well. > >I think it's a certain sign of the maturity of the protocol and networks >at this stage of the game. > >I have observed some traffic step-down in the network, but it's not >entirely clear if it's lowered to levels pre-v6-day. > >Looking forward to those sharing data at NANOG next week. (I'm not >convinced the data I have is worth sharing, but will send it over to the >nanogpc soon enough..) > >- Jared > >On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: > >> I dont think ISOC dashboard is updating any more. Google is no longer >> advertising AAAA but dashboard still shows green and TTLs were short on >> those records. > > From rps at maine.edu Thu Jun 9 13:10:17 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 9 Jun 2011 14:10:17 -0400 Subject: Thank you Microsoft (and others) In-Reply-To: <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> References: <001201cc25f9$82a72be0$87f583a0$@com> <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> Message-ID: Agreed, in fact, I don't usually applaud Microsoft, but IPv6 wouldn't be nearly as possible as it is today without them. They've been better than almost everyone in making sure IPv6 support has been in place and implemented correctly. On Wed, Jun 8, 2011 at 9:20 PM, Jared Mauch wrote: > I think it's important to thank Microsoft for leaving sites like xbox IPv6 enabled. ?Hope many other participants leave it on as well. > > I think it's a certain sign of the maturity of the protocol and networks at this stage of the game. > > I have observed some traffic step-down in the network, but it's not entirely clear if it's lowered to levels pre-v6-day. > > Looking forward to those sharing data at NANOG next week. ?(I'm not convinced the data I have is worth sharing, but will send it over to the nanogpc soon enough..) > > - Jared > > On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: > >> I dont think ISOC dashboard is updating any more. Google is no longer >> advertising AAAA but dashboard still shows green and TTLs were short on >> those records. > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From iljitsch at muada.com Thu Jun 9 13:14:36 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 9 Jun 2011 20:14:36 +0200 Subject: World IPv6 Only Day. In-Reply-To: References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> <1307594175.3760.44.camel@karl> <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> Message-ID: <2E128C6E-29B0-4540-AD1B-0DB0DAB5513D@muada.com> On 9 jun 2011, at 19:34, Ray Soucy wrote: > But you're correct that without MLD snooping IPv6 ND traffic is on par > with IPv4 broadcast traffic and not a major problem. It does mean, > however, that a large IPv6 multicast stream, like video or system > imaging, would be about as bad as doing so on IPv4 without IGMP > snooping. Of course the ethernet hardware in the host will filter multicast packets the host isn't listening for, so it just wastes some bandwidth on ports where the traffic isn't needed. This is unlike ARP, each ARP packet wakes up the CPU. From trejrco at gmail.com Thu Jun 9 13:56:45 2011 From: trejrco at gmail.com (TJ) Date: Thu, 9 Jun 2011 14:56:45 -0400 Subject: World IPv6 Only Day. In-Reply-To: References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> <1307594175.3760.44.camel@karl> <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> Message-ID: On Thu, Jun 9, 2011 at 13:34, Ray Soucy wrote: > Cisco has had MLD snooping support for some time. But they seem to > have broken it in a recent release, so it drops ND traffic and breaks > IPv6; been after them to fix it, but doesn't look like it's been > resolved yet. > > But you're correct that without MLD snooping IPv6 ND traffic is on par > with IPv4 broadcast traffic and not a major problem. > While I certainly agree it is not a major problem, it should be _even less_ of a problem than ARP. Yes, the non-MLD-snooping switch forwards all multicast to every port - but the other end of those cables (the nodes plugged in to the switch) don't need to process the frame at all - not listening for that MAC. Compared to ARP, where the frame is picked up and handed to layer3/IPv4 before being discarded. /TJ From joly at punkcast.com Thu Jun 9 14:03:16 2011 From: joly at punkcast.com (Joly MacFie) Date: Thu, 9 Jun 2011 15:03:16 -0400 Subject: IPv6 day non-participants In-Reply-To: References: Message-ID: Someone has told me that Microsoft "switched off IPv6" for the day. Is that true? To what extent? j -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From heather.schiller at verizonbusiness.com Thu Jun 9 14:18:03 2011 From: heather.schiller at verizonbusiness.com (Schiller, Heather A) Date: Thu, 09 Jun 2011 19:18:03 +0000 Subject: IPv6 day non-participants In-Reply-To: References: Message-ID: They are probably referring to this: http://support.microsoft.com/kb/2533454/ "The following Fix it solution will resolve the issue by configuring your computer to prefer IPv4, instead of IPv6. By default, Windows prefers IPv6 over IPv4. This Fix it solution is temporary, to resolve issues on World IPv6 Day for affected Internet users. On June 10, 2011 at 12:00AM, your computer will be configured to prefer IPv6 again after your next reboot." --h -----Original Message----- From: Joly MacFie [mailto:joly at punkcast.com] Sent: Thursday, June 09, 2011 3:03 PM To: Wes Hardaker Cc: nanog Subject: Re: IPv6 day non-participants Someone has told me that Microsoft "switched off IPv6" for the day. Is that true? To what extent? j -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From georgeb at gmail.com Thu Jun 9 14:21:12 2011 From: georgeb at gmail.com (George B.) Date: Thu, 9 Jun 2011 12:21:12 -0700 Subject: IPv6 day non-participants In-Reply-To: References: Message-ID: > > IMHO, it's worse than that. ?Most sites only added a AAAA record for > their website, and frequently didn't for their DNS server. ?So they > weren't *really* doing a complete IPv6 test, IMHO. There is a reason for that. First of all, we (my employer) took this as a brief test to simply see how much IPv6 traffic there really was, and who and what would actually attempt to reach us by IPv6. The idea here being to attempt to identify IPv6 native networks. We had to do this in a way that did not break our existing IPv4 services. We run some services that we do not consider "breakable" and our user profile is much different than a web site is. We might have millions of clients on a network that are, for the most part, identically configured. So for example, if one users device believes it has IPv6 but doesn't *really* have IPv6 (as a link local IP so it believes it has IPv6 or has IPv6 inside its network but not clean to the Internet), then there are probably tens of thousands of identically configured devices in that customer's network. So we don't face the "some small fraction of one percent are broken" problem, we face a "if one is broken, then a significant portion of and possibly all of that customer's devices are broken". If we put IPv6 DNS records in place that caused 100,000 clients to break, we would have some serious explaining to do. In this case, a very safe approach was to place an IPv6 address for our web site in DNS. None of our "business" traffic goes to our website. In the course of IPv6 day for the roughly 18 hours it was operating, we might have had 200 hits on IPv6 compared to thousands of transactions per second on our "business" protocols. The test did, however, expose a bug in a piece of vendor gear that was catastrophic to the business service. The entire piece of gear blew up that handles the business traffic in addition to the web traffic. It rebooted itself but apparently did not boot cleanly. This was bad enough but it was rather quickly placed back into service (manual kick) and happened at the slowest traffic time of the day and few/no clients would have noticed. Had we also experienced customer complaints of slow/poor/no service during the time of the test, it would have been pretty bad. So enabling IPv6 DNS had the potential to cause global problems and not limited to a single data center, it could have had global impact to the domain. Placing a single IPv6 DNS glue record and DNS server in service would have also potentially resulted in local DNS servers from around the globe that might prefer IPv6 attempting to reach that one DNS server. In other words, it would have created a potential single point of failure and possibly degraded performance. So the IPv6 DNS infrastructure is being rolled out in a planned, methodical fashion. Dropping an AAAA record for the web site was an easy thing to do that was considered very low risk (as we assumed all of our other gear could simply pass IPv6 packets without exploding) and offered some participation with the community. George (speaking for himself) From jared at puck.nether.net Thu Jun 9 14:21:09 2011 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Jun 2011 15:21:09 -0400 Subject: IPv6 day non-participants In-Reply-To: References: Message-ID: <4A063721-3D7E-41AE-8260-2487465D13DB@puck.nether.net> On Jun 9, 2011, at 3:03 PM, Joly MacFie wrote: > Someone has told me that Microsoft "switched off IPv6" for the day. Is that > true? To what extent? I think this depends on the division. their search (bing) folks turned it off. % host www.bing.com. www.bing.com is an alias for search.ms.com.edgesuite.net. search.ms.com.edgesuite.net is an alias for a134.b.akamai.net. a134.b.akamai.net has address 96.17.150.114 a134.b.akamai.net has address 96.17.150.112 a134.b.akamai.net has address 96.17.150.105 their gaming folks (xbox) left it on. % host www.xbox.com. www.xbox.com is an alias for www.gtm.xbox.com. www.gtm.xbox.com is an alias for msxbwsd.vo.llnwd.net. msxbwsd.vo.llnwd.net has address 208.111.170.165 msxbwsd.vo.llnwd.net has address 68.142.73.109 msxbwsd.vo.llnwd.net has IPv6 address 2607:f4e8:200:12:225:90ff:fe2a:9f9a msxbwsd.vo.llnwd.net has IPv6 address 2607:f4e8:200:11:230:48ff:fed2:5022 (another view on the world) 2011-06-08.out:www.bing.com.|216.156.249.136,216.156.249.152|2600:1406::5043:4aa7,2600:1406::5043:4a8e|OK|OK|OKOK 2011-06-09.out:www.bing.com.|63.236.253.34,63.236.253.75,63.236.253.82,63.236.253.81,63.236.253.32,63.236.253.41,63.236.253.48,63.236.253.25||OK|Name or service not known| 2011-06-08.out:www.xbox.com.|128.242.186.238,128.242.186.198|2001:418:2401:3::c6ad:1531,2001:418:2401:3::c6ad:1548|OK|OK|OKOK 2011-06-09.out:www.xbox.com.|128.242.186.198,128.242.186.238|2a02:26f0:c:1::5c7a:32ba,2a02:26f0:c:1::5c7a:32b2|OK|OK|OKOK From dr at cluenet.de Thu Jun 9 14:23:33 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 9 Jun 2011 21:23:33 +0200 Subject: Quick comparison of LSNs and NAT64 In-Reply-To: References: <4DF053AA.50400@axu.tm> <20110609083143.E9A9910A34C8@drugs.dv.isc.org> Message-ID: <20110609192333.GA9408@srv03.cluenet.de> On Thu, Jun 09, 2011 at 07:39:17AM -0700, Cameron Byrne wrote: > Each solution fits well for some set of constraints and objectives Indeed. Unfortunately there's no good way to support v6-only clients in an environment, where dual stacked endpoints do exist as well, see RFC6147 (DNS64) ch. 6.3.2. We still need to find some solution to that problem. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Thu Jun 9 14:31:50 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 9 Jun 2011 21:31:50 +0200 Subject: World IPv6 Only Day. In-Reply-To: References: <201106090031.32321.fredan-nanog@fredan.se> <4DEFFB64.2090105@he.net> <201106090108.27224.fredan-nanog@fredan.se> <4DF03FFA.4070900@paulgraydon.co.uk> <1307594175.3760.44.camel@karl> <2EA1DD65-21CC-492D-B150-4C0943F216A9@muada.com> Message-ID: <20110609193150.GB9408@srv03.cluenet.de> On Thu, Jun 09, 2011 at 01:34:25PM -0400, Ray Soucy wrote: > Cisco has had MLD snooping support for some time. But they seem to > have broken it in a recent release, so it drops ND traffic and breaks > IPv6; been after them to fix it, but doesn't look like it's been > resolved yet. Nice. Juniper went a step farther - IGMP snooping breaks some IPv6 multicast on EX series (e.g. DHCPv6). :-) Chasing JNPR since November... Not a priority for them to fix though, I think it's "planned" for end of this year in 11.4 or so. Who needs DHCPv6 while using IGMP snooping anyway, eh? :-) So if IGMP snooping already breaks IPv6, I'm really looking forward to upcoming MLD snooping bugs :-) Best regards, Daniel PS: PR/456700 - "closed" state and "resolved in" information is bogus, they don't care to fix that either. It's definately NOT resolved in 10.4R3. And it affects more than just EX8200 - personally confirmed EX3200 and rumor is "all EX". -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From gbonser at seven.com Thu Jun 9 14:35:13 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 9 Jun 2011 12:35:13 -0700 Subject: Cogent IPv6 In-Reply-To: <4DF0D25E.9080903@brightok.net> References: <6ac5bc37$45ab67ae$73965090$@com> <20110609033329.GE24907@hiwaay.net> <4DF0D25E.9080903@brightok.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E377B@RWC-EX1.corp.seven.com> > > Some networks prefer a uniform numbering scheme. /112 allows for > reasonable addressing needs on a circuit. In addition, while Ethernet > is > often used in a point-to-point access circuit, such layouts may change > and renumbering would be annoying. > > Finally, having chunks 4-7 define the circuit and chunk 8 provide the > circuit addressing makes it more human readable and is prone to less > mistakes by those who suck at math. > > > Jack I actually see that as a pretty good compromise. You could have all of your point-to-points at a pop in the same /64, you can give them all ::1 and ::2 addressing, and the addressing scheme supports both point-to-point and point-to-multipoint topologies. A customer with multiple locations in a region could run a circuit from each location and they could possibly all be in the same /112. If they want to multihome to you, they run similar links to a different pop in a different /112 in a different /64 that is part of that pop's /48. And the numbering is consistent at the user end. The ::2 site or ::3 site would be the ::2 site or ::3 from both pops with a different prefix. Seems reasonable to me. From owen at delong.com Thu Jun 9 16:09:44 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Jun 2011 14:09:44 -0700 Subject: Cogent IPv6 In-Reply-To: <957672C2-3DB4-466D-9513-4E1529B6B2E6@muada.com> References: <6ac5bc37$45ab67ae$73965090$@com> <957672C2-3DB4-466D-9513-4E1529B6B2E6@muada.com> Message-ID: On Jun 9, 2011, at 9:56 AM, Iljitsch van Beijnum wrote: > On 9 jun 2011, at 10:32, Owen DeLong wrote: > >> You can actually use DHCPv6 to assign addresses to hosts dynamically >> on longer than /64 networks. > > The trouble is that DHCPv6 can't tell you the prefix length for your address, so either set up the routers to advertise this prefix (but without the autonomous autoconfiguration flag set) or prepare for surprising results. > > I say: life is too short to fiddle with this kind of stuff, just use /64, at least for everything that isn't a point-to-point link or loopback address. I don't disagree with you, but, the claim that you can only choose between SLAAC and Static and therefore only use /64 for dynamic addressing wasn't true. Owen From cabenth at gmail.com Thu Jun 9 17:02:58 2011 From: cabenth at gmail.com (eric clark) Date: Thu, 9 Jun 2011 15:02:58 -0700 Subject: Multi Factor authentication options for wireless networks Message-ID: Wondering what people are using to provide security from their Wireless environments to their corporate networks? 2 or more factors seems to be the accepted standard and yet we're being told that Microsoft's equipment can't do it. Our system being a Microsoft Domain... seemed logical, but they can only do 1 factor. What are you guys using? Thanks From jna at retina.net Thu Jun 9 17:08:44 2011 From: jna at retina.net (John Adams) Date: Thu, 9 Jun 2011 15:08:44 -0700 Subject: Multi Factor authentication options for wireless networks In-Reply-To: References: Message-ID: On Thu, Jun 9, 2011 at 3:02 PM, eric clark wrote: > Wondering what people are using to provide security from their Wireless > environments to their corporate networks? 2 or more factors seems to be the > accepted standard and yet we're being told that Microsoft's equipment can't > do it. Our system being a Microsoft Domain... seemed logical, but they can > only do 1 factor. > What are you guys using? Move to 802.1X with Radius. Connect your APs or AP Controllers to a decent OTP system like otpd+rlm_otp+freeradius and then connect to the Microsoft domain using LDAP. Extend the LDAP schema to hold the private keys for the OTP system. Many vendors offer this solution, although I suggest that you don't go with SecurID or any token vendor that does not disclose their algorithm to you. Go open, and use OATH. The work being done on OATH is where future one-time, two-factor systems are headed: http://www.openauthentication.org/ -john From cabenth at gmail.com Thu Jun 9 17:15:15 2011 From: cabenth at gmail.com (eric clark) Date: Thu, 9 Jun 2011 15:15:15 -0700 Subject: Multi Factor authentication options for wireless networks In-Reply-To: References: Message-ID: Tokens are an option but I should have been more clear. As we're a windows shop (apologies, but that's the way it is), we were planning on going with user credentials and the machine's domain certificate. Your solution might still be viable, but I'm not certain if I can get at the machine certs with LDAP that way,have to check that. On Thu, Jun 9, 2011 at 3:08 PM, John Adams wrote: > On Thu, Jun 9, 2011 at 3:02 PM, eric clark wrote: > >> Wondering what people are using to provide security from their Wireless >> environments to their corporate networks? 2 or more factors seems to be >> the >> accepted standard and yet we're being told that Microsoft's equipment >> can't >> do it. Our system being a Microsoft Domain... seemed logical, but they can >> only do 1 factor. >> What are you guys using? > > > Move to 802.1X with Radius. > > Connect your APs or AP Controllers to a decent OTP system like > otpd+rlm_otp+freeradius and then connect to the Microsoft domain using LDAP. > Extend the LDAP schema to hold the private keys for the OTP system. > > Many vendors offer this solution, although I suggest that you don't go with > SecurID or any token vendor that does not disclose their algorithm to you. > Go open, and use OATH. > > The work being done on OATH is where future one-time, two-factor systems > are headed: > > http://www.openauthentication.org/ > > -john > > From jna at retina.net Thu Jun 9 17:18:02 2011 From: jna at retina.net (John Adams) Date: Thu, 9 Jun 2011 15:18:02 -0700 Subject: Multi Factor authentication options for wireless networks In-Reply-To: References: Message-ID: You could always take the route of not trusting the wireless network at all. Users who get to wireless can only go to the Internet. Put all the APs in a DMZ. Users who can open up a VPN to your microsoft vpn servers can authenticate and get to the corporate network. This is the way things were done on the Apple campus for a long time. -john On Thu, Jun 9, 2011 at 3:15 PM, eric clark wrote: > Tokens are an option but I should have been more clear. > As we're a windows shop (apologies, but that's the way it is), we were > planning on going with user credentials and the machine's domain > certificate. Your solution might still be viable, but I'm not certain if I > can get at the machine certs with LDAP that way,have to check that. > > > On Thu, Jun 9, 2011 at 3:08 PM, John Adams wrote: > >> On Thu, Jun 9, 2011 at 3:02 PM, eric clark wrote: >> >>> Wondering what people are using to provide security from their Wireless >>> environments to their corporate networks? 2 or more factors seems to be >>> the >>> accepted standard and yet we're being told that Microsoft's equipment >>> can't >>> do it. Our system being a Microsoft Domain... seemed logical, but they >>> can >>> only do 1 factor. >>> What are you guys using? >> >> >> Move to 802.1X with Radius. >> >> Connect your APs or AP Controllers to a decent OTP system like >> otpd+rlm_otp+freeradius and then connect to the Microsoft domain using LDAP. >> Extend the LDAP schema to hold the private keys for the OTP system. >> >> Many vendors offer this solution, although I suggest that you don't go >> with SecurID or any token vendor that does not disclose their algorithm to >> you. Go open, and use OATH. >> >> The work being done on OATH is where future one-time, two-factor systems >> are headed: >> >> http://www.openauthentication.org/ >> >> -john >> >> > From ras at e-gerbil.net Thu Jun 9 17:21:33 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 9 Jun 2011 17:21:33 -0500 Subject: Cogent & HE In-Reply-To: References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> Message-ID: <20110609222133.GQ18302@gerbil.cluepon.net> On Thu, Jun 09, 2011 at 12:55:44AM -0700, Owen DeLong wrote: > > Respectfully, RAS, I disagree. I think there's a big difference > between being utterly unwilling to resolve the situation by peering > and merely refusing to purchase transit to a network that appears to > offer little or no value to the purchaser or their customers. Owen, can you please name me one single instance in the history of the Internet where a peering dispute which lead to network partitioning did NOT involve one side saying "hey, we're willing to peer" and the other side saying "no thanks"? Being the one who wants to peer means absolutely NOTHING here, the real question is which side is causing the partitioning, and in this case the answer is very clearly HE. HE wants to peer with Cogent, Cogent doesn't want to peer with HE, and thus you have an impass and there will be no peering. HE has no problem using transit to reach Cogent for IPv4 (I see HE reaching Cogent via 1299/Telia, and Cogent reaching HE via 3549/Global Crossing, both very clearly HE transit providers and Cogent peers), but HE has chosen not to use transit for the IPv6 traffic. Quite simply, HE feels that they are entitled to peer with Cogent for the IPv6 traffic, and has deliberately chosen to create this partition to try and force the issue. These are *PRECISELY* the same motivations and actions as EVERY OTHER NETWORK who has ever created a network partition in pursuit of peering that the other party doesn't want to give them, period. Again, this isn't necessarily a bad thing if HE thinks it can work to their long term advantage, but to try and claim that this is anything else is completely disingenuous. I understand that you have a PR position to take, and you may even have done a good job convincing the weak minded who don't understand how peering works that HE is the victim, but please don't try to feed a load of bullshit to the rest of us. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From intensifysecurity at gmail.com Thu Jun 9 17:39:18 2011 From: intensifysecurity at gmail.com (Jeff Hartley) Date: Thu, 9 Jun 2011 18:39:18 -0400 Subject: Quick comparison of LSNs and NAT64 In-Reply-To: <20110609192333.GA9408@srv03.cluenet.de> References: <4DF053AA.50400@axu.tm> <20110609083143.E9A9910A34C8@drugs.dv.isc.org> <20110609192333.GA9408@srv03.cluenet.de> Message-ID: > Indeed. Unfortunately there's no good way to support v6-only clients in > an environment, where dual stacked endpoints do exist as well, see > RFC6147 (DNS64) ch. 6.3.2. > > We still need to find some solution to that problem. > We've been using two workarounds: 1. Separate DNS resolvers (both BIND 9.8; one DNS64 and the other DNS6). Have the client provisioning system assign the appropriate DNS server IPs (dual-stack to anycast set 1, v6-only to anycast set 2). 2. Use range-specific views to determine whether or not to apply DNS64 (this setup isn't standard BIND, though). One is a kludge, and the other is vendor-specific, but they work. -Jeff From brian.peter.dickson at gmail.com Thu Jun 9 18:06:29 2011 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Thu, 9 Jun 2011 19:06:29 -0400 Subject: Cogent & HE Message-ID: RAS wrote: >On Thu, Jun 09, 2011 at 12:55:44AM -0700, Owen DeLong wrote: >> >> Respectfully, RAS, I disagree. I think there's a big difference >> between being utterly unwilling to resolve the situation by peering >> and merely refusing to purchase transit to a network that appears to > offer little or no value to the purchaser or their customers. >Owen, can you please name me one single instance in the history of the >Internet where a peering dispute which lead to network partitioning did >NOT involve one side saying "hey, we're willing to peer" and the other >side saying "no thanks"? Being the one who wants to peer means >absolutely NOTHING here, the real question is which side is causing the >partitioning, and in this case the answer is very clearly HE. I don't know if Owen can, but I know I can. Back in the day, when there were many fewer Tier-1's but the number was growing, there were enough disputes over peering requests that there was a danger of things actually getting regulated (e.g. by the dreaded FCC). As part of one of the many mergers, the biggest player at that time (AS 701), made their peering requirements public, *and* honored those requirements. So, long history short, there were in fact peering disputes that had one side saying, "hey, we want to peer" and the other side saying "you don't have enough traffic", or "your ratio is too imbalanced", or "you're my customer - tough!". And some of those got resolved by the ratios changing, or the traffic levels reaching sufficiently high. (I can historically mention AS 6453.) Some of the other early players didn't play fair, and to my knowledge still don't. You have to know someone, or be named "Ren" to get peering with them. (Sorry, Ren. :-)) IMHO, what Cogent are effectively trying to do, is to extort "paid peering", masquerading as transit. Personally, I think the global traffic patterns, loss/latency/jitter, and general karma of the Internet would be improved, if those who currently peer with Cogent were to do evaluate the impact of de-peering them: - How many networks are *single*-homed behind Cogent? - Is anyone who *needs* Internet connectivity that unwise (to be single homed anywhere, let alone behind Cogent)? - If they *are* single-homed-to-Cogent, they aren't *your* customers. :-) - (This could be applied to both IPv6 *and* IPv4 - the logic is the same) Brinksmanship, like virtue or stupidity, is its own reward. Brian P.S. In the ancient game "go", there's a special rule on the two players playing alternate single-piece steals, that limits it to N times for very small N. The game becomes futile and pointless, beyond a certain number of repeated moves. Ditto for not peering. From sclark at netwolves.com Thu Jun 9 18:20:29 2011 From: sclark at netwolves.com (Steve Clark) Date: Thu, 09 Jun 2011 19:20:29 -0400 Subject: Cogent & HE In-Reply-To: <20110609222133.GQ18302@gerbil.cluepon.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609222133.GQ18302@gerbil.cluepon.net> Message-ID: <4DF1553D.6060104@netwolves.com> On 06/09/2011 06:21 PM, Richard A Steenbergen wrote: > On Thu, Jun 09, 2011 at 12:55:44AM -0700, Owen DeLong wrote: >> Respectfully, RAS, I disagree. I think there's a big difference >> between being utterly unwilling to resolve the situation by peering >> and merely refusing to purchase transit to a network that appears to >> offer little or no value to the purchaser or their customers. > Owen, can you please name me one single instance in the history of the > Internet where a peering dispute which lead to network partitioning did > NOT involve one side saying "hey, we're willing to peer" and the other > side saying "no thanks"? Being the one who wants to peer means > absolutely NOTHING here, the real question is which side is causing the > partitioning, and in this case the answer is very clearly HE. > > HE wants to peer with Cogent, Cogent doesn't want to peer with HE, and > thus you have an impass and there will be no peering. HE has no problem > using transit to reach Cogent for IPv4 (I see HE reaching Cogent via > 1299/Telia, and Cogent reaching HE via 3549/Global Crossing, both very > clearly HE transit providers and Cogent peers), but HE has chosen not to > use transit for the IPv6 traffic. Quite simply, HE feels that they are > entitled to peer with Cogent for the IPv6 traffic, and has deliberately > chosen to create this partition to try and force the issue. These are > *PRECISELY* the same motivations and actions as EVERY OTHER NETWORK who > has ever created a network partition in pursuit of peering that the > other party doesn't want to give them, period. > > Again, this isn't necessarily a bad thing if HE thinks it can work to > their long term advantage, but to try and claim that this is anything > else is completely disingenuous. I understand that you have a PR > position to take, and you may even have done a good job convincing the > weak minded who don't understand how peering works that HE is the > victim, but please don't try to feed a load of bullshit to the rest of > us. :) > From reading everything you have said my impression is YOU either work for Cogent or have an axe to grind with HE. Otherwise I can see no reason for your obvious bias against HE. -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From ras at e-gerbil.net Thu Jun 9 18:20:59 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 9 Jun 2011 18:20:59 -0500 Subject: Cogent & HE In-Reply-To: References: Message-ID: <20110609232059.GS18302@gerbil.cluepon.net> On Thu, Jun 09, 2011 at 07:06:29PM -0400, Brian Dickson wrote: > > So, long history short, there were in fact peering disputes that had > one side saying, "hey, we want to peer" and the other side saying "you > don't have enough traffic", or "your ratio is too imbalanced", or > "you're my customer - tough!". And some of those got resolved by the > ratios changing, or the traffic levels reaching sufficiently high. (I > can historically mention AS 6453.) How is that different from what I said? One side wants to peer, the other side says "no thanks". A list of reasons is nice, especially if they will actually grant peering after you meet those requirements (instead of just changing their requirements to deny you again :P), but immaterial to the point. In EVERY peering dispute there is one side who wants to peer, but that doesn't make this side any more noble or right, especially if they don't meet the requirements and are simply trying to force the peering through intentionally creating a partition then playing the propaganda game to blame the other side for it. Everyone complained when Cogent did it to others, why should it be any different when HE does it to Cogent? I'm sorry but I don't accept "because Cogent is giving away free IPv6 transit right now" as a valid reason, especially when it very clearly advances their goals of artificially inflating their customer base specifically so they CAN engage in these peering disputes. It's a perfectly valid tactic that has been used by the finest networks for years, but at least have the decency to admit it for what it is, that's all I'm saying. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From mysidia at gmail.com Thu Jun 9 18:26:01 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 9 Jun 2011 18:26:01 -0500 Subject: Cogent & HE In-Reply-To: <20110609222133.GQ18302@gerbil.cluepon.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609222133.GQ18302@gerbil.cluepon.net> Message-ID: On Thu, Jun 9, 2011 at 5:21 PM, Richard A Steenbergen wrote: > On Thu, Jun 09, 2011 at 12:55:44AM -0700, Owen DeLong wrote: Er, Sorry... you are kind of siding with Cogent and claiming HE responsible without any logically sound argument explicitly stated that supports that position... I would consider them both responsible for the partition, with Cogent slightly more complicit, in that Cogent's expectation of selling HE transit is slightly less reasonable than HE's expectation of Cogent peering with HE. Perhaps Cogent is actually responsible, because Cogent has failed to ask HE to peer, and Cogent has not sought to buy transit from HE to correct the network partition. > HE wants to peer with Cogent, Cogent doesn't want to peer with HE, and > thus you have an impass and there will be no peering. HE has no problem > using transit to reach Cogent for IPv4 (I see HE reaching Cogent via Cogent wants HE to buy IPv6 transit with Cogent, HE doesn't want to buy IPv6 transit with Cogent, and thus you have an impass, and there will be no buying of transit. [References to IPv4 networks are irrelevent; the IPv4 internet is not like the IPv6 internet.] > 1299/Telia, and Cogent reaching HE via 3549/Global Crossing, both very > clearly HE transit providers and Cogent peers), but HE has chosen not to > use transit for the IPv6 traffic. Quite simply, HE feels that they are > entitled to peer with Cogent for the IPv6 traffic, and has deliberately Cogent has chosen not to use transit for the IPv6 traffic to HE. Quite simply, Cogent feels they are entitled to sell transit to HE for the IPv6 traffic, and has deliberately > chosen to create this partition to try and force the issue. These are > *PRECISELY* the same motivations and actions as EVERY OTHER NETWORK who has ever created a network partition in pursuit of selling transit that the other party doesn't want to buy, period. > Again, this isn't necessarily a bad thing if HE thinks it can work to Again, this isn't necessarily a bad thing if Cogent thinks it can work to > their long term advantage, but to try and claim that this is anything > else is completely disingenuous. I understand that you have a PR > position to take, and you may even have done a good job convincing the > weak minded who don't understand how peering works that HE is the weak minded who don't understand how peering works that Cogent is the > victim, but please don't try to feed a load of bullshit to the rest of > us. :) -- -JH From marka at isc.org Thu Jun 9 18:29:47 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 10 Jun 2011 09:29:47 +1000 Subject: Quick comparison of LSNs and NAT64 In-Reply-To: Your message of "Thu, 09 Jun 2011 07:39:17 MST." References: <4DF053AA.50400@axu.tm> <20110609083143.E9A9910A34C8@drugs.dv.isc.org> Message-ID: <20110609232947.A447C10AA73A@drugs.dv.isc.org> In message , Cameron Byrne writes: > --000e0ce0b4eaf1531104a5486aed > Content-Type: text/plain; charset=ISO-8859-1 > > On Jun 9, 2011 1:32 AM, "Mark Andrews" wrote: > > > > > > In message <4DF053AA.50400 at axu.tm>, Aleksi Suhonen writes: > > > Hello, > > > > > > Some people were talking about Large Scale NATs (LSN) or Carrier Grade > > > NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are > > > basically LSNs and they suffer from all the same problems. I don't think > > > that NAT64 is as bad as other LSNs and here's why: > > > > > > NAT64 scales much better than NAT44 and NAT444(*) > > > > > > The trick is with its companion DNS64. If you need more NAT64 capacity, > > > you can just add more NAT64 boxes with unique /96 prefixes around your > > > network and have your DNS64 load-balance traffic to those boxes. You can > > > also map one A record into two AAAA records of different NAT64 boxes, in > > > case that works better with some application protocols. > > > > You can add more capacity with DS-Lite as well though it does take a while > > for the DHCP option to be refreshed without push support. > > > > > The smallest granularity of load-balancing easily available with NAT444 > > > is per customer or per customer group. DNS64 allows per flow granularity > > > for load-balancing without even breaking a sweat. > > > > > > I've been testing NAT64 at home using a public NAT64 trial and generally > > > I've been very happy with it: > > > > > > http://www.trex.fi/2011/dns64.html > > > > > > A neat feature I've liked is that I don't have to pass all my traffic > > > via the NAT64 box, and so it doesn't have to be between me and the > > > Internet. NAT44 usually acts as a fuse between me and my Internet. > > > > You don't have to pass all the traffic through the AFTR box or the > > LSN when dual stacked either. The AFTR box can be on the other > > side of the world or out sourced if you want it to be. The same > > can be done with NAT64. > > > > > The biggest downsides I've encountered are: > > > > > > I. Some streaming websites use IP addresses in their video stream > > > URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64. > > > Thankfully these are a minority. > > > > Not a problem with DS-Lite or NAT444. > > > > > II. Networked games usually use some sort of a tracker to help clients > > > find games to connect to, and those only use plain IP addresses too. And > > > some games only query for A records, and thus can't benefit from DNS64 > > > either. > > > > Not a problem with DS-Lite or NAT444 > > > > > So I guess the optimal way to stretch the lifetime of IPv4 while still > > > moving toward IPv6 all the time would be to dual-stack customers and > > > deploy both NAT64/DNS64 and some other LSN which can handle the two > > > downsides above. All the traffic that you can shift to NAT64 means that > > > your other LSN (which doesn't scale as well) can handle that much more > > > traffic before becoming a bottleneck. And naturally, you'll want to > > > shift all that youtube/facebook/whatever traffic to native IPv6 to help > > > both NAT boxes cope. > > > > > > My 2 cents delivered, > > > > > > -- > > > Aleksi Suhonen > > > > > > () ascii ribbon campaign > > > /\ support plain text e-mail > > > > > > (*) NAT44 means the normal NAT from private IPv4 addresses to public > > > IPv4 addresses. NAT444 means that there are two layers of NAT boxes: > > > usually one at customer premises and the other at the ISP, doing LSN. > > > > > All good and accurate info. I would just restate that nat64 unlike nat444 > does not need to be "on path", this is what drives its improved scaling over > nat444. NAT44 only needs to be on the IPv4 path. It does NOT need to be on the IPv6 path. Similarly NAT64 and AFTR need to be on the IPv4 path not the IPv6 path. > Also, unlike ds-lite, nat64 works without any special client, such as the b4 > function in the ds-lite architecture. Any fully functional ipv6 system such > as win7 can work out of the box (ipv4 only apps being the exception) No. It needs a specialised nameserver with DNS64 support, which prevents machines running there own nameserver until they get such a nameserver and get the prefix information to configure the DNS64 component. As for the B4, I can manually configure that on 10 year old boxes. It's basically a IPv4 in IPv6 tunnel. > Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by > making ipv6 end to end and forcing applications to be AF agnostic .... as > where the others enable ipv4 without any backpressure. DS-lite and NAT444 don't break existing applications. If you have a green field deployment the limitations of NAT64/DNS64 can often be overlooked. When you are deploying into a exist IPv4 network you don't have the luxury of breaking more existing applications that is absolutely necessary. > Each solution fits well for some set of constraints and objectives > > Cb > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joelja at bogus.com Thu Jun 9 18:36:42 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 9 Jun 2011 16:36:42 -0700 Subject: Multi Factor authentication options for wireless networks In-Reply-To: References: Message-ID: <78AF2B07-762B-4605-BFC7-F52ED72D8508@bogus.com> We use wireless authentication for the purposes of protecting the link layer... authenticated users are still outside the privileged corprate network and therefore need to vpn in. joel On Jun 9, 2011, at 3:02 PM, eric clark wrote: > Wondering what people are using to provide security from their Wireless > environments to their corporate networks? 2 or more factors seems to be the > accepted standard and yet we're being told that Microsoft's equipment can't > do it. Our system being a Microsoft Domain... seemed logical, but they can > only do 1 factor. > What are you guys using? > > Thanks > From ras at e-gerbil.net Thu Jun 9 18:49:58 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 9 Jun 2011 18:49:58 -0500 Subject: Cogent & HE In-Reply-To: References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609222133.GQ18302@gerbil.cluepon.net> Message-ID: <20110609234958.GU18302@gerbil.cluepon.net> On Thu, Jun 09, 2011 at 06:26:01PM -0500, Jimmy Hess wrote: > Er, Sorry... you are kind of siding with Cogent and claiming HE > responsible without any logically sound argument explicitly stated > that supports that position... You're confused, read again. :) > I would consider them both responsible for the partition, with Cogent > slightly more complicit, in that Cogent's expectation of selling HE > transit is slightly less reasonable than HE's expectation of Cogent > peering with HE. Cogent is (unfortunately, note I have no particular love for Cogent here) a transit free network, who peers with every other Tier 1. HE is a perfectly fine network, but they are not even CLOSE to a transit free network. HE buys transit from multiple other networks, including 3549/Global Crossing and 1299/Telia (both easily visible in the routing table), which they use to reach Cogent for IPv4. There is absolutely NO requirement that there be a direct interconnection between HE and Cogent. None, period, and if you think otherwise you are vastly confused about routing on the Internet. Let me say this again, there is NO requirement that HE buy transit from Cogent, but there is a requirement that HE buy transit from *SOMEONE* if they are not a transit free network. HE has deliberately chosen NOT to use transit for their IPv6 routes, in order to force people like Cogent to peer with them so they can become an "IPv6 Tier 1", and thus you have a partition. These are the same tactics and strategies used by every other network in pursuit of becoming a Tier 1, including Cogent, and everyone complained their ass off when Cogent caused partitioning several times during THEIR peering disputes on the road to their current transit free status. If your answer is "I like HE better than Cogent so I'm willing to overlook it", that's fine, but you're just making things up if you're trying to claim that they AREN'T causing this partition. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From mysidia at gmail.com Thu Jun 9 19:18:49 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 9 Jun 2011 19:18:49 -0500 Subject: Cogent & HE In-Reply-To: <20110609234958.GU18302@gerbil.cluepon.net> References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609222133.GQ18302@gerbil.cluepon.net> <20110609234958.GU18302@gerbil.cluepon.net> Message-ID: On Thu, Jun 9, 2011 at 6:49 PM, Richard A Steenbergen wrote: > On Thu, Jun 09, 2011 at 06:26:01PM -0500, Jimmy Hess wrote: You seem to have missed it, so I will say again: IPv6 is not IPv4. They are two different internetworks, with different participants -- many IPv4 networks have no IPv6 counterpart as of yet. Having any kind of IPv6 network is a new thing for Cogent; they opened shop, when, 2008, sometime? I'm pretty sure HE had an IPv6 network and a greater degree of connectivity, before you could get IPv6 from Cogent. Many Tier1 IPv4 networks had no IPv6 network for a long time; the first day an IPv4 Tier1 turns on IPv6 doesn't magically make them IPv6 Tier1 -- because the v6 network has a different topology, there are many 'holes' in the graph, where the new network's peering arrangements will be IPv4 only. An IPv4 Tier1 might actually need to buy transit to get connected to the IPv6 internet, if they are sufficiently late for the show. There is a chance IPv4 and IPv6 topologies will become more similar in the future, but for now that is not the case, and that is no reason to confuse the two networks, or speak as if they are one and the same. Cogent doesn't have a transit-free global IPv6 network view. > Cogent is (unfortunately, note I have no particular love for Cogent > here) a transit free network, who peers with every other Tier 1. HE is a No, Cogent has a transit free IPv4 network; Cogent peers with every other IPv4 Tier 1. It appears as if they are trying to use their IPv4 Tier1 status as a strategic piece, to attempt to get Tier1 status on the IPv6 network. That might work well with other Tier1s who are also behind in IPv6 deployment, and possibly apt to peer with Cogent. But that effort doesn't automatically make Cogent a Tier1 on the IPv6 network. We'll just have to wait and see about that, I think. > perfectly fine network, but they are not even CLOSE to a transit free > network. HE buys transit from multiple other networks, including You mean HE is not close to being a transit free IPv4 network. They have a very nearly transit-free IPv6 network. > There is absolutely NO requirement that there be a direct > interconnection between HE and Cogent. None, period, and if you think > otherwise you are vastly confused about routing on the Internet. Let me > say this again, there is NO requirement that HE buy transit from Cogent, > but there is a requirement that HE buy transit from *SOMEONE* if they > are not a transit free network. HE doesn't need to buy IPv6 transit, because they are in effect transit-free (except to Cogent). > HE has deliberately chosen NOT to use transit for their IPv6 routes, in > order to force people like Cogent to peer with them so they can become > an "IPv6 Tier 1", and thus you have a partition. These are the same -JH From jra at baylink.com Thu Jun 9 19:39:50 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 9 Jun 2011 20:39:50 -0400 (EDT) Subject: OT: Google logo In-Reply-To: <20110609192500.A11344@iglou.com> Message-ID: <25335664.20.1307666390612.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Fairlight" > Not just graphics...the fact that Chrome is HTML5 compliant. That's how > they're doing what they're doing with this one, and the previous one with > all the physics balls that would blow around, etc. FF4 too apparently; I had it. -- jr 'call you tomorrow, Brian' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Thu Jun 9 19:43:28 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 9 Jun 2011 20:43:28 -0400 (EDT) Subject: Yup; the Internet is screwed up. Message-ID: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster That can't be good. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jimi.thompson at gmail.com Thu Jun 9 22:22:09 2011 From: jimi.thompson at gmail.com (Jimi Thompson) Date: Thu, 9 Jun 2011 22:22:09 -0500 Subject: Ready For A Good Laugh Message-ID: Ok, I have to paste this in time order so that the rest of you can play along.... it all started when I tried to transfer in a new domain name for - of all people, my future father in law. I am SO not screwing that up because I don't want to hear it at every family gathering.... Since my hunny bunny who is somewhat technical has been managing it, he wanted me take it over mainly so that we could host his email on the server I already run. I apologize in advance for the HTML email, but plain text just can't convey some things - including the phishy appearance of the official emails that come from these people. Email #1 - Dated May 4 * Aplus.Net 110 East Broward Boulevard, Suite 1650 Fort Lauderdale, FL 33301 Phone: 1.877.275.8763 * * Customer Information* Name: Jimi Thompson Customer number: * Amount due: * All amounts in US dollars. *Service Description* *Term* *Total* Domain Registration -- Domain name: XXXXXXX -- Ongoing fee from 2011-05-04 to 2012-05-04 1 year $12.99 1 month $0.00 *Total Savings* *$0.00* *Total Due Now* *$12.99* Keep in mind that this is just the domain registration - NO hosting. I do my own hosting. So I get this on May 5. Congratulations on your decision to host with Aplus.net! We're proud to have your business, and we're committed to making your web hosting experience a success. This email provides you with information on how to get started. Please keep this message for future reference. Thanks again for choosing Aplus.net! Best regards, Your Aplus.net Team Now what I can't paste in here are the several rather heated telephone conversations we had because they don't preserve the DNS servers when a domain name is transferred to them. Oh, no... YOU get a parking page until the transfer is complete and you can manage the name servers. And I was informed that the transfer would take at least 5 business days. And the user interface doesn't allow you to set the DNS servers until after the transfer is completed.With the weekend included, that was nearly a full week of down time. Completely unacceptable. Finally, they agreed to cancel the transfer. This missive arrives after a few hours of wrangling with their tech support and DNS support people, who incidentally are also unable to set the name servers until the transfer is complete. And during all this, I am required to recite both my user name and password. Since one phone call happened at Taco Bell during my lunch break, I'm understandably upset over having to give sensitive credentials in order to attempt to obtain some assistance. Dear Jimi Thompson We confirm that the following domain transfer has been cancelled. Followed Immediately By This Dear valued customer, Your email has been received by the Aplus.net Support Team. One of our technical support representatives will review and respond to your request. Should you have an immediate question or concern, please call us at 877.275.8763, or try our chat service at www.aplus.net (select Technical Support). Our reps are available 24 hours a day, 7 days a week. If you have questions related to the recent platform enhancements, please visit http://faq.aplus.net to view answers to many frequently asked questions. Thank you for choosing Aplus.net. We appreciate your continued business. Sincerely, Aplus.net And not long after that arrived, I got this: Hello Jimi, Thank you for contacting Aplus.net Technical Support! We have forwarded your question on to our Customer Service Department team, and they will be able to assist you with this issue. You will be hearing back from them directly. If you prefer to contact Customer Service Department directly, you can reach them at billing at cs.aplus.net or by phone 877-275-8763 option 3+1 for United States and 858-410-6929 option 3+1 Worldwide. For more information about the Aplus.net Upgrade or for answers to Frequently Asked Questions please visit our Aplus.net FAQ at http://faq.aplus.net. To find out more about how to set up your email account visit http://faq.aplus.net/email To find out more about domain registration visit http://faq.aplus.net/domain To find out more about how to connect to your site using FTP visit http://faq.aplus.net To find out more about new DNS settings visit http://faq.aplus.net/dns Did You Know? You can review or submit tickets to the Aplus.net Support Team through your control panel. To review or submit a ticket simply take the following steps: 1. Log into your control panel. 2. Select "My Account". 3. Click on the "Tickets" icon. To assist us in serving you better, please do not delete any portion of the Technical Support Specialist correspondences. For your convenience we are available 24 hours a day, 7 days a week and invite you to contact us if you have any additional concerns. Regards, Sylvia Y. Technical Support Specialist APLUS.NET , a Deluxe Company Phone: 877.275.8763 Email: support at aplus.net www.aplus.net I'm having a Foamy the Squirrel moment by this point. All I want is my dang $12.99 back and by now it's completely a matter of principle. After a few more phone calls during which I was forced to give both the user name and password yet again - full credentials - over my cell phone to the registrar, I finally get this. Having to give out my user name and password is flatly ridiculous. Fortunately, I'm able to find a private area where I can do this without being overheard. On May 5, 2011, a Refund of USD $ 12.99 was successfully applied to your credit card. Amount processed: USD $12.99 TOTAL: USD $12.99 Questions? Our staff of professionals are ready to assist you, 7 days a week, 24 hours a day. Contact us by email at support at cs.aplus.net or by phone toll-free at 877-275-8763. For billing assistance, please email billing at cs.aplus.net. We want to make sure you're satisfied with your Aplus.Net account, and we look forward to providing you with highest level of service possible. Please don't hesitate to contact us with any questions or concerns. On June 1, I log in to transfer some more domain names to my new domain registrar. I find that these are not only still showing my FIL's domain but have it set to autorenew. So I write to inform them that they are not the registrar of record and that this should be removed as they are not authoritative for it. Mind you that attached to this missive was the entire thread for the cancellation and the refund, which they could easily have verified on their end using their own transaction numbers. Note the multiple fonts and font sizes and how the last sentence cuts off. My hunny bunny thought it was a phishing attempt. Had I not initiated the contact with them, I would have too. Here's what I got back: Jimi, Good Morning, Thank you for contacting Aplus.net, a Deluxe company! For security we will need you to verify your registration number and the main account password please. Once verified we are able to process your request. If you have any questions we have agents available on the telephone and Regards, Billing Department APLUS.NET , a Deluxe Company 877-275-8763 International 858.410.6929 Option 3 then 1 At this point, I'm pretty angry and pretty fed up with their craptastic security model. And so yes, they got a very snarky reply. Why? Because they had the nerve to tell me over the phone that they are protecting me from the theft of my domains by asking me to send via an unecrypted email the necessary account information to log in and transfer those domains. WTF???? But wait... it gets better.... MUCH MUCH better, in fact. Wow... I'm supposed to hand over my log in credentials over the phone. I'm certainly NOT doing that via email. Seriously????? Do you people have any concept of security???????? At all? And I'm supposed to trust you with important business assets for myself and my customers.... Now I'm going to go off on you people - What kind of crack are you people smoking? If you even for a moment think that I'm going to email you what amounts to my user name and password to the entire account you are either A) very high in which case you think this o.k. to do or B) such complete window-licking morons who are obviously wearing your foam helmets cinched down a little to tight since they seem to have cut off the miniscule blood supply to your tiny brains. Considering that this is the email account you have on file, this is just another reason that I'll be changing registrars. I've already moved 5 of my domains and I'll keep moving the rest. The reply I get some hours later... Jimi, Good afternoon, to make any changes to your account you will need to verify yourself. You do this by verifying the main account password, if you do not have this we can send it to the email on file. If you are not comfortable emailing this information then you will need to call in and speak with an agent. Regards, Billing Department APLUS.NET , a Deluxe Company 877-275-8763 International 858.410.6929 Option 3 then 1 Since they started advertising that they're "a DeLuxe Company", I figured I'd hunt down the parent corp in the hopes that there is someone there who might have an idea of what a clue is. And the answer is no... Good morning. My name is Jocef Knapp and I am a member of Aplus.net's Escalations & Retentions team. I was hoping to speak to you regarding your post on the Deluxe Blog (copied below). We appreciate your business as well as any feedback regarding our services, support, and policies. While I understand your position and your worries about giving out information over the phone and email, please try to understand this practice. Webhosting and domain registration as an industry experiences a very high amount of attempted theft and fraud. In many cases once an account is compromised, rights to the domain name, files, and emails are unable to be fully recovered, and often will lead to lengthy legal battles. Therefore, security of our customers' accounts is of the upmost important to us, and we do our best to not divulge any account information or give account details away. This means that each request for support that may involve the slightest account details must first go through a procedure to verify that we are speaking only to the account holder, or a person to whom they have authorized account access. The goal is to provide the best customer support experience possible while protecting the account security of the customer and our company from litigation. In order to verify that we are speaking to an authorized user, it is our standard procedure to ask for the account password. This includes phone, chat, and email conversations. It is not flawless, as you said emails are never completely secure. However, I have been with Aplus.net for several years, and have seen several verification methods come and go, and this procedure seems to work best. Should you not feel comfortable sharing this information over email, we do offer both live chat and phone support 24 hours a day, 7 days a week. I understand that you may not feel comfortable giving this information over the phone in some environments, unfortunately we cannot control where you make your phone calls from, or who may be in earshot of your voice. We can simply secure our end of things, and provide you with alternative means to reach us for support. Should you not have your password or truly not feel comfortable at all sharing it, you may request that our support contact you directly at the home or business phone number on file for your account. We will get back to you as soon as possible. Should this still be unacceptable or if you have no access to your account information, your case may be escalated, however this may involve a slightly longer turn around time. Again, we appreciate your business and I am sorry that you are frustrated with our verification policies, I hope my email helps in this regard. If you have any questions or concerns regarding our verification policy, please do not hesitate to contact me Jocef Knapp Sr. Technical Lead Escalations and Retentions APLUS.NET , A Deluxe Company [image: Phone]1-888-771-7587 ext. 646808 [image: Email]jocefk at aplus.net [image: Aplus.net Logo] Thanks, Jimi From joe at nethead.com Thu Jun 9 22:46:05 2011 From: joe at nethead.com (Joe Hamelin) Date: Thu, 9 Jun 2011 20:46:05 -0700 Subject: Ready For A Good Laugh In-Reply-To: References: Message-ID: On Thu, Jun 9, 2011 at 8:22 PM, Jimi Thompson wrote: > Ok, I have to paste this in time order so that the rest of you can play > along.... tl';dr Summary: cheap registers abound. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 re a From tvhawaii at shaka.com Thu Jun 9 23:31:44 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 9 Jun 2011 18:31:44 -1000 Subject: Ready For A Good Laugh References: Message-ID: <641557933CAC4813AEF30E1DFA4778A5@owner59e1f1502> Jimi Thompson wrote: > Now I'm going to go off on you people - What kind of crack are you people > smoking? The same stuff they're smoking over at PayPal. Some genius decided to send out E-mails which said: "Hello , It looks like you may be using an outdated browser with known security issues. Help keep your computer and your PayPal account protected by updating your browser today." and included a link (different from what was represented). Even magaged to fool the folks at spoof at paypal.com 11 pages of wtf? at: https://www.paypal-community.com/t5/Fraud-phishing-and-spoof/New-scam/td-p/273626 From jra at baylink.com Thu Jun 9 23:39:52 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 10 Jun 2011 00:39:52 -0400 (EDT) Subject: Ready For A Good Laugh In-Reply-To: Message-ID: <929220.34.1307680792664.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Hamelin" > On Thu, Jun 9, 2011 at 8:22 PM, Jimi Thompson > wrote: > > Ok, I have to paste this in time order so that the rest of you can > > play along.... > > tl';dr It's a damned shame there isn't a .dr ccTLD, isn't it? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From rmcneilly at ColumbusGrenada.com Thu Jun 9 23:52:46 2011 From: rmcneilly at ColumbusGrenada.com (Richard McNeilly) Date: Fri, 10 Jun 2011 00:52:46 -0400 Subject: Hotmail Problems Message-ID: <3AE06D8D6A4B8E4AA9F8BBF2DB5D96FE8F2B8C@mailsrv.ColumbusGrenada.com> Any other operators getting complaints from subscribers about not being able to open emails in hotmail? The problem seems to be random. Are there are hotmail administrators on this list? Richard From ulf at Alameda.net Fri Jun 10 00:33:08 2011 From: ulf at Alameda.net (Ulf Zimmermann) Date: Thu, 9 Jun 2011 22:33:08 -0700 Subject: Hotmail Problems In-Reply-To: <3AE06D8D6A4B8E4AA9F8BBF2DB5D96FE8F2B8C@mailsrv.ColumbusGrenada.com> References: <3AE06D8D6A4B8E4AA9F8BBF2DB5D96FE8F2B8C@mailsrv.ColumbusGrenada.com> Message-ID: <20110610053308.GC44339@evil.alameda.net> On Fri, Jun 10, 2011 at 12:52:46AM -0400, Richard McNeilly wrote: > > Any other operators getting complaints from subscribers about not being able to open emails in hotmail? The problem seems to be random. Are there are hotmail administrators on this list? > > Richard > At my work we do have some complaints about email to Hotmail not showing up. One users is sending email to two different users at Hotmail, one of those receives them, the other not. Both are accepted by the Hotmail relays. From jeroen at unfix.org Fri Jun 10 00:37:59 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 10 Jun 2011 07:37:59 +0200 Subject: Cogent & HE In-Reply-To: References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609222133.GQ18302@gerbil.cluepon.net> <20110609234958.GU18302@gerbil.cluepon.net> Message-ID: <4DF1ADB7.9040908@unfix.org> On 2011-Jun-10 02:18, Jimmy Hess wrote: > On Thu, Jun 9, 2011 at 6:49 PM, Richard A Steenbergen wrote: >> On Thu, Jun 09, 2011 at 06:26:01PM -0500, Jimmy Hess wrote: > > You seem to have missed it, so I will say again: IPv6 is not IPv4. First you seem to have missed the point where the Internet is since the day before yesterday the combination of IPv4+IPv6. You also seemed to have missed the part where Tier1 are supposed to provide quality native multi-path connectivity globally and not peering mostly in a tunneled fashion (oh MTU what you don't reveal) with one little router stashed at an unmanned IX. Especially that tunneled part requires IPv4 to actually be able to transmit those IPv6 packets, thus without the Tier1 status in IPv4 you really cannot claim Tier1 in IPv6 in that case. Also note that prefix count says nothing, first aggregate all the prefixes properly, ignoring ASNs which use prefixes out of a PA dump, then see how many are actually left. Of course as an extra and possibly way more important metric: check how many of those prefixes you would actually like to reach (that is where you have an interest of sending packets to/from). You might indeed be able to 'complete' your routes with it, but are those routes worth it calling something a Tier1? ;) Greets, Jeroen From globichen at gmail.com Fri Jun 10 02:01:54 2011 From: globichen at gmail.com (Andy B.) Date: Fri, 10 Jun 2011 09:01:54 +0200 Subject: Cogent & HE In-Reply-To: References: <1139995622-1307562524-cardhu_decombobulator_blackberry.rim.net-510085940-@b11.c14.bise6.blackberry> <20110608200505.GD18302@gerbil.cluepon.net> <20110609222133.GQ18302@gerbil.cluepon.net> <20110609234958.GU18302@gerbil.cluepon.net> Message-ID: On Fri, Jun 10, 2011 at 2:18 AM, Jimmy Hess wrote: > HE doesn't need to buy IPv6 transit, because they are in effect transit-free > (except to Cogent). It's not just a Cogent issue. They also chose not to buy from Level3 or buy those routes through a Level3 peer: >From HE's route-server: route-server> sh bgp ipv6 regexp _3356_ % No Results route-server> sh bgp ipv6 regexp _174_ % No Results - Andy From dr at cluenet.de Fri Jun 10 02:11:28 2011 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 10 Jun 2011 09:11:28 +0200 Subject: Quick comparison of LSNs and NAT64 In-Reply-To: References: <4DF053AA.50400@axu.tm> <20110609083143.E9A9910A34C8@drugs.dv.isc.org> <20110609192333.GA9408@srv03.cluenet.de> Message-ID: <20110610071128.GA3605@srv03.cluenet.de> On Thu, Jun 09, 2011 at 06:39:18PM -0400, Jeff Hartley wrote: > We've been using two workarounds: > 1. Separate DNS resolvers (both BIND 9.8; one DNS64 and the other > DNS6). Have the client provisioning system assign the appropriate DNS > server IPs (dual-stack to anycast set 1, v6-only to anycast set 2). > 2. Use range-specific views to determine whether or not to apply DNS64 > (this setup isn't standard BIND, though). > > One is a kludge, and the other is vendor-specific, but they work. Not for SLAAC environments and others where there is no mandatory endpoint registration. E.g. residential LANs. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Fri Jun 10 02:14:25 2011 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 10 Jun 2011 09:14:25 +0200 Subject: Quick comparison of LSNs and NAT64 In-Reply-To: <20110609232947.A447C10AA73A@drugs.dv.isc.org> References: <4DF053AA.50400@axu.tm> <20110609083143.E9A9910A34C8@drugs.dv.isc.org> <20110609232947.A447C10AA73A@drugs.dv.isc.org> Message-ID: <20110610071425.GB3605@srv03.cluenet.de> On Fri, Jun 10, 2011 at 09:29:47AM +1000, Mark Andrews wrote: > DS-lite and NAT444 don't break existing applications. They do, to different degrees. There is plenty of evidence for that. > > Each solution fits well for some set of constraints and objectives Pick your poison. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jeroen at easyhosting.nl Fri Jun 10 02:25:03 2011 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Fri, 10 Jun 2011 09:25:03 +0200 Subject: Cogent IPv6 In-Reply-To: References: <6ac5bc37$45ab67ae$73965090$@com> <4DF0406A.9030609@kenweb.org> <1307608785.2039.4.camel@teh-desktop> <4DF0C1A9.9010000@kenweb.org> Message-ID: <4DF1C6CF.1000207@easyhosting.nl> Here in the Netherlands we got it 'free' (i.e. dual-stack on top of the IPv4 transit without extra cost) But we're currently looking into an alternative for a provider with non-broken IPv6 transit and cancel our contract with Cogent. They called us once asking how satisfied we were with their IPv6 transit. After bringing up the HE issue the conversation ended surprisingly fast. The Google depeering thing was the final straw, all our transits can provide a reasonably complete IPv6 prefix table, except for Cogent. On 6/9/11 7:14 PM, Jeff Wheeler wrote: > but just two weeks ago I heard about this IPv6 surcharge stupidity > still being applied to Cogent's customers in Europe. > > -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From a.harrowell at gmail.com Fri Jun 10 03:24:01 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 10 Jun 2011 09:24:01 +0100 Subject: Ready For A Good Laugh In-Reply-To: <641557933CAC4813AEF30E1DFA4778A5@owner59e1f1502> References: <641557933CAC4813AEF30E1DFA4778A5@owner59e1f1502> Message-ID: <201106100924.31310.a.harrowell@gmail.com> On Friday 10 Jun 2011 05:31:44 Michael Painter wrote: > Jimi Thompson wrote: > > Now I'm going to go off on you people - What kind of crack are you people > > smoking? > > The same stuff they're smoking over at PayPal. > Some genius decided to send out E-mails which said: > "Hello , > > It looks like you may be using an outdated browser with known security issues. > > Help keep your computer and your PayPal account protected by updating your browser today." > > and included a link (different from what was represented). > Even magaged to fool the folks at spoof at paypal.com > 11 pages of wtf? at: > https://www.paypal-community.com/t5/Fraud-phishing-and-spoof/New-scam/td- p/273626 > PayPal has been doing this for as long as I've been a member. They are terrible ones for sending out e-mails to teach you to type passwords into the spam. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From iljitsch at muada.com Fri Jun 10 05:01:25 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 12:01:25 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <4DF104C4.8050107@foobar.org> References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF104C4.8050107@foobar.org> Message-ID: On 9 jun 2011, at 19:37, Nick Hilliard wrote: >> DHCPv6 does not provide route information because this task is handled >> by RA in IPv6. > Thankfully this silliness is in the process of being fixed, So where do I point out the stupidity of trying to fix this non-brokenness? > along with prefix delegation Also works fine. > - so in future, there will be no requirement for either RA or cartloads of per-interface configuration on routers. Good luck with that. Next month, the last major operating system will add support for DHCPv6. Which was published in 2003. So now you want to change some more stuff so in 2019 we can finally actually start USING DHCPv6? From iljitsch at muada.com Fri Jun 10 05:03:33 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 12:03:33 +0200 Subject: IPv6 routing protocols In-Reply-To: <4DF105D8.7050300@foobar.org> References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF10101.4010407@foobar.org> <4DF105D8.7050300@foobar.org> Message-ID: On 9 jun 2011, at 19:41, Nick Hilliard wrote: > Iljitsch noted: "IPv6 routing protocols also pretty much only use link locals". This is not true in the general case. So which routing protocols communicate using global addresses then? As far as I know only BGP but BGP runs over TCP so it's different from all other routing protocols. And it still carries link local next hop addresses. From sthaug at nethelp.no Fri Jun 10 05:10:37 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 10 Jun 2011 12:10:37 +0200 (CEST) Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> Message-ID: <20110610.121037.74748867.sthaug@nethelp.no> > >> DHCPv6 does not provide route information because this task is handled > >> by RA in IPv6. > > > Thankfully this silliness is in the process of being fixed, > > So where do I point out the stupidity of trying to fix this non-brokenness? Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. > > - so in future, there will be no requirement for either RA or cartloads of per-interface configuration on routers. > > Good luck with that. Next month, the last major operating system will add support for DHCPv6. Which was published in 2003. > > So now you want to change some more stuff so in 2019 we can finally actually start USING DHCPv6? We're planning to use DHCPv6 and RA (with no prefixes, only for the link local next hop). This is more complex than using DHCPv6 alone, without RA, would be. When and if DHCPv6 without RA is possible, we certainly plan to turn off RA on our BRAS boxes. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From iljitsch at muada.com Fri Jun 10 05:20:16 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 12:20:16 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610.121037.74748867.sthaug@nethelp.no> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> Message-ID: On 10 jun 2011, at 12:10, sthaug at nethelp.no wrote: >> So where do I point out the stupidity of trying to fix this non-brokenness? > Several large operators have said, repeatedly, that they want to use > DHCPv6 without RA. I disagree that this is stupid. It is a mistake to want this, because having the router tell you who the router is gives you fait sharing so less breakage. It's also unnecessary because you still need cooperation from your switches to be safe from rogue DHCPv6 servers even if you go visit all your hosts and turn off stateless autoconfig in an effort to thwart rogue RAs. But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes. > We're planning to use DHCPv6 and RA (with no prefixes, only for the > link local next hop). This is more complex than using DHCPv6 alone, > without RA, would be. It is. It's also more robust. And doing this is less complex than trying to change DHCPv6 so you get to use a less complex system in the future after a complex transition. From nick at foobar.org Fri Jun 10 05:20:54 2011 From: nick at foobar.org (Nick Hilliard) Date: Fri, 10 Jun 2011 11:20:54 +0100 Subject: IPv6 routing protocols In-Reply-To: References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF10101.4010407@foobar.org> <4DF105D8.7050300@foobar.org> Message-ID: <4DF1F006.3010501@foobar.org> On 10/06/2011 11:03, Iljitsch van Beijnum wrote: > As far as I know only BGP but BGP runs over TCP so it's different from > all other routing protocols. OSPF runs over protocol ospf, so it's also different from the other routing protocols. EIGRP uses protocol 88 and ISIS runs over CLNS so both of them must be different too. On the other hand, RIP runs on UDP, so I guess that it must be the same as all the other routing protocols. (sorry, but I'm lost as to what point you were making here :-) > And it still carries link local next hop > addresses. it's a bit more subtle than that - it depends on how the underlying router operating system handles next-hop resolution and how you configure your BGP. Nick From iljitsch at muada.com Fri Jun 10 05:27:24 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 12:27:24 +0200 Subject: IPv6 routing protocols In-Reply-To: <4DF1F006.3010501@foobar.org> References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF10101.4010407@foobar.org> <4DF105D8.7050300@foobar.org> <4DF1F006.3010501@foobar.org> Message-ID: <88A0EBA4-039B-4028-9623-B58693ACBB1B@muada.com> On 10 jun 2011, at 12:20, Nick Hilliard wrote: [nothing to support his earlier claim] >> And it still carries link local next hop >> addresses. > it's a bit more subtle than that - it depends on how the underlying router operating system handles next-hop resolution and how you configure your BGP. It doesn't depend. RFC 4760: An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute. From iljitsch at muada.com Fri Jun 10 05:37:34 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 12:37:34 +0200 Subject: IPv6 routing protocols In-Reply-To: <88A0EBA4-039B-4028-9623-B58693ACBB1B@muada.com> References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF10101.4010407@foobar.org> <4DF105D8.7050300@foobar.org> <4DF1F006.3010501@foobar.org> <88A0EBA4-039B-4028-9623-B58693ACBB1B@muada.com> Message-ID: <0E0F104D-1B8F-4D64-9FD6-2AB78FE3F577@muada.com> On 10 jun 2011, at 12:27, Iljitsch van Beijnum wrote: > RFC 4760: > An UPDATE message that carries the MP_REACH_NLRI MUST also carry the > ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP > exchanges). Moreover, in IBGP exchanges such a message MUST also > carry the LOCAL_PREF attribute. Sorry, this is stupid. I should have read beyond "LOCAL". So it depends a little, but I still don't see any implementation leeway in RFC 2545: 3. Constructing the Next Hop field A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop. The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field. The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16). From tjc at ecs.soton.ac.uk Fri Jun 10 05:40:58 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 10 Jun 2011 11:40:58 +0100 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> Message-ID: On 10 Jun 2011, at 11:20, Iljitsch van Beijnum wrote: > On 10 jun 2011, at 12:10, sthaug at nethelp.no wrote: > >>> So where do I point out the stupidity of trying to fix this non-brokenness? > >> Several large operators have said, repeatedly, that they want to use >> DHCPv6 without RA. I disagree that this is stupid. > > It is a mistake to want this, because having the router tell you who the router is gives you fait sharing so less breakage. It's also unnecessary because you still need cooperation from your switches to be safe from rogue DHCPv6 servers even if you go visit all your hosts and turn off stateless autoconfig in an effort to thwart rogue RAs. > > But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes. Well, remember that, from Google's estimate, only 0.3% of the access networks are IPv6 capable, so there's still 99.7% to deploy. But yes, any changes to add features a la draft-droms-dhc-dhcpv6-default-router-00 would take time, and support in the IETF seems minimal. >> We're planning to use DHCPv6 and RA (with no prefixes, only for the >> link local next hop). This is more complex than using DHCPv6 alone, >> without RA, would be. > > It is. It's also more robust. And doing this is less complex than trying to change DHCPv6 so you get to use a less complex system in the future after a complex transition. The focus right now should be on getting the existing RA+DHCPv6 to work as intended, and to validate the model within the 0.3% base. I don't buy that a transition from RA+DHCP to DHCP-only is particularly complex though. Turn off the RAs and let DHCP do it's (extra) things. However, you'd then need to know that every device you want to network supports that new DHCP-only operation, and that will be some time off, if it happens at all. Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6. Tim From iljitsch at muada.com Fri Jun 10 06:03:14 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 13:03:14 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> Message-ID: <875F5E6C-1C2A-4C10-BADB-60684F99827C@muada.com> On 10 jun 2011, at 12:40, Tim Chown wrote: >> But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes. > Well, remember that, from Google's estimate, only 0.3% of the access networks are IPv6 capable, so there's still 99.7% to deploy. There's deployment of code and deployment of configuration. The former is in good shape now, so better not tinker with it unnecessarily. It's also not very useful to count the 80% of the internet that consists of home users behind the cheapest home gateway running with the default settings the same way as we count the other 20% who actually have an opinion on the matter. > I don't buy that a transition from RA+DHCP to DHCP-only is particularly complex though. Turn off the RAs and let DHCP do it's (extra) things. Well, but if you turn off RAs while there are still systems that can't understand a new DHCPv6 router address option, then those systems have no idea where the routers are so they don't work. > Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6. The trouble is that having the correct router NOT send RAs buys you very little: in theory you can now skip coordination between different departments if the DHCPv6 and router configs are handled by different people. In practice, you need to coordinate regardless because the routers need to know where to send the packets so they need to have the prefixes that the DHCPv6 servers assign from configured on their interfaces. What you really want is for the hosts to ignore RAs sent by incorrect routers. This means turning off autoconfig on the hosts, which seems, at the very least, an uphill struggle unless we're talking about places with hosts bolted to the floor so the configuration can be tied to a specific network. And in that case you can do tons of other stuff, such as SEND or simply statically configuring everything. Lest anyone accuse me of raining on their parade: I think very workable compromise would be to have a router preference option in DHCPv6. This way, routers still advertise themselves, but if there are multiple routers, the DHCPv6 info is the tie breaker so rogue RAs are avoided when this option is understood. But doing this doesn't impose difficulties on hosts that don't implement the new option. From hank at efes.iucc.ac.il Fri Jun 10 07:22:59 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 10 Jun 2011 15:22:59 +0300 (IDT) Subject: Strongest Solar Tsunami in Years to Hit Earth Today Message-ID: http://www.ibtimes.com/articles/159964/20110609/nasa-solar-flare-tsunami-earth-sun-radio-satellite-interference-aurora-displays-coronal-mass-ejectio.htm -Hank From nick at foobar.org Fri Jun 10 07:26:09 2011 From: nick at foobar.org (Nick Hilliard) Date: Fri, 10 Jun 2011 13:26:09 +0100 Subject: IPv6 routing protocols In-Reply-To: <0E0F104D-1B8F-4D64-9FD6-2AB78FE3F577@muada.com> References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF10101.4010407@foobar.org> <4DF105D8.7050300@foobar.org> <4DF1F006.3010501@foobar.org> <88A0EBA4-039B-4028-9623-B58693ACBB1B@muada.com> <0E0F104D-1B8F-4D64-9FD6-2AB78FE3F577@muada.com> Message-ID: <4DF20D61.7060508@foobar.org> On 10/06/2011 11:37, Iljitsch van Beijnum wrote: > So it depends a little, but I still don't see any implementation leeway in RFC 2545: On all competently constructed interior networks, ibgp will use loopbacks as the session endpoints. This means that the loopback address will be carried as the next-hop in the UPDATE messages rather than the link local address. Ok, you can do physical interface to physical interface on ibgp if you want, and if you do, good luck with that idea. For those bgp sessions which use directly connected subnets (e.g. most ebgp and badly configured interior networks), this is implementation dependent. Some stacks by default provide both the link-local and the global address; others provide just the global address; others still will provide link-local depending on interface configuration (e.g. the per-interface "ipv6 enable" command on IOS). Once the router has learned the next-hop, it may or may not choose to display it differently when you're displaying ipv6 forwarding information. Some router stacks implement implicit next-hop resolution for their own RIB to forwarding table; others don't. Some will display this information and others don't. So really, it depends. Nick From iljitsch at muada.com Fri Jun 10 07:30:50 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 14:30:50 +0200 Subject: IPv6 routing protocols In-Reply-To: <4DF20D61.7060508@foobar.org> References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF10101.4010407@foobar.org> <4DF105D8.7050300@foobar.org> <4DF1F006.3010501@foobar.org> <88A0EBA4-039B-4028-9623-B58693ACBB1B@muada.com> <0E0F104D-1B8F-4D64-9FD6-2AB78FE3F577@muada.com> <4DF20D61.7060508@foobar.org> Message-ID: <2B5FC4A4-4B85-419E-A154-6084298923D7@muada.com> On 10 jun 2011, at 14:26, Nick Hilliard wrote: [...] Of course none of this supports your original claim: > "IPv6 routing protocols also pretty much only use link locals". This is not true in the general case. From tim at pelican.org Fri Jun 10 07:48:21 2011 From: tim at pelican.org (Tim Franklin) Date: Fri, 10 Jun 2011 13:48:21 +0100 (BST) Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: Message-ID: <0da8e2a8-aae4-414c-873d-6dcdedf22ba7@jennyfur.pelican.org> > Standing back a little, I can see an argument that IPv6 would be an > easier 'sell' if there were two modes of operation, one with only > RAs, and one with only DHCPv6. This +1. There are plenty of enterprises, employing actual network engineers (allegedly), who are just about getting to grips with CIDR and VLSM. They are *thinking* about reconfiguring their hosts to stop having 10.x.x.x/8 as the interface address, and letting proxy-arp on the routers worry about which subnets are which. They *might* have been convinced that an ATM cloud (or sometimes even MPLS!) has robust traffic separation, and they don't need a full mesh of leased lines any more. IPv6 is hugely scary as it is, without breaking their "hosts and host info" / "routers and routing info" silo model. Not all of the networking world runs on Internet time :( Regards, Tim. From bzeeb-lists at lists.zabbadoz.net Fri Jun 10 08:03:01 2011 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri, 10 Jun 2011 13:03:01 +0000 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610.121037.74748867.sthaug@nethelp.no> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> Message-ID: On Jun 10, 2011, at 10:10 AM, sthaug at nethelp.no wrote: >>>> DHCPv6 does not provide route information because this task is handled >>>> by RA in IPv6. >> >>> Thankfully this silliness is in the process of being fixed, >> >> So where do I point out the stupidity of trying to fix this non-brokenness? > > Several large operators have said, repeatedly, that they want to use > DHCPv6 without RA. I disagree that this is stupid. I wonder if it's just a "violation" of rule #1: stop thinking legacy! People are used to what they have done for a decade or two. It's hard to see the change and results in "why is this all so different and complicated?". It's hard to open ones mind for the new, but it is essential to do with new technology. So I advice people not to get trapped by their legacy habits! /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From sthaug at nethelp.no Fri Jun 10 08:17:07 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 10 Jun 2011 15:17:07 +0200 (CEST) Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <20110610.121037.74748867.sthaug@nethelp.no> Message-ID: <20110610.151707.74737321.sthaug@nethelp.no> > > Several large operators have said, repeatedly, that they want to use > > DHCPv6 without RA. I disagree that this is stupid. > > I wonder if it's just a "violation" of rule #1: stop thinking legacy! If having a significant infrastructure that supports IPv4 DHCP is legacy, yes then you could argue that this is legacy. "Stop thinking legacy" is easy to say - however, it has a very real *cost* if you need to change large parts of this infrastructure. >From my own point of view, I also regard the dependency DHCPv6 on RA as a completely *unnecessary* dependency which has been introduced with IPv6. I would much rather have DHCPv6 as a protocol that can be operated on its own, without RA. [Yes, you would still need Neighbor Discovery / Neighbor Solicitation.] Steinar Haug, Nethelp consulting, sthaug at nethelp.no From tme at americafree.tv Fri Jun 10 08:19:24 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 10 Jun 2011 09:19:24 -0400 Subject: Strongest Solar Tsunami in Years to Hit Earth Today In-Reply-To: References: Message-ID: <265E1DC9-9346-4BBF-8B47-D8E7969C2913@americafree.tv> On Jun 10, 2011, at 8:22 AM, Hank Nussbacher wrote: > http://www.ibtimes.com/articles/159964/20110609/nasa-solar-flare-tsunami-earth-sun-radio-satellite-interference-aurora-displays-coronal-mass-ejectio.htm > > -Hank > > If you are interested in the actual event, watch the AIA video of the explosion (flare) itself in the highest bandwidth you can tolerate : http://sohowww.nascom.nasa.gov/hotshots/index.html/ Regards Marshall From rps at maine.edu Fri Jun 10 08:27:41 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 10 Jun 2011 09:27:41 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <0da8e2a8-aae4-414c-873d-6dcdedf22ba7@jennyfur.pelican.org> References: <0da8e2a8-aae4-414c-873d-6dcdedf22ba7@jennyfur.pelican.org> Message-ID: My goodness, this argument comes up a lot. Firstly, RA isn't broken, and DHCPv6 isn't broken. Second, work IS being done to provide DHCPv6 with a method of handing out additional routing information: http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-01 So I'm not sure what all the fuss is about here. Third, the point of keeping RA and DHCPv6 separate was exactly this. You make a change to RA and it will take 10 years to get implemented; you add a feature to DHCPv6 and you have a good chance of seeing it adopted in months rather than years. While I support the route option in DHCPv6; I support it for administrators who need non-standard routing setups because they're stuck on some archaic topology that they are unable to migrate away from. I'd counter the OPs assertion that RA is "silly" with the suggestion of using DHCPv6 only and not RA is even more silly. The router knows if it's up, the router knows what it's connected to, the router can making routing decisions in real time. The DHCPv6 server has no idea if the router is up or what it's connected to beyond what it's been told, and because updates are infrequent it makes any changes take very long. You still need to protect against rogue DHCPv6, and it still needs to be done at the switch. Not really sure what everyone is so worked up about here, aside from wanting IPv6 to be more like IPv4 (ignoring that they were probably the ones complaining about IPv4 working this way when they were migrating away from Apple Talk or IPX). On Fri, Jun 10, 2011 at 8:48 AM, Tim Franklin wrote: >> Standing back a little, I can see an argument that IPv6 would be an >> easier 'sell' if there were two modes of operation, one with only >> RAs, and one with only DHCPv6. > > This +1. > > There are plenty of enterprises, employing actual network engineers (allegedly), who are just about getting to grips with CIDR and VLSM. ?They are *thinking* about reconfiguring their hosts to stop having 10.x.x.x/8 as the interface address, and letting proxy-arp on the routers worry about which subnets are which. ?They *might* have been convinced that an ATM cloud (or sometimes even MPLS!) has robust traffic separation, and they don't need a full mesh of leased lines any more. > > IPv6 is hugely scary as it is, without breaking their "hosts and host info" / "routers and routing info" silo model. ?Not all of the networking world runs on Internet time :( > > Regards, > Tim. > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From bicknell at ufp.org Fri Jun 10 08:32:43 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Jun 2011 06:32:43 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> Message-ID: <20110610133243.GA19449@ussenterprise.ufp.org> In a message written on Fri, Jun 10, 2011 at 01:03:01PM +0000, Bjoern A. Zeeb wrote: > On Jun 10, 2011, at 10:10 AM, sthaug at nethelp.no wrote: > > Several large operators have said, repeatedly, that they want to use > > DHCPv6 without RA. I disagree that this is stupid. > > I wonder if it's just a "violation" of rule #1: stop thinking legacy! > > People are used to what they have done for a decade or two. It's hard to > see the change and results in "why is this all so different and complicated?". > It's hard to open ones mind for the new, but it is essential to do with new > technology. The problem in this case is that the failure modes are significantly different. Some folks have learned this the hard way. It's a very easy scenario to reconstruct. Consider the "branch office router" in a typical corporate enviornment. We're talking a device with one WAN port, and one LAN port. Configure it for dual stack, speaking IPv4, and in IPv4 configure it the typical corporate way with a "DHCP Helper" forwarding requests over the WAN to a central DHCP server. In IPv6, configure it with RA's, the supposed "better" way. Now, take the 100% working branch router and have it sent back to corporate. Maybe they got a bigger router, maybe the office closed. A network engineer gets the router and is tasked with making it ready to redeploy. The network engineer plugs it into the switch on his desktop, plugs in a serial cable, turns it on and steps out to get a coffee while it boots. He's planning to erase the configuration and then load new software over the network. As soon as the router boots the IPv6 network fails for all the users on his subnet. IPv4 keeps working fine. Oops. What happened? Well, the router sent IPv6 RA's as soon as it came up, and every workstation instantly started using them. In IPv4, the router received DHCPv4 requests and forwarded them per the helper address, except that its WAN port is down, and thus it in fact didn't send them anywhere. The important points: - IPv4 "failed safe" with the DHCP config. This "rogue device" will never disrupt the IPv4 configuration. DHCP snooping isn't even needed in your switches, since it never returns a response. - IPv6 "failed immediately" with the RA configuration. What's worse is if you simply turn the device off after you realized you took down the entire network devices will continue to be broken for 2-4 hours until the RA's time out. The only method to mitigate is to deploy RA guard on all of your switches, which probably means replacing 100% of your hardware with new stuff that can do that, and then deploying new features. The fact of the matter is that the failure modes of these two protocols are vastly different operationally. The DHCP failure semantics are not only better understood, but cause less disruption to the network. Even a properly rouge DHCP server will only damage _new_ clients coming up on a network, existing folks will work just fine. Contrast with RA's which instantly break 100% of the users. Even more annoying is that if I use RA's for the default gateway, I still have to run DHCPv6 anyway. If I don't my boxes don't have DNS servers, NTP servers, know where to tftpboot, etc. It's not a choice of one or the other, it's I always run DHCPv6, do I need RA's or not. Given the failure modes I would much prefer to run with RA's turned off completely, and have DHCPv6 able to provide a default gateway just as it works in IPv4. My opinion comes not from "thinking legacy", indeed my employer has been fully dual stacked since 2003. My opinion comes from the fact that in the 8 years of operational experience we have RA's are significantly more fragile, and IMHO not ready for widespread IPv6 deployment. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jared at puck.nether.net Fri Jun 10 08:36:51 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 10 Jun 2011 09:36:51 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> Message-ID: <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> On Jun 9, 2011, at 8:43 PM, Jay Ashworth wrote: > Even Cracked realizes this: > > http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster I would describe this as "local market failure". It's common even in highly populated areas, not just rural ones here in the US. What I have observed is the roll-out of the AT&T U-verse service (aka internet-lite as it is not possible to disable some of their ALG on the gateway) skip areas along the way to hit higher density neighborhoods. They are getting better with their pair bonding, but many people are unable to get access at the edges of these populated areas. - Jared (who would have rather seen google roll into an entire county that faces these challenges vs major cities) From rps at maine.edu Fri Jun 10 08:37:11 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 10 Jun 2011 09:37:11 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610133243.GA19449@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> Message-ID: You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you? Honestly. This whole argument is getting ridiculous. On Fri, Jun 10, 2011 at 9:32 AM, Leo Bicknell wrote: > In a message written on Fri, Jun 10, 2011 at 01:03:01PM +0000, Bjoern A. Zeeb wrote: >> On Jun 10, 2011, at 10:10 AM, sthaug at nethelp.no wrote: >> > Several large operators have said, repeatedly, that they want to use >> > DHCPv6 without RA. I disagree that this is stupid. >> >> I wonder if it's just a "violation" of rule #1: stop thinking legacy! >> >> People are used to what they have done for a decade or two. ?It's hard to >> see the change and results in "why is this all so different and complicated?". >> It's hard to open ones mind for the new, but it is essential to do with new >> technology. > > The problem in this case is that the failure modes are significantly > different. ?Some folks have learned this the hard way. > > It's a very easy scenario to reconstruct. ?Consider the "branch > office router" in a typical corporate enviornment. ?We're talking > a device with one WAN port, and one LAN port. ?Configure it for > dual stack, speaking IPv4, and in IPv4 configure it the typical > corporate way with a "DHCP Helper" forwarding requests over the WAN > to a central DHCP server. ?In IPv6, configure it with RA's, the > supposed "better" way. > > Now, take the 100% working branch router and have it sent back to > corporate. ?Maybe they got a bigger router, maybe the office closed. > A network engineer gets the router and is tasked with making it > ready to redeploy. > > The network engineer plugs it into the switch on his desktop, plugs in a > serial cable, turns it on and steps out to get a coffee while it boots. > He's planning to erase the configuration and then load new software over > the network. > > As soon as the router boots the IPv6 network fails for all the users on > his subnet. ?IPv4 keeps working fine. > > Oops. > > What happened? ?Well, the router sent IPv6 RA's as soon as it came > up, and every workstation instantly started using them. ?In IPv4, > the router received DHCPv4 requests and forwarded them per the > helper address, except that its WAN port is down, and thus it in > fact didn't send them anywhere. > > The important points: > > - IPv4 "failed safe" with the DHCP config. ?This "rogue device" will > ?never disrupt the IPv4 configuration. ?DHCP snooping isn't even needed > ?in your switches, since it never returns a response. > > - IPv6 "failed immediately" with the RA configuration. ?What's worse is > ?if you simply turn the device off after you realized you took down the > ?entire network devices will continue to be broken for 2-4 hours until > ?the RA's time out. ?The only method to mitigate is to deploy RA guard > ?on all of your switches, which probably means replacing 100% of your > ?hardware with new stuff that can do that, and then deploying new > ?features. > > The fact of the matter is that the failure modes of these two > protocols are vastly different operationally. ?The DHCP failure > semantics are not only better understood, but cause less disruption > to the network. ?Even a properly rouge DHCP server will only damage > _new_ clients coming up on a network, existing folks will work just > fine. ?Contrast with RA's which instantly break 100% of the users. > > Even more annoying is that if I use RA's for the default gateway, > I still have to run DHCPv6 anyway. ?If I don't my boxes don't have > DNS servers, NTP servers, know where to tftpboot, etc. ?It's not a > choice of one or the other, it's I always run DHCPv6, do I need > RA's or not. > > Given the failure modes I would much prefer to run with RA's turned off > completely, and have DHCPv6 able to provide a default gateway just as it > works in IPv4. > > My opinion comes not from "thinking legacy", indeed my employer has been > fully dual stacked since 2003. ?My opinion comes from the fact that in > the 8 years of operational experience we have RA's are significantly > more fragile, and IMHO not ready for widespread IPv6 deployment. > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From cmadams at hiwaay.net Fri Jun 10 08:47:46 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 10 Jun 2011 08:47:46 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> Message-ID: <20110610134746.GA11923@hiwaay.net> Once upon a time, Jared Mauch said: > On Jun 9, 2011, at 8:43 PM, Jay Ashworth wrote: > > Even Cracked realizes this: > > > > http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster > > I would describe this as "local market failure". It's common even in highly populated areas, not just rural ones here in the US. I'd go so far as to say "user failure". If I wanted cable TV (especially if I needed it at home as part of my job), I wouldn't buy/rent/lease/whatever a home without checking that cable TV is available at that location. I live in a city with two cable providers, each of which covers the "whole" city, yet there are pockets where one (or even both) don't provide service. Before I bought my house, I made sure I could get my preferred Internet service at my house. There are definately things wrong with the state of last-mile Internet access in the US, but moving somewhere without checking is IMHO your own fault. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bicknell at ufp.org Fri Jun 10 08:47:44 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Jun 2011 06:47:44 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> Message-ID: <20110610134744.GA20607@ussenterprise.ufp.org> In a message written on Fri, Jun 10, 2011 at 09:37:11AM -0400, Ray Soucy wrote: > You really didn't just write an entire post saying that RA is bad > because if a moron of a network engineer plugs an incorrectly > configured device into a production network it may cause problems, did > you? No, I posed the easiest way to recreate this issue. I've seen the entire NANOG and IETF lans taken out because some dork enabled microsoft connecting sharing to their cell card. I've seen entire corporate networks taken out because someone ran the patch cable to the wrong port. The point is, RA's are operationally fragile and DHCP is operationally robust. You can choose to stick your head in the sand about that if you want, but it's still true. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From rps at maine.edu Fri Jun 10 08:53:06 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 10 Jun 2011 09:53:06 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610134744.GA20607@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> Message-ID: I can also take down a network with spanning-tree, but oh wait, we protect against that don't we. Maybe protecting against rogue RA to begin with would be a better idea than waiting until a problem happens. Just saying. On Fri, Jun 10, 2011 at 9:47 AM, Leo Bicknell wrote: > In a message written on Fri, Jun 10, 2011 at 09:37:11AM -0400, Ray Soucy wrote: >> You really didn't just write an entire post saying that RA is bad >> because if a moron of a network engineer plugs an incorrectly >> configured device into a production network it may cause problems, did >> you? > > No, I posed the easiest way to recreate this issue. > > I've seen the entire NANOG and IETF lans taken out because some > dork enabled microsoft connecting sharing to their cell card. > > I've seen entire corporate networks taken out because someone ran > the patch cable to the wrong port. > > The point is, RA's are operationally fragile and DHCP is operationally > robust. ?You can choose to stick your head in the sand about that > if you want, but it's still true. > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From kyle.creyts at gmail.com Fri Jun 10 09:01:13 2011 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Fri, 10 Jun 2011 10:01:13 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <20110610134746.GA11923@hiwaay.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> Message-ID: I think the point is the ubiquity of access isn't what it should be. On Fri, Jun 10, 2011 at 9:47 AM, Chris Adams wrote: > Once upon a time, Jared Mauch said: > > On Jun 9, 2011, at 8:43 PM, Jay Ashworth wrote: > > > Even Cracked realizes this: > > > > > > > http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster > > > > I would describe this as "local market failure". It's common even in > highly populated areas, not just rural ones here in the US. > > I'd go so far as to say "user failure". If I wanted cable TV > (especially if I needed it at home as part of my job), I wouldn't > buy/rent/lease/whatever a home without checking that cable TV is > available at that location. I live in a city with two cable providers, > each of which covers the "whole" city, yet there are pockets where one > (or even both) don't provide service. > > Before I bought my house, I made sure I could get my preferred Internet > service at my house. > > There are definately things wrong with the state of last-mile Internet > access in the US, but moving somewhere without checking is IMHO your own > fault. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > -- Kyle Creyts Information Assurance Professional From scott.brim at gmail.com Fri Jun 10 09:04:30 2011 From: scott.brim at gmail.com (Scott Brim) Date: Fri, 10 Jun 2011 10:04:30 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <20110610134746.GA11923@hiwaay.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> Message-ID: On Fri, Jun 10, 2011 at 09:47, Chris Adams wrote: > I'd go so far as to say "user failure". ?If I wanted cable TV > (especially if I needed it at home as part of my job), I wouldn't > buy/rent/lease/whatever a home without checking that cable TV is > available at that location. Yeah, he messed up, but the social problem is still real. The Internet is now more important than electricity or water -- you can go off the grid or dig your own well, but more and more you can't get a job or talk to the government without web access and email. From iljitsch at muada.com Fri Jun 10 09:08:06 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 16:08:06 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610134744.GA20607@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> Message-ID: <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> On 10 jun 2011, at 15:47, Leo Bicknell wrote: > I've seen the entire NANOG and IETF lans taken out because some > dork enabled microsoft connecting sharing to their cell card. Ok, so now we've identified the problem. How exactly does adding default gateway information to DHCPv6 solve this problem? Are there perhaps easier and more timely ways to solve it? (And it's insane that Windows still exhibits this completely broken behavior.) From bill at herrin.us Fri Jun 10 09:10:13 2011 From: bill at herrin.us (William Herrin) Date: Fri, 10 Jun 2011 10:10:13 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF104C4.8050107@foobar.org> Message-ID: On Fri, Jun 10, 2011 at 6:01 AM, Iljitsch van Beijnum wrote: > On 9 jun 2011, at 19:37, Nick Hilliard wrote: > >>> DHCPv6 does not provide route information because this task is handled >>> by RA in IPv6. > >> Thankfully this silliness is in the process of being fixed, > > So where do I point out the stupidity of trying to fix this non-brokenness? Hi Iljitsch, There are three schools of thought on that: 1. SLAAC is the optimal way to configure IP addresses under IPv6. DHCPv6 should only facilitate configuration of other things that SLAAC doesn't deal with (e.g. DNS resolver) 2. SLAAC was a clever idea that for a variety of reasons (e.g. the server configuration knowledge leak) isn't panning out. DHCPv6 should replace SLAAC. It should do the same work as IPv4 DHCP, as expected by folks used to IPv4. 3. Give it to me both ways. I'll make the choice I decide is optimal for my network. With my operations hat on, I'm a fan of option #3. I find the theorists' intrusion into my prerogative as a system administrator (option #1) to be disagreeable. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tjc at ecs.soton.ac.uk Fri Jun 10 09:12:29 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 10 Jun 2011 15:12:29 +0100 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <4A84DCEA-0C3F-49F2-B80D-0984BBD93CF8@ecs.soton.ac.uk> Message-ID: On 10 Jun 2011, at 15:08, Iljitsch van Beijnum wrote: > > (And it's insane that Windows still exhibits this completely broken behavior.) We could derail into some broken MacOS X behaviour if you like ;) Tim From Jay.Murphy at state.nm.us Fri Jun 10 09:15:27 2011 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Fri, 10 Jun 2011 14:15:27 +0000 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> Message-ID: <218A1779A7A0984894CBD218EFF84AC45D964E@CEXMB003.nmes.lcl> The umbra of it all. We have jobs though. ~Jay "We move the information that moves your world." ?Engineering is about finding the sweet spot between what's solvable and what isn't." ?Good engineering demands that we understand what we?re doing and why, keep an open mind, and learn from experience.? Radia Perlman "If human beings are perceived as potentials rather than problems, as possessing strengths instead of weaknesses, as unlimited rather than dull and unresponsive, then they thrive and grow to their capabilities." ? Please consider the environment before printing e-mail -----Original Message----- From: Kyle Creyts [mailto:kyle.creyts at gmail.com] Sent: Friday, June 10, 2011 8:01 AM To: Chris Adams; NANOG Subject: Re: Yup; the Internet is screwed up. I think the point is the ubiquity of access isn't what it should be. On Fri, Jun 10, 2011 at 9:47 AM, Chris Adams wrote: > Once upon a time, Jared Mauch said: > > On Jun 9, 2011, at 8:43 PM, Jay Ashworth wrote: > > > Even Cracked realizes this: > > > > > > > http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster > > > > I would describe this as "local market failure". It's common even in > highly populated areas, not just rural ones here in the US. > > I'd go so far as to say "user failure". If I wanted cable TV > (especially if I needed it at home as part of my job), I wouldn't > buy/rent/lease/whatever a home without checking that cable TV is > available at that location. I live in a city with two cable providers, > each of which covers the "whole" city, yet there are pockets where one > (or even both) don't provide service. > > Before I bought my house, I made sure I could get my preferred Internet > service at my house. > > There are definately things wrong with the state of last-mile Internet > access in the US, but moving somewhere without checking is IMHO your own > fault. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > -- Kyle Creyts Information Assurance Professional From jared at puck.nether.net Fri Jun 10 09:17:32 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 10 Jun 2011 10:17:32 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> Message-ID: <0AB43BCD-E143-4B26-A556-88DDB6C29BCA@puck.nether.net> On Jun 10, 2011, at 10:01 AM, Kyle Creyts wrote: > I think the point is the ubiquity of access isn't what it should be. I think there were several good points made in the article. 1) Data caps and how they impact software updates (or downloads) - hughesnet was mentioned but .. Looking to the near future, Apple is selling a 4GB download for $30 in the next month or so. That will have a large impact on networks that day IMHO. If you have a 3G/4G/LTE/whatnot device it makes it impossible to pull down the image without hitting your 5GB or 10GB cap compared to a fixed access network. Even assuming you go to the local Panera/McDonalds/Starbucks/Library access, if you get 2MB/s (16Mb/s) you're talking about 20-25 minutes. Those locales don't usually have that fast of a network though. 2) Last mile is expensive to install and hard to justify for people. This is because of a long history of universal service and subsidization/regulation. In Michigan you could get a phone line installed for $42 (not sure, haven't installed POTS in a long time, may have gone up) regardless of the cost to the carrier. This isn't the case when you want to extend other utilities (eg Gas, electric, water...). People are willing to pay 10k+ to install these services as part of their construction expense. Their other utility cost is masked in part due to the past 100+ years of telecom history. The cost of lighting a 20km strand of fiber at 1Gb/s is somewhere in the $600, including ONT, etc. Many people here on nanog would happily pay that amount. Now, the 12-100k per mile to build the fiber is the hard part to eat. 3) Certainly he did a poor job of site selection. Perhaps he was misled or even lied to. I've faced similar challenges when working with both hardware vendors and carriers out there. The sales peoples eyes get big once you start talking about "doing" something, but the engineers at the table generally start asking serious questions. (I certainly will not move anywhere that doesn't have a HFC or PON/FTTH network. Sorry AT&T/Centurylink/others but the plusses don't justify the minuses). - It's certainly possible that we will see improved last-mile access. The USDA/RUS and DOC/NTIA efforts are to be applauded. If you look at the current AT&T + T-Mobile merger people are talking about it will bring broadband to 97% of the country, and help AT&T (mobility division) with last-mile/local tower regulatory hurdles. They are not talking about how it will remove the need for data caps that are 1/30th the size of their 150GB cap on their mobile side elements. I suspect there's a lot that could be improved by each market player here, but as happened with Verizon in the Northeast, I expect the less-dense markets will need to have better local service from regional players vs the "big guys". Overall this will be good, but the costs will also have to be paid for more with the local subscriber. - Jared From jared at puck.nether.net Fri Jun 10 09:22:04 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 10 Jun 2011 10:22:04 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> Message-ID: <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> On Jun 10, 2011, at 10:04 AM, Scott Brim wrote: > On Fri, Jun 10, 2011 at 09:47, Chris Adams wrote: >> I'd go so far as to say "user failure". If I wanted cable TV >> (especially if I needed it at home as part of my job), I wouldn't >> buy/rent/lease/whatever a home without checking that cable TV is >> available at that location. > > Yeah, he messed up, but the social problem is still real. The > Internet is now more important than electricity or water -- you can go > off the grid or dig your own well, but more and more you can't get a > job or talk to the government without web access and email. > I have an off-the-grid location I can go to. I can get internet access there with a VZ MIFI at speeds of 1Mb/s. What I can't get is a software update over that service to keep my devices secure. The 5GB data cap gets in the way. The current set of iphone/ipad firmware updates are about 700mb per device. Not counting the latest combo updater (or incremental) for MacOS. (Hopefully with the 5.0 software announced they will do OTA updates on a different APN that doesn't count against ones data limits). I don't use windows so not sure what those weigh in at, but they're bound to be a few hundred megs. - Jared From iljitsch at muada.com Fri Jun 10 09:24:15 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 16:24:15 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <4A84DCEA-0C3F-49F2-B80D-0984BBD93CF8@ecs.soton.ac.uk> Message-ID: On 10 jun 2011, at 16:12, Tim Chown wrote: >> (And it's insane that Windows still exhibits this completely broken behavior.) > We could derail into some broken MacOS X behaviour if you like ;) Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN. From bicknell at ufp.org Fri Jun 10 09:28:02 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Jun 2011 07:28:02 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> Message-ID: <20110610142802.GA21261@ussenterprise.ufp.org> In a message written on Fri, Jun 10, 2011 at 04:08:06PM +0200, Iljitsch van Beijnum wrote: > Ok, so now we've identified the problem. > > How exactly does adding default gateway information to DHCPv6 solve this problem? Please go back and re-read my original scenario and think about it. The difference here is that if a client gets a DHCP address it generally won't be broken until it tries to renew, and then often won't be broken at renewal because it sends a directed request back. In specific technical terms: DHCP relies on broadcast _ONCE_ at boot, and then uses static unicast config to verify that is still the correct config. RA's use broadcast every few seconds to broadcast new information that everyone is supposed to "trust" instantly. Turn up a Rogue DHCP server on one of your subnets. It won't affect anyone who's already up and running. It may grab newly booted machines, depending on a race condition, but it won't break anything that is already working. Turn up rogue RA's, and everyone instantly fails. The behavior of these protocols is different, which leads to different failure modes. My assertion is that in every failure mode you can come up with RA's lead to more clients being down faster and for longer periods of time. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From rps at maine.edu Fri Jun 10 09:28:55 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 10 Jun 2011 10:28:55 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <4A84DCEA-0C3F-49F2-B80D-0984BBD93CF8@ecs.soton.ac.uk> Message-ID: Windows ICS has been a thorn in everyone's side at one point or another; I for one think that it's been a force for good, though, as it's put protection against rogue RA on people's radar; without ICS I'm sure I'd be having a lot of augments on NANOG about whether or not RA Guard is needed with people saying "I run IPv6 without it and never have problems" etc. On Fri, Jun 10, 2011 at 10:24 AM, Iljitsch van Beijnum wrote: > On 10 jun 2011, at 16:12, Tim Chown wrote: > >>> (And it's insane that Windows still exhibits this completely broken behavior.) > >> We could derail into some broken MacOS X behaviour if you like ;) > > Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN. > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From tjc at ecs.soton.ac.uk Fri Jun 10 09:31:07 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 10 Jun 2011 15:31:07 +0100 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <4A84DCEA-0C3F-49F2-B80D-0984BBD93CF8@ecs.soton.ac.uk> <2EB8BE57-3436-4447-B7AC-C783050BA49D@ecs.soton.ac.uk> Message-ID: On 10 Jun 2011, at 15:24, Iljitsch van Beijnum wrote: > On 10 jun 2011, at 16:12, Tim Chown wrote: > >>> (And it's insane that Windows still exhibits this completely broken behavior.) > >> We could derail into some broken MacOS X behaviour if you like ;) > > Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN. Indeed. Well, hopefully MS is listening to the 6to4-advisory draft. Tim From rps at maine.edu Fri Jun 10 09:34:57 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 10 Jun 2011 10:34:57 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610142802.GA21261@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> Message-ID: All I'm saying is that it's generally a bad idea to have different standards for "accidental" and "malicious" traffic. Say you were using DHCPv6 for routing; a malicious user could still inject traffic on the network to disrupt service. People get all uppity about RA because vendors have been painfully slow to implement RA Guard. To be fair, RA Guard probably should have been an early RFC as it was an obvious concern even at the time ICMPv6 was being drafted. I for one look forward to the day where things like RA Guard and MLD Snooping are standard on every switch. Just IPv6 growing pains. Also agree that I want flexibility to use RA or DHCPv6; the disagreement is that RA needs to be removed or changed from IPv6. Don't go breaking my IPv6 stack for your own ambitions, please. On Fri, Jun 10, 2011 at 10:28 AM, Leo Bicknell wrote: > In a message written on Fri, Jun 10, 2011 at 04:08:06PM +0200, Iljitsch van Beijnum wrote: >> Ok, so now we've identified the problem. >> >> How exactly does adding default gateway information to DHCPv6 solve this problem? > > Please go back and re-read my original scenario and think about it. > > The difference here is that if a client gets a DHCP address it > generally won't be broken until it tries to renew, and then often > won't be broken at renewal because it sends a directed request back. > > In specific technical terms: DHCP relies on broadcast _ONCE_ at > boot, and then uses static unicast config to verify that is still > the correct config. ?RA's use broadcast every few seconds to broadcast > new information that everyone is supposed to "trust" instantly. > > Turn up a Rogue DHCP server on one of your subnets. ?It won't affect > anyone who's already up and running. ?It may grab newly booted > machines, depending on a race condition, but it won't break anything > that is already working. > > Turn up rogue RA's, and everyone instantly fails. > > > The behavior of these protocols is different, which leads to different > failure modes. ?My assertion is that in every failure mode you can > come up with RA's lead to more clients being down faster and for > longer periods of time. > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From ricardofbferreira at gmail.com Fri Jun 10 09:36:09 2011 From: ricardofbferreira at gmail.com (Ricardo Ferreira) Date: Fri, 10 Jun 2011 15:36:09 +0100 Subject: Yup; the Internet is screwed up. In-Reply-To: <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> Message-ID: Funny, how in the title refers to the Internet globally when the article is specific about the USA. I live in europe and we have at home 100Mbps . Mid sized city of 500k people. Some ISPs even spread WiFi across town so that subscribers can have internet access outside their homes. On Fri, Jun 10, 2011 at 3:22 PM, Jared Mauch wrote: > > On Jun 10, 2011, at 10:04 AM, Scott Brim wrote: > > > On Fri, Jun 10, 2011 at 09:47, Chris Adams wrote: > >> I'd go so far as to say "user failure". If I wanted cable TV > >> (especially if I needed it at home as part of my job), I wouldn't > >> buy/rent/lease/whatever a home without checking that cable TV is > >> available at that location. > > > > Yeah, he messed up, but the social problem is still real. The > > Internet is now more important than electricity or water -- you can go > > off the grid or dig your own well, but more and more you can't get a > > job or talk to the government without web access and email. > > > > I have an off-the-grid location I can go to. I can get internet access > there with a VZ MIFI at speeds of 1Mb/s. What I can't get is a software > update over that service to keep my devices secure. The 5GB data cap gets > in the way. > > The current set of iphone/ipad firmware updates are about 700mb per device. > Not counting the latest combo updater (or incremental) for MacOS. > (Hopefully with the 5.0 software announced they will do OTA updates on a > different APN that doesn't count against ones data limits). > > I don't use windows so not sure what those weigh in at, but they're bound > to be a few hundred megs. > > - Jared > -- Ricardo Ferreira From iljitsch at muada.com Fri Jun 10 09:37:24 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 16:37:24 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610142802.GA21261@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> Message-ID: <37E668D4-4EBB-4C51-9C33-1DEE1AA33BFF@muada.com> On 10 jun 2011, at 16:28, Leo Bicknell wrote: >> Ok, so now we've identified the problem. >> How exactly does adding default gateway information to DHCPv6 solve this problem? > Please go back and re-read my original scenario and think about it. I don't have to, as you restate pretty much all of it here... So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. From owen at delong.com Fri Jun 10 09:38:49 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jun 2011 07:38:49 -0700 Subject: IPv6 routing protocols In-Reply-To: <0E0F104D-1B8F-4D64-9FD6-2AB78FE3F577@muada.com> References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF10101.4010407@foobar.org> <4DF105D8.7050300@foobar.org> <4DF1F006.3010501@foobar.org> <88A0EBA4-039B-4028-9623-B58693ACBB1B@muada.com> <0E0F104D-1B8F-4D64-9FD6-2AB78FE3F577@muada.com> Message-ID: On Jun 10, 2011, at 3:37 AM, Iljitsch van Beijnum wrote: > On 10 jun 2011, at 12:27, Iljitsch van Beijnum wrote: > >> RFC 4760: > >> An UPDATE message that carries the MP_REACH_NLRI MUST also carry the >> ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP >> exchanges). Moreover, in IBGP exchanges such a message MUST also >> carry the LOCAL_PREF attribute. > > Sorry, this is stupid. I should have read beyond "LOCAL". > > So it depends a little, but I still don't see any implementation leeway in RFC 2545: > > 3. Constructing the Next Hop field > > A BGP speaker shall advertise to its peer in the Network Address of > Next Hop field the global IPv6 address of the next hop, potentially > followed by the link-local IPv6 address of the next hop. > > The value of the Length of Next Hop Network Address field on a > MP_REACH_NLRI attribute shall be set to 16, when only a global > address is present, or 32 if a link-local address is also included in > the Next Hop field. > > The link-local address shall be included in the Next Hop field if and > only if the BGP speaker shares a common subnet with the entity > identified by the global IPv6 address carried in the Network Address > of Next Hop field and the peer the route is being advertised to. > > In all other cases a BGP speaker shall advertise to its peer in the > Network Address field only the global IPv6 address of the next hop > (the value of the Length of Network Address of Next Hop field shall > be set to 16). I read that as: If the peer is directly connected and the next hop is local, there is the option of sending both the global unicast address and the link local address for the directly connected link. In all other cases, you must send only the global unicast address of the next hop. That sounds like not using link local in the general case and having it available as an option in the directly adjacent case. Owen From andyring at inebraska.com Fri Jun 10 09:44:02 2011 From: andyring at inebraska.com (Andy Ringsmuth) Date: Fri, 10 Jun 2011 09:44:02 -0500 Subject: Contact at BNSF Railway Message-ID: <0A7F9160-0752-4CDA-9A46-7C75E605C68E@inebraska.com> Anyone on here have a contact at BNSF Railway in Fort Worth, Texas, who could contact me off-list? I think something is mucked up with their mail servers and is starting to refuse incoming mail. Don't know if it's just from my domain or more globally, but my company handles the lion's share of BNSF's employee communications, which is fairly critical. --- Andy Ringsmuth andyring at inebraska.com From bicknell at ufp.org Fri Jun 10 09:47:51 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Jun 2011 07:47:51 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <37E668D4-4EBB-4C51-9C33-1DEE1AA33BFF@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> Message-ID: <20110610144751.GA25027@ussenterprise.ufp.org> In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: > Also agree that I want flexibility to use RA or DHCPv6; the > disagreement is that RA needs to be removed or changed from IPv6. > Don't go breaking my IPv6 stack for your own ambitions, please. I want that flexability as well, but the IETF won't deliver. The two options delivered so far are: RA's only. DHCPv6 with RA's to learn a default route. I want a third option: DHCPv6 only. I have no desire to remove either of the first two options. In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote: > So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. There are various drafts and proposals in the IETF to solve this problem, and they pretty much all focus on the DHCP side of things. You see, in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented. To pick on Ray for a moment, the IETF seems to largely have a similar attitude to Ray's. I spent a year or so trying to talk to the various folks involved, only to be told that I "didn't understand IPv6", "didn't know what I was talking about with respect to how RA's work", and "wouldn't want a network with only DHCPv6". I can't tell you how many times I had been told I clearly didn't have enough experience with IPv6, when we've been dual stacked for years. When I do get someone at the IETF who will listen to my operational issues the response is always the same as Ray's. Deploy RA guard. Never mind that until a year or so ago no vendors at all had it. Never mind that even today only a handful of switch models support it. Never mind that it requires me to forklift out every working L2 switch I have just to run IPv6. As far as I can tell the IETF has been killing or stalling the necessary DHCP additions for the better part of 7 years now. If you really want to fix this problem you either need to get a vendor to just implement it and ignore the IETF, or enough operators to go to the IETF meeting with pitchforks that perhaps someone finally listens. I really beieve this is going to be the single largest impediment to deploying _end user_ IPv6. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From m.hotze at hotze.com Fri Jun 10 09:53:22 2011 From: m.hotze at hotze.com (Martin Hotze) Date: Fri, 10 Jun 2011 14:53:22 +0000 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: Message-ID: <9DDD3733AE0DB544B7E2B78F81BFDCD3034282D0@SBSSRV.hotze.local> > From: Iljitsch van Beijnum > Subject: Re: The stupidity of trying to "fix" DHCPv6 > To: Tim Chown > Cc: NANOG list (...) > Not saying that Apple is perfect, but at least their IPv6-related bugs > don't ruin the day for others on the LAN. Let them (Apple) finally (*dooohhh*) fix the 2.4GHz/DHCP bug on the iPad ... Those "?$%?"$!""?!%$"?$%-censored didn't make my day, really. :-( #m From owen at delong.com Fri Jun 10 09:51:24 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jun 2011 07:51:24 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <37E668D4-4EBB-4C51-9C33-1DEE1AA33BFF@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <37E668D4-4EBB-4C51-9C33-1DEE1AA33BFF@muada.com> Message-ID: <7C1C06A4-8933-4DB3-9436-F8A0F077DE5E@delong.com> On Jun 10, 2011, at 7:37 AM, Iljitsch van Beijnum wrote: > On 10 jun 2011, at 16:28, Leo Bicknell wrote: > >>> Ok, so now we've identified the problem. > >>> How exactly does adding default gateway information to DHCPv6 solve this problem? > >> Please go back and re-read my original scenario and think about it. > > I don't have to, as you restate pretty much all of it here... > > So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. Seems to me that adding a routing information option to DHCPv6 solves the problem without breaking the legacy hosts. What's wrong with that idea? Owen From owen at delong.com Fri Jun 10 09:53:36 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jun 2011 07:53:36 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610144751.GA25027@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> Message-ID: <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote: > In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: >> Also agree that I want flexibility to use RA or DHCPv6; the >> disagreement is that RA needs to be removed or changed from IPv6. >> Don't go breaking my IPv6 stack for your own ambitions, please. > > I want that flexability as well, but the IETF won't deliver. > > The two options delivered so far are: > > RA's only. Only sort of... This only works if you don't want to auto-configure things like DNS, NTP, etc. I would like to see both protocols made optionally complete, so, in addition to fixing DHCPv6 by adding routing information options, I'd also like to see something done where it would be possible to add at least DNS servers to RA. > DHCPv6 with RA's to learn a default route. > > I want a third option: > > DHCPv6 only. > > I have no desire to remove either of the first two options. > > In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote: >> So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. > > There are various drafts and proposals in the IETF to solve this > problem, and they pretty much all focus on the DHCP side of things. > > You see, in DHCPv6 it was decided to not implment a field for the > default gateway or subnet mask, under the logic that the former was > learned via RA's, and the latter was always a /64. While it's not > quite as trivial as adding those two fields, it's not that much > more complex. The right behavior for a host that comes up and sees > no RA's needs to be documented. > > To pick on Ray for a moment, the IETF seems to largely have a similar > attitude to Ray's. I spent a year or so trying to talk to the > various folks involved, only to be told that I "didn't understand > IPv6", "didn't know what I was talking about with respect to how > RA's work", and "wouldn't want a network with only DHCPv6". I can't > tell you how many times I had been told I clearly didn't have enough > experience with IPv6, when we've been dual stacked for years. > > When I do get someone at the IETF who will listen to my operational > issues the response is always the same as Ray's. Deploy RA guard. > Never mind that until a year or so ago no vendors at all had it. > Never mind that even today only a handful of switch models support > it. Never mind that it requires me to forklift out every working > L2 switch I have just to run IPv6. > > As far as I can tell the IETF has been killing or stalling the > necessary DHCP additions for the better part of 7 years now. If > you really want to fix this problem you either need to get a vendor > to just implement it and ignore the IETF, or enough operators to > go to the IETF meeting with pitchforks that perhaps someone finally > listens. > > I really beieve this is going to be the single largest impediment to > deploying _end user_ IPv6. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From cmadams at hiwaay.net Fri Jun 10 10:09:00 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 10 Jun 2011 10:09:00 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> References: <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> Message-ID: <20110610150859.GB11923@hiwaay.net> Once upon a time, Owen DeLong said: > I would like to see both protocols made optionally complete, so, in addition > to fixing DHCPv6 by adding routing information options, I'd also like to > see something done where it would be possible to add at least DNS > servers to RA. Isn't that what RDNSS (recursive DNS servers) and DNSSL (DNS search list) extensions are? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jason at i6ix.com Fri Jun 10 10:10:18 2011 From: jason at i6ix.com (Jason Bertoch) Date: Fri, 10 Jun 2011 11:10:18 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> Message-ID: <4DF233DA.6080603@i6ix.com> On 6/10/2011 10:53 AM, Owen DeLong wrote: > I would like to see both protocols made optionally complete, so, in addition > to fixing DHCPv6 by adding routing information options, I'd also like to > see something done where it would be possible to add at least DNS > servers to RA. +1. /Jason From rps at maine.edu Fri Jun 10 10:11:09 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 10 Jun 2011 11:11:09 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <7C1C06A4-8933-4DB3-9436-F8A0F077DE5E@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <37E668D4-4EBB-4C51-9C33-1DEE1AA33BFF@muada.com> <7C1C06A4-8933-4DB3-9436-F8A0F077DE5E@delong.com> Message-ID: On Fri, Jun 10, 2011 at 10:51 AM, Owen DeLong wrote: > Seems to me that adding a routing information option to DHCPv6 solves the problem > without breaking the legacy hosts. > > What's wrong with that idea? > > Owen Thank you, Owen. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From iljitsch at muada.com Fri Jun 10 10:13:09 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 17:13:09 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610144751.GA25027@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> Message-ID: On 10 jun 2011, at 16:47, Leo Bicknell wrote: >> So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. > in DHCPv6 it was decided to not implment a field for the > default gateway or subnet mask, under the logic that the former was > learned via RA's, and the latter was always a /64. While it's not > quite as trivial as adding those two fields, it's not that much > more complex. The right behavior for a host that comes up and sees > no RA's needs to be documented. Don't you realize that this doesn't solve anything? The whole point of stateless autoconfig and DHCP is to allow a host that arrives without any prior knowledge about the network to be configured without human intervention so it can communicate over the network. So we must assume a host with no prior configuration. All currently existing IPv6 hosts that I'm aware of have stateless autoconfig enabled by default (save for some *X distros that assume the system will be some kind of server). So if you put such a host with an updated DHCPv6 implementation in a network with rogue RAs, they will autoconfigure addresses in the advertised prefixes exactly the same as today. Like I said before: removing the correct information from RAs does nothing to get rid of the incorrect information in RAs. Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues: 1. No longer the fait sharing that comes from RA-learned gateway addresses 2. Old and new hosts may use different gateways on the same network So my suggestion is: learn gateway addresses from RAs as we do today, but in addition create a DHCPv6 option that contains gateway addresses, and then when a gateway address is in the DHCPv6 list, it gets a higher priority. This way, if there are no rogue RAs the behavior is the same for unupdated and updated hosts. If there are rogue RAs, the updated hosts ignore them. If system administrators screw up and the DHCPv6 info doesn't match the actual routers, everything still works except that there is no rogue RA protection. This should make everyone happy except those so set in their IPv4 ways that they insist on removing RAs. Which is not only a bad idea, but an exercise in futility because of the large number of "legacy IPv6" hosts that need RAs to function and won't go away anytime soon. From bill at herrin.us Fri Jun 10 10:22:31 2011 From: bill at herrin.us (William Herrin) Date: Fri, 10 Jun 2011 11:22:31 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> Message-ID: On Fri, Jun 10, 2011 at 10:53 AM, Owen DeLong wrote: > Only sort of... This only works if you don't want to auto-configure things like DNS, > NTP, etc. > > I would like to see both protocols made optionally complete, so, in addition > to fixing DHCPv6 by adding routing information options, I'd also like to > see something done where it would be possible to add at least DNS > servers to RA. The RA's aren't really supposed to be for configuring applications. DNS and NTP are applications in the IPv4 and IPv6 paradigms, not core protocol functions. Another approach to the problem would be defining anycast addresses (in the IPv4 sense of anycast) defined as "nearest DNS resolver" and "nearest NTP server." You then make a request directed to that anycast address to discover the unicast addresses of the servers you should be using. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Fri Jun 10 10:26:29 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Jun 2011 08:26:29 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> Message-ID: <20110610152629.GA26942@ussenterprise.ufp.org> In a message written on Fri, Jun 10, 2011 at 05:13:09PM +0200, Iljitsch van Beijnum wrote: > Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues: > > 1. No longer the fait sharing that comes from RA-learned gateway addresses I proport that VRRPv6 is a superior solution to have redundant gateways than using RA's to broadcast both and let the host choose. > 2. Old and new hosts may use different gateways on the same network This problem already exists. Have IPv4 hosts come up with IPv4, change the gateway on the server, and let some new hosts come up. I agree having two different methods to configure a default gateway is silly. You can do it in IPv4, broadcast a default route in RIP and learn one via DHCP. I'm going to assume operators aren't going to do such stupid things. > So my suggestion is: learn gateway addresses from RAs as we do today, but in addition create a DHCPv6 option that contains gateway addresses, and then when a gateway address is in the DHCPv6 list, it gets a higher priority. I think that would probably be an acceptable solution. I'm pondering that off the top of my head, but I don't see any major, crazy flaws. My guess is that most networks that use DHCPv6 will disable RA's completely on the routers. Sure, they can't disable rogue RA's until more switches support filtering them, but that will happen over time. > This should make everyone happy except those so set in their IPv4 ways that they insist on removing RAs. Which is not only a bad idea, but an exercise in futility because of the large number of "legacy IPv6" hosts that need RAs to function and won't go away anytime soon. You have now hit my greatest frustration on the head. This problem has been known and documented for 7-8 years, at least. I believe the first time I saw RA's take down a conference network was in 2005. Proposed solutions have been floating around almost as long. We could have solved this before a lot of hosts were deployed. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From rps at maine.edu Fri Jun 10 10:29:56 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 10 Jun 2011 11:29:56 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610144751.GA25027@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <37E668D4-4EBB-4C51-9C33-1DEE1AA33BFF@muada.com> <20110610144751.GA25027@ussenterprise.ufp.org> Message-ID: I don't mind being picked on; and I hope I don't come off as hostile. It's all in good fun. I'm really kind of a young punk compared to a lot of people on list, and there usually isn't a day that goes by where something I said the previous day comes back to haunt me. ;-) I think we have a lot of IPv6 that is usable, and better than IPv4, in place already. People were complaining about DHCPv6 being useless and saying everything should be SLAAC; then we started seeing good client and server implementations for DHCPv6 and people started coming around. As you roll out IPv6 you're going to make some mistakes, you're going to learn a bit, and you're going to look back at comments you made in the past and laugh a little. My idea of IPv6 a year ago was very different than it is today; tough today I have IPv6 deployed state-wide on an R&E network, and have met a lot of the technical and political challenges that I never anticipated along the way. Given that IPv6 has taken so long to implement to begin with, I usually have a negative reaction to people marching in on a pony and telling everyone how IPv6 needs to be re-written because it could be better. I don't see the DHCPv6 route option being viable as the primary method for default nexthop for several years. It not only needs to become an actual standard, but then it needs to be implemented, and you need to wait out the legacy systems. So what we have for IPv6 today is generally a good starting point. I'm of the mindset that it's reasonable to expect more form network switches, so RA Guard being a "requirement" for IPv6, while a messy transition, is something I'm OK with in the long run. The addressing piece is something a lot of people get hung up on because it's very, very different than IPv4, and it's the first thing people new to IPv6 are exposed to; but I think once you understand it it's not really a roadblock from deployment. The next step is figuring out how we deliver IPv6 to the SMB that currently makes use of a dinky Dual-WAN NAT box for redundancy. We don't want these guys in the BGP tables; but we don't want to tell them that they're stuck with a single provider either. I think that's where things start to get a lot more interesting, not all this DHCPv6 vs SLAAC talk ;-) On Fri, Jun 10, 2011 at 10:47 AM, Leo Bicknell wrote: > In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: >> Also agree that I want flexibility to use RA or DHCPv6; the >> disagreement is that RA needs to be removed or changed from IPv6. >> Don't go breaking my IPv6 stack for your own ambitions, please. > > I want that flexability as well, but the IETF won't deliver. > > The two options delivered so far are: > > RA's only. > DHCPv6 with RA's to learn a default route. > > I want a third option: > > DHCPv6 only. > > I have no desire to remove either of the first two options. > > In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote: >> So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. > > There are various drafts and proposals in the IETF to solve this > problem, and they pretty much all focus on the DHCP side of things. > > You see, in DHCPv6 it was decided to not implment a field for the > default gateway or subnet mask, under the logic that the former was > learned via RA's, and the latter was always a /64. ?While it's not > quite as trivial as adding those two fields, it's not that much > more complex. ?The right behavior for a host that comes up and sees > no RA's needs to be documented. > > To pick on Ray for a moment, the IETF seems to largely have a similar > attitude to Ray's. ?I spent a year or so trying to talk to the > various folks involved, only to be told that I "didn't understand > IPv6", "didn't know what I was talking about with respect to how > RA's work", and "wouldn't want a network with only DHCPv6". ?I can't > tell you how many times I had been told I clearly didn't have enough > experience with IPv6, when we've been dual stacked for years. > > When I do get someone at the IETF who will listen to my operational > issues the response is always the same as Ray's. ?Deploy RA guard. > Never mind that until a year or so ago no vendors at all had it. > Never mind that even today only a handful of switch models support > it. ?Never mind that it requires me to forklift out every working > L2 switch I have just to run IPv6. > > As far as I can tell the IETF has been killing or stalling the > necessary DHCP additions for the better part of 7 years now. ?If > you really want to fix this problem you either need to get a vendor > to just implement it and ignore the IETF, or enough operators to > go to the IETF meeting with pitchforks that perhaps someone finally > listens. > > I really beieve this is going to be the single largest impediment to > deploying _end user_ IPv6. > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From xleonzhao at gmail.com Fri Jun 10 10:29:57 2011 From: xleonzhao at gmail.com (Xiaoliang Zhao) Date: Fri, 10 Jun 2011 11:29:57 -0400 Subject: IPv6 routing protocols In-Reply-To: References: <20110609120923.GW25373@angus.ind.WPI.EDU> <20110609.141945.74661869.sthaug@nethelp.no> <4DF10101.4010407@foobar.org> <4DF105D8.7050300@foobar.org> <4DF1F006.3010501@foobar.org> <88A0EBA4-039B-4028-9623-B58693ACBB1B@muada.com> <0E0F104D-1B8F-4D64-9FD6-2AB78FE3F577@muada.com> Message-ID: > That sounds like not using link local in the general case and having > it available as an option in the directly adjacent case. I'd like to second that. All in all, protocol nexthop has to be reachable via IGP, otherwise, your v6 routes won't be installed in the forwarding table. By its name, I would think link local addresses are meant to be used only on a link, not igp. Best, Leon From mohacsi at niif.hu Fri Jun 10 10:32:49 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 10 Jun 2011 17:32:49 +0200 (CEST) Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610134744.GA20607@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> Message-ID: On Fri, 10 Jun 2011, Leo Bicknell wrote: > In a message written on Fri, Jun 10, 2011 at 09:37:11AM -0400, Ray Soucy wrote: >> You really didn't just write an entire post saying that RA is bad >> because if a moron of a network engineer plugs an incorrectly >> configured device into a production network it may cause problems, did >> you? > > No, I posed the easiest way to recreate this issue. > > I've seen the entire NANOG and IETF lans taken out because some > dork enabled microsoft connecting sharing to their cell card. > > I've seen entire corporate networks taken out because someone ran > the patch cable to the wrong port. > > The point is, RA's are operationally fragile and DHCP is operationally > robust. You can choose to stick your head in the sand about that > if you want, but it's still true. I don't see, why do you claim that DHCP is more robust, than SLAAC. I have seen half day outage due to broken/misbehaving DHCP server.... I agree with Wiliam Herrin: have both SLAAC and DHCPv6 as an option. Give me both ways....And probably I will use both... Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From rps at maine.edu Fri Jun 10 10:38:42 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 10 Jun 2011 11:38:42 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> Message-ID: There is almost no difference between having RA give out DNS information, and having an "other only" DHCPv6 server from a software standpoint. The difference is that DHCPv6 is in the application space, while RA is in the kernel space. It's easier to modify DHCPv6 than RA; so over time when we add options, we don't need to go back and modify the IPv6 implementation in every OS; just update the DHCPv6 client. We could just re-name DHCPv6 other-only mode and call it "Extended RA" if you like; it wouldn't even require any code change. Most routers that support IPv6 also support running an "Other Only" (stateless) DHCPv6 server; it's like 3 lines of configuration and costs next to nothing. We haven't seen any DHCPv6 client implementations for "other only" but it would be equally trivial to write them. I think the general feeling, though, is that a full DHCPv6 client should be considered a requirement for any host regardless of if the network makes use of DHCPv6 for address assignment or not. On Fri, Jun 10, 2011 at 10:53 AM, Owen DeLong wrote: > > On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote: > >> In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: >>> Also agree that I want flexibility to use RA or DHCPv6; the >>> disagreement is that RA needs to be removed or changed from IPv6. >>> Don't go breaking my IPv6 stack for your own ambitions, please. >> >> I want that flexability as well, but the IETF won't deliver. >> >> The two options delivered so far are: >> >> RA's only. > > Only sort of... This only works if you don't want to auto-configure things like DNS, > NTP, etc. > > I would like to see both protocols made optionally complete, so, in addition > to fixing DHCPv6 by adding routing information options, I'd also like to > see something done where it would be possible to add at least DNS > servers to RA. > >> DHCPv6 with RA's to learn a default route. >> >> I want a third option: >> >> DHCPv6 only. >> >> I have no desire to remove either of the first two options. >> >> In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote: >>> So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. >> >> There are various drafts and proposals in the IETF to solve this >> problem, and they pretty much all focus on the DHCP side of things. >> >> You see, in DHCPv6 it was decided to not implment a field for the >> default gateway or subnet mask, under the logic that the former was >> learned via RA's, and the latter was always a /64. ?While it's not >> quite as trivial as adding those two fields, it's not that much >> more complex. ?The right behavior for a host that comes up and sees >> no RA's needs to be documented. >> >> To pick on Ray for a moment, the IETF seems to largely have a similar >> attitude to Ray's. ?I spent a year or so trying to talk to the >> various folks involved, only to be told that I "didn't understand >> IPv6", "didn't know what I was talking about with respect to how >> RA's work", and "wouldn't want a network with only DHCPv6". ?I can't >> tell you how many times I had been told I clearly didn't have enough >> experience with IPv6, when we've been dual stacked for years. >> >> When I do get someone at the IETF who will listen to my operational >> issues the response is always the same as Ray's. ?Deploy RA guard. >> Never mind that until a year or so ago no vendors at all had it. >> Never mind that even today only a handful of switch models support >> it. ?Never mind that it requires me to forklift out every working >> L2 switch I have just to run IPv6. >> >> As far as I can tell the IETF has been killing or stalling the >> necessary DHCP additions for the better part of 7 years now. ?If >> you really want to fix this problem you either need to get a vendor >> to just implement it and ignore the IETF, or enough operators to >> go to the IETF meeting with pitchforks that perhaps someone finally >> listens. >> >> I really beieve this is going to be the single largest impediment to >> deploying _end user_ IPv6. >> >> -- >> ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 >> ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Fri Jun 10 10:42:29 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 10 Jun 2011 11:42:29 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> Message-ID: On a side note; I think the RDNSS stuff was pretty silly. Now instead of hosts having a DHCPv6 client, they have a DHCPv6 client AND and RDNSS client. Two services instead of one to do essentially the same thing. That's been my biggest issue with the "let's add things to RA" movement. On Fri, Jun 10, 2011 at 11:38 AM, Ray Soucy wrote: > There is almost no difference between having RA give out DNS > information, and having an "other only" DHCPv6 server from a software > standpoint. ?The difference is that DHCPv6 is in the application > space, while RA is in the kernel space. ?It's easier to modify DHCPv6 > than RA; so over time when we add options, we don't need to go back > and modify the IPv6 implementation in every OS; just update the DHCPv6 > client. ?We could just re-name DHCPv6 other-only mode and call it > "Extended RA" if you like; it wouldn't even require any code change. > > Most routers that support IPv6 also support running an "Other Only" > (stateless) DHCPv6 server; it's like 3 lines of configuration and > costs next to nothing. ?We haven't seen any DHCPv6 client > implementations for "other only" but it would be equally trivial to > write them. ?I think the general feeling, though, is that a full > DHCPv6 client should be considered a requirement for any host > regardless of if the network makes use of DHCPv6 for address > assignment or not. > > On Fri, Jun 10, 2011 at 10:53 AM, Owen DeLong wrote: >> >> On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote: >> >>> In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: >>>> Also agree that I want flexibility to use RA or DHCPv6; the >>>> disagreement is that RA needs to be removed or changed from IPv6. >>>> Don't go breaking my IPv6 stack for your own ambitions, please. >>> >>> I want that flexability as well, but the IETF won't deliver. >>> >>> The two options delivered so far are: >>> >>> RA's only. >> >> Only sort of... This only works if you don't want to auto-configure things like DNS, >> NTP, etc. >> >> I would like to see both protocols made optionally complete, so, in addition >> to fixing DHCPv6 by adding routing information options, I'd also like to >> see something done where it would be possible to add at least DNS >> servers to RA. >> >>> DHCPv6 with RA's to learn a default route. >>> >>> I want a third option: >>> >>> DHCPv6 only. >>> >>> I have no desire to remove either of the first two options. >>> >>> In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote: >>>> So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. >>> >>> There are various drafts and proposals in the IETF to solve this >>> problem, and they pretty much all focus on the DHCP side of things. >>> >>> You see, in DHCPv6 it was decided to not implment a field for the >>> default gateway or subnet mask, under the logic that the former was >>> learned via RA's, and the latter was always a /64. ?While it's not >>> quite as trivial as adding those two fields, it's not that much >>> more complex. ?The right behavior for a host that comes up and sees >>> no RA's needs to be documented. >>> >>> To pick on Ray for a moment, the IETF seems to largely have a similar >>> attitude to Ray's. ?I spent a year or so trying to talk to the >>> various folks involved, only to be told that I "didn't understand >>> IPv6", "didn't know what I was talking about with respect to how >>> RA's work", and "wouldn't want a network with only DHCPv6". ?I can't >>> tell you how many times I had been told I clearly didn't have enough >>> experience with IPv6, when we've been dual stacked for years. >>> >>> When I do get someone at the IETF who will listen to my operational >>> issues the response is always the same as Ray's. ?Deploy RA guard. >>> Never mind that until a year or so ago no vendors at all had it. >>> Never mind that even today only a handful of switch models support >>> it. ?Never mind that it requires me to forklift out every working >>> L2 switch I have just to run IPv6. >>> >>> As far as I can tell the IETF has been killing or stalling the >>> necessary DHCP additions for the better part of 7 years now. ?If >>> you really want to fix this problem you either need to get a vendor >>> to just implement it and ignore the IETF, or enough operators to >>> go to the IETF meeting with pitchforks that perhaps someone finally >>> listens. >>> >>> I really beieve this is going to be the single largest impediment to >>> deploying _end user_ IPv6. >>> >>> -- >>> ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 >>> ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ >> >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From iljitsch at muada.com Fri Jun 10 10:49:51 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 17:49:51 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610152629.GA26942@ussenterprise.ufp.org> References: <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <20110610152629.GA26942@ussenterprise.ufp.org> Message-ID: <10BD976B-7EEB-40DF-936B-4D19CFD2D187@muada.com> On 10 jun 2011, at 17:26, Leo Bicknell wrote: >> 1. No longer the fait sharing that comes from RA-learned gateway addresses > I proport that VRRPv6 is a superior solution to have redundant > gateways than using RA's to broadcast both and let the host choose. It's not about redundancy, it's about misconfiguration. You can't misconfigure an RA to provide the wrong gateway address because the gateway address is the source address of the packet. > My guess is that most networks that use DHCPv6 will disable RA's > completely on the routers. Haven't you been paying attention? One of my main points is that you can't do that for many years to come, becasue CURRENT hosts require them. It took us 8 years to get from the publication of the DHCPv6 RFC to the deployment of DHCPv6 in all big operating systems. What's the point of doing all kinds of stuff now just so you can turn off RAs in 2019? By that time the switches will have all the necessary options so the problem is moot. > I'm going to assume operators aren't going to do such stupid things. Not sure what universe you live in. In mine, if you give people a way to misconfigure, a good number of them will do so. And a small but vocal group will defend their misconfiguration and claim that this is really the best way to run their network, all the while complaining to their vendors and the IETF about the problems that this creates and that those need to be solved. From bicknell at ufp.org Fri Jun 10 11:06:28 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Jun 2011 09:06:28 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <10BD976B-7EEB-40DF-936B-4D19CFD2D187@muada.com> References: <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <20110610152629.GA26942@ussenterprise.ufp.org> <10BD976B-7EEB-40DF-936B-4D19CFD2D187@muada.com> Message-ID: <20110610160628.GA28993@ussenterprise.ufp.org> In a message written on Fri, Jun 10, 2011 at 05:49:51PM +0200, Iljitsch van Beijnum wrote: > One of my main points is that you can't do that for many years to come, becasue CURRENT hosts require them. It took us 8 years to get from the publication of the DHCPv6 RFC to the deployment of DHCPv6 in all big operating systems. What's the point of doing all kinds of stuff now just so you can turn off RAs in 2019? By that time the switches will have all the necessary options so the problem is moot. You may be correct for folks who deploy the free public WiFi at the local beverage vendor. However, many networks are much more closed deployments. Enterprises have not deployed IPv6 internally yet. Many will not deploy it for another 3-5 years, chosing instead to use web proxies at the edge that speak IPv4 (RFC1918) internally and IPv6 externally. They often can enforce the software deployed on the boxes connected. I very much think there are a lot of people who could deploy RA-less networks in the timeframe you describe, if and only if the standard to do so where published. If we had a standard today you could have patches from a vendor in a year, and still be well before many of these folks deploy anything. The fact that bad standards and software exist today should never be an argument to not design and deploy better software. So what if it takes until 2019, at least from 2019 to the end of IPv6 we'll have something better. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From matthew at matthew.at Fri Jun 10 11:22:24 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 10 Jun 2011 09:22:24 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> Message-ID: On Jun 10, 2011, at 7:34 AM, Ray Soucy wrote: > > I for one look forward to the day where things like RA Guard and MLD > Snooping are standard on every switch. Just IPv6 growing pains. I look forward to the day where "layer 2" switches don't need to implement hacks to fix "layer 3" flaws. Matthew Kaufman From jbates at brightok.net Fri Jun 10 11:33:28 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 10 Jun 2011 11:33:28 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> Message-ID: <4DF24758.4080502@brightok.net> On 6/10/2011 11:22 AM, Matthew Kaufman wrote: > > On Jun 10, 2011, at 7:34 AM, Ray Soucy wrote: > >> >> I for one look forward to the day where things like RA Guard and MLD >> Snooping are standard on every switch. Just IPv6 growing pains. > > > I look forward to the day where "layer 2" switches don't need to implement hacks to fix "layer 3" flaws. > > Matthew Kaufman We already have that. Run everything as a point to point for layer 2, and there's no need to implement hacks. :P Granted, RA Guard could also be handled transparent to the layer 2 switches, but that requires a common security model to inform the devices who they are allowed to listen to. MLD Snooping is just a problem of the switch being too stupid to know which ports to send multicast out. It's technically not required if there's a layer 2 protocol to inform the switch, but those are in limited supply. Both issues often suffer heavily from multi-vendor interoperability problems. Jack From Jay.Murphy at state.nm.us Fri Jun 10 11:49:11 2011 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Fri, 10 Jun 2011 16:49:11 +0000 Subject: Thank you Microsoft (and others) In-Reply-To: <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> References: <001201cc25f9$82a72be0$87f583a0$@com> <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> Message-ID: <218A1779A7A0984894CBD218EFF84AC45D9765@CEXMB003.nmes.lcl> I've been saved by the sound of Microsoft. ~Jay "We move the information that moves your world." ?Engineering is about finding the sweet spot between what's solvable and what isn't." ?Good engineering demands that we understand what we?re doing and why, keep an open mind, and learn from experience.? Radia Perlman ? Please consider the environment before printing e-mail -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Wednesday, June 08, 2011 7:20 PM To: Shahid Shafi Cc: NANOG list Subject: Thank you Microsoft (and others) I think it's important to thank Microsoft for leaving sites like xbox IPv6 enabled. Hope many other participants leave it on as well. I think it's a certain sign of the maturity of the protocol and networks at this stage of the game. I have observed some traffic step-down in the network, but it's not entirely clear if it's lowered to levels pre-v6-day. Looking forward to those sharing data at NANOG next week. (I'm not convinced the data I have is worth sharing, but will send it over to the nanogpc soon enough..) - Jared On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: > I dont think ISOC dashboard is updating any more. Google is no longer > advertising AAAA but dashboard still shows green and TTLs were short on > those records. From owen at delong.com Fri Jun 10 12:32:13 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jun 2011 12:32:13 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> Message-ID: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> Sent from my iPad On Jun 10, 2011, at 10:13, Iljitsch van Beijnum wrote: > On 10 jun 2011, at 16:47, Leo Bicknell wrote: > >>> So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. > >> in DHCPv6 it was decided to not implment a field for the >> default gateway or subnet mask, under the logic that the former was >> learned via RA's, and the latter was always a /64. While it's not >> quite as trivial as adding those two fields, it's not that much >> more complex. The right behavior for a host that comes up and sees >> no RA's needs to be documented. > > Don't you realize that this doesn't solve anything? > Actually, it does. It doesn't solve the problem you choose to argue about below. That problem is addressed by RA Guard. However, it does solve a different problem. Some administrators want DHCP to be a complete solution and do not want to use RA at all, whether from a legitimate router or otherwise. There are situations, for example, where the administrator does not want all hosts in a broadcast domain to receive the same set of prefixes and/or the same set of routers. This can be achieved by using different parameters based on the system identifier in the DHCP configuration. It cannot be achieved using RA. > The whole point of stateless autoconfig and DHCP is to allow a host that arrives without any prior knowledge about the network to be configured without human intervention so it can communicate over the network. > Sure, but... > So we must assume a host with no prior configuration. All currently existing IPv6 hosts that I'm aware of have stateless autoconfig enabled by default (save for some *X distros that assume the system will be some kind of server). > > So if you put such a host with an updated DHCPv6 implementation in a network with rogue RAs, they will autoconfigure addresses in the advertised prefixes exactly the same as today. Like I said before: removing the correct information from RAs does nothing to get rid of the incorrect information in RAs. > Eliminating rogue RAs is not the problem being described. That problem is solved through RA-Guard. The problem being described is the desire to be able to configure a host from zero to functionally on the internet using DHCP without RAs. I think everyone understands that you don't want to do so. That's fine. However, adding the functionality to DHCPv6 doesn't require you to use it. Making it available for operators that want to use it is not a bad thing. > Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues: > > 1. No longer the fait sharing that comes from RA-learned gateway addresses > 2. Old and new hosts may use different gateways on the same network > In some situations, this fate (it's fate, not fait, btw) sharing is not desired. In some situations, the use of VRRP is a more useful alternative. > So my suggestion is: learn gateway addresses from RAs as we do today, but in addition create a DHCPv6 option that contains gateway addresses, and then when a gateway address is in the DHCPv6 list, it gets a higher priority. > That would be a fine partial solution. However, it is desirable (IMHO) to provide for a more generic DHCPv6 option that allows one to convey routing information so that DHCPv6 could be used to convey a predetermined static routing table of arbitrary complexity. (yes, this would usually be a single default route, but, there are circumstances where it is desirable for a host to have additional static routes). > This way, if there are no rogue RAs the behavior is the same for unupdated and updated hosts. If there are rogue RAs, the updated hosts ignore them. If system administrators screw up and the DHCPv6 info doesn't match the actual routers, everything still works except that there is no rogue RA protection. > > This should make everyone happy except those so set in their IPv4 ways that they insist on removing RAs. Which is not only a bad idea, but an exercise in futility because of the large number of "legacy IPv6" hosts that need RAs to function and won't go away anytime soon. I think it's a fine solution as far as it goes and a good part of a complete solution. However, documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO. As it currently stands, some hosts which are DHCPv6 capable will not attempt to query DHCP until they receive an RA with the M bit set. Yes, there will be an issue with legacy IPv6 hosts needing to catch up with the protocol change for some time. However, this has been the case with many changes over time in IPv4 as well. Look at the transition from BootP to DHCP. Administrators are actually capable of adapting to or in some cases influencing the level of required hardware/software performance of things that connect to their network if given the tools to do so. Owen From nanog at jima.tk Fri Jun 10 12:54:17 2011 From: nanog at jima.tk (Jima) Date: Fri, 10 Jun 2011 12:54:17 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> Message-ID: <4DF25A49.1050100@jima.tk> On 06/10/2011 12:32 PM, Owen DeLong wrote: > I think it's a fine solution as far as it goes and a good part of a complete solution. However, > documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO. As it currently stands, some hosts which are DHCPv6 capable will not attempt to query DHCP until they receive an RA with the M bit set. If we go down this path, how long before we hear screaming about rogue DHCPv6 servers giving v4-only networks a false v6 path? (At least that could be nullified by adding actual v6 support and an RA without the M bit.) Jima From Valdis.Kletnieks at vt.edu Fri Jun 10 13:18:12 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Jun 2011 14:18:12 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: Your message of "Fri, 10 Jun 2011 12:54:17 CDT." <4DF25A49.1050100@jima.tk> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <4DF25A49.1050100@jima.tk> Message-ID: <25705.1307729892@turing-police.cc.vt.edu> On Fri, 10 Jun 2011 12:54:17 CDT, Jima said: > If we go down this path, how long before we hear screaming about rogue > DHCPv6 servers giving v4-only networks a false v6 path? Already happened. Good way to install an MITM against any v6-enabled boxes on a v4-only network, been multiple reported uses of that technique. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Christopher.Palmer at microsoft.com Fri Jun 10 13:20:04 2011 From: Christopher.Palmer at microsoft.com (Christopher Palmer) Date: Fri, 10 Jun 2011 18:20:04 +0000 Subject: Thank you Microsoft (and others) In-Reply-To: <218A1779A7A0984894CBD218EFF84AC45D9765@CEXMB003.nmes.lcl> References: <001201cc25f9$82a72be0$87f583a0$@com> <4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net> <218A1779A7A0984894CBD218EFF84AC45D9765@CEXMB003.nmes.lcl> Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CE46011@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Thank you for the thanks :) We'll be leaving the www.xbox.com web properties online indefinitely. We're holding on other properties but are moving forward at a brisk pace. Best, Chris -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Friday, June 10, 2011 9:49 AM To: Jared Mauch; Shahid Shafi Cc: NANOG list Subject: RE: Thank you Microsoft (and others) I've been saved by the sound of Microsoft. ~Jay "We move the information that moves your world." ?Engineering is about finding the sweet spot between what's solvable and what isn't." ?Good engineering demands that we understand what we?re doing and why, keep an open mind, and learn from experience.? Radia Perlman ? Please consider the environment before printing e-mail -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Wednesday, June 08, 2011 7:20 PM To: Shahid Shafi Cc: NANOG list Subject: Thank you Microsoft (and others) I think it's important to thank Microsoft for leaving sites like xbox IPv6 enabled. Hope many other participants leave it on as well. I think it's a certain sign of the maturity of the protocol and networks at this stage of the game. I have observed some traffic step-down in the network, but it's not entirely clear if it's lowered to levels pre-v6-day. Looking forward to those sharing data at NANOG next week. (I'm not convinced the data I have is worth sharing, but will send it over to the nanogpc soon enough..) - Jared On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: > I dont think ISOC dashboard is updating any more. Google is no longer > advertising AAAA but dashboard still shows green and TTLs were short on > those records. From cscora at apnic.net Fri Jun 10 14:02:38 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Jun 2011 05:02:38 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201106101902.p5AJ2cjt011776@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 11 Jun, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 359107 Prefixes after maximum aggregation: 162630 Deaggregation factor: 2.21 Unique aggregates announced to Internet: 178253 Total ASes present in the Internet Routing Table: 37831 Prefixes per ASN: 9.49 Origin-only ASes present in the Internet Routing Table: 31580 Origin ASes announcing only one prefix: 15168 Transit ASes present in the Internet Routing Table: 5113 Transit-only ASes present in the Internet Routing Table: 135 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 783 Unregistered ASNs in the Routing Table: 419 Number of 32-bit ASNs allocated by the RIRs: 1446 Number of 32-bit ASNs visible in the Routing Table: 1138 Prefixes from 32-bit ASNs in the Routing Table: 2602 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 164 Number of addresses announced to Internet: 2487684608 Equivalent to 148 /8s, 71 /16s and 14 /24s Percentage of available address space announced: 67.1 Percentage of allocated address space announced: 67.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.1 Total number of prefixes smaller than registry allocations: 149733 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 88931 Total APNIC prefixes after maximum aggregation: 29983 APNIC Deaggregation factor: 2.97 Prefixes being announced from the APNIC address blocks: 85430 Unique aggregates announced from the APNIC address blocks: 36696 APNIC Region origin ASes present in the Internet Routing Table: 4477 APNIC Prefixes per ASN: 19.08 APNIC Region origin ASes announcing only one prefix: 1251 APNIC Region transit ASes present in the Internet Routing Table: 703 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 46 Number of APNIC addresses announced to Internet: 620146464 Equivalent to 36 /8s, 246 /16s and 175 /24s Percentage of available APNIC address space announced: 78.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 140907 Total ARIN prefixes after maximum aggregation: 71613 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 112819 Unique aggregates announced from the ARIN address blocks: 46088 ARIN Region origin ASes present in the Internet Routing Table: 14426 ARIN Prefixes per ASN: 7.82 ARIN Region origin ASes announcing only one prefix: 5503 ARIN Region transit ASes present in the Internet Routing Table: 1517 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 818671872 Equivalent to 48 /8s, 203 /16s and 241 /24s Percentage of available ARIN address space announced: 65.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 85501 Total RIPE prefixes after maximum aggregation: 48681 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 78946 Unique aggregates announced from the RIPE address blocks: 52214 RIPE Region origin ASes present in the Internet Routing Table: 15695 RIPE Prefixes per ASN: 5.03 RIPE Region origin ASes announcing only one prefix: 7840 RIPE Region transit ASes present in the Internet Routing Table: 2472 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 847 Number of RIPE addresses announced to Internet: 477055488 Equivalent to 28 /8s, 111 /16s and 74 /24s Percentage of available RIPE address space announced: 76.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 32899 Total LACNIC prefixes after maximum aggregation: 7498 LACNIC Deaggregation factor: 4.39 Prefixes being announced from the LACNIC address blocks: 31955 Unique aggregates announced from the LACNIC address blocks: 16895 LACNIC Region origin ASes present in the Internet Routing Table: 1451 LACNIC Prefixes per ASN: 22.02 LACNIC Region origin ASes announcing only one prefix: 433 LACNIC Region transit ASes present in the Internet Routing Table: 253 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 228 Number of LACNIC addresses announced to Internet: 84687104 Equivalent to 5 /8s, 12 /16s and 57 /24s Percentage of available LACNIC address space announced: 56.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8043 Total AfriNIC prefixes after maximum aggregation: 1920 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 6357 Unique aggregates announced from the AfriNIC address blocks: 1904 AfriNIC Region origin ASes present in the Internet Routing Table: 460 AfriNIC Prefixes per ASN: 13.82 AfriNIC Region origin ASes announcing only one prefix: 141 AfriNIC Region transit ASes present in the Internet Routing Table: 100 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 24155648 Equivalent to 1 /8s, 112 /16s and 150 /24s Percentage of available AfriNIC address space announced: 36.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2462 9500 924 Korea Telecom (KIX) 17974 1561 441 38 PT TELEKOMUNIKASI INDONESIA 7545 1539 301 86 TPG Internet Pty Ltd 4755 1471 634 166 TATA Communications formerly 24560 1152 336 187 Bharti Airtel Ltd., Telemedia 7552 1146 1064 7 Vietel Corporation 9583 1071 79 500 Sify Limited 4808 1052 2098 299 CNCGROUP IP network: China169 9829 1029 870 67 BSNL National Internet Backbo 17488 946 191 102 Hathway IP Over Cable Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3628 3822 252 bellsouth.net, inc. 4323 1963 1097 401 Time Warner Telecom 18566 1913 365 237 Covad Communications 1785 1791 681 122 PaeTec Communications, Inc. 6478 1721 319 45 AT&T Worldnet Services 20115 1539 1541 633 Charter Communications 19262 1490 4932 314 Verizon Global Networks 7018 1364 7052 891 AT&T WorldNet Services 22773 1340 2897 87 Cox Communications, Inc. 2386 1271 536 912 AT&T Data Communications Serv Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 521 106 180 BILISIM TELEKOM 6830 513 1780 320 UPC Distribution Services 3292 464 2078 399 TDC Tele Danmark 20940 462 135 354 Akamai Technologies European 29049 451 33 48 AzerSat LLC. 8866 445 134 26 Bulgarian Telecommunication C 12479 436 593 7 Uni2 Autonomous System 3320 425 8152 370 Deutsche Telekom AG 8551 406 355 45 Bezeq International 702 396 1803 310 UUNET - Commercial IP service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1513 278 157 TVCABLE BOGOTA 28573 1321 992 80 NET Servicos de Comunicao S.A 8151 1268 2727 364 UniNet S.A. de C.V. 7303 990 506 170 Telecom Argentina Stet-France 6503 739 354 73 AVANTEL, S.A. 14420 677 54 80 CORPORACION NACIONAL DE TELEC 22047 564 310 15 VTR PUNTO NET S.A. 3816 528 231 94 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 13489 516 262 124 Orbitel S.A. E.S.P. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 797 445 11 TEDATA 24863 795 147 37 LINKdotNET AS number 15475 527 74 8 Nile Online 36992 308 415 18 Etisalat MISR 3741 264 937 225 The Internet Solution 6713 241 215 13 Itissalat Al-MAGHRIB 24835 210 78 10 RAYA Telecom - Egypt 33776 200 12 11 Starcomms Nigeria Limited 29571 192 17 11 Ci Telecom Autonomous system 16637 150 441 86 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3628 3822 252 bellsouth.net, inc. 23456 2602 639 1421 32-bit ASN transition 4766 2462 9500 924 Korea Telecom (KIX) 4323 1963 1097 401 Time Warner Telecom 18566 1913 365 237 Covad Communications 1785 1791 681 122 PaeTec Communications, Inc. 6478 1721 319 45 AT&T Worldnet Services 17974 1561 441 38 PT TELEKOMUNIKASI INDONESIA 7545 1539 301 86 TPG Internet Pty Ltd 20115 1539 1541 633 Charter Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 18566 1913 1676 Covad Communications 6478 1721 1676 AT&T Worldnet Services 1785 1791 1669 PaeTec Communications, Inc. 4323 1963 1562 Time Warner Telecom 4766 2462 1538 Korea Telecom (KIX) 17974 1561 1523 PT TELEKOMUNIKASI INDONESIA 7545 1539 1453 TPG Internet Pty Ltd 10620 1513 1356 TVCABLE BOGOTA 4755 1471 1305 TATA Communications formerly 22773 1340 1253 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 27.0.128.0/17 7514 Media Exchange, Inc. 31.131.192.0/19 42368 RIPE Network Coordination Cen 41.190.32.0/23 31856 CABSAS 41.190.34.0/23 31856 CABSAS Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:22 /9:12 /10:28 /11:80 /12:230 /13:462 /14:800 /15:1394 /16:11946 /17:5847 /18:9787 /19:19372 /20:25829 /21:26021 /22:34187 /23:33194 /24:186895 /25:1055 /26:1225 /27:663 /28:41 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2233 3628 bellsouth.net, inc. 18566 1870 1913 Covad Communications 6478 1675 1721 AT&T Worldnet Services 10620 1403 1513 TVCABLE BOGOTA 23456 1290 2602 32-bit ASN transition 11492 1092 1138 Cable One 7011 1061 1161 Citizens Utilities 1785 1050 1791 PaeTec Communications, Inc. 7029 909 1159 Alltel Information Services, 4323 875 1963 Time Warner Telecom Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:285 2:48 4:16 5:1 6:3 8:338 12:1977 13:1 14:461 15:15 16:3 17:8 20:10 23:11 24:1611 27:772 31:429 32:60 33:4 34:2 37:1 38:737 40:103 41:2515 42:2 44:3 46:957 47:3 49:187 50:405 52:13 54:2 55:4 56:2 57:29 58:841 59:475 60:387 61:1122 62:1053 63:1935 64:3939 65:2254 66:4138 67:1884 68:1086 69:3003 70:705 71:373 72:1846 74:2354 75:309 76:340 77:881 78:706 79:457 80:1106 81:832 82:493 83:457 84:666 85:1080 86:581 87:751 88:330 89:1529 90:204 91:3839 92:526 93:1037 94:1292 95:825 96:444 97:251 98:871 99:36 101:68 103:56 106:6 107:11 108:83 109:973 110:601 111:710 112:299 113:399 114:537 115:687 116:959 117:675 118:793 119:1142 120:313 121:669 122:1627 123:950 124:1274 125:1217 128:261 129:175 130:164 131:577 132:110 133:19 134:214 135:48 136:214 137:144 138:300 139:112 140:469 141:238 142:404 143:417 144:495 145:54 146:448 147:214 148:606 149:247 150:172 151:187 152:330 153:180 154:3 155:399 156:195 157:352 158:138 159:380 160:318 161:208 162:309 163:165 164:500 165:352 166:530 167:424 168:729 169:155 170:832 171:77 172:1 173:1605 174:584 175:371 176:133 177:135 178:1003 180:886 181:18 182:466 183:216 184:297 185:1 186:1188 187:753 188:848 189:910 190:4890 192:5841 193:4918 194:3497 195:3003 196:1231 197:20 198:3585 199:3927 200:5498 201:1480 202:8316 203:8357 204:4187 205:2339 206:2679 207:2826 208:3946 209:3471 210:2713 211:1400 212:2008 213:1727 214:742 215:68 216:4923 217:1638 218:548 219:364 220:1205 221:490 222:317 223:156 End of report From sclark at netwolves.com Fri Jun 10 14:21:27 2011 From: sclark at netwolves.com (Steve Clark) Date: Fri, 10 Jun 2011 15:21:27 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> Message-ID: <4DF26EB7.70502@netwolves.com> On 06/10/2011 09:37 AM, Ray Soucy wrote: > You really didn't just write an entire post saying that RA is bad > because if a moron of a network engineer plugs an incorrectly > configured device into a production network it may cause problems, did > you? > You are the moron - this stuff happens and wishing it didn't doesn't stop it. Get a clue! > Honestly. This whole argument is getting ridiculous. > > On Fri, Jun 10, 2011 at 9:32 AM, Leo Bicknell wrote: >> In a message written on Fri, Jun 10, 2011 at 01:03:01PM +0000, Bjoern A. Zeeb wrote: >>> On Jun 10, 2011, at 10:10 AM, sthaug at nethelp.no wrote: >>>> Several large operators have said, repeatedly, that they want to use >>>> DHCPv6 without RA. I disagree that this is stupid. >>> I wonder if it's just a "violation" of rule #1: stop thinking legacy! >>> >>> People are used to what they have done for a decade or two. It's hard to >>> see the change and results in "why is this all so different and complicated?". >>> It's hard to open ones mind for the new, but it is essential to do with new >>> technology. >> The problem in this case is that the failure modes are significantly >> different. Some folks have learned this the hard way. >> >> It's a very easy scenario to reconstruct. Consider the "branch >> office router" in a typical corporate enviornment. We're talking >> a device with one WAN port, and one LAN port. Configure it for >> dual stack, speaking IPv4, and in IPv4 configure it the typical >> corporate way with a "DHCP Helper" forwarding requests over the WAN >> to a central DHCP server. In IPv6, configure it with RA's, the >> supposed "better" way. >> >> Now, take the 100% working branch router and have it sent back to >> corporate. Maybe they got a bigger router, maybe the office closed. >> A network engineer gets the router and is tasked with making it >> ready to redeploy. >> >> The network engineer plugs it into the switch on his desktop, plugs in a >> serial cable, turns it on and steps out to get a coffee while it boots. >> He's planning to erase the configuration and then load new software over >> the network. >> >> As soon as the router boots the IPv6 network fails for all the users on >> his subnet. IPv4 keeps working fine. >> >> Oops. >> >> What happened? Well, the router sent IPv6 RA's as soon as it came >> up, and every workstation instantly started using them. In IPv4, >> the router received DHCPv4 requests and forwarded them per the >> helper address, except that its WAN port is down, and thus it in >> fact didn't send them anywhere. >> >> The important points: >> >> - IPv4 "failed safe" with the DHCP config. This "rogue device" will >> never disrupt the IPv4 configuration. DHCP snooping isn't even needed >> in your switches, since it never returns a response. >> >> - IPv6 "failed immediately" with the RA configuration. What's worse is >> if you simply turn the device off after you realized you took down the >> entire network devices will continue to be broken for 2-4 hours until >> the RA's time out. The only method to mitigate is to deploy RA guard >> on all of your switches, which probably means replacing 100% of your >> hardware with new stuff that can do that, and then deploying new >> features. >> >> The fact of the matter is that the failure modes of these two >> protocols are vastly different operationally. The DHCP failure >> semantics are not only better understood, but cause less disruption >> to the network. Even a properly rouge DHCP server will only damage >> _new_ clients coming up on a network, existing folks will work just >> fine. Contrast with RA's which instantly break 100% of the users. >> >> Even more annoying is that if I use RA's for the default gateway, >> I still have to run DHCPv6 anyway. If I don't my boxes don't have >> DNS servers, NTP servers, know where to tftpboot, etc. It's not a >> choice of one or the other, it's I always run DHCPv6, do I need >> RA's or not. >> >> Given the failure modes I would much prefer to run with RA's turned off >> completely, and have DHCPv6 able to provide a default gateway just as it >> works in IPv4. >> >> My opinion comes not from "thinking legacy", indeed my employer has been >> fully dual stacked since 2003. My opinion comes from the fact that in >> the 8 years of operational experience we have RA's are significantly >> more fragile, and IMHO not ready for widespread IPv6 deployment. >> >> -- >> Leo Bicknell - bicknell at ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ >> > > -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From josh.hoppes at gmail.com Fri Jun 10 14:52:16 2011 From: josh.hoppes at gmail.com (Josh Hoppes) Date: Fri, 10 Jun 2011 14:52:16 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <4DF26EB7.70502@netwolves.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> Message-ID: On Fri, Jun 10, 2011 at 2:21 PM, Steve Clark wrote: > On 06/10/2011 09:37 AM, Ray Soucy wrote: >> >> You really didn't just write an entire post saying that RA is bad >> because if a moron of a network engineer plugs an incorrectly >> configured device into a production network it may cause problems, did >> you? >> > > You are the moron - this stuff happens and wishing it didn't doesn't stop > it. Get a clue! > No matter how much stupidity you try account for, there is infinitely more to come. From iljitsch at muada.com Fri Jun 10 14:57:07 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 21:57:07 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> Message-ID: On 10 jun 2011, at 18:06, Leo Bicknell wrote: > However, many networks are much more closed deployments. Enterprises > have not deployed IPv6 internally yet. Many will not deploy it for > another 3-5 years, chosing instead to use web proxies at the edge > that speak IPv4 (RFC1918) internally and IPv6 externally. They > often can enforce the software deployed on the boxes connected. If they have such tight control over their network and what attaches to it, then obviously rogue RAs can be clamped down upon in a variety of ways. > The fact that bad standards and software exist today should never be an > argument to not design and deploy better software. So what if it takes > until 2019, at least from 2019 to the end of IPv6 we'll have something > better. If only. Having third parties point to routers is less robust than having routers announce their own presence. In the telco world, there's a separation between the control and data channels, which has important security advantages. But the IETF has always favored fate sharing. It makes routing protocols more robust and it makes RA more robust than IPv4 DHCP. I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems. People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. On 10 jun 2011, at 19:32, Owen DeLong wrote: > Some administrators want DHCP to be a complete solution and do not want to use RA at all, whether from a legitimate router or otherwise. It's good to want things. Doesn't mean you'll get it. One of the three big RIRs has already run out of IPv4 space, the second will within less than a year. IPv6 deployment is still measured by counting zeroes behind the decimal point. We still don't have good CPE and broadband specs. The "happy eyeballs" stuff is still experimental but much needed. Important operating systems have serious IPv6-related bugs. And THIS is the time to start asking for a new feature that even when viewed most favorably, is just a nice-to-have? No more that pesky multicast packet once every 200 seconds (or when a new host attaches to the network). Yes, that's really something the IETF and vendors have to spend their cycles on. NOW. Because otherwise, you know, there's this packet. It's really bad. Every 200 seconds! > There are situations, for example, where the administrator does not want all hosts in a broadcast domain to receive the same set of prefixes and/or the same set of routers. This can be achieved by using different parameters based on the system identifier in the DHCP configuration. It cannot be achieved using RA. It can also be done using my suggested "DHCP validates RA gateway address" mechanism. > Eliminating rogue RAs is not the problem being described. That problem is solved through RA-Guard. Well, someone certainly intermingled the discussions, and it wasn't me. > The problem being described is the desire to be able to configure a host from zero to functionally on the internet using DHCP without RAs. I think everyone understands that you don't want to do so. That's fine. However, adding the functionality to DHCPv6 doesn't require you to use it. Making it available for operators that want to use it is not a bad thing. It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such an option. As such, my life will be worse when this is done so I'm against doing this. I just wish someone had said the same when it was decided that .ip6.int in reverse DNS zone files was ugly and needed to be changed to .ip6.arpa. Or when someone decided that it's a good idea to set the DF bit on ALL packets when doing PMTUD. This industry has a history of doing stuff that ends up wasting huge amounts of time and money that could easily have been avoided but apparently the voice of reason was absent that day. Not this time. > In some situations, this fate (it's fate, not fait, btw) Oh, right, I always get that wrong and I know I always get it wrong but still that doesn't help me to get it right. > sharing is not desired. Why not? > documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO. Nope, not a good thing. It doesn't work for normal operation because the delay while lack of RAs is observed would be unacceptable. Also, the M and O bits need to be honored. A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack acknowledgments. And like I said before, we have more pressing things to do than tinker some more with DHCPv6. From os10rules at gmail.com Fri Jun 10 15:13:32 2011 From: os10rules at gmail.com (Greg Ihnen) Date: Fri, 10 Jun 2011 15:43:32 -0430 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> Message-ID: <4D8B7202-B59B-4C14-8CE7-85F72837130F@gmail.com> On Jun 10, 2011, at 10:06 AM, Ricardo Ferreira wrote: > I live in europe and we have at home 100Mbps . Mid sized city of 500k > people. Some ISPs even spread WiFi across town so that subscribers can have > internet access outside their homes. Cablevision does that somewhat. Greg From jfbeam at gmail.com Fri Jun 10 15:24:58 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 10 Jun 2011 16:24:58 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610134744.GA20607@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> Message-ID: On Fri, 10 Jun 2011 09:47:44 -0400, Leo Bicknell wrote: > The point is, RA's are operationally fragile and DHCP is operationally > robust. No. Both are just as fragile... if you haven't taken steps to protect them. If you aren't doing any sort of DHCP snooping, anyone can setup a rogue DHCP server and kill your network -- been there, laughed at them. Even my *home* lan has DHCP snooping configured. The only question is support for "RA Guard" in your network hardware. A lot of old gear isn't going to support it. But DHCP was no different. --Ricky PS: Don't read into this... I hate SLAAC and RA, more than most people. (it's been a bad idea from day one.) From bicknell at ufp.org Fri Jun 10 15:27:58 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Jun 2011 13:27:58 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> Message-ID: <20110610202758.GA38897@ussenterprise.ufp.org> In a message written on Fri, Jun 10, 2011 at 09:57:07PM +0200, Iljitsch van Beijnum wrote: > If only. Having third parties point to routers is less robust than having routers announce their own presence. In the telco world, there's a separation between the control and data channels, which has important security advantages. But the IETF has always favored fate sharing. It makes routing protocols more robust and it makes RA more robust than IPv4 DHCP. Apparently we don't have a long enough view of history, as history will tell you that this is wrong. You see, we tried the RA experiement once before. Let's go back to the Internet circa 1988, or so. There was a time when it was very common for routers to run RIP. There was a time when Sun systems (in particular, other vendors did the same) shipped with routed enabled by default. Many of these systems learned their default gateway by listening to these RIP announcements. The funny thing is, no one does this anymore. We turned off RIP, turned off routed, and invented things like HSRP to handle router redundancy. These things weren't done because someone was bored, no, they were done because these RIP deployments failed, repeatedly and often. Any device could broadcast bad information, and they did. It could be a legitimate network admin plugging a cable into the wrong jack, or it could be a hacker who rooted a machine and is injecting bad information on purpose. I submit to you those who designed RA's do not remember those days, and did not study history. The only difference is that RA's only carry a default route, where as RIP could carry several routes. The security model is identical. The failure modes are largely overlapping. IPv4 also had a similar feature, ICMP router discovery, RFC 1256. Works a little different than RA's do, but not a lot. Have you ever seen it used? I haven't. Least you think the IETF is proud of their RA work, one needs look no further than RFC 6104, where they carefully document the problem of rogue RA's and provide a list of solutions. Indeed, my proposed DHCP solution is documented in section 3.10. The IETF seems to think SEND is the solution, but it also requires deploying new software to 100% of all devices in order to be the solution. > People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. I participated until a working group chair told some protocol wonks "Don't listen to him, he's an operator and doesn't understand IPv6 yet." The IETF has a long history of being openly hostle to operators. That was the day I gave up on the IETF. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Fri Jun 10 15:38:42 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Jun 2011 16:38:42 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: Your message of "Fri, 10 Jun 2011 13:27:58 PDT." <20110610202758.GA38897@ussenterprise.ufp.org> References: <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <20110610202758.GA38897@ussenterprise.ufp.org> Message-ID: <46691.1307738322@turing-police.cc.vt.edu> On Fri, 10 Jun 2011 13:27:58 PDT, Leo Bicknell said: > The funny thing is, no one does this anymore. We turned off RIP, > turned off routed, and invented things like HSRP to handle router > redundancy. These things weren't done because someone was bored, > no, they were done because these RIP deployments failed, repeatedly > and often. Any device could broadcast bad information, and they > did. It could be a legitimate network admin plugging a cable into > the wrong jack, or it could be a hacker who rooted a machine and > is injecting bad information on purpose. Has senility set in, or wasn't there even an incident where somebody advertised 127/8 via RIP - and lots of nodes *believed* it, even though they should have realized that they had an interface on that network already? (And yes, I know of *multiple* failures of broadcasting a default route and getting swamped as a result - this one was 127/8 specifically)... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nonobvious at gmail.com Fri Jun 10 15:39:37 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 10 Jun 2011 13:39:37 -0700 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <13265444.192.1307571526628.JavaMail.root@benjamin.baylink.com> References: <20110608220518.426791082F53@drugs.dv.isc.org> <13265444.192.1307571526628.JavaMail.root@benjamin.baylink.com> Message-ID: So should monthly IPv6 day be the same week as Microsoft Patch Tuesday? :-) From jared at puck.nether.net Fri Jun 10 15:45:19 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 10 Jun 2011 16:45:19 -0400 Subject: IPv6 Week (was Re: So... is it time to do IPv6 day monthy yet?) In-Reply-To: References: <20110608220518.426791082F53@drugs.dv.isc.org> <13265444.192.1307571526628.JavaMail.root@benjamin.baylink.com> Message-ID: My thoughts are that we need either a week or a 36-48 hour period. I thought this before the events of last week. I am very happy with the results and that based on the public statements so far (Looking forward to hearing what is presented at NANOG on this as well) that it was viewed as "didn't break much" by the major players. This affirms to me what we've observed for many years. Having IPv6 enabled doesn't break "much", and not in a way that is any more broken by the issues you can observe in networks otherwise. - Jared On Jun 10, 2011, at 4:39 PM, Bill Stewart wrote: > So should monthly IPv6 day be the same week as Microsoft Patch Tuesday? :-) From joelja at bogus.com Fri Jun 10 16:06:33 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 10 Jun 2011 14:06:33 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <4DF26EB7.70502@netwolves.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> Message-ID: <64A1C6B5-A8AB-40A2-BE79-31D41B2256FE@bogus.com> On Jun 10, 2011, at 12:21 PM, Steve Clark wrote: > On 06/10/2011 09:37 AM, Ray Soucy wrote: >> You really didn't just write an entire post saying that RA is bad >> because if a moron of a network engineer plugs an incorrectly >> configured device into a production network it may cause problems, did >> you? >> > > You are the moron - this stuff happens and wishing it didn't doesn't stop it. Get a clue! engaging in ad homenim in the course of a technical argument on this list is not appropriate. >> Honestly. This whole argument is getting ridiculous. From rhys at rhavenindustrys.com Fri Jun 10 16:30:49 2011 From: rhys at rhavenindustrys.com (Rhys Rhaven) Date: Fri, 10 Jun 2011 16:30:49 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610202758.GA38897@ussenterprise.ufp.org> References: <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <20110610202758.GA38897@ussenterprise.ufp.org> Message-ID: <4DF28D09.1070304@rhavenindustrys.com> And here I thought with IPv6, we would have learned from our mistakes, fixed those problems. We've had 15 years to think about it. I was looking forward to a future where ICMPv6 might even be used. At this point I'm looking forward to IPv6 being the bane of my career for the next 5 years. On 06/10/2011 03:27 PM, Leo Bicknell wrote: > IPv4 also had a similar feature, ICMP router discovery, RFC 1256. > Works a little different than RA's do, but not a lot. Have you ever > seen it used? I haven't. From iljitsch at muada.com Fri Jun 10 16:34:56 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 10 Jun 2011 23:34:56 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <4DF28D09.1070304@rhavenindustrys.com> References: <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <20110610202758.GA38897@ussenterprise.ufp.org> <4DF28D09.1070304@rhavenindustrys.com> Message-ID: <28545FB6-44FA-488B-AF8C-A95A4A901B27@muada.com> On 10 jun 2011, at 23:30, Rhys Rhaven wrote: > And here I thought with IPv6, we would have learned from our mistakes, > fixed those problems. We've had 15 years to think about it. I was > looking forward to a future where ICMPv6 might even be used. What are you talking about?? ICMPv6 does what IPv4 ICMP does as well as ARP and then some. From joelja at bogus.com Fri Jun 10 16:42:23 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 10 Jun 2011 14:42:23 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <25705.1307729892@turing-police.cc.vt.edu> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <4DF25A49.1050100@jima.tk> <25705.1307729892@turing-police.cc.vt.edu> Message-ID: On Jun 10, 2011, at 11:18 AM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 10 Jun 2011 12:54:17 CDT, Jima said: >> If we go down this path, how long before we hear screaming about rogue >> DHCPv6 servers giving v4-only networks a false v6 path? > > Already happened. Good way to install an MITM against any v6-enabled boxes > on a v4-only network, been multiple reported uses of that technique. What's more v4 seem rather less likely to have any countermeasures or methods for detecting this... Back when I worked for a security vendor our endpoint security product specifically disabled ipv6 to address this exposure. From cidr-report at potaroo.net Fri Jun 10 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Jun 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201106102200.p5AM00w6087652@wattle.apnic.net> BGP Update Report Interval: 02-Jun-11 -to- 09-Jun-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19743 33461 2.4% 5576.8 -- 2 - AS7184 31256 2.3% 538.9 -- Universidad Verecruzana 3 - AS9829 22167 1.6% 26.2 -- BSNL-NIB National Internet Backbone 4 - AS27738 16576 1.2% 48.9 -- Ecuadortelecom S.A. 5 - AS32528 16367 1.2% 2045.9 -- ABBOTT Abbot Labs 6 - AS7029 15057 1.1% 7.8 -- WINDSTREAM - Windstream Communications Inc 7 - AS4766 14915 1.1% 6.3 -- KIXS-AS-KR Korea Telecom 8 - AS33475 13665 1.0% 99.0 -- RSN-1 - RockSolid Network, Inc. 9 - AS9498 13223 1.0% 25.7 -- BBIL-AP BHARTI Airtel Ltd. 10 - AS17974 12061 0.9% 23.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS24560 11947 0.9% 23.1 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 12 - AS11492 10573 0.8% 18.1 -- CABLEONE - CABLE ONE, INC. 13 - AS14420 10259 0.8% 15.2 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 14 - AS3320 9990 0.7% 285.4 -- DTAG Deutsche Telekom AG 15 - AS15475 9873 0.7% 17.7 -- NOL 16 - AS45595 9187 0.7% 30.3 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 17 - AS9228 8969 0.7% 332.2 -- CENTRALONLINE-ID-AS-AP PT. Total Info Kharisma 18 - AS8551 8070 0.6% 25.1 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone 19 - AS4788 7758 0.6% 5.1 -- TMNET-AS-AP TM Net, Internet Service Provider 20 - AS3454 7439 0.5% 7439.0 -- Universidad Autonoma de Nuevo Leon TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3454 7439 0.5% 7439.0 -- Universidad Autonoma de Nuevo Leon 2 - AS19743 33461 2.4% 5576.8 -- 3 - AS32528 16367 1.2% 2045.9 -- ABBOTT Abbot Labs 4 - AS17408 3479 0.2% 1739.5 -- ABOVE-AS-AP AboveNet Communications Taiwan 5 - AS24666 6687 0.5% 1671.8 -- AXA-AS AXA Luxembourg S.A 6 - AS51722 1668 0.1% 1668.0 -- EAD-TELECOM-AS EAD TELECOM SRL 7 - AS44100 1044 0.1% 1044.0 -- ARIELTV-AS Ariel TV AD 8 - AS38388 2837 0.2% 945.7 -- BEN-AS-KR Bukbu District Office of Education in Seoul 9 - AS49600 901 0.1% 901.0 -- LASEDA La Seda de Barcelona, S.A 10 - AS42934 739 0.1% 739.0 -- SSIF-AS CONFIDENT INVEST Bucuresti SA 11 - AS39263 657 0.1% 657.0 -- ILIMIT Ilimit Comunicacions, S.L. Barcelona Spain 12 - AS3 596 0.0% 735.0 -- RC-IKT RC IKT, d.o.o. 13 - AS5313 547 0.0% 547.0 -- DNIC-ASBLK-05120-05376 - DoD Network Information Center 14 - AS7184 31256 2.3% 538.9 -- Universidad Verecruzana 15 - AS10445 2400 0.2% 480.0 -- HTG - Huntleigh Telcom 16 - AS56050 455 0.0% 455.0 -- NEW-SHINE-INTERNET-TH 134 Yenchit Road 17 - AS44584 1764 0.1% 441.0 -- PTLINE-AS Progress Tehnologiya LLC 18 - AS38021 439 0.0% 439.0 -- IIFTNET-AS-AP Network of Indian Institute of Foreign Trade, 19 - AS28519 1286 0.1% 428.7 -- Universidad Autonoma de Guadalajara, A.C. 20 - AS37178 766 0.1% 383.0 -- ALPHA-BETA-CONSULTING TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 11703 0.8% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 91.217.214.0/24 9547 0.6% AS3320 -- DTAG Deutsche Telekom AG 3 - 130.36.34.0/24 8173 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 8169 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 200.23.202.0/24 7439 0.5% AS3454 -- Universidad Autonoma de Nuevo Leon 6 - 65.122.196.0/24 6386 0.4% AS19743 -- 7 - 65.163.182.0/24 5418 0.4% AS19743 -- 8 - 65.162.204.0/24 5416 0.4% AS19743 -- 9 - 72.164.144.0/24 5415 0.4% AS19743 -- 10 - 66.238.91.0/24 5414 0.4% AS19743 -- 11 - 66.89.98.0/24 5412 0.4% AS19743 -- 12 - 202.153.174.0/24 3478 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 13 - 195.39.244.0/24 2136 0.1% AS24666 -- AXA-AS AXA Luxembourg S.A 14 - 193.110.190.0/24 2134 0.1% AS24666 -- AXA-AS AXA Luxembourg S.A 15 - 65.181.192.0/23 2111 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 16 - 77.81.5.0/24 1668 0.1% AS51722 -- EAD-TELECOM-AS EAD TELECOM SRL 17 - 202.54.86.0/24 1408 0.1% AS4755 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 18 - 24.116.1.0/24 1405 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 19 - 24.116.2.0/24 1373 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 20 - 1.231.14.0/24 1246 0.1% AS38388 -- BEN-AS-KR Bukbu District Office of Education in Seoul Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 10 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Jun 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201106102200.p5AM00gU087644@wattle.apnic.net> This report has been generated at Fri Jun 10 21:12:02 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 03-06-11 362189 212183 04-06-11 362105 212448 05-06-11 362218 212474 06-06-11 362277 212388 07-06-11 362171 212165 08-06-11 362348 212448 09-06-11 362409 212595 10-06-11 362401 213037 AS Summary 37946 Number of ASes in routing system 15980 Number of ASes announcing only one prefix 3626 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109886720 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 10Jun11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 363046 213017 150029 41.3% All ASes AS6389 3626 256 3370 92.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 1963 402 1561 79.5% TWTC - tw telecom holdings, inc. AS4766 2462 934 1528 62.1% KIXS-AS-KR Korea Telecom AS6478 1721 285 1436 83.4% ATT-INTERNET3 - AT&T Services, Inc. AS18566 1913 493 1420 74.2% COVAD - Covad Communications Co. AS22773 1340 96 1244 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1493 308 1185 79.4% VZGNI-TRANSIT - Verizon Online LLC AS4755 1472 418 1054 71.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1796 759 1037 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS7552 1146 112 1034 90.2% VIETEL-AS-AP Vietel Corporation AS28573 1317 294 1023 77.7% NET Servicos de Comunicao S.A. AS10620 1513 625 888 58.7% Telmex Colombia S.A. AS7545 1539 747 792 51.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 934 145 789 84.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1152 391 761 66.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4808 1056 338 718 68.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS8151 1268 556 712 56.2% Uninet S.A. de C.V. AS7303 990 310 680 68.7% Telecom Argentina S.A. AS3356 1118 457 661 59.1% LEVEL3 Level 3 Communications AS17488 946 315 631 66.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS17974 1561 939 622 39.8% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS14420 677 80 597 88.2% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS17676 666 70 596 89.5% GIGAINFRA Softbank BB Corp. AS22561 933 356 577 61.8% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 978 417 561 57.4% GBLX Global Crossing Ltd. AS855 647 109 538 83.2% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4780 750 214 536 71.5% SEEDNET Digital United Inc. AS22047 564 30 534 94.7% VTR BANDA ANCHA S.A. AS7011 1161 628 533 45.9% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4804 586 87 499 85.2% MPX-AS Microplex PTY LTD Total 39288 11171 28117 71.6% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 27.0.128.0/17 AS7514 MEX Media EXchange, Inc. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.22.32.0/19 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 103.10.100.0/22 AS17547 QALA-SG-AP M1 CONNECT PTE. LTD. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 131.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.72.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.100.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.161.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.221.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.157.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.184.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.191.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 134.175.0.0/16 AS14576 RHNL-NET - Righthosting.com 134.175.0.0/19 AS12124 THORN - Thorn Communications 138.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.36.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.94.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.97.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.99.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.117.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.118.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.122.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.185.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.186.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.219.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 143.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.137.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.208.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.101.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.102.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.103.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.156.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.166.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.167.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.168.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.169.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.170.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.171.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.172.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.173.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.174.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.175.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.200.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.201.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.203.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.206.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.207.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.230.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.235.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.236.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.237.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.240.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.241.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.242.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.243.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.248.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.252.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.253.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 161.10.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.18.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.22.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.138.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.140.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.212.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.57.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.58.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.60.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.61.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.62.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.63.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.116.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.90.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.181.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.194.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.195.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.196.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.197.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.227.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.228.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.78.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.79.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.80.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.81.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.82.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.83.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.84.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.150.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 176.67.64.0/20 AS48944 ASKHALIJFARSONLINE Khalij Ettela Resan Jonoub LTD 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 191.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.158.25.0/24 AS2717 CUMMINS-AS1 - Cummins Engine Co. Inc. 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.167.176.0/22 AS29748 CARPATHIA-HOSTING - Carpathia Hosting, Inc. 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.101.0/24 AS45645 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.63.80.0/24 AS9557 PKTELECOM-AS-PK Paknet Limited Merged into PTCL 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.147.110.0/24 AS45165 203.147.111.0/24 AS45165 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.190.32.0/22 AS24564 204.10.232.0/21 AS33150 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jeroen at mompl.net Fri Jun 10 18:43:39 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 10 Jun 2011 16:43:39 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> Message-ID: <4DF2AC2B.7070108@mompl.net> Jay Ashworth wrote: > Even Cracked realizes this: > > http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster > > That can't be good. "up to 10 percent of the country can't even get basic broadband" I think I saw much larger numbers a few years ago when I read some hype stories about how broadband access in the USA sucks. I am positively surprised the gap has narrowed that much. I wonder, what's wrong with dialup through ISDN? You get speed that is about the same as low end broadband I'd say. And I think it'd be available at these locations where DSL is not. To quote http://en.wikipedia.org/wiki/Broadband_Internet_access#ISDN "A basic rate ISDN line (known as ISDN-BRI) is an ISDN line with 2 data "bearer" channels (DS0 - 64 kbit/s each). Using ISDN terminal adapters (erroneously called modems), it is possible to bond together 2 or more separate ISDN-BRI lines to reach bandwidths of 256 kbit/s or more. The ISDN channel bonding technology has been used for video conference applications and broadband data transmission." My low end home DSL connection has similar bandwidth. With regards to the writer's main gripe, if your telecommute work typically consists of ssh sessions and email then even y'olde dialup will do just fine. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From tshaw at oitc.com Fri Jun 10 19:00:37 2011 From: tshaw at oitc.com (TR Shaw) Date: Fri, 10 Jun 2011 20:00:37 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF2AC2B.7070108@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> Message-ID: On Jun 10, 2011, at 7:43 PM, Jeroen van Aart wrote: > Jay Ashworth wrote: >> Even Cracked realizes this: >> http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster >> That can't be good. > > > > "up to 10 percent of the country can't even get basic broadband" > > I think I saw much larger numbers a few years ago when I read some hype stories about how broadband access in the USA sucks. I am positively surprised the gap has narrowed that much. > > I wonder, what's wrong with dialup through ISDN? You get speed that is about the same as low end broadband I'd say. And I think it'd be available at these locations where DSL is not. > > To quote http://en.wikipedia.org/wiki/Broadband_Internet_access#ISDN > > "A basic rate ISDN line (known as ISDN-BRI) is an ISDN line with 2 data "bearer" channels (DS0 - 64 kbit/s each). Using ISDN terminal adapters (erroneously called modems), it is possible to bond together 2 or more separate ISDN-BRI lines to reach bandwidths of 256 kbit/s or more. The ISDN channel bonding technology has been used for video conference applications and broadband data transmission." > > My low end home DSL connection has similar bandwidth. > With regards to the writer's main gripe, if your telecommute work typically consists of ssh sessions and email then even y'olde dialup will do just fine. > > Try ordering one. If I wanted one here I couldn't order one today. Years ago I had a bonded BRI serving my first server and and it took 3 months to get it working. I am not sure central offices have that capability any more. There was also a distance constraint from the CO (kinda like the distance issue from the DSLAM demark) I have a fishing cabin out in the middle of nowhere and I get broadband via a small ISP that serves via Canopy coresiding on 300 ft cell towers. This provides 1-20Mbps service even when the cell towers only provide Edge Tom From shadowedstranger at gmail.com Fri Jun 10 19:04:46 2011 From: shadowedstranger at gmail.com (Jacob Broussard) Date: Fri, 10 Jun 2011 17:04:46 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF2AC2B.7070108@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> Message-ID: I love how articles like this seem to convienently ignore the fact that the US is a BIG COUNTRY, and countries like Korea and Japan are very small countries comparitively. I haven't done any research to backup the following claim, but I suspect that the Russian Federation's internet probably isn't on the level of these much smaller, denser countries. Anecdotal evidence from friends in Russia about the quality (or lack thereof) of their connections would support this claim though. On Jun 10, 2011 4:44 PM, "Jeroen van Aart" wrote: > Jay Ashworth wrote: >> Even Cracked realizes this: >> >> http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster >> >> That can't be good. > > > > "up to 10 percent of the country can't even get basic broadband" > > I think I saw much larger numbers a few years ago when I read some hype > stories about how broadband access in the USA sucks. I am positively > surprised the gap has narrowed that much. > > I wonder, what's wrong with dialup through ISDN? You get speed that is > about the same as low end broadband I'd say. And I think it'd be > available at these locations where DSL is not. > > To quote http://en.wikipedia.org/wiki/Broadband_Internet_access#ISDN > > "A basic rate ISDN line (known as ISDN-BRI) is an ISDN line with 2 data > "bearer" channels (DS0 - 64 kbit/s each). Using ISDN terminal adapters > (erroneously called modems), it is possible to bond together 2 or more > separate ISDN-BRI lines to reach bandwidths of 256 kbit/s or more. The > ISDN channel bonding technology has been used for video conference > applications and broadband data transmission." > > My low end home DSL connection has similar bandwidth. > With regards to the writer's main gripe, if your telecommute work > typically consists of ssh sessions and email then even y'olde dialup > will do just fine. > > > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > From Valdis.Kletnieks at vt.edu Fri Jun 10 19:07:34 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Jun 2011 20:07:34 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: Your message of "Fri, 10 Jun 2011 16:43:39 PDT." <4DF2AC2B.7070108@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> Message-ID: <56804.1307750854@turing-police.cc.vt.edu> On Fri, 10 Jun 2011 16:43:39 PDT, Jeroen van Aart said: > Jay Ashworth wrote: > > Even Cracked realizes this: > > > > http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster > > > > That can't be good. > > > > "up to 10 percent of the country can't even get basic broadband" > > I think I saw much larger numbers a few years ago when I read some hype > stories about how broadband access in the USA sucks. I am positively > surprised the gap has narrowed that much. The FCC numbers say "10% can't get it", computed on a per-county basis. However, if *one* person in one corner of the county closest to a major city can get broadband, then *everybody in the county* is counted as "can get broadband" by the FCC, even if 99.8% of them are 15 or 20 cable miles away from actually getting anything usable. So the *actual* numbers are much worse than the FCC numbers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jeroen at mompl.net Fri Jun 10 19:59:38 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 10 Jun 2011 17:59:38 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <56804.1307750854@turing-police.cc.vt.edu> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <56804.1307750854@turing-police.cc.vt.edu> Message-ID: <4DF2BDFA.7060801@mompl.net> Valdis.Kletnieks at vt.edu wrote: > So the *actual* numbers are much worse than the FCC numbers. Be that as it may, when I moved to the States I had to give up DSL back in the Netherlands. But since I got flat rate dialup in return in the USA it wasn't such a big deal, for me the internet worked just fine on 56K dialup between 2002 and 2006. The reason I really wanted DSL in the first place is to get rid of those excessive phone bills. Increased speed was just an added bonus. Since most countries do not offer flat rate local phone calls I'd say that makes it a more urgent matter for them to move to broadband. Maybe flat rate local phone calls is one of the reasons broadband lags behind here. Because your bills actually increase with broadband. From a mere $10 to something like $30 and up per month. That's a considerable difference for many households. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From nmaxpierson at gmail.com Fri Jun 10 20:11:16 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Fri, 10 Jun 2011 20:11:16 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <0AB43BCD-E143-4B26-A556-88DDB6C29BCA@puck.nether.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <0AB43BCD-E143-4B26-A556-88DDB6C29BCA@puck.nether.net> Message-ID: > 2) Last mile is expensive to install and hard to justify for people. This is because of a long history of universal service and subsidization/regulation. Not only that, it makes it even worse when you hear firsthand accounts of "yea, this customer's DSL is screwed because at&t was too cheap to install proper guage wires like they did down the street in the same neighborhood!!" from an actual at&t digital technician. And yes, this was in the middle of a US city with almost 500k population. So much for "rethink possible", I guess we'll just have to live with "reach out and touch someone"...... -- m On Fri, Jun 10, 2011 at 9:17 AM, Jared Mauch wrote: > > On Jun 10, 2011, at 10:01 AM, Kyle Creyts wrote: > > > I think the point is the ubiquity of access isn't what it should be. > > I think there were several good points made in the article. > > 1) Data caps and how they impact software updates (or downloads) - > hughesnet was mentioned but .. > > Looking to the near future, Apple is selling a 4GB download for $30 in the > next month or so. That will have a large impact on networks that day IMHO. > If you have a 3G/4G/LTE/whatnot device it makes it impossible to pull down > the image without hitting your 5GB or 10GB cap compared to a fixed access > network. > > Even assuming you go to the local Panera/McDonalds/Starbucks/Library > access, if you get 2MB/s (16Mb/s) you're talking about 20-25 minutes. Those > locales don't usually have that fast of a network though. > > 2) Last mile is expensive to install and hard to justify for people. This > is because of a long history of universal service and > subsidization/regulation. > > In Michigan you could get a phone line installed for $42 (not sure, haven't > installed POTS in a long time, may have gone up) regardless of the cost to > the carrier. This isn't the case when you want to extend other utilities > (eg Gas, electric, water...). People are willing to pay 10k+ to install > these services as part of their construction expense. Their other utility > cost is masked in part due to the past 100+ years of telecom history. The > cost of lighting a 20km strand of fiber at 1Gb/s is somewhere in the $600, > including ONT, etc. Many people here on nanog would happily pay that > amount. Now, the 12-100k per mile to build the fiber is the hard part to > eat. > > 3) Certainly he did a poor job of site selection. Perhaps he was misled or > even lied to. I've faced similar challenges when working with both hardware > vendors and carriers out there. The sales peoples eyes get big once you > start talking about "doing" something, but the engineers at the table > generally start asking serious questions. (I certainly will not move > anywhere that doesn't have a HFC or PON/FTTH network. Sorry > AT&T/Centurylink/others but the plusses don't justify the minuses). > > - > > It's certainly possible that we will see improved last-mile access. The > USDA/RUS and DOC/NTIA efforts are to be applauded. If you look at the > current AT&T + T-Mobile merger people are talking about it will bring > broadband to 97% of the country, and help AT&T (mobility division) with > last-mile/local tower regulatory hurdles. They are not talking about how it > will remove the need for data caps that are 1/30th the size of their 150GB > cap on their mobile side elements. > > I suspect there's a lot that could be improved by each market player here, > but as happened with Verizon in the Northeast, I expect the less-dense > markets will need to have better local service from regional players vs the > "big guys". Overall this will be good, but the costs will also have to be > paid for more with the local subscriber. > > - Jared > From Valdis.Kletnieks at vt.edu Fri Jun 10 20:13:51 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 10 Jun 2011 21:13:51 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: Your message of "Fri, 10 Jun 2011 17:59:38 PDT." <4DF2BDFA.7060801@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <56804.1307750854@turing-police.cc.vt.edu> <4DF2BDFA.7060801@mompl.net> Message-ID: <59428.1307754831@turing-police.cc.vt.edu> On Fri, 10 Jun 2011 17:59:38 PDT, Jeroen van Aart said: > Maybe flat rate local phone calls is one of the reasons broadband lags > behind here. Because your bills actually increase with broadband. From a > mere $10 to something like $30 and up per month. That's a considerable > difference for many households. That *is* a consideration for many, but it's generally not regarded as one of the biggest issues. The lack of an enforced build-out similar to what Ma Bell had to do 50 years ago for telephone service, and related regulatory issues that result in most areas having essentially one telco and one cable operator, both of whom are free to pick-and-choose their service areas, is a bigger issue. (Biggest single issue? Probably that some companies got really big incentives a number of years ago to deploy broadband, and were allowed to pocket the money without actually deploying. Will take quite a bit to reverse *that* fiasco...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From don at bowenvale.co.nz Fri Jun 10 20:55:42 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sat, 11 Jun 2011 13:55:42 +1200 Subject: Yup; the Internet is screwed up. - Land Assistance... In-Reply-To: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> Message-ID: <4DF2CB1E.5050309@bowenvale.co.nz> Hi List, Farmer Don here... Wonder if I could get some help please? 40?46'42.77"N - 73?58'0.83"W I found a bit of land that I like the look of, with what appears to be a nice water reserve so my animals can drink and I can water the grass. Being from New Zealand (a farming community a bit below and east of Australia), I'm sorry but I don't know much about regulations to install irrigation systems in the area that I'm quite keen to set up my next farming venture. I'm wondering if anyone can give me some pointers? Being from Christchurch (site of two massive earthquakes) I know a reasonable amount about demolition now, so I'm not worried at all about the adjacent buildings as we can deal with those as we need to expand the farm. I'm attracted to this area for a number of reasons, mainly because of the abundant wireless broadband options across the entire property. I've done some factoring and the cash I can save by not having to invest in my own wireless network spanning across the country will mean I can pay for my new dairy milking shed within 3 years, (unlike the investment I've had to make on a family property in New Zealand where our property was out side of the reach of the local Telephone companies high speed DSL service and we were going to be limited to sub ADSL1 speeds!) After reading this post on NANog and following the link provided, it really struck me as a great place to ask for assistance. Some may be wondering why I don't want a more rural setting? I want to be able to enjoy a city life style every day, and I really don't feel that's unreasonable given the rant I hearing about the right to enjoy a rural life style while also having all the quality refinements that an urban city provides. Further, I don't see why I should have to invest in my community and why others shouldn't be focused and tasked with just doing it for me! I do hope that my desire to use some of your land for my smelly cows doesn't offend any of you, but I really think my right to enjoy looking at tall buildings every day has to be respected! Cheers Farmer Don On 10/06/2011 12:43 p.m., Jay Ashworth wrote: > Even Cracked realizes this: > > http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster > > That can't be good. > > Cheers, > -- jra -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From joly at punkcast.com Fri Jun 10 20:55:37 2011 From: joly at punkcast.com (Joly MacFie) Date: Fri, 10 Jun 2011 21:55:37 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <59428.1307754831@turing-police.cc.vt.edu> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <56804.1307750854@turing-police.cc.vt.edu> <4DF2BDFA.7060801@mompl.net> <59428.1307754831@turing-police.cc.vt.edu> Message-ID: > (Biggest single issue? Probably that some companies got really big > incentives a > number of years ago to deploy broadband, and were allowed to pocket the > money > without actually deploying. Will take quite a bit to reverse *that* > fiasco...) > > It sounds, Valdis, like you've been listening to Bruce Kushnick. The good news is that, after years of windward urination by Bruce, renewed scrutiny resulting from the recent T-Mobile gambit has brought more than one investigative journalist to his door. One hopes for major coverage soon. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From jeff-kell at utc.edu Fri Jun 10 20:59:26 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 10 Jun 2011 21:59:26 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF2AC2B.7070108@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> Message-ID: <4DF2CBFE.1050602@utc.edu> On 6/10/2011 7:43 PM, Jeroen van Aart wrote: > I wonder, what's wrong with dialup through ISDN? You get speed that is > about the same as low end broadband I'd say. And I think it'd be > available at these locations where DSL is not. Well, it "was" available. I had one ~15 years ago, and a Cisco 801 to boot. There was a big build-out in some areas, the small-town local Bell (not yet Borg'ed into the conglomerate) went all digital (well, "digital" at the time) on their new nnx CO. Still recall the Northern Telecom "network interface" boxes on the sides of houses. Closer to the city, it was "order and wait" as you had to be crossed over or patched to the nearest ISDN CO. They weren't "wholesale" digital. Most of that has converted over to DSL. But ISDN is still available (we have some video conferencing gear that uses bonded ISDN). Jeff From owen at delong.com Fri Jun 10 21:03:46 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jun 2011 19:03:46 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> Message-ID: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> On Jun 10, 2011, at 12:57 PM, Iljitsch van Beijnum wrote: > On 10 jun 2011, at 18:06, Leo Bicknell wrote: > >> However, many networks are much more closed deployments. Enterprises >> have not deployed IPv6 internally yet. Many will not deploy it for >> another 3-5 years, chosing instead to use web proxies at the edge >> that speak IPv4 (RFC1918) internally and IPv6 externally. They >> often can enforce the software deployed on the boxes connected. > > If they have such tight control over their network and what attaches to it, then obviously rogue RAs can be clamped down upon in a variety of ways. > Rogue RA is not the problem this seeks to solve. Yes, it helps with that problem also, but, I wouldn't be saying we need this if it was just rogue RA that people are concerned about. >> The fact that bad standards and software exist today should never be an >> argument to not design and deploy better software. So what if it takes >> until 2019, at least from 2019 to the end of IPv6 we'll have something >> better. > > If only. Having third parties point to routers is less robust than having routers announce their own presence. In the telco world, there's a separation between the control and data channels, which has important security advantages. But the IETF has always favored fate sharing. It makes routing protocols more robust and it makes RA more robust than IPv4 DHCP. > So you say, but, the real world doesn't bear out your claim. For one thing, assuming that routers on a link are intended to serve all machines on a link assumes facts not in evidence. You can call that bad network design if you want, but, there are real world requirements and scenarios where that has to happen for a variety of reasons. Those networks have working configurations in DHCPv4 and no ability to move to IPv6 until this is solved. This isn't about fate sharing vs. non-fate sharing. This is about giving administrators a rich set of tools and allowing them to pick the ones that best fit their situation. Nobody is trying to prevent you from using RA/SLAAC on your network. More power to you. I use it on some of my networks too. However, I also deal with customers who have situations that are not well served by it and they need DHCP with the ability to provide different routing configurations to different hosts on the same link. > I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems. > I see no reason that additional DHCPv6 options would have to fragment the installed base or perpetuate the lack of agreed upon DHCPv6 behavior. In fact, I think that adding these options could allow for a set of rules that would be acceptable to all and would allow administrators to make choices based on the needs of their environments. A host which receives a DHCPv6 option it doesn't understand is expected to ignore that option. Administrators who count on DHCPv6 options that are newer than the software/hardware on some of their hosts should expect those hosts to ignore the option. This is easily documented. > People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. > There were a lot of people who tried to "show up" at the IETF 10 years ago and talk about this stuff from an operational perspective. They were basically told that operators don't know what they want and they should shut up and go away and let real men do the work. Perhaps we should have stood up stronger at the time, but, frankly, we had real work to do that mattered to our users for the next 24 hours rather than a decade later. As such, we had limited bandwidth to attempt to push our goals somewhere where our "interference" was not welcome. So, if you want to blame younger selves, blame the IETF younger selves and the protocol zealots that shouted down the operator community and told us to mind or own business. > On 10 jun 2011, at 19:32, Owen DeLong wrote: > >> Some administrators want DHCP to be a complete solution and do not want to use RA at all, whether from a legitimate router or otherwise. > > It's good to want things. Doesn't mean you'll get it. > No, but, it does mean some might reject your shiny new protocol until it provides them the tools they believe they need, whether you agree with their assessment of their needs or not. Personally, I'd rather not have administrators rejecting IPv6 and it seems to me that adding routing information options to DHCPv6 is a light-weight action that is already possible within the existing protocol specification (just need to assign option numbers and attribute/value formats) and makes IPv6 a whole lot more palatable to a rather large number of administrators. > One of the three big RIRs has already run out of IPv4 space, the second will within less than a year. IPv6 deployment is still measured by counting zeroes behind the decimal point. We still don't have good CPE and broadband specs. The "happy eyeballs" stuff is still experimental but much needed. Important operating systems have serious IPv6-related bugs. > > And THIS is the time to start asking for a new feature that even when viewed most favorably, is just a nice-to-have? No more that pesky multicast packet once every 200 seconds (or when a new host attaches to the network). Yes, that's really something the IETF and vendors have to spend their cycles on. NOW. Because otherwise, you know, there's this packet. It's really bad. Every 200 seconds! > Yes... This _IS_ the time to ask for a simple additional DHCP option definition that does not require rewriting any existing standards and allows much greater operator flexibility. This _IS_ absolutely the time to solve these issues before we get widespread refusal to deploy a dysfunctional protocol that causes operators to believe that IPv4+more NAT is a superior solution because they can make their networks work well enough for their needs by doing so and IPv6 still won't work in their environment. This isn't about getting rid of the RA packet. Heck, anyone can turn of RAs on almost any host or router easily enough. What this is about is providing missing functionality that a significant number of operators consider vital to their ability to use the protocol in their environment. I know you want to make this about eliminating the RA packet and solving rogue RA because, frankly, if it were about that, the argument here would be pretty weak. However, that's not what it's about. It never was what this is about. This solution would provide some small amount of help to the rogue RA issue, but, it wouldn't solve it and there is already a known complete solution (RA Guard) which just needs to be more widely implemented. >> There are situations, for example, where the administrator does not want all hosts in a broadcast domain to receive the same set of prefixes and/or the same set of routers. This can be achieved by using different parameters based on the system identifier in the DHCP configuration. It cannot be achieved using RA. > > It can also be done using my suggested "DHCP validates RA gateway address" mechanism. > Only if you add the routing information options to DHCP which you seem to be opposing. If you add the routing information options to DHCP, then, we don't need RA any more and we can simply turn it off on the routers and be done. >> Eliminating rogue RAs is not the problem being described. That problem is solved through RA-Guard. > > Well, someone certainly intermingled the discussions, and it wasn't me. > You may not have started the intermingling, but, you certainly exacerbated it. >> The problem being described is the desire to be able to configure a host from zero to functionally on the internet using DHCP without RAs. I think everyone understands that you don't want to do so. That's fine. However, adding the functionality to DHCPv6 doesn't require you to use it. Making it available for operators that want to use it is not a bad thing. > > It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such an option. As such, my life will be worse when this is done so I'm against doing this. > How does this make your life worse? If it's not your network, why do you care? If you're worried that someone running a network you support will make a decision you don't like if we give them that option, then, I don't have a lot of sympathy for you. As to fragmentation of the installed base, I don't see how adding a couple of options to DHCPv6 creates fragmentation. It adds functionality that people can use. It's just another tool. Railing against it as you do is, frankly, about as useful as claiming that we shouldn't allow anyone to develop a non-ethernet layer 2 transport because it will fragment the installed base and turn us away from the everything converges as ethernet path that we currently seem to be on. > I just wish someone had said the same when it was decided that .ip6.int in reverse DNS zone files was ugly and needed to be changed to .ip6.arpa. Or when someone decided that it's a good idea to set the DF bit on ALL packets when doing PMTUD. > Frankly, I agree that ip6.arpa makes more sense than ip6.int. What I don't understand is why we needed a different in-addr SLD to begin with. Why couldn't it be in-addr.arpa? It's not like any valid IPv6 PTR record would conflict with any valid IPv4 PTR record. I don't mind ip6.arpa, but, whatever. Having said that, that decision frankly strikes me as being largely irrelevant to anything of operational concern. Who cares what the zone is called as long as everyone uses the same name and expects the same structures within the zone. What we're talking about here is a lack of functionality that has real operational impact. > This industry has a history of doing stuff that ends up wasting huge amounts of time and money that could easily have been avoided but apparently the voice of reason was absent that day. Not this time. > You're right. Unfortunately, I think you are mistaken who has spoken with the voice of reason in this instance. >> In some situations, this fate (it's fate, not fait, btw) > > Oh, right, I always get that wrong and I know I always get it wrong but still that doesn't help me to get it right. > lol >> sharing is not desired. > > Why not? > Because in some cases, the HOST administrator is not the NETWORK administrator and cannot necessarily control how the administrator of a given router does things. In some cases, this means that the HOST administrator wants his hosts to act in a manner that is not consistent with what the administrator of certain network devices wants to tell other hosts on the same link to do. In the real world, things are not as black and white as the configuration examples in a router manual and there are political issues that require technical functionality to work around. I'm not defending these designs or situations, and, I agree that solving them at layers 8 and 9 would be preferable. However, solving them at layer 8 and 9 is nearly impossible and has to be done differently and uniquely in each circumstance. In the meantime, working around them by adding a couple of DHCPv6 options to the existing standard is harmless and pragmatic. >> documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO. > > Nope, not a good thing. It doesn't work for normal operation because the delay while lack of RAs is observed would be unacceptable. Also, the M and O bits need to be honored. > If there's no RA, there are no M or O bits to honor. If the delay is unacceptable, the administrator can turn on RAs that send the M and O bits and don't deliver any prefixes. If there's no RA, there's nothing lost by having the host fall back to DHCP Only. Yes, the DHCP with RA functionality would still be preferable (though, frankly, I see no reason that a host couldn't send the RS and DHCP Solicitation at the same time and only use the DHCP answer received (if any) if it got back an M|O bit(s) or no RA at all). In this way, the RA delay would be only minimally disruptive and probably well within acceptability in most environments. The M|O bits would still be honored if present. > A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack acknowledgments. > Shouldn't happen. First, if some form of back-off isn't built into DHCPv6, that should be fixed. Second, if your network doesn't have any RAs and your DHCP server isn't answering, it really doesn't matter that it gets clogged up because nothing is working anyway. > And like I said before, we have more pressing things to do than tinker some more with DHCPv6. Meh... We can achieve a big win for relatively low cost very quickly and make IPv6 much more palatable to a wide audience of enterprise administrators. I can't really say that there's much more pressing than that. Yes, the issues you described above also fit into that category, so, I'd say this is about equal. Owen From joly at punkcast.com Fri Jun 10 21:11:47 2011 From: joly at punkcast.com (Joly MacFie) Date: Fri, 10 Jun 2011 22:11:47 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF2CBFE.1050602@utc.edu> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <4DF2CBFE.1050602@utc.edu> Message-ID: I had dual ISDN from nynex in the 90s. 128k woohoo! It cost me $500+/mth. j On Fri, Jun 10, 2011 at 9:59 PM, Jeff Kell wrote: > On 6/10/2011 7:43 PM, Jeroen van Aart wrote: > > I wonder, what's wrong with dialup through ISDN? You get speed that is > > about the same as low end broadband I'd say. And I think it'd be > > available at these locations where DSL is not. > > Well, it "was" available. I had one ~15 years ago, and a Cisco 801 to > boot. There was a big build-out in some areas, the small-town local > Bell (not yet Borg'ed into the conglomerate) went all digital (well, > "digital" at the time) on their new nnx CO. Still recall the Northern > Telecom "network interface" boxes on the sides of houses. > > Closer to the city, it was "order and wait" as you had to be crossed > over or patched to the nearest ISDN CO. They weren't "wholesale" digital. > > Most of that has converted over to DSL. But ISDN is still available (we > have some video conferencing gear that uses bonded ISDN). > > Jeff > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From george.herbert at gmail.com Fri Jun 10 21:21:05 2011 From: george.herbert at gmail.com (George Herbert) Date: Fri, 10 Jun 2011 19:21:05 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> Message-ID: On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong wrote: >> And like I said before, we have more pressing things to do than tinker some more with DHCPv6. > > Meh... We can achieve a big win for relatively low cost very quickly and make IPv6 much > more palatable to a wide audience of enterprise administrators. I can't really say that there's > much more pressing than that. Yes, the issues you described above also fit into that category, > so, I'd say this is about equal. Right. Please, everyone - this is not just an "IPv4 way of thinking". This is different types of networks and network users. Just because your experience and your network don't have anything affected by these issues with DHCPv6 / RA doesn't mean that others don't. IPv6 adoption is driven by exhaustion, but it's limited by glitches like this. -- -george william herbert george.herbert at gmail.com From joly at punkcast.com Fri Jun 10 21:23:32 2011 From: joly at punkcast.com (Joly MacFie) Date: Fri, 10 Jun 2011 22:23:32 -0400 Subject: Yup; the Internet is screwed up. - Land Assistance... In-Reply-To: <4DF2CB1E.5050309@bowenvale.co.nz> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2CB1E.5050309@bowenvale.co.nz> Message-ID: That would be http://maps.google.com/maps?q=40.778547+-73.966897 Fortunately American Telephone and Telegraph are on the case http://bit.ly/jTak0Q j On Fri, Jun 10, 2011 at 9:55 PM, Don Gould wrote: > Hi List, > > Farmer Don here... Wonder if I could get some help please? > > 40?46'42.77"N - 73?58'0.83"W > > I found a bit of land that I like the look of, with what appears to be a > nice water reserve so my animals can drink and I can water the grass. > > Being from New Zealand (a farming community a bit below and east of > Australia), I'm sorry but I don't know much about regulations to install > irrigation systems in the area that I'm quite keen to set up my next farming > venture. I'm wondering if anyone can give me some pointers? > > Being from Christchurch (site of two massive earthquakes) I know a > reasonable amount about demolition now, so I'm not worried at all about the > adjacent buildings as we can deal with those as we need to expand the farm. > > I'm attracted to this area for a number of reasons, mainly because of the > abundant wireless broadband options across the entire property. > > I've done some factoring and the cash I can save by not having to invest in > my own wireless network spanning across the country will mean I can pay for > my new dairy milking shed within 3 years, (unlike the investment I've had to > make on a family property in New Zealand where our property was out side of > the reach of the local Telephone companies high speed DSL service and we > were going to be limited to sub ADSL1 speeds!) > > After reading this post on NANog and following the link provided, it really > struck me as a great place to ask for assistance. > > Some may be wondering why I don't want a more rural setting? > > I want to be able to enjoy a city life style every day, and I really don't > feel that's unreasonable given the rant I hearing about the right to enjoy a > rural life style while also having all the quality refinements that an urban > city provides. > > Further, I don't see why I should have to invest in my community and why > others shouldn't be focused and tasked with just doing it for me! > > I do hope that my desire to use some of your land for my smelly cows > doesn't offend any of you, but I really think my right to enjoy looking at > tall buildings every day has to be respected! > > Cheers Farmer Don > > > > > > > On 10/06/2011 12:43 p.m., Jay Ashworth wrote: > >> Even Cracked realizes this: >> >> >> http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster >> >> That can't be good. >> >> Cheers, >> -- jra >> > > -- > Don Gould > 31 Acheson Ave > Mairehau > Christchurch, New Zealand > Ph: + 64 3 348 7235 > Mobile: + 64 21 114 0699 > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From james.cutler at consultant.com Fri Jun 10 21:43:24 2011 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 10 Jun 2011 22:43:24 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> Message-ID: On Jun 10, 2011, at 10:21 PM, George Herbert wrote: > On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong wrote: >>> And like I said before, we have more pressing things to do than tinker some more with DHCPv6. >> >> Meh... We can achieve a big win for relatively low cost very quickly and make IPv6 much >> more palatable to a wide audience of enterprise administrators. I can't really say that there's >> much more pressing than that. Yes, the issues you described above also fit into that category, >> so, I'd say this is about equal. > > Right. > > Please, everyone - this is not just an "IPv4 way of thinking". This > is different types of networks and network users. > > Just because your experience and your network don't have anything > affected by these issues with DHCPv6 / RA doesn't mean that others > don't. > > IPv6 adoption is driven by exhaustion, but it's limited by glitches like this. > > > -- > -george william herbert > george.herbert at gmail.com > This is "different types of networks and network users" and also different operational, administrative, and security domains. I am also getting frustrated with the endless discussions that could be immediately shortened by "tinkering with DHCP" to add one or two additional options -- a minimal cost process. Why is the argument not about business needs instead of technical purity? See these quotes from 2009 and let us collectively get off the dime! On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote: > ? 11:10 -0700 ?? 22.10.2009 (??), Owen DeLong ??????: >> OK... Here's the real requirement: >> >> Systems administrators who do not control routers need the ability in a dynamic host configuration mechanism to assign a number of parameters to the hosts they administer through that dynamic configuration mechanism. These parameters include, but, are not limited to: >> >> 1. Default Router >> 2. DNS Resolver information >> 3. Host can provide name to server so server can supply dynamic DNS update >> 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things like Shim6, etc.) >> 5. NTP servers >> 6. Boot server >> 7. Site specific attribute/value pairs (ala DHCPv4 Options) >> >> These assignments MUST be controlled by a server and not by the router because the router is outside of the administrative control of the Systems Administrator responsible for the hosts being configured. > > > And to add a real-world case for this - two months ago at HAR (hacking at random, a convention in the Netherlands) I was in the network team, handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6 connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and at some point we asked the question around - ok, how should we provide DNS and other useful information for the V6 only people? > > After a while with all the brains around, the decision was to write it on the datenklos through the field, where people can read it and configure it in their browsers. This would've been funny if it wasn't so sad. > > OTOH, for V4 everything with the DHCP worked fine (as it has always done, even at an event of this size), as is my experience with all the networks I've administered. Saying that DHCP doesn't work for me is extremely weird, as to me this means someone made specific effort to fuck it up. > > Finally - we have something that works, that's called DHCP. It might not be perfect, it might have some weird issues and implementations, but it's actually making our lives easier, is tested and works. I'd love anything that would be better, but as an option, not as the only choice I have. And it's not just the protocol that I care about. I care about that it's implemented in a HOST, where I can play with the software as much as possible, instead on a ROUTER, which is a vastly different device with > rarely-updated OS, and even in the case where they're both the same machine(as in small office environments), they're again handled at different layers (kernel vs userspace). There are reasons that we're using what we're using, and not all of > them are "because we're masochistic idiots". > -- > Regards, > Vasil Kolev Following on the comments above: The security domain for HOST should not overlap the security domain for ROUTER. That is the primary driver of the separate administration of HOST and ROUTER. Heaven help us if the latest M$ virus, or even social-engineering distributed malware began to affect BGP! Give the router managers the NTP server addresses and their DHCP forwarding list and leave them alone to produce a robust and reliable transport facility! James R. Cutler james.cutler at consultant.com From james.cutler at consultant.com Fri Jun 10 21:51:26 2011 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 10 Jun 2011 22:51:26 -0400 Subject: The Business Wisdom of trying to "fix" DHCPv6 References: Message-ID: > James R. Cutler james.cutler at consultant.com > Fri Feb 6 18:00:52 UTC 2009 > > DHCP items are end system considerations, not routing network > considerations. > > The network operations staff and router configuration engineers do not > generally concern themselves with end systems. > > End systems generally are managed quite independently from the routing > network. And, they are more subject to the vagaries of day to day > business variability. Note the "one place" in the quoted message below. > > The only overlap is broadcast forwarding for DHCP initiation. > > Besides, configuration control is hard enough for router engineers > without adding the burden of changing end system requirements. Adding > the forwarding entries is almost too much already! ;) > > So, for routing network operators to denigrate DHCP is probably due to > lack of consideration of the end user system requirements. And those > who denigrate DHCP and say "just hard code it" make end system > management that much more difficult. > > I still conclude that DHCP is a useful tool for both IPv4 and IPv6 > systems. ? 11:10 -0700 ?? 22.10.2009 (??), Owen DeLong ??????: > OK... Here's the real requirement: > > Systems administrators who do not control routers need the ability in a dynamic host configuration mechanism to assign a number of parameters to the hosts they administer through that dynamic configuration mechanism. These parameters include, but, are not limited to: > > 1. Default Router > 2. DNS Resolver information > 3. Host can provide name to server so server can supply dynamic DNS update > 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things like Shim6, etc.) > 5. NTP servers > 6. Boot server > 7. Site specific attribute/value pairs (ala DHCPv4 Options) > > These assignments MUST be controlled by a server and not by the router because the router is outside of the administrative control of the Systems Administrator responsible for the hosts being configured. James R. Cutler james.cutler at consultant.com From don at bowenvale.co.nz Fri Jun 10 21:56:49 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sat, 11 Jun 2011 14:56:49 +1200 Subject: Yup; the Internet is screwed up. - Land Assistance... In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2CB1E.5050309@bowenvale.co.nz> Message-ID: <4DF2D971.7030608@bowenvale.co.nz> Yes thank you very much Mr J for the links you provided. :) We have actually done our research, unlike the gent having a rant in the initial linked article, and were aware of the abundance of both low cost 2g, 3g and free wifi in the area. Again, as I explained it is one of the reasons for selecting settlement in the area. The savings of not having to pay for broadband access for the transceivers on each of our cows will more than off set the investment in the new milking shed (all cows are fitted with wifi/2/3g transceivers with bluetooth integrated headsets so we can do a broadcast to them telling them it's time to come in for milking). However, what does concern me is the lack of free wifi choice and the fact that only one provider is going to be delivering it and the terms they plan to offer such free access and the fact that we are generally opposed to using American Telephone and Telegraph because of their perceived alignment with some political or social groups. What we would like to see is a government mandate that all network providers in the area step up and form a long term working party for the establishment of short, mid and long term outcomes that will fully represent the interests of foreign rural farming investors such as my company. In keeping with the general tone of many technical internet mailing lists, I would also like to point out that you have not assisted in addressing the question, which I might remind you is around regulations for installation of irrigation and not the availability of free wifi from a company that very clearly has vested interests in locking my watering system investment out of the market so they can dominate the industry and impose different levels of water supply based on their shareholders interests. Farmer Don On 11/06/2011 2:23 p.m., Joly MacFie wrote: > That would be http://maps.google.com/maps?q=40.778547+-73.966897 > > Fortunately American Telephone and Telegraph are on the case > http://bit.ly/jTak0Q > > j From joly at punkcast.com Fri Jun 10 22:00:38 2011 From: joly at punkcast.com (Joly MacFie) Date: Fri, 10 Jun 2011 23:00:38 -0400 Subject: Yup; the Internet is screwed up. - Land Assistance... In-Reply-To: <4DF2D971.7030608@bowenvale.co.nz> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2CB1E.5050309@bowenvale.co.nz> <4DF2D971.7030608@bowenvale.co.nz> Message-ID: Yep, don't mention it One regulation you may run afoul of is the the new zero tolerance quiet zone enforcement Cowbells are definitely out, mooing dubious. http://newyork.cbslocal.com/2011/06/01/nina-in-new-york-grouchiness-prevails-in-central-park/ On Fri, Jun 10, 2011 at 10:56 PM, Don Gould wrote: > Yes thank you very much Mr J for the links you provided. :) > > We have actually done our research, unlike the gent having a rant in the > initial linked article, and were aware of the abundance of both low cost 2g, > 3g and free wifi in the area. Again, as I explained it is one of the > reasons for selecting settlement in the area. > > The savings of not having to pay for broadband access for the transceivers > on each of our cows will more than off set the investment in the new milking > shed (all cows are fitted with wifi/2/3g transceivers with bluetooth > integrated headsets so we can do a broadcast to them telling them it's time > to come in for milking). > > However, what does concern me is the lack of free wifi choice and the fact > that only one provider is going to be delivering it and the terms they plan > to offer such free access and the fact that we are generally opposed to > using American Telephone and Telegraph because of their perceived alignment > with some political or social groups. > > What we would like to see is a government mandate that all network > providers in the area step up and form a long term working party for the > establishment of short, mid and long term outcomes that will fully represent > the interests of foreign rural farming investors such as my company. > > In keeping with the general tone of many technical internet mailing lists, > I would also like to point out that you have not assisted in addressing the > question, which I might remind you is around regulations for installation of > irrigation and not the availability of free wifi from a company that very > clearly has vested interests in locking my watering system investment out of > the market so they can dominate the industry and impose different levels of > water supply based on their shareholders interests. > > Farmer Don > > > > On 11/06/2011 2:23 p.m., Joly MacFie wrote: > >> That would be http://maps.google.com/maps?q=40.778547+-73.966897 >> >> Fortunately American Telephone and Telegraph are on the case >> http://bit.ly/jTak0Q >> >> j >> > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From mpalmer at hezmatt.org Fri Jun 10 22:11:06 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 11 Jun 2011 13:11:06 +1000 Subject: Strongest Solar Tsunami in Years to Hit Earth Today In-Reply-To: References: Message-ID: <20110611031106.GO13108@hezmatt.org> On Fri, Jun 10, 2011 at 03:22:59PM +0300, Hank Nussbacher wrote: > http://www.ibtimes.com/articles/159964/20110609/nasa-solar-flare-tsunami-earth-sun-radio-satellite-interference-aurora-displays-coronal-mass-ejectio.htm Someone should tell the IB Times that "Tsunami" doesn't mean "anything big and destructive". Oh, and that popup ads are *soooo* 1997. - Matt From don at bowenvale.co.nz Fri Jun 10 22:14:32 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sat, 11 Jun 2011 15:14:32 +1200 Subject: Yup; the Internet is screwed up. - Land Assistance... In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2CB1E.5050309@bowenvale.co.nz> <4DF2D971.7030608@bowenvale.co.nz> Message-ID: <4DF2DD98.7010404@bowenvale.co.nz> Dear Mr J, Again let me thank you for engaging this issue. However again we have done our research and were well aware of the issue before making the investment choice (unlike the OP's linked article where the writer clearly hadn't researched the availability of services/resources he needed for his primary income.) I grant you that many list members may not be aware that the rural community are in fact extremely large users of technology (gps being just one small example). When we first read about the noise issues in the area we invested a large sum of capital in an R&D facility to developed electronic cow bells that have integrated GPS in them so the cow knows where it is and can simply turn the bell off. The bells are now under manufacture in China and we are looking at export opportunities in many markets including the US (part of the reason for investment in the location you were kind enough to link before). Again, in keeping with list protocols, can we please focus on the regulations for installation if irrigation piping? Kindest and warmest regards Farmer Don On 11/06/2011 3:00 p.m., Joly MacFie wrote: > > One regulation you may run afoul of is the the new zero tolerance > quiet zone enforcement > > Cowbells are definitely out, mooing dubious. > > http://newyork.cbslocal.com/2011/06/01/nina-in-new-york-grouchiness-prevails-in-central-park/ > > -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From matt at mattreath.com Fri Jun 10 22:36:40 2011 From: matt at mattreath.com (Matthew Reath) Date: Fri, 10 Jun 2011 22:36:40 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> Message-ID: > This is "different types of networks and network users" and also different > operational, administrative, and security domains. > > I am also getting frustrated with the endless discussions that could be > immediately shortened by "tinkering with DHCP" to add one or two > additional options -- a minimal cost process. Why is the argument not > about business needs instead of technical purity? > I'd have to agree with this. Although from a technical standpoint RA Guard would be a plausible solution to the rogue RA problem. However, the bigger issue seems to be the mixing of what used to be managed by different groups. Now you have IP transport folks implementing parameters sent to client machines or routers. Less than ideal probably. What are the current options for a company to disable RA messages, implement RAGuard, and force clients/routers to use DHCPv6 or static assignment for IPv6 addresses? I believe ignoring M and O bits would break standard though - but what if they never get sent? I know on Cisco you can suppress the RA, but not sure if you can force most clients to make DHCPv6 requests instead of listen for RAs. -- Matt Reath CCIE #27316 (SP) matt at mattreath.com | http://mattreath.com Twitter: http://twitter.com/mpreath From mpalmer at hezmatt.org Fri Jun 10 22:39:09 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 11 Jun 2011 13:39:09 +1000 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> References: <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <81A7C5A1-0424-4750-9F85-C3FBDE8C3771@delong.com> Message-ID: <20110611033909.GP13108@hezmatt.org> On Fri, Jun 10, 2011 at 07:53:36AM -0700, Owen DeLong wrote: > On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote: > > In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: > >> Also agree that I want flexibility to use RA or DHCPv6; the > >> disagreement is that RA needs to be removed or changed from IPv6. > >> Don't go breaking my IPv6 stack for your own ambitions, please. > > > > I want that flexability as well, but the IETF won't deliver. > > > > The two options delivered so far are: > > > > RA's only. > > Only sort of... This only works if you don't want to auto-configure things like DNS, > NTP, etc. > > I would like to see both protocols made optionally complete, so, in addition > to fixing DHCPv6 by adding routing information options, I'd also like to > see something done where it would be possible to add at least DNS > servers to RA. RFC6106... the future is nooooooow... I like it, inasmuch as I don't need to run a separate DHCPv6 server on a simple network, but that'd be equally solved by merging radvd into the DHCP server and just running that. The client-side configuration is annoying for RDNSS. - Matt From owen at delong.com Fri Jun 10 23:12:26 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Jun 2011 21:12:26 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> Message-ID: <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> On Jun 10, 2011, at 8:36 PM, Matthew Reath wrote: > >> This is "different types of networks and network users" and also different >> operational, administrative, and security domains. >> >> I am also getting frustrated with the endless discussions that could be >> immediately shortened by "tinkering with DHCP" to add one or two >> additional options -- a minimal cost process. Why is the argument not >> about business needs instead of technical purity? >> > > I'd have to agree with this. Although from a technical standpoint RA Guard > would be a plausible solution to the rogue RA problem. However, the bigger > issue seems to be the mixing of what used to be managed by different > groups. Now you have IP transport folks implementing parameters sent to > client machines or routers. Less than ideal probably. > > What are the current options for a company to disable RA messages, > implement RAGuard, and force clients/routers to use DHCPv6 or static > assignment for IPv6 addresses? I believe ignoring M and O bits would break > standard though - but what if they never get sent? > Currently, you cannot disable RA unless you want to statically configure EVERYTHING. You must have RA to at least tell you: Default Router Go ask the DHCP server (M and/or O bit) As it currently stands, an RFC-compliant host will not attempt to solicit a DHCP response unless it receives an RA with the M inclusive-or O bits set. > I know on Cisco you can suppress the RA, but not sure if you can force > most clients to make DHCPv6 requests instead of listen for RAs. > You cannot. You also cannot (as it currently stands) get DHCP to issue prefix length information (other than through PD which is different and not what most hosts will ask for) or routing information (default or a series of static routes). This is why we need the following: 1. Add options to DHCPv6 for routing configuration 2. Add the ability to have site-defined and/or vendor-speciic options to DHCPv6 if it hasn't been added yet (I'm not sure of the current state on this one). 3. Add options to DHCPv6 to specify prefix information, including prefix length. These are light-weight adds to the DHCP specification that can be very easily implemented by DHCP server producers. Hosts would also need to be modified as follows: 1. If the M bit is set or no RA was received, the host should only use the RA default gateway if there is no routing information in the DHCPv6 options. This would require updates to the DHCP client and possibly the parts of the OS that handle RA route installation. Also relatively simple modifications and probably easy to get into the OS relatively quickly once documented. In addition, it is _VERY_ desirable to modify the host autoconfiguration specification going forward to require hosts to: 1. Solicit an RA (as they do now). 2. Solicit DHCP (immediately, without waiting for an RA with the M or O bit). 3. Wait seconds for RA to come back. 4. If RA received, process it appropriately and finish the DHCP transaction if specified (M and/or O bit in RA). 5. If no RA received, complete the DHCP transaction as if an empty RA with the M bit set was received. While it will take a year or so for this to start making its way into boot-ROM firmware and such, and, another 3-5 years of technology refresh for that to become the PXE default behavior, it will actually make it into OS updates much faster and that covers the majority of dynamically addressed systems anyway. Note, in the meantime, sites that don't want to use RA can limp along with the existing process by providing DHCPv6 configuration information and essentially empty RAs with the M bit set (once host modification 1 in the previous list is implemented). Owen From ikiris at gmail.com Sat Jun 11 00:39:20 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Sat, 11 Jun 2011 00:39:20 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <4DF2CBFE.1050602@utc.edu> Message-ID: On Fri, Jun 10, 2011 at 21:11, Joly MacFie wrote: > I had dual ISDN from nynex in the 90s. 128k woohoo! It cost me $500+/mth. > > j > I still have 128k ISDN in one site in rural TN, and it's the POP for my WISP! I'd spring for a whopping 256k, but I can't justify the cost. Been running on my remaining stack of P75s for years, still have about 30 left for the lightning to kill. When it rains, it drops, and fails to a 56k modem that trains at about 19k. Just try and get the RBOC Bell (the new SBC *sigh*) to fix that. Oh and it also drops randomly, finally got me an X10 appliance module and stuck it on the router, and rigged up some nagios scripting. Nothing so reliable as an auto-rebooting router. It's the only option besides Satelite, which isn't really an option, or maybe a gold plated (price) T1 due to the distance. Squid makes it almost tolerable, until someone needs their windows updates... -Blake From cmadams at hiwaay.net Sat Jun 11 00:54:48 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 11 Jun 2011 00:54:48 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF2AC2B.7070108@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> Message-ID: <20110611055447.GB19266@hiwaay.net> Once upon a time, Jeroen van Aart said: > I wonder, what's wrong with dialup through ISDN? You get speed that is > about the same as low end broadband I'd say. And I think it'd be > available at these locations where DSL is not. For the most part, it probably isn't, especially now. Telco front-line support doesn't even know what a BRI is anymore. While POTS lines are largely flat-rate for local access in the US, many telcos put per-minute charges on ISDN BRIs (and that's per-channel-minute, so 128k runs mintes at 2x wall clock time), so the "power users" that wanted higher-than-dialup speeds didn't move to ISDN very fast (because they also wanted to be on line nearly 24x7). Also, the telcos generally made getting a BRI difficult to impossible. An early string of Dilbert cartoons covered Dilbert's attempts to get ISDN at his house, and IIRC they were based on Scott Adams' real-life attempts (and this was either when or shortly after he worked for the phone company). I live in Huntsville, AL, and we supposedly were one of the first cities in BellSouth territory (if not the US) to have ISDN available at essentially every address. After a while, it usually wasn't too painful to get a BRI turned up, as long as you didn't want any special configs (such as hunting); when I got mine, it pretty much "just worked". However, the billing was confusing at best; IIRC in the several years I had ISDN service, my bill was never exactly the same amount two consecutive months (and I never had any usage charges, so it wasn't because of that). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From joly at punkcast.com Sat Jun 11 01:46:23 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 11 Jun 2011 02:46:23 -0400 Subject: Yup; the Internet is screwed up. - Land Assistance... In-Reply-To: <4DF2DD98.7010404@bowenvale.co.nz> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2CB1E.5050309@bowenvale.co.nz> <4DF2D971.7030608@bowenvale.co.nz> <4DF2DD98.7010404@bowenvale.co.nz> Message-ID: > > > When we first read about the noise issues in the area we invested a large > sum of capital in an R&D facility to developed electronic cow bells that > have integrated GPS in them so the cow knows where it is and can simply turn > the bell off. The bells are now under manufacture in China and we are > looking at export opportunities in many markets including the US (part of > the reason for investment in the location you were kind enough to link > before). > > Well I think this would be subject to the NYC Parks Department approving multiple quiet zone database administrators via an open application process. Might take some time. > Again, in keeping with list protocols, can we please focus on the > regulations for installation if irrigation piping? > > In NYC the matter of additional conduits is mostly in the hands of Empire City Subway, happens to be an entirely owned subsidiary of Verizon, but quite open to doing business with anybody. I suggest you describe your pipes as "cables" to avoid difficulties. See http://www.empirecitysubway.com/dbwes_addcndt.html -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From don at bowenvale.co.nz Sat Jun 11 03:59:39 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sat, 11 Jun 2011 20:59:39 +1200 Subject: Yup; the Internet is screwed up. - Land Assistance... In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2CB1E.5050309@bowenvale.co.nz> <4DF2D971.7030608@bowenvale.co.nz> <4DF2DD98.7010404@bowenvale.co.nz> Message-ID: <4DF32E7B.9030401@bowenvale.co.nz> Dear Mr J, Many thanks for your attention and focus on the issues. I do hope that the author of the link in the OPs post has had his attention drawn to my series of posts. You have demonstrated in less then half a dozen posts that the article author simply isn't getting off his butt and getting focused on getting 1's and 0's to his location. Your responses clearly demonstrate by asking a few simple questions, and allowing those with a few clues to be creative, that there are any number of ways to get things done if you really want to.... perhaps this is a new concept for people in rural America, I don't know.... On 11/06/2011 6:46 p.m., Joly MacFie wrote: > > Again, in keeping with list protocols, can we please focus on the > regulations for installation if irrigation piping? > > > In NYC the matter of additional conduits is mostly in the hands of > Empire City Subway, happens to be an entirely owned subsidiary of > Verizon, but quite open to doing business with anybody. I suggest you > describe your pipes as "cables" to avoid difficulties. > > See http://www.empirecitysubway.com/dbwes_addcndt.html > Again I must thank you for the link. It is with interest that you mention Verizon. In this part of the world we are very well aware of who they are and what they do. We are aware that they have deployed FTTH to 21 million homes - an inspiration that has helped to drive ftth projects in this part of the world. I am interested to know if I can get a layer 2 service delivered to my new farming location (per my earlier posts) that will be compatible with the new Australian NBN? http://www.youtube.com/watch?v=yd5nfhZo57w&feature=player_embedded Please start viewing from 2:30 in to the clip above and you will fully understand my need for a layer 2 service that is compatible with the NBN at the desired location. We also have a very large number of sheep to bring with us to the "new world". However they are very expensive to transport using traditional services such as PAN AM or United Airlines. So our current plan is to ship them to a place called Tasmania (the only place that the NBN is currently in full swing - 40?50'31.11"S - 145? 7'32.85"E) and then use the Alcatel technology shown in the clip above to move them to our new farm - http://maps.google.com/maps?q=40.778547+-73.966897 I did note with interest some comments made by other posters of the size of the US v's HongKong or Korea. I'd like to draw those posters attention to the NBN project with a goal of 93% FTTH in a country with a land mass of what compared to the USA and a population of what? While we're comparing a few stats, .nz has just about finished it's fttn roll out which targeted 80% of homes with 10/1 DSL services but has managed to deliver 84% (60% of that will be in range of 60/30 VDSL2) and is now working on it's FTTH roll out to 75% of homes with a population of 4 million people. However I can see some validity in some of the points raised by list members.... http://maps.google.com/maps/place?ftid=0x6d318966e837fd75:0xa45e7599497ba9d9&q=31+Acheson+Avenue,+Mairehau,+Canterbury,+New+Zealand&hl=en&sll=-43.500758,172.65518&sspn=0.006295,0.006295&ie=UTF8&ll=-43.496036,172.648044&spn=0,0&z=16 At my New Zealand farm, I only have a choice of 3 fibre, 2 tp, 1 cable (HFC) and 3 mobile broadband providers (with out counting WISP's) in a city of ~360,000 people. I concur that fibre is currently expensive as the best quote I've been able to get so far is $NZD1,100 a month for a 30mbit feed, which is why our local community is working on a WISP solution to connect ~580 homes to eventually deliver better capacity in our local community (low socio-economic, high crime area). I guess the point of my posts today are: * Stop winging about crap and just get on and build your own local solutions using help from the global friendly army of guys out there willing to lend a hand - that's what I'm doing and I know it's what many on this list are also doing every day. * Stop expecting the same services in rural areas that are in cities - the idea that I can set up a farm in Central Park just so people in offices can see cows while they trade stocks is just stupid, good luck trying to park a combine in any of your parking buildings. * The rural area has any amount of cash - they just don't see need to spend it on getting connected. * .us is getting left behind the rest of the world - I follow NA Nog quite a bit, and often just close the window in amazement. In closing I'd like to add that I'm 40 years old. I was born 12 months after the USA landing the first man on the moon. I grew up in ore of Neil Armstrong and the technical achievements of the Americans. Russia were the bad guys, at 11 years of age I got my first computer, at ~20 years of age I was inspired by Bill Gates and was devoted to 'the Microsoft Way' for a decade or more as a successful Visual Basic programmer - 'go the good old USA'?... Today I work with open source solutions from around the globe, having lost favour with Microsoft a decade ago, my current toy is a Mikrotik router (something I know many of you on list are also playing with more and more) and my inspiration is a guy called Simon Hackett from an ISP in Australia (with 250,000 customers and 450 staff) and Michael Mallone from another Australian ISP who started his company in his car shed and is now the number two DSL telco in less than 25 years. I could go on... but I'm sure I'm already on enough plonk lists now ;) Farmer Don -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From jeroen at mompl.net Sat Jun 11 04:34:10 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Sat, 11 Jun 2011 02:34:10 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> Message-ID: <4DF33692.6000300@mompl.net> Ricardo Ferreira wrote: > Funny, how in the title refers to the Internet globally when the article is > specific about the USA. > > I live in europe and we have at home 100Mbps . Mid sized city of 500k > people. Some ISPs even spread WiFi across town so that subscribers can have > internet access outside their homes. Though it's nice to have why would one *need* 100 Mbps at home? I understand the necessity of internet access and agree everyone has a right to it. But that necessity can be perfectly fulfilled with a stable internet connection of a reasonable speed (say low to mid range DSL speed tops). I don't regard simultaneously streaming 6 channels of TV and downloading the latest movie torrent in 2 minutes as a basic necessity, let alone essential. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From randy at psg.com Sat Jun 11 04:39:49 2011 From: randy at psg.com (Randy Bush) Date: Sat, 11 Jun 2011 11:39:49 +0200 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33692.6000300@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> Message-ID: > Though it's nice to have why would one *need* 100 Mbps at home? some of us try to get work done from home. and anyone who has worked and/or lived in a first world country thinks american 'broadband' speeds are a joke, even for a home network. randy From jmamodio at gmail.com Sat Jun 11 04:50:18 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 11 Jun 2011 04:50:18 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> Message-ID: > some of us try to get work done from home. ?and anyone who has worked > and/or lived in a first world country thinks american 'broadband' speeds > are a joke, even for a home network. amen -J From mpalmer at hezmatt.org Sat Jun 11 05:00:24 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 11 Jun 2011 20:00:24 +1000 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33692.6000300@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> Message-ID: <20110611100024.GT13108@hezmatt.org> On Sat, Jun 11, 2011 at 02:34:10AM -0700, Jeroen van Aart wrote: > Ricardo Ferreira wrote: > >Funny, how in the title refers to the Internet globally when the article is > >specific about the USA. > > > >I live in europe and we have at home 100Mbps . Mid sized city of 500k > >people. Some ISPs even spread WiFi across town so that subscribers can have > >internet access outside their homes. > > Though it's nice to have why would one *need* 100 Mbps at home? I > understand the necessity of internet access and agree everyone has a > right to it. But that necessity can be perfectly fulfilled with a > stable internet connection of a reasonable speed (say low to mid > range DSL speed tops). > > I don't regard simultaneously streaming 6 channels of TV and > downloading the latest movie torrent in 2 minutes as a basic > necessity, let alone essential. Well, you probably live in a premises with only a couple of people. A household with the "standard" 2.3 kids might need to stream 4.3 TV channels, and it'd be nice if that didn't have an adverse impact on other traffic (an incoming SIP call or two, and useful work). - Matt From don at bowenvale.co.nz Sat Jun 11 05:05:26 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sat, 11 Jun 2011 22:05:26 +1200 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33692.6000300@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> Message-ID: <4DF33DE6.2080205@bowenvale.co.nz> On 11/06/2011 9:34 p.m., Jeroen van Aart wrote: > I don't regard simultaneously streaming 6 channels of TV and downloading > the latest movie torrent in 2 minutes as a basic necessity, let alone > essential. 100/40 isn't about 6 channels of TV and even less about torrents. It's about BIR not CIR. It's about dropping my HD video recorder, with 2 hours of random video recorded at todays 'family birthday party', on its 'hot shoe' and it just dumps 40gb to my back up server in the 10 minutes it takes me make a cup of coffee and check my blog. 10 minutes later I expect the transfer to be done, and I'll then put the camera (which was also charged in that time) back in the bag and away in the draw. Because I'm using CrashPlan, my back up server is actually some free space on my PC at work and also my mum's computer at her home (in another city) - not a cloud provider because I can't (choose not to) trust. (note I'm sending the back up to 2 sites at the same time) I don't want that transfer to saturate my link, but at the same time my wife is grabing a copy of the video her sister made of the same event and her brother is dropping a copy of his video on my computer (also as a CrashPlan[1] back up) from his house. My son has just flicked on his TV, has chosen a movie from iTunes and is downloading it flat out to his AppleTV[2] STB. The phone goes, it's my Dad just catching up... well actually he's Skypeing[3] me and wants a bit of help with a web site he's working on so orders up remote desktop (which uses ~4mbit if the capacity is there). Mean time my wife has flicked on our TV and chosen a film that we want to watch and that's also streaming in to our AppleTV STB. For about 30 minutes we'll be maxing out our 100/40, but I fully agree with any suggestion that with a bit of planning we really don't need more than 5mbits... But if you want to talk about planning... When my mother was a kid, my grandmother would get meat at the butcher each day. When I was a kid my mother would get meat out of the freezer in the morning. I grab what I need 10 minutes before I use it and put it in the microwave to defrost. Do we need this technology? The microwave gave me my first job in sales but today you just buy them at the supermarket. 100/40 will drive homes to use more of their spare hard disk space using crash plan or some other software that does the same thing. It will drive people to buy, use and back up their HD cameras. It will drive people buy STB's like AppleTV etc in numbers. Not just one in the family room. All these new gadgets will drive the need for much more home networking technology. It's why we need more 1's and 0's to move. D [1][2][3] - I don't represent any of these companies, but I have been looking at these products specifically with UFB in mind because they are popular/functional and slurp 1's and 0's like a V12 and gas. From eugen at leitl.org Sat Jun 11 05:15:18 2011 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 11 Jun 2011 12:15:18 +0200 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33692.6000300@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> Message-ID: <20110611101518.GL19622@leitl.org> On Sat, Jun 11, 2011 at 02:34:10AM -0700, Jeroen van Aart wrote: > Though it's nice to have why would one *need* 100 Mbps at home? I Residential broadband is asymmetric, so it's typically more like 6/100 MBit/s, though VDSL and FTTH are also making (slow) progress. Even with that slow upstream telecommuting suddenly becomes useful. There are virtual environments like OpenQwaq which will needly plenty of uncongested/good QoS upstream for video and audio to work. There are plenty of P2P protocols (Skype, Tor, I2P, Bitcoin, distributed searches like YaCy, etc.) which absolutely require bandwidth, especially if you run several of them at the same time. You will increasingly see anonymizing traffic picking up as geolocation and censorship increase. > understand the necessity of internet access and agree everyone has a > right to it. But that necessity can be perfectly fulfilled with a stable It definitely reduces need for moving human bodies in metal boxes back and forth, and reduces road wear and carbon dioxide emissions. > internet connection of a reasonable speed (say low to mid range DSL > speed tops). > > I don't regard simultaneously streaming 6 channels of TV and downloading Cable providers have an incentive to move to streaming video, as it saves bandwidth. > the latest movie torrent in 2 minutes as a basic necessity, let alone > essential. I can think of many constructive uses for symmetric 100 MBit/s and higher residential. Of course you won't see the demand until you offer uncrippled upstream. From jared at puck.nether.net Sat Jun 11 06:20:36 2011 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 11 Jun 2011 07:20:36 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <20110611055447.GB19266@hiwaay.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <20110611055447.GB19266@hiwaay.net> Message-ID: <94FE96B7-F74B-49EC-8892-AFFFAC8E2CFA@puck.nether.net> On Jun 11, 2011, at 1:54 AM, Chris Adams wrote: > IIRC in the several years I > had ISDN service, my bill was never exactly the same amount two > consecutive months (and I never had any usage charges, so it wasn't > because of that). I upgraded several years ago to ISDN at home to move the D<->A conversion to my house to get clear dial-tone. About every other bill the price is adjusted up or down 2-3c due to some 'change in price'. I get 2 lines plus caller-id delivery for under $55/mo. Mobile/IP telephony for long-distance instead of sending it out the BRI. I've debated canceling the service and porting the number over to the verizon home connect box as it'd lower the cost to $19 and still leave the kids with the experience of learning their phone number and the babysitter having something they can dial with. It also likely has better battery time than my UPS setup for when the power goes out. Haven't quite convinced myself to dump the ISDN yet but i'm getting there. I do figure it's a mixture of "sticking it to at&t" to keep the service active vs "is it actually worth it". I still have a modem (not sure i'd know where to dial) if I needed to dial-out to someplace in the event of a major internet meltdown to assist. Time to revise that continuity of operations plan? :) - Jared From trejrco at gmail.com Sat Jun 11 06:39:35 2011 From: trejrco at gmail.com (TJ) Date: Sat, 11 Jun 2011 07:39:35 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33692.6000300@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> Message-ID: On Sat, Jun 11, 2011 at 05:34, Jeroen van Aart wrote: > Ricardo Ferreira wrote: > >> Funny, how in the title refers to the Internet globally when the article >> is >> specific about the USA. >> >> I live in europe and we have at home 100Mbps . Mid sized city of 500k >> people. Some ISPs even spread WiFi across town so that subscribers can >> have >> internet access outside their homes. >> > > Though it's nice to have why would one *need* 100 Mbps at home? First, since when is "Why?" important/relevant? :) Second, working from home - video conferences while working with 10-30mb (mostly) Powerpoint files (that people keep insisting on emailing multiple copies of) ... and to be blunt, my time is important. If I can get that file in seconds instead of minutes that speed is important to me. Third, 4 windows laptops, 1 Ubuntu laptop, 2 phones, 1 tablet and 2 XBOXes, 1 TV - all of which get updates at certain points and are streaming/downloading various content simultaneously. And if my console (game or TV) is getting an update while I want to be playing/watching, (again) seconds instead of minutes is important :). Note that it isn't the specific speed that is important - it is relative. If a noticeable number of Internet users have access at a certain speed 1) services can be built that take advantage of that and 2) those w/o that speed are even more left out. /TJ From everettt at mitre.org Sat Jun 11 06:55:31 2011 From: everettt at mitre.org (Everett, Thomas E.) Date: Sat, 11 Jun 2011 07:55:31 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: Message-ID: <4FD125153A070D45BC87645D3B88028802B0FD5446@IMCMBX3.MITRE.ORG> L Thomas E Everett bb Enterprise Systems Engineering & Exploitation [G091] National Cyber Operations & Support everettt at mitre.org MITRE -- 703.983.1400 Cell 978.852.2400 ----- Original Message ----- From: TJ [mailto:trejrco at gmail.com] Sent: Saturday, June 11, 2011 07:39 AM To: nanog at nanog.org Subject: Re: Yup; the Internet is screwed up. On Sat, Jun 11, 2011 at 05:34, Jeroen van Aart wrote: > Ricardo Ferreira wrote: > >> Funny, how in the title refers to the Internet globally when the article >> is >> specific about the USA. >> >> I live in europe and we have at home 100Mbps . Mid sized city of 500k >> people. Some ISPs even spread WiFi across town so that subscribers can >> have >> internet access outside their homes. >> > > Though it's nice to have why would one *need* 100 Mbps at home? First, since when is "Why?" important/relevant? :) Second, working from home - video conferences while working with 10-30mb (mostly) Powerpoint files (that people keep insisting on emailing multiple copies of) ... and to be blunt, my time is important. If I can get that file in seconds instead of minutes that speed is important to me. Third, 4 windows laptops, 1 Ubuntu laptop, 2 phones, 1 tablet and 2 XBOXes, 1 TV - all of which get updates at certain points and are streaming/downloading various content simultaneously. And if my console (game or TV) is getting an update while I want to be playing/watching, (again) seconds instead of minutes is important :). Note that it isn't the specific speed that is important - it is relative. If a noticeable number of Internet users have access at a certain speed 1) services can be built that take advantage of that and 2) those w/o that speed are even more left out. /TJ From shrdlu at deaddrop.org Sat Jun 11 08:42:28 2011 From: shrdlu at deaddrop.org (Lynda) Date: Sat, 11 Jun 2011 06:42:28 -0700 Subject: Yup; the Internet is screwed up. - Land Assistance... In-Reply-To: <4DF32E7B.9030401@bowenvale.co.nz> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2CB1E.5050309@bowenvale.co.nz> <4DF2D971.7030608@bowenvale.co.nz> <4DF2DD98.7010404@bowenvale.co.nz> <4DF32E7B.9030401@bowenvale.co.nz> Message-ID: <4DF370C4.6010701@deaddrop.org> On 6/11/2011 1:59 AM, Don Gould wrote: > Your responses clearly demonstrate by asking a few simple questions, and > allowing those with a few clues to be creative, that there are any > number of ways to get things done if you really want to.... perhaps this > is a new concept for people in rural America, I don't know.... Mostly, I've just ignored this, since it wasn't really contributing to a solution for anything I could see, and wasn't finding it as amusing to read as the author did to write. This statement, however, needs a bit of changing, sir. I'd say that "people in rural America" (many of whom are my neighbors) are adept at making do, and very clever at finding solutions to the problems that the author of this piece did not. Please note that the author seems to be yet another transplanted city boy, and as such, might not have been aware of how to solve this problem quickly, and in the most expedient manner, but that does not mean you should lump rural America in one large bucket... I should also point out that the author of the article isn't even *in* a rural setting. Contrary to popular belief, living in a small town is not rural. I've lived 5 five miles out of town, and we barely considered that rural. We had neighbors less than a quarter mile walk away. In addition (since my annoyance factor seems to be set on high), I'm a bit curious as to how someone living in New Zealand is so concerned with broadband access in the US. From jgreco at ns.sol.net Sat Jun 11 08:44:12 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 11 Jun 2011 08:44:12 -0500 (CDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33692.6000300@mompl.net> Message-ID: <201106111344.p5BDiDTq046205@aurora.sol.net> > I don't regard simultaneously streaming 6 channels of TV and downloading > the latest movie torrent in 2 minutes as a basic necessity, let alone > essential. Ten years ago, most people would have been shocked at the idea of a cell phone that had a touchscreen, a 600MHz CPU, 16GB flash, and the ability to download at 1Mbps. Yet today many people find that limiting. You might not feel that it's important to be able to stream 6 channels of TV and a torrent, but some of us have been saying for some time that things are changing. The number of TV's in a household are going up. Some can now stream directly to the TV. I have numerous devices that stream Internet radio audio, something that would have seemed completely frivolous 15 years ago, but today my AV receiver comes with the capability built-in and I even have an alarm clock that'll do it, not to mention all the MP3 players, tablet computers, etc. Streaming video is more demanding, certainly, but for a large family, what you propose isn't necessarily way out there, especially if we think about ten years down the road. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From scott.brim at gmail.com Sat Jun 11 09:03:27 2011 From: scott.brim at gmail.com (Scott Brim) Date: Sat, 11 Jun 2011 10:03:27 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33692.6000300@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> Message-ID: On Sat, Jun 11, 2011 at 05:34, Jeroen van Aart wrote: > Though it's nice to have why would one *need* 100 Mbps at home? The essential point is: if people have the bandwidth, they fill it, sometimes with uses we haven't dreamed up yet. In the USA at least, creativity and productivity are _often_ bandwidth-limited (that's documented). Open the door and you get a positive feedback loop of: opportunity -> creativity -> perceived need -> services -> opportunity, leading to More Money For Everyone, including ISPs. From nmaxpierson at gmail.com Sat Jun 11 09:09:02 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Sat, 11 Jun 2011 09:09:02 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <20110611055447.GB19266@hiwaay.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <20110611055447.GB19266@hiwaay.net> Message-ID: >Also, the telcos generally made getting a BRI difficult to impossible. >An early string of Dilbert cartoons covered Dilbert's attempts to get >ISDN at his house, and IIRC they were based on Scott Adams' real-life >attempts (and this was either when or shortly after he worked for the >phone company). >I live in Huntsville, AL, and we supposedly were one of the first cities >in BellSouth territory (if not the US) to have ISDN available at >essentially every address. LOL, I actually remember that one. Dilbert and Calvin & Hobbs, great way to pass the time when I had it. I'm in former BS territory myself, and as soon as they started deploying Alcatel 1000's in most of the CO's here in the south, there was a mass exodus from B channels to ADSL. Most businesses couldn't justify a $90 circuit charge from them and on top of that, $200 per B channel dedicated from us (CLEC/ISP), when we resold ADSL for $59 a month. In some cases, we were able to order 2 or 4 wires and put the customer on our own DSLAM's if they were < 15k feet from the CO (or at least no less than -6db). However, there are still places I know of today that can't even get B channels, forget about any other digital services. I don't believe that we've ordered an ISDN 128k circuit in quite some time, but I would imagine that at&t would make it very difficult to do so as their policies now pretty much put T1's in the same category as a standard POTS line as far as turn around time on a trouble ticket. A sad state to say the least :( -- m On Sat, Jun 11, 2011 at 12:54 AM, Chris Adams wrote: > Once upon a time, Jeroen van Aart said: > > I wonder, what's wrong with dialup through ISDN? You get speed that is > > about the same as low end broadband I'd say. And I think it'd be > > available at these locations where DSL is not. > > For the most part, it probably isn't, especially now. Telco front-line > support doesn't even know what a BRI is anymore. While POTS lines are > largely flat-rate for local access in the US, many telcos put per-minute > charges on ISDN BRIs (and that's per-channel-minute, so 128k runs mintes > at 2x wall clock time), so the "power users" that wanted > higher-than-dialup speeds didn't move to ISDN very fast (because they > also wanted to be on line nearly 24x7). > > Also, the telcos generally made getting a BRI difficult to impossible. > An early string of Dilbert cartoons covered Dilbert's attempts to get > ISDN at his house, and IIRC they were based on Scott Adams' real-life > attempts (and this was either when or shortly after he worked for the > phone company). > > I live in Huntsville, AL, and we supposedly were one of the first cities > in BellSouth territory (if not the US) to have ISDN available at > essentially every address. After a while, it usually wasn't too painful > to get a BRI turned up, as long as you didn't want any special configs > (such as hunting); when I got mine, it pretty much "just worked". > However, the billing was confusing at best; IIRC in the several years I > had ISDN service, my bill was never exactly the same amount two > consecutive months (and I never had any usage charges, so it wasn't > because of that). > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From drc at virtualized.org Sat Jun 11 09:19:40 2011 From: drc at virtualized.org (David Conrad) Date: Sat, 11 Jun 2011 07:19:40 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33692.6000300@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> Message-ID: <029527DF-8E07-47BB-9509-7C0724316B5C@virtualized.org> On Jun 11, 2011, at 2:34 AM, Jeroen van Aart wrote: > Though it's nice to have why would one *need* 100 Mbps at home? "640K ought to be enough for anybody" -- Bill Gates Regards, -drc From iljitsch at muada.com Sat Jun 11 09:21:12 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 11 Jun 2011 16:21:12 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> Message-ID: <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com> On 11 jun 2011, at 4:03, Owen DeLong wrote: > You can call that bad network design if you want, but, there are real world requirements and scenarios where that has to happen for a variety of reasons. > Those networks have working configurations in DHCPv4 and no ability to move to IPv6 > until this is solved. Yeah, and they needed provider independent space to be able to move to IPv6, too. Didn't happen to a measurable degree either. There is no point in repeating all the IPv4 mistakes with IPv6, if that's what you want, stay on IPv4. Just because someone wants it doesn't make something a good idea. Especially because time and time again people take some underlying need, translate that in some technical "need" that is an extremely bad way to address that underlying need. So just giving people what they ask for invariably leads to sub-par results. Your doctor doesn't just give you the medicine you ask for either. Yes, I know this carries an implicit accusation of stupidity. I can live with that, and I'm not impressed if people are offended. (You get used to that surprisingly quickly.) >> I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems. > I see no reason that additional DHCPv6 options would have to fragment the installed > base or perpetuate the lack of agreed upon DHCPv6 behavior. Risks are in the eye of the beholder. I'm sure the financial sector didn't see any problems coming their way in 2007 either. I'm sure I sometimes see problems that never materialize. Still better safe than sorry. Especially because this is all nonsense in the margin that we can all very easily live without. What are we talking about here? One RA message every 200 seconds? Is that so bad? >> People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. > There were a lot of people who tried to "show up" at the IETF 10 years ago and talk > about this stuff from an operational perspective. They were basically told that operators > don't know what they want and they should shut up and go away and let real men > do the work. So what has changed now? Is it helpful to take that advice for 10 years and THEN revisit the issue? BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like). > Personally, I'd rather not have administrators rejecting IPv6 and it seems to me that adding routing information options > to DHCPv6 is a light-weight action that is already possible within the existing protocol specification (just need to assign > option numbers and attribute/value formats) and makes IPv6 a whole lot more palatable to a rather large number of > administrators. Assuming facts not in evidence. There is a small group of people that is never happy. Give them more, they remain unhappy. The adagium "don't feed the trolls" applies to them. >> It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such an option. As such, my life will be worse when this is done so I'm against doing this. > How does this make your life worse? If it's not your network, why do you care? Because it allows one more configuration that works for some stuff and not other stuff. I get around enough that I'll encounter such a configuration at some point. > As to fragmentation of the installed base, I don't see how adding a couple of options to DHCPv6 creates fragmentation. It adds functionality that > people can use. No, it add functionality that allows administrators to remove functionality but that only works if there are no systems that don't have the first functionality and hence can do without the second functionality. It'll take years for operating systems to catch up, and all of that just to fix something that isn't broken in the first place. (Remember, not talking about rogue RAs!) > Because in some cases, the HOST administrator is not the NETWORK administrator and cannot > necessarily control how the administrator of a given router does things. In some cases, this means > that the HOST administrator wants his hosts to act in a manner that is not consistent with what > the administrator of certain network devices wants to tell other hosts on the same link to do. Again, why NOW? We are just getting to the point where DHCPv6 can actually be used. Quit while you're ahead. And fixing protocols to make them work even in the face of explicit misconfiguration is a road that leads nowhere quickly. >> A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack acknowledgments. > Shouldn't happen. First, if some form of back-off isn't built into DHCPv6, that should be fixed. Right, first we break, then we fix. Job security all around! > Second, if your network doesn't have any RAs and your DHCP server isn't answering, it > really doesn't matter that it gets clogged up because nothing is working anyway. Oh right, IPv4 only networks aren't considered to be "working" these days. From drc at virtualized.org Sat Jun 11 09:39:14 2011 From: drc at virtualized.org (David Conrad) Date: Sat, 11 Jun 2011 07:39:14 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com> Message-ID: <6AE1C8D4-57C7-4FF4-9B0F-AD0CF6D7D96B@virtualized.org> Iljitsch, On Jun 11, 2011, at 7:21 AM, Iljitsch van Beijnum wrote: > There is no point in repeating all the IPv4 mistakes with IPv6, if that's what you want, stay on IPv4. As should be apparent by now, the vast majority of people don't want to move to IPv6. They simply want access to "the Internet". ISPs are looking for the easiest/cheapest way to do this, which generally means the way they've done it in the past. Forcing them to change simply slows things down. Regards, -drc From smb at cs.columbia.edu Sat Jun 11 09:59:20 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 11 Jun 2011 10:59:20 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33692.6000300@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> Message-ID: <5AB5CD2F-2839-4C8F-93BA-E8249E2B8C1B@cs.columbia.edu> On Jun 11, 2011, at 5:34 10AM, Jeroen van Aart wrote: > Ricardo Ferreira wrote: >> Funny, how in the title refers to the Internet globally when the article is >> specific about the USA. >> I live in europe and we have at home 100Mbps . Mid sized city of 500k >> people. Some ISPs even spread WiFi across town so that subscribers can have >> internet access outside their homes. > > Though it's nice to have why would one *need* 100 Mbps at home? I understand the necessity of internet access and agree everyone has a right to it. But that necessity can be perfectly fulfilled with a stable internet connection of a reasonable speed (say low to mid range DSL speed tops). When I was in grad school, the director of the computer center (remember those) felt that there was no need for 1200 bps modems -- 300 bps was fine, since no one could read the scrolling output any faster than that anyway. Right now, I'm running an rsync job to back up my laptop's hard drive to my office. I hope it finishes before I leave today for Denver. --Steve Bellovin, https://www.cs.columbia.edu/~smb From owen at delong.com Sat Jun 11 10:05:01 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 11 Jun 2011 08:05:01 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com> Message-ID: On Jun 11, 2011, at 7:21 AM, Iljitsch van Beijnum wrote: > On 11 jun 2011, at 4:03, Owen DeLong wrote: > >> You can call that bad network design if you want, but, there are real world requirements and scenarios where that has to happen for a variety of reasons. > >> Those networks have working configurations in DHCPv4 and no ability to move to IPv6 >> until this is solved. > > Yeah, and they needed provider independent space to be able to move to IPv6, too. Didn't happen to a measurable degree either. > IPv6 PI has actually proven to be good and did result in a measurable increase in the IPv6 adoption rate among end-sites. Unfortunately, it's still not as well known as would be ideal. I still get a lot of enterprise administrators saying to me "How can I move to IPv6, I can't get PI space." Seems a lot of administrators don't pay close enough attention to know that policies changed several years ago. > There is no point in repeating all the IPv4 mistakes with IPv6, if that's what you want, stay on IPv4. > Agreed... However, that's not what this is. > Just because someone wants it doesn't make something a good idea. Especially because time and time again people take some underlying need, translate that in some technical "need" that is an extremely bad way to address that underlying need. So just giving people what they ask for invariably leads to sub-par results. Your doctor doesn't just give you the medicine you ask for either. > True. However, since a lot of people need it, it doesn't hurt anyone who isn't using it, and is relatively easy to implement, it is a good idea. I respect it's not your chosen solution. Your chosen solution is not the solution others think is the best. In fact, many people think that your chosen solution is an extremely bad way to address that underlying need. Giving people alternatives and letting them decide what is best for their network invariably leads to results. If the network administrator doesn't like the results and has other options, then, he is free to choose different options seeking better results. Failing to give the network administrator options invariably leads to sub-par results which may only be considered optimal by someone who isn't even familiar with the particular situation in question. As to my doctor and medicine, actually, my doctor knows that I have some medical background and we do discuss drug choices openly. I don't ask for things that don't make sense and my doctor has generally either convinced me that there is a better choice through an open discussion or has prescribed the drug I chose/requested. You are not talking about a doctor/patient scenario here where the doctor is an expert and the people asking for this have no medical training. Here, we are talking about requirements coming from network engineers that are every bit as skilled as you are in the field and every bit as capable of making informed decisions about the correct solution for their environment. The difference is that they are not trying to tell you that you can't have the solution you want, they're merely trying to also have the ability to choose a different solution. Choice never leads to sub-par solutions. It invariably leads to the solution most favored by the people making the choices. > Yes, I know this carries an implicit accusation of stupidity. I can live with that, and I'm not impressed if people are offended. (You get used to that surprisingly quickly.) > Yes, I'm well familiar with your level of arrogance. I'm not impressed by that any more than you are impressed by people being offended when you call them stupid. >>> I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems. > >> I see no reason that additional DHCPv6 options would have to fragment the installed >> base or perpetuate the lack of agreed upon DHCPv6 behavior. > > Risks are in the eye of the beholder. I'm sure the financial sector didn't see any problems coming their way in 2007 either. I'm sure I sometimes see problems that never materialize. Still better safe than sorry. Especially because this is all nonsense in the margin that we can all very easily live without. What are we talking about here? One RA message every 200 seconds? Is that so bad? > You're still railing on the idea that the goal here is to eliminate the RA message. That's simply not the case. The goal here is to deal with the fact that host administration is NOT the purview of people who run routers and people who run hosts do NOT want the network guys configuring their hosts. This is about administrative boundaries and the ability for the correct group within a company to have the correct policy controls over their pieces of the puzzle. If they could make the hosts flat-out ignore the RA, they could (for the most part) care less about the RA being there or not. The goal is to eliminate the ability of those whack-jobs that run the network to dictate the fate of the host administration team. (Yes, I realize that I just implicitly called you a whack-job, but, realize that I'm part of the networking team, too, so, we're both whack-jobs in the eyes of the system administrators. You get used to that surprisingly quickly as well.) >>> People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. > >> There were a lot of people who tried to "show up" at the IETF 10 years ago and talk >> about this stuff from an operational perspective. They were basically told that operators >> don't know what they want and they should shut up and go away and let real men >> do the work. > > So what has changed now? Is it helpful to take that advice for 10 years and THEN revisit the issue? > Yes, because now the issue is more pressing and more important to more administrators. 10 years ago, it was a fight over something that might become relevant later. Today, it's a fight over something that matters today or maybe tomorrow at the latest. > BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like). > Good for you. Did you try proposing anything that was contrary to the current religion at the time or did you join the ivory tower biggots in supporting solutions that work better in theory than in operational reality and embrace their bold new failure to address major concerns (such as scalable routing) while focusing on irrelevant minutiae such as 8+8 vs. GSE? If you just went to drink the Kool-aid, I'm sure you didn't encounter that attitude. OTOH, if you told them you didn't like their Kool-aid and proposed a new flavor, your results would probably have been closer to mine. >> Personally, I'd rather not have administrators rejecting IPv6 and it seems to me that adding routing information options >> to DHCPv6 is a light-weight action that is already possible within the existing protocol specification (just need to assign >> option numbers and attribute/value formats) and makes IPv6 a whole lot more palatable to a rather large number of >> administrators. > > Assuming facts not in evidence. > Not really. I talk to a lot of enterprise administrators in my job and this is a pretty universal issue. > There is a small group of people that is never happy. Give them more, they remain unhappy. The adagium "don't feed the trolls" applies to them. > While that is true, I don't think it is an accurate portrayal of the situation in this case. For one thing, if you analyze it carefully, you see that they aren't asking for more. They are merely asking for the functionality and capabilities that they already have to be made available in what they are being told is their next protocol whether they like it or not. >>> It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such an option. As such, my life will be worse when this is done so I'm against doing this. > >> How does this make your life worse? If it's not your network, why do you care? > > Because it allows one more configuration that works for some stuff and not other stuff. I get around enough that I'll encounter such a configuration at some point. > I have no sympathy for you here. If you choose to be a consultant, then, you knew the job was dangerous when you took it. If it wasn't this, it would be something else. That's the nature of the job. If we consider the protocol to be set in stone, it will never advance and you have taken a giant step backwards from the very things that made IPv4 successful. Look at the number of serious changes that have happened to IPv4 since IPv6 was first published. >> As to fragmentation of the installed base, I don't see how adding a couple of options to DHCPv6 creates fragmentation. It adds functionality that >> people can use. > > No, it add functionality that allows administrators to remove functionality but that only works if there are no systems that don't have the first functionality and hence can do without the second functionality. It'll take years for operating systems to catch up, and all of that just to fix something that isn't broken in the first place. > Since the administrator knows his network, it's up to the administrator to make that determination. Obviously this would not be a good solution for $RANDOM_COFFEESHOP_WIFI. OTOH, for an enterprise with a relatively homogenous set of host requirements (and most enterprises do actually have this in order to reduce their administrative costs), that's not an issue. It doesn't remove functionality. It provides the same functions (and a few more) in a different manner. The fact that you don't like that particular manner is irrelevant to the discussion, nobody is asking you to use it. Remember, I'm not proposing that we just add default-route to DHCP. I'm proposing routing information. This would include functionality that would allow multiple specific static routes to be defined, for example. > (Remember, not talking about rogue RAs!) > Neither am I. We already agree that RA-Guard is the better solution to that problem. >> Because in some cases, the HOST administrator is not the NETWORK administrator and cannot >> necessarily control how the administrator of a given router does things. In some cases, this means >> that the HOST administrator wants his hosts to act in a manner that is not consistent with what >> the administrator of certain network devices wants to tell other hosts on the same link to do. > > Again, why NOW? > Because NOW IPv6 is starting to become an operational discussion that matters to administrators rather than a theoretical discussion that matters to a bunch of people in an ivory tower somewhere where they hopefully can't do too much harm to the operational network. > We are just getting to the point where DHCPv6 can actually be used. Quit while you're ahead. > The fact that this was such a battle is testament to the ivory-tower failure of the IETF and the dysfunction of allowing decisions to be made without input from the operational community who is generally too busy keeping the present working to spend a lot of time debating the (presently) irrelevant minutiae of possible futures. > And fixing protocols to make them work even in the face of explicit misconfiguration is a road that leads nowhere quickly. > Huh? That's not what anyone is discussing here. >>> A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack acknowledgments. > >> Shouldn't happen. First, if some form of back-off isn't built into DHCPv6, that should be fixed. > > Right, first we break, then we fix. Job security all around! > If DHCP doesn't back off, it's already broken. The fact that this breakage would only affect networks with the M bit set presently where it would break more universally under my proposal does not make it less broken. >> Second, if your network doesn't have any RAs and your DHCP server isn't answering, it >> really doesn't matter that it gets clogged up because nothing is working anyway. > > Oh right, IPv4 only networks aren't considered to be "working" these days. IPv4 networks don't work if the DHCP server doesn't answer unless the network is statically configured. IPv4 DHCP _DOES_ have a backoff built in to the protocol. If your IPv6 network is statically configured, then it won't have a bunch of hosts trying DHCPv6. I'm not sure I see the relevance of your statement there. Owen From petri at helenius.fi Sat Jun 11 10:20:16 2011 From: petri at helenius.fi (Petri Helenius) Date: Sat, 11 Jun 2011 18:20:16 +0300 Subject: Resilient streaming protocols In-Reply-To: <03CD777FAC464AABA1D6A216659D99DE@nbtsc.org> References: <03CD777FAC464AABA1D6A216659D99DE@nbtsc.org> Message-ID: There is a RTP FEC extension... Pete On May 29, 2011, at 12:40 AM, Aria Stewart wrote: > Anyone have any interest in a forward-error-corrected streaming protocol suitable for multicast, possibly both audio and video? > > Good for when there's some packet loss. > > ---- > Aria Stewart > > > From ikiris at gmail.com Sat Jun 11 11:08:05 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Sat, 11 Jun 2011 11:08:05 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com> Message-ID: I'm sorry, but IPv4 DHCP was a wonderful solution to many issues, which are very very difficult in IPv6. RA is a solution looking for an actual problem. That being said, I like having the option of RA, but it is only useful in a very small subset of use cases, many it actually causes issues, instead of solving them. Not all devices are client computers, and it is *MUCH* harder to build scripting to determine what config options are specific to a network for a portable device like a SIP phone, than to simply add the options into DHCP. As it stands, IPv6 is a complete non starter to about half of my customer's VLANs due to the above. The best comment I've seen goes something like this: "We don't run RIP w/ a default route on our routers now for a reason, why do you suddenly think now it's a good idea, and willfully/ignorantly ignore the past 15 years" -Blake From kloch at kl.net Sat Jun 11 11:41:17 2011 From: kloch at kl.net (Kevin Loch) Date: Sat, 11 Jun 2011 12:41:17 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610152629.GA26942@ussenterprise.ufp.org> References: <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <20110610152629.GA26942@ussenterprise.ufp.org> Message-ID: <4DF39AAD.5050304@kl.net> Leo Bicknell wrote: > In a message written on Fri, Jun 10, 2011 at 05:13:09PM +0200, Iljitsch van Beijnum wrote: >> Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues: >> >> 1. No longer the fait sharing that comes from RA-learned gateway addresses > > I proport that VRRPv6 is a superior solution to have redundant > gateways than using RA's to broadcast both and let the host choose. VRRP is definitely superior to RA's in that you can have many different redundant gateway groups for different purposes. Things like alternate default gateways, gateways to other back-end networks and VPN routers. In all but the most trivial hosting environments RA's will have to be disabled, filtered, and protected against at all cost. VRRPv3 (http://tools.ietf.org/html/rfc5798) is still a bit broken in that it makes mention of "MUST advertise RA's" and inexplicably limits VRRP addresses to link local only (?!)*. But at least we have something, it took years for the RA police at the IETF to allow even this limited solution. * In many cases it may be desirable to have VRRP addresses routed via IGP, especially static routes to VRRP next-hops. - Kevin From matt at mattreath.com Sat Jun 11 13:45:47 2011 From: matt at mattreath.com (Matthew Reath) Date: Sat, 11 Jun 2011 13:45:47 -0500 Subject: Resilient streaming protocols In-Reply-To: References: <03CD777FAC464AABA1D6A216659D99DE@nbtsc.org> Message-ID: <3e32c6ec8171c56a0889092199a96f8a.squirrel@mail.mattreath.com> > > There is a RTP FEC extension... > > Pete > > On May 29, 2011, at 12:40 AM, Aria Stewart wrote: > >> Anyone have any interest in a forward-error-corrected streaming protocol >> suitable for multicast, possibly both audio and video? >> >> Good for when there's some packet loss. >> >> ---- >> Aria Stewart >> >> I believe Cisco had/has a solution called VQE: http://www.cisco.com/en/US/prod/collateral/video/ps7191/ps7127/product_data_sheet0900aecd806c0bfb.html. It works by having a free software (LGPL or GPL) VQE client on the STB or PC device that queues and requests missing packets. -- Matt Reath CCIE #27316 (SP) matt at mattreath.com | http://mattreath.com Twitter: http://twitter.com/mpreath From if at xip.at Sat Jun 11 15:37:09 2011 From: if at xip.at (Ingo Flaschberger) Date: Sat, 11 Jun 2011 22:37:09 +0200 (CEST) Subject: Resilient streaming protocols In-Reply-To: <3e32c6ec8171c56a0889092199a96f8a.squirrel@mail.mattreath.com> References: <03CD777FAC464AABA1D6A216659D99DE@nbtsc.org> <3e32c6ec8171c56a0889092199a96f8a.squirrel@mail.mattreath.com> Message-ID: I'm also searching something cheap software or device to stream audio only (radio broadcasting, stream from external site to head-office). Kind regards, Ingo Flaschberger From frnkblk at iname.com Sat Jun 11 16:09:28 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 11 Jun 2011 16:09:28 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110610144751.GA25027@ussenterprise.ufp.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> Message-ID: <004901cc287b$d9be7d50$8d3b77f0$@iname.com> RA is fine for residential use, its enterprises and institutions that would benefit most from a route option with DHCPv6. Frank -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Friday, June 10, 2011 9:48 AM To: Ray Soucy; Iljitsch van Beijnum Cc: nanog at nanog.org Subject: Re: The stupidity of trying to "fix" DHCPv6 I really beieve this is going to be the single largest impediment to deploying _end user_ IPv6. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From jeroen at mompl.net Sat Jun 11 17:16:19 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Sat, 11 Jun 2011 15:16:19 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> Message-ID: <4DF3E933.4080809@mompl.net> Randy Bush wrote: > some of us try to get work done from home. and anyone who has worked > and/or lived in a first world country thinks american 'broadband' speeds > are a joke, even for a home network. I understand, but I was referring to the average home internet connection. But even for work 100Mbps seems a bit overkill for most purposes. Whole offices work fine with a "mere" bonded T1 at 10Mbps. Admitted it's symmetrical and is more stable. But regarding speed it's quite a bit slower than the mentioned 100Mbps home internet. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From jeroen at mompl.net Sat Jun 11 17:20:12 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Sat, 11 Jun 2011 15:20:12 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <20110611100024.GT13108@hezmatt.org> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611100024.GT13108@hezmatt.org> Message-ID: <4DF3EA1C.1060708@mompl.net> Matthew Palmer wrote: > Well, you probably live in a premises with only a couple of people. A > household with the "standard" 2.3 kids might need to stream 4.3 TV channels, Right, but now you're talking about the luxury aspect of it. And then all bets are off. The necessity would already be fulfilled with a lower speed. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From jeroen at mompl.net Sat Jun 11 17:25:41 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Sat, 11 Jun 2011 15:25:41 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33DE6.2080205@bowenvale.co.nz> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <4DF33DE6.2080205@bowenvale.co.nz> Message-ID: <4DF3EB65.7080105@mompl.net> Don Gould wrote: > 100/40 isn't about 6 channels of TV and even less about torrents. > > It's about BIR not CIR. > > It's about dropping my HD video recorder, with 2 hours of random video > recorded at todays 'family birthday party', on its 'hot shoe' and it > All these new gadgets will drive the need for much more home networking > technology. > > It's why we need more 1's and 0's to move. But this is all luxury, it's not the fulfillment of a basic need and even a right (as proclaimed by the UN). It's going above and beyond that, which is fine, but it's not *needed* in the sense of survival and being able to further yourself in life and career. Just as a toyota corolla perfectly fulfills the need to drive your toddlers around and drive to and from work. An SUV in almost all cases is added luxury. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From jeroen at mompl.net Sat Jun 11 17:37:58 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Sat, 11 Jun 2011 15:37:58 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <20110611101518.GL19622@leitl.org> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611101518.GL19622@leitl.org> Message-ID: <4DF3EE46.8040103@mompl.net> Eugen Leitl wrote: > It definitely reduces need for moving human bodies in metal boxes > back and forth, and reduces road wear and carbon dioxide emissions. I think a world of telecommuting employees is a utopia that will not be reached in my lifetime. Most companies have proven to be unwilling to make it a reality, exceptions just confirm the rule. Fiber to the premises or whatever broadband solution one may implement will not change that much. Until the human factor changes... -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From tshaw at oitc.com Sat Jun 11 17:59:15 2011 From: tshaw at oitc.com (TR Shaw) Date: Sat, 11 Jun 2011 18:59:15 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF3EE46.8040103@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611101518.GL19622@leitl.org> <4DF3EE46.8040103@mompl.net> Message-ID: <8C59B815-B659-407C-A14B-6E87F0F1083F@oitc.com> On Jun 11, 2011, at 6:37 PM, Jeroen van Aart wrote: > Eugen Leitl wrote: >> It definitely reduces need for moving human bodies in metal boxes >> back and forth, and reduces road wear and carbon dioxide emissions. > > I think a world of telecommuting employees is a utopia that will not be reached in my lifetime. Most companies have proven to be unwilling to make it a reality, exceptions just confirm the rule. Fiber to the premises or whatever broadband solution one may implement will not change that much. > > Until the human factor changes... I'm not sure where this thread is going but rural america and rural canada are rolling their own broadband connectivity in places. I just helped a friend in NW Ont (in the bush) to mesh all his neighbors (the term neighbors is a stretch due to distance) together with the wireless mesh connected all the way back to where a cabin had LOS view to a canopy POP. I know of similar grass roots wireless mesh system in the farmlands of mid america. Its very big in the Caribbean also. As there become more folks around to help and kids learn networking so that they can help deploy in their communities, I expect that this will occur more and more unless carriers fill the void which I doubt. If major carriers want eyeballs then they are missing out rolling out cheap wireless mesh systems. Their problem I guess is lack of huge return and even more lack of physical control over the mesh nodes. Tom From nanog at jima.tk Sat Jun 11 18:19:42 2011 From: nanog at jima.tk (Jima) Date: Sat, 11 Jun 2011 18:19:42 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> Message-ID: <4DF3F80E.9040803@jima.tk> On 2011-06-10 21:03, Owen DeLong wrote: > On Jun 10, 2011, at 12:57 PM, Iljitsch van Beijnum wrote: >> I just wish someone had said the same when it was decided that .ip6.int in reverse DNS zone files was ugly and needed to be changed to .ip6.arpa. Or when someone decided that it's a good idea to set the DF bit on ALL packets when doing PMTUD. >> > > Frankly, I agree that ip6.arpa makes more sense than ip6.int. What I don't understand is why we needed a different in-addr SLD to begin with. > Why couldn't it be in-addr.arpa? It's not like any valid IPv6 PTR record would conflict with any valid IPv4 PTR record. I don't mind ip6.arpa, > but, whatever. The PTRs would never conflict, but the v4 NS records would pre-empt delegation of certain v6 prefixes. Case in point: if authority for 2.0.0.0/24 were delegated (which it is), any requests for authoritative information for 2001::/16 would have to go through their servers. Compare: 0.0.2.in-addr.arpa. 1.0.0.2.in-addr.arpa. Oops. And yes, I tested this little theory -- it actually applies to large chunks of 2000::/4. Jima From cjp at 0x1.net Sat Jun 11 18:29:43 2011 From: cjp at 0x1.net (Christopher Pilkington) Date: Sat, 11 Jun 2011 19:29:43 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <8C59B815-B659-407C-A14B-6E87F0F1083F@oitc.com> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611101518.GL19622@leitl.org> <4DF3EE46.8040103@mompl.net> <8C59B815-B659-407C-A14B-6E87F0F1083F@oitc.com> Message-ID: <6047076084616721761@unknownmsgid> On Jun 11, 2011, at 19:00, TR Shaw wrote: > I'm not sure where this thread is going but rural america and rural canada are rolling their own broadband connectivity in places. This is my eventual goal where I'm moving. (Oswego Co., NY). I'm well aware that I'm moving outside of "broadband-land", and while I'm not happy about this, the pros of moving there outweighed this con. Options seem to be limited to HughesNet and dial for the moment, but things may change if I put a tower on the property. HughesNet seems to relax it's bandwidth cap between 2am and 7am, which is helpful, but still a great shift from what I'm used to at the current residence (15/2). It would be great to get neighbors in on some sort of community solution, but it will take some time to feel out where they are on this. From jgreco at ns.sol.net Sat Jun 11 18:40:46 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 11 Jun 2011 18:40:46 -0500 (CDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF3EB65.7080105@mompl.net> Message-ID: <201106112340.p5BNeku0051520@aurora.sol.net> > But this is all luxury, it's not the fulfillment of a basic need and > even a right (as proclaimed by the UN). It's going above and beyond > that, which is fine, but it's not *needed* in the sense of survival and > being able to further yourself in life and career. A smartphone may be a luxury. I strongly suspect, for example, that for the 14-year-old kid wandering around with an iPhone that the use is one of luxury; I, on the other hand, finally felt forced into one because I had a compelling (even if only occasional) business need to do things like ssh without lugging a laptop and wireless card with me at all times. Is that an accurate way to look at it? Maybe. However, if I were a parent, maybe I would have an additional perspective: perhaps I like the idea that I can run "Find my iPhone" and be likely to be able to track my kid, because I know damn well that the social status bump of having the phone means it's going to be with him/her. Or maybe one day my kid is snatched. The ability to call 911, the ability to track, the ability to record, the ability to take pictures, even the ability to use the camera as a flashlight, etc., who knows what might be useful. So while the phone might be a luxury on one hand, there's also a real big potential for it to be a serious tool, even a lifesaving one, in a crisis. What about http://arstechnica.com/tech-policy/news/2011/06/if-you-pull-out-your.ars for example? With police frequently snatching and confiscating, or even smashing, recording devices, might we consider a high speed communications channel as an essential way to record evidence away from the scene of an event in realtime? It doesn't have to be a cellphone. How about a home security system's external cameras? We continue to evolve new uses and technologies that make the capabilities that we have more useful. Luxuries? Sure, many are nice to have as well, but just because something might frequently be used for unnecessary purposes does not reduce the importance of other uses. > Just as a toyota corolla perfectly fulfills the need to drive your > toddlers around and drive to and from work. An SUV in almost all cases > is added luxury. My SUV carries seven passengers and allows me to haul gear including conduit, lumber, ladders, etc. It's actively dangerous to do some of these things in a sedan. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jlewis at lewis.org Sat Jun 11 19:53:06 2011 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 11 Jun 2011 20:53:06 -0400 (EDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF2AC2B.7070108@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> Message-ID: On Fri, 10 Jun 2011, Jeroen van Aart wrote: > I wonder, what's wrong with dialup through ISDN? You get speed that is about > the same as low end broadband I'd say. And I think it'd be available at these > locations where DSL is not. No you don't. BRI with 2 B channels bonded is 128kbit/s. Does anyone offer DSL that slow? I just had 25mbit DSL installed...though 15 of it is reserved for IPTV service. Have you heard the joke...ISDN = I Still Don't kNow? For whatever reason, BRI service is something the US telcos apparently never really wanted to sell...perhaps because it might have cut into their T1 business. Initially, with BellSouth you could get flat-rate BRI. It didn't take long for them to limit it to 200 hours/month and then charge per minute for overages. At 128kbit/s going flat out all day, you can transfer just a bit more than 1GB. Also, just the ISDN line from the telco will probably cost a couple times what DSL from the telco would cost if you could get it...and if you're in a rural area where you can't get cable or DSL, I wouldn't hold your breath for ISDN. > My low end home DSL connection has similar bandwidth. How slow a DSL connection do you have? > With regards to the writer's main gripe, if your telecommute work typically > consists of ssh sessions and email then even y'olde dialup will do just fine. For SSH sessions, ISDN is fine and the latency is much lower than analog dialup. At home, I went from analog dialup at 14.4kbps, to 28.8/33.6kbps, to 128k ISDN (a flat rate line), to 1.5mbit DSL, to [I don't even remember the speed] several mbit cable, to now 10mbit DSL. I made sure before moving 3 years ago to where I am now that there was at least one broadband internet provider servicing the area. 3 years later, there are now two choices. If your work/life depends on internet access (particularly high speed) and you move somewhere without checking on its availability, you're not too bright. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jra at baylink.com Sat Jun 11 20:04:13 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 11 Jun 2011 21:04:13 -0400 (EDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <218A1779A7A0984894CBD218EFF84AC45D964E@CEXMB003.nmes.lcl> Message-ID: <20254587.114.1307840653760.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Murphy, DOH" > The umbra of it all. We have jobs though. Not all of us. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Sat Jun 11 20:05:57 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 11 Jun 2011 21:05:57 -0400 (EDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <0AB43BCD-E143-4B26-A556-88DDB6C29BCA@puck.nether.net> Message-ID: <19040352.116.1307840756999.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Mauch" > On Jun 10, 2011, at 10:01 AM, Kyle Creyts wrote: > > I think the point is the ubiquity of access isn't what it should be. > > I think there were several good points made in the article. > > 1) Data caps and how they impact software updates (or downloads) - > hughesnet was mentioned but .. > > Looking to the near future, Apple is selling a 4GB download for $30 in > the next month or so. That will have a large impact on networks that > day IMHO. If you have a 3G/4G/LTE/whatnot device it makes it > impossible to pull down the image without hitting your 5GB or 10GB cap > compared to a fixed access network. > > Even assuming you go to the local Panera/McDonalds/Starbucks/Library > access, if you get 2MB/s (16Mb/s) you're talking about 20-25 minutes. > Those locales don't usually have that fast of a network though. Much more to the point: the (vendors hope for the) coming preponderance of services like iCloud mean that you'll be able to *pay someone* to force you to use up your capped service, downloading music *you already paid for in the first place*. People Are Stupid. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Sat Jun 11 20:06:56 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 11 Jun 2011 21:06:56 -0400 (EDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> Message-ID: <27674475.118.1307840816280.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Mauch" > The current set of iphone/ipad firmware updates are about 700mb per > device. Not counting the latest combo updater (or incremental) for > MacOS. (Hopefully with the 5.0 software announced they will do OTA > updates on a different APN that doesn't count against ones data > limits). "Delta RPMs". Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From r.engehausen at gmail.com Sat Jun 11 20:07:42 2011 From: r.engehausen at gmail.com (Roy) Date: Sat, 11 Jun 2011 18:07:42 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <6047076084616721761@unknownmsgid> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611101518.GL19622@leitl.org> <4DF3EE46.8040103@mompl.net> <8C59B815-B659-407C-A14B-6E87F0F1083F@oitc.com> <6047076084616721761@unknownmsgid> Message-ID: <4DF4115E.4030000@gmail.com> On 6/11/2011 4:29 PM, Christopher Pilkington wrote: > On Jun 11, 2011, at 19:00, TR Shaw wrote: > >> I'm not sure where this thread is going but rural america and rural canada are rolling their own broadband connectivity in places. > This is my eventual goal where I'm moving. (Oswego Co., NY). > > I'm well aware that I'm moving outside of "broadband-land", and while > I'm not happy about this, the pros of moving there outweighed this > con. > > Options seem to be limited to HughesNet and dial for the moment, but > things may change if I put a tower on the property. HughesNet seems to > relax it's bandwidth cap between 2am and 7am, which is helpful, but > still a great shift from what I'm used to at the current residence > (15/2). > No 3G cellphone service? > It would be great to get neighbors in on some sort of community > solution, but it will take some time to feel out where they are on > this. > > From jra at baylink.com Sat Jun 11 20:13:41 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 11 Jun 2011 21:13:41 -0400 (EDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <59428.1307754831@turing-police.cc.vt.edu> Message-ID: <3593183.120.1307841221128.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > (Biggest single issue? Probably that some companies got really big incentives a > number of years ago to deploy broadband, and were allowed to pocket the money > without actually deploying. Will take quite a bit to reverse *that* > fiasco...) Also remember there are a lot of moves afoot to *make it illegal* for cities and other municipalities to deploy last-mile fiber, as we discussed a couple weeks ago. Who's responsible for most of that? Verizon. Can you spell FiOS? My assertion's been that they need it to save them from 30 years of "cut to clear", but someone with some insider knowledge told me once that it at least isn't that *everywhere*... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Sat Jun 11 20:20:50 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 11 Jun 2011 21:20:50 -0400 (EDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF33692.6000300@mompl.net> Message-ID: <1725907.124.1307841650347.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeroen van Aart" > Though it's nice to have why would one *need* 100 Mbps at home? (I can't imagine that no one's gone here yet...) Jeroen: does your computer have more than 640KB of RAM? Cheers, -- jr 'or your cellphone? Watch?' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From fabio.mendes at bsd.com.br Sat Jun 11 20:30:26 2011 From: fabio.mendes at bsd.com.br (Fabio Mendes) Date: Sat, 11 Jun 2011 22:30:26 -0300 Subject: IPv6 and DNS Message-ID: Hi guys, Firstly, sorry if this may sound too newbie for the list. Reading the discussion about dhcpv6 vs RAs, this question just popped in my mind. It seems that most of IPv6 addressing for hosts will be choosed using EUI-64 method. Considering that no one (specially endusers) will bother to memorize an IPv6 prefix plus a mac address, integration between DNS servers and routers/dhcpv6 servers will be crucial. For dhcp there is already a mechanism for updating names in the DNS server for dynamically assigned IPs. I suppose it will be used (use some modifications) for IPv6. However, I never heard of anything similar for routers (in the case of autoconfigured addresses). Are there any dns servers that support updates from routers ? From owen at delong.com Sat Jun 11 20:02:41 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 11 Jun 2011 18:02:41 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF3E933.4080809@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <4DF3E933.4080809@mompl.net> Message-ID: Sent from my iPad On Jun 11, 2011, at 15:16, Jeroen van Aart wrote: > Randy Bush wrote: >> some of us try to get work done from home. and anyone who has worked >> and/or lived in a first world country thinks american 'broadband' speeds >> are a joke, even for a home network. > > I understand, but I was referring to the average home internet connection. But even for work 100Mbps seems a bit overkill for most purposes. Whole offices work fine with a "mere" bonded T1 at 10Mbps. Admitted it's symmetrical and is more stable. But regarding speed it's quite a bit slower than the mentioned 100Mbps home internet. > Depends on the office and the user profile at home. I would be very unhappy and so would my coworkers behind a bonded T1 at 10 Mbps. However, I do admit I think my 70 Mbps at home will probably be adequate for a few years to come. Owen From rcarpen at network1.net Sat Jun 11 20:50:22 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Sat, 11 Jun 2011 21:50:22 -0400 (EDT) Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <50aec808-d26c-42b1-abd9-c45111ae4a2e@zimbra.network1.net> Message-ID: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines. The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections. With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished? In a nutshell: how do you have 2 upstream connections, and choose between them based on outbound destination? thanks, -Randy From joly at punkcast.com Sat Jun 11 21:00:30 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 11 Jun 2011 22:00:30 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <3593183.120.1307841221128.JavaMail.root@benjamin.baylink.com> References: <59428.1307754831@turing-police.cc.vt.edu> <3593183.120.1307841221128.JavaMail.root@benjamin.baylink.com> Message-ID: > > > Also remember there are a lot of moves afoot to *make it illegal* for > cities > and other municipalities to deploy last-mile fiber, as we discussed a > couple > weeks ago. Who's responsible for most of that? > > Verizon. > > Can you spell FiOS? > > My assertion's been that they need it to save them from 30 years of "cut to > clear", but someone with some insider knowledge told me once that it at > least isn't that *everywhere*... > > Cheers, > -- jra > > Well, Time Warner too, F'r instance North Carolina. See analysis http://www.muninetworks.org/content/digging-h129-another-bill-nc-limit-local-authority-and-broadband-competition Not exactly illegal but so many hoops that nobody will jump I suppose the TW argument is that they need a monopoly to justify investment Here in NYC, in exchange for a franchise, Verizon had to promise universal coverage by mid 2014 http://newscenter.verizon.com/press-releases/verizon/2008/verizon-files-application-and.html and there was no exclusive deal. j -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From mpalmer at hezmatt.org Sat Jun 11 21:04:08 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sun, 12 Jun 2011 12:04:08 +1000 Subject: IPv6 and DNS In-Reply-To: References: Message-ID: <20110612020408.GX13108@hezmatt.org> On Sat, Jun 11, 2011 at 10:30:26PM -0300, Fabio Mendes wrote: > Firstly, sorry if this may sound too newbie for the list. Reading the > discussion about dhcpv6 vs RAs, this question just popped in my mind. > > It seems that most of IPv6 addressing for hosts will be choosed using EUI-64 > method. Considering that no one (specially endusers) will bother to memorize > an IPv6 prefix plus a mac address, integration between DNS servers and > routers/dhcpv6 servers will be crucial. > > For dhcp there is already a mechanism for updating names in the DNS server > for dynamically assigned IPs. I suppose it will be used (use some > modifications) for IPv6. > > However, I never heard of anything similar for routers (in the case of > autoconfigured addresses). > > Are there any dns servers that support updates from routers ? The router isn't assigning an address, it's merely telling everyone on the segment what the local prefix and default route is. As such, there's no reason why the router should try to register a DNS entry. On the other hand, the host could (and should) register it's address with whatever DNS server handles it's name. The protocol for such is already standardised and should be independent of IPv4/IPv6. - Matt From if at xip.at Sat Jun 11 21:15:23 2011 From: if at xip.at (Ingo Flaschberger) Date: Sun, 12 Jun 2011 04:15:23 +0200 (CEST) Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> Message-ID: > I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines. > > The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections. > > With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished? > > In a nutshell: how do you have 2 upstream connections, and choose between them based on outbound destination? *LAUGH* really interesting and funny. my only idea is to have a 2nd ip and 2nd gateway at all "users" workstations with explicit routes. (scales very very well, perhaps run some routing protocol? ospf? :) bye, Ingo Flaschberger From if at xip.at Sat Jun 11 21:18:38 2011 From: if at xip.at (Ingo Flaschberger) Date: Sun, 12 Jun 2011 04:18:38 +0200 (CEST) Subject: IPv6 and DNS In-Reply-To: <20110612020408.GX13108@hezmatt.org> References: <20110612020408.GX13108@hezmatt.org> Message-ID: > The router isn't assigning an address, it's merely telling everyone on the > segment what the local prefix and default route is. As such, there's no > reason why the router should try to register a DNS entry. 1) configure the router without knowing the address? Kind regards, Ingo Flaschberger From rcarpen at network1.net Sat Jun 11 21:41:35 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Sat, 11 Jun 2011 22:41:35 -0400 (EDT) Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: Message-ID: > *LAUGH* > > really interesting and funny. > > my only idea is to have a 2nd ip and 2nd gateway at all "users" > workstations with explicit routes. (scales very very well, perhaps > run some routing > protocol? ospf? :) I've thought of that, but that is a management nightmare, particularly on windows machines... I would rather just get rid of the cable modem, and expand their main connections, but the cost is more than an order of magnitude more expensive. thanks for the reply :-) -Randy From scott at doc.net.au Sat Jun 11 21:52:55 2011 From: scott at doc.net.au (Scott Howard) Date: Sat, 11 Jun 2011 19:52:55 -0700 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> References: <50aec808-d26c-42b1-abd9-c45111ae4a2e@zimbra.network1.net> <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> Message-ID: On Sat, Jun 11, 2011 at 6:50 PM, Randy Carpenter wrote: > With IPv6, we are having some trouble coming up with a way to do this. > Since there is no NAT, does anyone have any ideas as to how this could be > accomplished? > Juniper, *BSD (including pfsense) and Linux all do NAT66 in some form or other, as potentially do others. Scott From matt at mattreath.com Sat Jun 11 22:21:32 2011 From: matt at mattreath.com (Matthew Reath) Date: Sat, 11 Jun 2011 22:21:32 -0500 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> Message-ID: <0c666a923e1de05c17d3ed4296830ed3.squirrel@mail.mattreath.com> > > I have an interesting situation at a business that I am working on. We > currently have the office set up with redundant connections for their > mission critical servers and such, and also have a (cheap) cable modem for > general browsing on client machines. > > The interesting part is that the client machines need to access some > customer networks via the main redundant network, so we have a firewall > set up to route those connections via the redundant connections, and > everything else via the cheaper, faster cable modem. NAT is used on both > outbound connections. > > With IPv6, we are having some trouble coming up with a way to do this. > Since there is no NAT, does anyone have any ideas as to how this could be > accomplished? > > In a nutshell: how do you have 2 upstream connections, and choose between > them based on outbound destination? > > thanks, > -Randy > > Standard IP routing, the default gateway of the network can decide based on a route entry whether to send it to the cable modem or send it to the firewall. -- Matt Reath CCIE #27316 (SP) matt at mattreath.com | http://mattreath.com Twitter: http://twitter.com/mpreath From rob at ipninja.net Sat Jun 11 22:48:20 2011 From: rob at ipninja.net (Rob V) Date: Sat, 11 Jun 2011 23:48:20 -0400 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <0c666a923e1de05c17d3ed4296830ed3.squirrel@mail.mattreath.com> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <0c666a923e1de05c17d3ed4296830ed3.squirrel@mail.mattreath.com> Message-ID: <006d01cc28b3$957128e0$c0537aa0$@net> > -----Original Message----- > From: Matthew Reath [mailto:matt at mattreath.com] > Sent: June-11-11 11:22 PM > To: Randy Carpenter > Cc: nanog at nanog.org > Subject: Re: Question about migrating to IPv6 with multiple upstreams. > > Standard IP routing, the default gateway of the network can decide based > on a route entry whether to send it to the cable modem or send it to the > firewall. If the source block is not routed via both connections it won't work without NAT. I had this same problem trying to use my ISP's native v6 over PPPoE and maintain a tunnel as backup since it was still pretty flaky as they were testing it at the time ... no way a residential ISP is going to route 3rd party blocks for all their customers, and no chance the tunnel provider was going to route the block my ISP assigned me either ... with no NAT66 in Tomato/ddWRT/etc it was 100% impossible to have multiple connections ... From matt at mattreath.com Sat Jun 11 23:00:45 2011 From: matt at mattreath.com (Matthew Reath) Date: Sat, 11 Jun 2011 23:00:45 -0500 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <006d01cc28b3$957128e0$c0537aa0$@net> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <0c666a923e1de05c17d3ed4296830ed3.squirrel@mail.mattreath.com> <006d01cc28b3$957128e0$c0537aa0$@net> Message-ID: <879a8217088bea5ff31df7f39902557a.squirrel@mail.mattreath.com> >> -----Original Message----- >> From: Matthew Reath [mailto:matt at mattreath.com] >> Sent: June-11-11 11:22 PM >> To: Randy Carpenter >> Cc: nanog at nanog.org >> Subject: Re: Question about migrating to IPv6 with multiple upstreams. >> >> Standard IP routing, the default gateway of the network can decide based >> on a route entry whether to send it to the cable modem or send it to the >> firewall. > > If the source block is not routed via both connections it won't work > without > NAT. I had this same problem trying to use my ISP's native v6 over PPPoE > and maintain a tunnel as backup since it was still pretty flaky as they > were > testing it at the time ... no way a residential ISP is going to route 3rd > party blocks for all their customers, and no chance the tunnel provider > was > going to route the block my ISP assigned me either ... with no NAT66 in > Tomato/ddWRT/etc it was 100% impossible to have multiple connections ... > > I guess I'm a little confused on the setup. You have a firewall with a connection to a local LAN, another connection to customer network(s), and a third connection to the Internet via cable modem? You have NAT setup to NAT your Local LAN out to the Internet and to the customer network? A customer network device would use the outside IP on the customer network connection to communicate with devices in the Local LAN? I think it makes more sense to me now. -- Matt Reath CCIE #27316 (SP) matt at mattreath.com | http://mattreath.com Twitter: http://twitter.com/mpreath From matt at mattreath.com Sat Jun 11 23:08:42 2011 From: matt at mattreath.com (Matthew Reath) Date: Sat, 11 Jun 2011 23:08:42 -0500 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <006d01cc28b3$957128e0$c0537aa0$@net> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <0c666a923e1de05c17d3ed4296830ed3.squirrel@mail.mattreath.com> <006d01cc28b3$957128e0$c0537aa0$@net> Message-ID: >> -----Original Message----- >> From: Matthew Reath [mailto:matt at mattreath.com] >> Sent: June-11-11 11:22 PM >> To: Randy Carpenter >> Cc: nanog at nanog.org >> Subject: Re: Question about migrating to IPv6 with multiple upstreams. >> >> Standard IP routing, the default gateway of the network can decide based >> on a route entry whether to send it to the cable modem or send it to the >> firewall. > > If the source block is not routed via both connections it won't work > without > NAT. I had this same problem trying to use my ISP's native v6 over PPPoE > and maintain a tunnel as backup since it was still pretty flaky as they > were > testing it at the time ... no way a residential ISP is going to route 3rd > party blocks for all their customers, and no chance the tunnel provider > was > going to route the block my ISP assigned me either ... with no NAT66 in > Tomato/ddWRT/etc it was 100% impossible to have multiple connections ... > > Are you able to create ip6ip tunnels from your firewall/router to each customer? -- Matt Reath CCIE #27316 (SP) matt at mattreath.com | http://mattreath.com Twitter: http://twitter.com/mpreath From rcarpen at network1.net Sat Jun 11 23:31:09 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Sun, 12 Jun 2011 00:31:09 -0400 (EDT) Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <879a8217088bea5ff31df7f39902557a.squirrel@mail.mattreath.com> Message-ID: <271765a8-20be-4ce8-b833-c28da0527be7@zimbra.network1.net> > I guess I'm a little confused on the setup. You have a firewall with > a > connection to a local LAN, another connection to customer network(s), > and > a third connection to the Internet via cable modem? > > You have NAT setup to NAT your Local LAN out to the Internet and to > the > customer network? A customer network device would use the outside IP > on > the customer network connection to communicate with devices in the > Local > LAN? > > I think it makes more sense to me now. Provider1 Provider2 | | | | cable modem router (PI space, BGP) | | | |--- Servers | | -------Firewall----- | Clients The clients are on rfc1918 space, or on a small chunk of a block of PI space. For normal web traffic, they get NATed as the outside cable modem IP address on the firewall. For traffic that is to specific places (customer sites), it is routed to the router. For the rfc1918 clients, they are NATed as the PI IP address on the firewall. For the clients that have fully routable PI addresses, they are simply routed normally. Has worked quite well for a long time. -Randy From joe at nethead.com Sat Jun 11 23:33:12 2011 From: joe at nethead.com (Joe Hamelin) Date: Sat, 11 Jun 2011 21:33:12 -0700 Subject: RIP Joe Wood Message-ID: Joe Wood passed in his sleep Friday morning. The only man I knew that had Juniper and Cisco logos tattooed on his forearms. A true Internet Rockstar who started at a legacy ISP in Seattle, moved to Flying Crocodile, and then to design a fair chunk of Google's network. He was well on his way to starting his own CLEC when his young body gave out on him. He was one of the most honest and loving friends that I've had in my life and the most brilliant IP engineer I have known. Please drink a toast to him with vendor supplied beer. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From rgolodner at infratection.com Sat Jun 11 23:54:16 2011 From: rgolodner at infratection.com (Richard Golodner) Date: Sat, 11 Jun 2011 23:54:16 -0500 Subject: 6-15-2011 Message-ID: <1307854456.2000.18.camel@Andromeda> Wishing all the attendees a good time and a great start in Denver. NewNog is now NANOG and thank you to the community which has been a great source of information and education. Way to go Betty,Patrick and everyone else I have never met, but take the ball and run with it. Thanks for all of your hard work. Sincerely, Richard Golodner From swhyte at gmail.com Sat Jun 11 23:57:58 2011 From: swhyte at gmail.com (Scott Whyte) Date: Sat, 11 Jun 2011 21:57:58 -0700 Subject: RIP Joe Wood In-Reply-To: References: Message-ID: On Sat, Jun 11, 2011 at 21:33, Joe Hamelin wrote: > Joe Wood passed in his sleep Friday morning. ?The only man I knew that had > Juniper and Cisco logos tattooed on his forearms. ?A true Internet Rockstar > who started at a legacy ISP in Seattle, moved to Flying Crocodile, and then > to design a fair chunk of Google's network. He not only designed at Google: implemented, supported, and upgraded as well, everything from optical systems to MPLS TE to routing protocols. He was a famous night owl, and a huge help all those wee AMs when I was oncall and needed more hands, because he was always willing to pitch in. > He was well on his way to > starting his own CLEC when his young body gave out on him. He was one of the > most honest and loving friends that I've had in my life and the most > brilliant IP engineer I have known. > > Please drink a toast to him with vendor supplied beer. I intend to have more than one toast to Joe, tomorrow in Denver. He will be missed. -Scott From frnkblk at iname.com Sun Jun 12 00:13:46 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 12 Jun 2011 00:13:46 -0500 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> References: <50aec808-d26c-42b1-abd9-c45111ae4a2e@zimbra.network1.net> <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> Message-ID: <000801cc28bf$81d05340$8570f9c0$@iname.com> For a fuller discussion of this scenario, you can read this draft: http://wiki.tools.ietf.org/id/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00.txt Frank -----Original Message----- From: Randy Carpenter [mailto:rcarpen at network1.net] Sent: Saturday, June 11, 2011 8:50 PM To: nanog at nanog.org Subject: Question about migrating to IPv6 with multiple upstreams. I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines. The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections. With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished? In a nutshell: how do you have 2 upstream connections, and choose between them based on outbound destination? thanks, -Randy From seth.mos at dds.nl Sun Jun 12 01:41:54 2011 From: seth.mos at dds.nl (Seth Mos) Date: Sun, 12 Jun 2011 08:41:54 +0200 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> Message-ID: <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven: > > I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines. So basically policy routing? > The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections. Yep that sounds like policy routing. > With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished? Sure there is NAT, you can use prefix translation to translate your Global Address Range from the redundant ISP to the Cable ISP Global address range when leaving that interface. I've run a similar setup with 3 independent ISPs with IPv6 netblocks. Whichever connection the traffic went out it got the right GUA mapped onto it. Note that this is 1:1 NAT and not N:1. In my case there was no primary GUA range, I used a ULA on the LAN side of things, and mapped the corresponding GUA onto it when leaving the network. I had 3 rules, 1 for each WAN and mapped the ULA/56 to the GUA/56. In your case you already have a primary connection of sorts, so I'd suggest using that on the LAN side and only map the other GUA onto it when it leaves the other interfaces. The policy routing rules on your firewall can make all the routing decissions for you. If you search google for "IPv6 network prefix translation" there will be a firewall listed that can do this somewhere in the middle of the page. Cheers, Seth From don at bowenvale.co.nz Sun Jun 12 02:18:59 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sun, 12 Jun 2011 19:18:59 +1200 Subject: Yup; the Internet is screwed up. - Land Assistance... In-Reply-To: <4DF370C4.6010701@deaddrop.org> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2CB1E.5050309@bowenvale.co.nz> <4DF2D971.7030608@bowenvale.co.nz> <4DF2DD98.7010404@bowenvale.co.nz> <4DF32E7B.9030401@bowenvale.co.nz> <4DF370C4.6010701@deaddrop.org> Message-ID: <4DF46863.6080403@bowenvale.co.nz> On 12/06/2011 1:42 a.m., Lynda wrote: > Mostly, I've just ignored this, As do I with most treads on this list. However I found the link in the OP's post offensive on so many different levels that I choose to put some comment in with a great deal of subtly and hopefully a little humour. Clearly, judging by the off list comments I got, some people got it and some people didn't. I'm not sure which comment in the OPs link I found most offensive, but the suggestion that most folk in small rural American towns are drug dealers and addicts was up there with the suggest that the entire reason for poor broadband in USA is the sole fault of AT&T. Perhaps that's not what the article was saying. However it is the impression I took from what I read, which is what compelled me to comment. I confess that I didn't even read the entire article... by the time I got though reason 2, I was already offended enough. > since it wasn't really contributing to a > solution for anything I could see, and wasn't finding it as amusing to > read as the author did to write. This statement, however, needs a bit of > changing, sir. I am sorry the humour was lost on you. :) I did change the subject heading on purpose, specifically so people, who weren't interested in the obvious direction of the thread, could simply ignore it. > I'd say that "people in rural America" (many of whom are my neighbors) > are adept at making do, and very clever at finding solutions to the > problems that the author of this piece did not. Agreed. As I come from a country that has an extremely large rural economic component and is as far from market as we are, I very much understand the need to adept and make do. > Please note that the > author seems to be yet another transplanted city boy, and as such, might > not have been aware of how to solve this problem quickly, and in the > most expedient manner, but that does not mean you should lump rural > America in one large bucket... No it does not mean you should lump rural people in any bucket, being the whole point, of my first post, by suggesting that I should get help with setting up a farm in the centre of down town Manhattan, from the list. Again, it's up there with the suggestion that the only way to get broadband in rural America is to wait until one of your drugged out neighbours dies from an over dose and you can then take over the free port on the DSLAM. > I should also point out that the author of the article isn't even *in* a > rural setting. Contrary to popular belief, living in a small town is not > rural. I've lived 5 five miles out of town, and we barely considered > that rural. We had neighbors less than a quarter mile walk away. I've lived in a country where it take 3 hours to drive to your next closes neighbour, while in my own country we call a town rural when it has 3,000 people in it and the housing density is not far off the urban suburb I live in today - at which point we seem to currently consider they don't need ftth and 5mbit's of contended mobile broadband is more than enough. > In addition (since my annoyance factor seems to be set on high), I'm a > bit curious as to how someone living in New Zealand is so concerned with > broadband access in the US. I'm interested in broadband access around the world, not just the USA. New Zealand culture is very influenced by the United States. The United States is a large trading partner from our point of view. What you do in the USA has global impact. For example if the USA says it's ok for rural folk not to have decent broadband then out countries around the world, such as my own, point to the USA as a point of reference. Same if you decide that every farmer must have 100Gbe connections. D From don at bowenvale.co.nz Sun Jun 12 04:09:21 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sun, 12 Jun 2011 21:09:21 +1200 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <4DF3E933.4080809@mompl.net> Message-ID: <4DF48241.7040902@bowenvale.co.nz> On 12/06/2011 1:02 p.m., Owen DeLong wrote: >>> On Jun 11, 2011, at 15:16, Jeroen van Aart wrote: >> Randy Bush wrote: >>> some of us try to get work done from home. and anyone who has worked >>> and/or lived in a first world country thinks american 'broadband' speeds >>> are a joke, even for a home network. >> I understand, but I was referring to the average home internet connection. But even for work 100Mbps seems a bit overkill for most purposes. Whole offices work fine with a "mere" bonded T1 at 10Mbps. Admitted it's symmetrical and is more stable. But regarding speed it's quite a bit slower than the mentioned 100Mbps home internet. > Depends on the office and the user profile at home. I would be very unhappy and so would my coworkers behind a bonded T1 at 10 Mbps. However, I do admit I think my 70 Mbps at home will probably be adequate for a few years to come. Some may find this of interest: http://home.bowenvale.co.nz/wp/apps.gif and this... http://forums.whirlpool.net.au/forum-replies.cfm?t=1515155 (Is there an NBN Killer App? - Australians talking about what they might use the FTTH for). With respect to home v's office, 100 v's 10... Applications such as back up may not even be attempted online in an office, which is why 10mbit is fine. As I said earlier, BIR is what 100mbit is about. In an office you have computers on for 8 hours a day. With QoS you can push data out in a controlled way. For example, when you send a 10mb email, it transfers to the office mail server 'instantly' and is then streamed out at what ever speed the QoS is letting port 25 run at. At home when you send 10mb it goes direct to the ISPs SMTP server and saturates the uplink while that's happening or QoS slows it down and the customer has to wait while their computer 'sends' the message. BIR is also about user experience. We know that when we give users a better experience they stay longer. See: http://home.bowenvale.co.nz/wp/sam where Sam Morgan talks about making sure that TradeMe.co.nz is fast so that users will stick about and use it more. At work you have limited choice. If it's slow, but you have to use it, then you will. Where as at home if it's slow, you'll give up and go read a book. Also at home we're more likely to make massive volumes of content, for example a simple photo shoot with your kid on your new digital camera can chew up 1gb in minutes (my 10mpx camera uses 1gb --> 220 shots which I can shoot off at a birthday party without even trying). How often do businesses produce that volume of content? From don at bowenvale.co.nz Sun Jun 12 04:22:17 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sun, 12 Jun 2011 21:22:17 +1200 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF3EA1C.1060708@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611100024.GT13108@hezmatt.org> <4DF3EA1C.1060708@mompl.net> Message-ID: <4DF48549.1090501@bowenvale.co.nz> 100mbit is not luxury, it's something my business needs all it's customers to have to drive more uptake of my services. My customers already have 10/1 today. Now I need them to have 100/40 so they have a reason to buy other CPE that in turn drives my business. See: http://home.bowenvale.co.nz/wp/apps.gif On 01/1 we can't even use half those apps. Which means there is no market for any of the CPE that those apps require. That CPE is a massive global economic driver. With out the ability to use the CPE there is no driver for further development of that CPE. The basic POTS telephone has stayed the same for 3 decades. There is just about no work for anyone designing POTS CPE, there was work 3 decades ago. 4 Decades ago parents around the globe were told that IT and computers where the future. We have to keep growing our data delivery systems in order to keep pushing IT forward. Is a job in IT a luxury? On 12/06/2011 10:20 a.m., Jeroen van Aart wrote: > Matthew Palmer wrote: >> Well, you probably live in a premises with only a couple of people. A >> household with the "standard" 2.3 kids might need to stream 4.3 TV >> channels, > > Right, but now you're talking about the luxury aspect of it. And then > all bets are off. The necessity would already be fulfilled with a lower > speed. > From dr at cluenet.de Sun Jun 12 05:05:33 2011 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 12 Jun 2011 12:05:33 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <4DF39AAD.5050304@kl.net> References: <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <20110610152629.GA26942@ussenterprise.ufp.org> <4DF39AAD.5050304@kl.net> Message-ID: <20110612100533.GA21879@srv03.cluenet.de> On Sat, Jun 11, 2011 at 12:41:17PM -0400, Kevin Loch wrote: > VRRPv3 (http://tools.ietf.org/html/rfc5798) is still a bit broken > in that it makes mention of "MUST advertise RA's" That's unintentional as per recent discussion on IETF VRRP mailing list where I seeked for clarification as JUNOS complains on every commit about no RAs for VRRP units. See http://www.ietf.org/mail-archive/web/vrrp/current/msg01447.html and response. I have yet to draft the RFC Erratum clarifying that unintentional interpretation. > and inexplicably limits VRRP addresses to link local only (?!)*. I cannot see that in RFC5798, and implementations and operational experience differs. VRRP communications itself is via link-local addresses. There is a requirement to have a link-local virtual address as well, but there might be many more, e.g. global scope. Otherwise a whole lot of IPv6 VRRP setups won't be working here. :) We use global scope addresses as VRRP virtual router addresses. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Sun Jun 12 05:35:44 2011 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 12 Jun 2011 12:35:44 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> References: <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> Message-ID: <20110612103544.GA25062@srv03.cluenet.de> On Fri, Jun 10, 2011 at 09:12:26PM -0700, Owen DeLong wrote: > You must have RA to at least tell you: > Default Router > Go ask the DHCP server (M and/or O bit) > > As it currently stands, an RFC-compliant host will not attempt to solicit > a DHCP response unless it receives an RA with the M inclusive-or O bits > set. RFC 4862 seems to acknowledge otherwise: 5.5.2. Absence of Router Advertisements Even if a link has no routers, the DHCPv6 service to obtain addresses may still be available, and hosts may want to use the service.[...] Could you point to any RFC which implies or explicitly states that DHCPv6 MUST NOT be used in absence of RA with M and/or O=1? Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Sun Jun 12 05:36:48 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 12 Jun 2011 12:36:48 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <6AE1C8D4-57C7-4FF4-9B0F-AD0CF6D7D96B@virtualized.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com> <6AE1C8D4-57C7-4FF4-9B0F-AD0CF6D7D96B@virtualized.org> Message-ID: <9AFF8A96-5BF6-4288-8E29-161AAD855BD7@muada.com> On 11 jun 2011, at 16:39, David Conrad wrote: >> There is no point in repeating all the IPv4 mistakes with IPv6, if that's what you want, stay on IPv4. > As should be apparent by now, the vast majority of people don't want to move to IPv6. They simply want access to "the Internet". ISPs are looking for the easiest/cheapest way to do this, which generally means the way they've done it in the past. Forcing them to change simply slows things down. Ok, removed my snarky comments on trying to be fast this late in the game. The problem is changing DHCPv6 so people want to deploy it more means waiting a couple of years for the changes to start appearing and then many more years for the non-changed systems to disappear. How doing this makes anything faster is a mystery to me. People just have to get over the fact that IPv6 is different from IPv4 in some regards and it's too late now to change that, because we're already way behind deploying IPv6 before the IPv4 addresses run out. From iljitsch at muada.com Sun Jun 12 06:01:39 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 12 Jun 2011 13:01:39 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com> Message-ID: <97623D46-87FA-4C9A-8AF8-A3023A2FE38F@muada.com> On 11 jun 2011, at 17:05, Owen DeLong wrote: >> Your doctor doesn't just give you the medicine you ask for either. > You are not talking about a doctor/patient scenario here where the doctor is an expert and the people asking for this have no > medical training. Here, we are talking about requirements coming from network engineers that are every bit as skilled as you > are in the field and every bit as capable of making informed decisions about the correct solution for their environment. It's true that the patient also knows some stuff here. There's a lot of bitching here on the NANOG list about how operators get no respect at the IETF. But that's a two-way street. There's also tons of people in operations who have no appreciation to what the IETF brings to the table. Operators tend to see issues in isolation, or at the very least only see the connections that are relevant to their environment. The IETF has to take into consideration all possible environments. Sometimes things that seem a clear win in a constrained environment could be a disaster if they were used all over the internet. You know what they say: a doctor who treats himself has a fool for a patient. > Yes, I'm well familiar with your level of arrogance. Yes, I know I stick out like a sore thumb in these humble parts. >> BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like). > Good for you. Did you try proposing anything that was contrary to the current religion at the time or did you join > the ivory tower biggots in supporting solutions that work better in theory than in operational reality and embrace > their bold new failure to address major concerns (such as scalable routing) while focusing on irrelevant minutiae > such as 8+8 vs. GSE? Judge for yourself: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt Let me wrap up this discussion with the following: IPv6 address configuration is a house of cards. Touch it and it all comes crashing down. DHCPv6 has a number of significant flaws, and the interaction between DHCPv6 and router advertisements only barely makes sense. All of this makes it seem like a good idea to tweak stuff to make it better, but in reality that's a mistake: it just means more opportunities for things to fail. What we need is to rethink the host configuration problem from the ground up, starting at the host and what it should do when it sees its interface come up. One model that seems attractive here is the on the iPhone uses, where you can modify the IP configuration on a per-wifi network basis. If we can apply this kind of logic to wired networks, too, then suddenly we're no longer limited to having one monolithic set of client side behavior that must always be followed, but we can be much more flexible. From iljitsch at muada.com Sun Jun 12 06:04:41 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 12 Jun 2011 13:04:41 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110612103544.GA25062@srv03.cluenet.de> References: <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> Message-ID: On 12 jun 2011, at 12:35, Daniel Roesen wrote: > Could you point to any RFC which implies or explicitly states that > DHCPv6 MUST NOT be used in absence of RA with M and/or O=1? But what's the alternative? Always run DHCPv6 even if there are no router advertisements or router advertisements with O=0, M=0? Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. And networks without RAs are very common. We call those networks "IPv4-only networks". And in the current situation DHCPv6 without router advertisements is pointless because you may get an address, but you have no place to send your packets. From fabio.mendes at bsd.com.br Sun Jun 12 07:38:32 2011 From: fabio.mendes at bsd.com.br (Fabio Mendes) Date: Sun, 12 Jun 2011 09:38:32 -0300 Subject: IPv6 and DNS In-Reply-To: <20110612020408.GX13108@hezmatt.org> References: <20110612020408.GX13108@hezmatt.org> Message-ID: 2011/6/11 Matthew Palmer > > The router isn't assigning an address, it's merely telling everyone on the > segment what the local prefix and default route is. As such, there's no > reason why the router should try to register a DNS entry. > > On the other hand, the host could (and should) register it's address with > whatever DNS server handles it's name. The protocol for such is already > standardised and should be independent of IPv4/IPv6. > > - Matt > Thanks Matt. I was thinking about something like this, it looks the natural way to go, but isn't too dangerous allow hosts to update entries (even if it's their own) in an DNS server ? I preferred to believe that a router would do this because routers are considered to be more reliable than a hosts. In the other hand, I also recognize that this could put a lot of weight in routers' CPU processing. Do you mind to point me out where can I find infos about this protocol that is being standardised ? F?bio From arturo.servin at gmail.com Sun Jun 12 08:27:43 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 12 Jun 2011 10:27:43 -0300 Subject: IPv6 and DNS In-Reply-To: References: <20110612020408.GX13108@hezmatt.org> Message-ID: <073E8CC1-B4D0-420C-B896-E94DB99AB439@gmail.com> On 12 Jun 2011, at 09:38, Fabio Mendes wrote: > 2011/6/11 Matthew Palmer > >> >> The router isn't assigning an address, it's merely telling everyone on the >> segment what the local prefix and default route is. As such, there's no >> reason why the router should try to register a DNS entry. >> >> On the other hand, the host could (and should) register it's address with >> whatever DNS server handles it's name. The protocol for such is already >> standardised and should be independent of IPv4/IPv6. >> >> - Matt >> > > Thanks Matt. > > I was thinking about something like this, it looks the natural way to go, > but isn't too dangerous allow hosts to update entries (even if it's their > own) in an DNS server ? > > I preferred to believe that a router would do this because routers are > considered to be more reliable than a hosts. In the other hand, I also > recognize that this could put a lot of weight in routers' CPU processing. Routers route packets, otherwise they would be called registrars or something like that. -as From bicknell at ufp.org Sun Jun 12 08:45:01 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 12 Jun 2011 06:45:01 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> Message-ID: <20110612134501.GA25078@ussenterprise.ufp.org> In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van Beijnum wrote: > But what's the alternative? Always run DHCPv6 even if there are no router advertisements or router advertisements with O=0, M=0? Yes. > Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. Huh? This is no worse than IPv4 where a host comes up and sends a subnet-broadcast to get DHCP. I have never heard of a network brought to its knees from these requests. A single packet each time a host boots is hardly a high PPS rate. > And networks without RAs are very common. We call those networks "IPv4-only networks". No, we call those server networks. I've seen lots of IPv6 networks with RA's disabled and all static devices on them. Sometimes having hosts dynamically get addresses and default routes is a bad thing. > And in the current situation DHCPv6 without router advertisements is pointless because you may get an address, but you have no place to send your packets. Which is what we would like to fix. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From joelja at bogus.com Sun Jun 12 08:58:20 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 12 Jun 2011 06:58:20 -0700 Subject: IPv6 and DNS In-Reply-To: References: <20110612020408.GX13108@hezmatt.org> Message-ID: <0C7E8703-E260-49DC-B3C4-AEF1102BCA01@bogus.com> dynamic dns update has been done by hosts for some time... http://www.ietf.org/rfc/rfc2136.txt On Jun 12, 2011, at 5:38 AM, Fabio Mendes wrote: > 2011/6/11 Matthew Palmer > >> >> The router isn't assigning an address, it's merely telling everyone on the >> segment what the local prefix and default route is. As such, there's no >> reason why the router should try to register a DNS entry. >> >> On the other hand, the host could (and should) register it's address with >> whatever DNS server handles it's name. The protocol for such is already >> standardised and should be independent of IPv4/IPv6. >> >> - Matt >> > > Thanks Matt. > > I was thinking about something like this, it looks the natural way to go, > but isn't too dangerous allow hosts to update entries (even if it's their > own) in an DNS server ? > > I preferred to believe that a router would do this because routers are > considered to be more reliable than a hosts. In the other hand, I also > recognize that this could put a lot of weight in routers' CPU processing. > > Do you mind to point me out where can I find infos about this protocol that > is being standardised ? > > > F?bio > From mysidia at gmail.com Sun Jun 12 08:59:50 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 12 Jun 2011 08:59:50 -0500 Subject: IPv6 and DNS In-Reply-To: <20110612020408.GX13108@hezmatt.org> References: <20110612020408.GX13108@hezmatt.org> Message-ID: On Sat, Jun 11, 2011 at 9:04 PM, Matthew Palmer wrote: > On Sat, Jun 11, 2011 at 10:30:26PM -0300, Fabio Mendes wrote: > The router isn't assigning an address, it's merely telling everyone on the > segment what the local prefix and default route is. ?As such, there's no > reason why the router should try to register a DNS entry. However, it would be logical to extend the DHCPv6 protocol to allow for registration of the workstation address in DNS by the DHCPv6 management server to be requested (similar to DHCPv4). The DHCPv6 management server needs to become aware of new IP addresses already to send ordinary unicast responses, and a DHCPv6 server is a central server that can be entrusted with the capability to update DNS records, with no need for overtrusting each individual client, or requiring a complicated authentication scheme on DNS servers, for clients to update DNS records corresponding to their own hostname, without each client's credentials being capable of updating any other machine's DNS entry. -- -JH From mpalmer at hezmatt.org Sun Jun 12 10:39:39 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 13 Jun 2011 01:39:39 +1000 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> Message-ID: <20110612153939.GY13108@hezmatt.org> On Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van Beijnum wrote: > On 12 jun 2011, at 12:35, Daniel Roesen wrote: > > > Could you point to any RFC which implies or explicitly states that > > DHCPv6 MUST NOT be used in absence of RA with M and/or O=1? > > But what's the alternative? Always run DHCPv6 even if there are no router > advertisements or router advertisements with O=0, M=0? That would seem to be the logical outcome, yes. > Like I said before, that would pollute the network with many multicasts > which can seriously degrade wifi performance. Regardless of it's potential downsides, the issue at hand was the RFC compliance of such a setup. Owen DeLong contended that: On Fri, Jun 10, 2011 at 09:12:26PM -0700, Owen DeLong wrote: > As it currently stands, an RFC-compliant host will not attempt to solicit > a DHCP response unless it receives an RA with the M inclusive-or O bits > set. Daniel was merely requesting a reference for that assertion. If you have one, I'm sure Daniel (and Owen) would appreciate it. - Matt From mpalmer at hezmatt.org Sun Jun 12 10:41:52 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 13 Jun 2011 01:41:52 +1000 Subject: IPv6 and DNS In-Reply-To: References: <20110612020408.GX13108@hezmatt.org> Message-ID: <20110612154152.GZ13108@hezmatt.org> On Sun, Jun 12, 2011 at 09:38:32AM -0300, Fabio Mendes wrote: > 2011/6/11 Matthew Palmer > > The router isn't assigning an address, it's merely telling everyone on the > > segment what the local prefix and default route is. As such, there's no > > reason why the router should try to register a DNS entry. > > > > On the other hand, the host could (and should) register it's address with > > whatever DNS server handles it's name. The protocol for such is already > > standardised and should be independent of IPv4/IPv6. > > I was thinking about something like this, it looks the natural way to go, > but isn't too dangerous allow hosts to update entries (even if it's their > own) in an DNS server ? What are the hazards and risks? > I preferred to believe that a router would do this because routers are > considered to be more reliable than a hosts. Reliable, or trusted? > Do you mind to point me out where can I find infos about this protocol that > is being standardised ? RFC2136. - Matt From mpalmer at hezmatt.org Sun Jun 12 10:44:02 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 13 Jun 2011 01:44:02 +1000 Subject: IPv6 and DNS In-Reply-To: References: <20110612020408.GX13108@hezmatt.org> Message-ID: <20110612154402.GA13108@hezmatt.org> On Sun, Jun 12, 2011 at 08:59:50AM -0500, Jimmy Hess wrote: > On Sat, Jun 11, 2011 at 9:04 PM, Matthew Palmer wrote: > > The router isn't assigning an address, it's merely telling everyone on the > > segment what the local prefix and default route is. ?As such, there's no > > reason why the router should try to register a DNS entry. > > However, it would be logical to extend the DHCPv6 protocol to allow for > registration of the workstation address in DNS by the DHCPv6 management > server to be requested (similar to DHCPv4). I don't believe we were talking about DHCPv6, we were talking about SLAAC. And I *still* think it's a better idea for the client to be registering itself in DNS; the host knows what domain(s) it should be part of, and hence which names refer to itself and should be updated with it's new address. - Matt From if at xip.at Sun Jun 12 10:49:04 2011 From: if at xip.at (Ingo Flaschberger) Date: Sun, 12 Jun 2011 17:49:04 +0200 (CEST) Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110612134501.GA25078@ussenterprise.ufp.org> References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> Message-ID: >> And networks without RAs are very common. We call those networks "IPv4-only networks". > > No, we call those server networks. I've seen lots of IPv6 networks with > RA's disabled and all static devices on them. Sometimes having hosts > dynamically get addresses and default routes is a bad thing. For my future ipv6 server network I tried to go without ra - but ran into troubles. I use ucarp from freebsd for the ipv4 servers to have a failover gateway - but this does not work because of dad. So I have now a ip for each gateway, still failover via ucarp to bring the interface up / down and advertise the active default gw via ra. Kind regards, Ingo Flaschberger From scott at doc.net.au Sun Jun 12 11:26:02 2011 From: scott at doc.net.au (Scott Howard) Date: Sun, 12 Jun 2011 09:26:02 -0700 Subject: Strongest Solar Tsunami in Years to Hit Earth Today In-Reply-To: <20110611031106.GO13108@hezmatt.org> References: <20110611031106.GO13108@hezmatt.org> Message-ID: On Fri, Jun 10, 2011 at 8:11 PM, Matthew Palmer wrote: > On Fri, Jun 10, 2011 at 03:22:59PM +0300, Hank Nussbacher wrote: > > > http://www.ibtimes.com/articles/159964/20110609/nasa-solar-flare-tsunami-earth-sun-radio-satellite-interference-aurora-displays-coronal-mass-ejectio.htm > > Someone should tell the IB Times that "Tsunami" doesn't mean "anything big > and destructive". Oh, and that popup ads are *soooo* 1997. > While you're at it you might want to let NASA know too... http://www.nasa.gov/mission_pages/stereo/news/solar_tsunami.html Scott From cjp at 0x1.net Sun Jun 12 12:04:46 2011 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Sun, 12 Jun 2011 11:04:46 -0600 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF4115E.4030000@gmail.com> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611101518.GL19622@leitl.org> <4DF3EE46.8040103@mompl.net> <8C59B815-B659-407C-A14B-6E87F0F1083F@oitc.com> <6047076084616721761@unknownmsgid> <4DF4115E.4030000@gmail.com> Message-ID: <8898C635-E8B4-457F-83E0-C567128B8B83@0x1.net> On Jun 11, 2011, at 7:07 PM, Roy wrote: > On 6/11/2011 4:29 PM, Christopher Pilkington wrote: >> Options seem to be limited to HughesNet and dial for the moment, but >> things may change if I put a tower on the property. HughesNet seems to >> relax it's bandwidth cap between 2am and 7am, which is helpful, but >> still a great shift from what I'm used to at the current residence >> (15/2). >> > > No 3G cellphone service? 3G at this location is marginal at best (stand on a hill and hold the phone up above your head.) That said, are there 3G radios that permit external antennas or are well suited to being sealed up in a weatherproof box and being placed on a pole/tower? 3G would get us around the 200-300MiB/day issue, but I'm fairly certain I'll be dealing with similar monthly caps. I can really hope for a wISP nearby, but so far my research hasn't turned up anything. Is there some wISP marketplace/directory about? The final option would be to unofficially put hardware on the roof of my office 50km away with some high-gain antennas, but the path is marginally LOS, I think I might need a very large tower at either end. -cjp From mark at amplex.net Sun Jun 12 12:21:56 2011 From: mark at amplex.net (Mark Radabaugh) Date: Sun, 12 Jun 2011 13:21:56 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <8898C635-E8B4-457F-83E0-C567128B8B83@0x1.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611101518.GL19622@leitl.org> <4DF3EE46.8040103@mompl.net> <8C59B815-B659-407C-A14B-6E87F0F1083F@oitc.com> <6047076084616721761@unknownmsgid> <4DF4115E.4030000@gmail.com> <8898C635-E8B4-457F-83E0-C567128B8B83@0x1.net> Message-ID: <4DF4F5B4.3080802@amplex.net> On 6/12/11 1:04 PM, Christopher J. Pilkington wrote: > On Jun 11, 2011, at 7:07 PM, Roy wrote: > >> On 6/11/2011 4:29 PM, Christopher Pilkington wrote: >>> Options seem to be limited to HughesNet and dial for the moment, but >>> things may change if I put a tower on the property. HughesNet seems to >>> relax it's bandwidth cap between 2am and 7am, which is helpful, but >>> still a great shift from what I'm used to at the current residence >>> (15/2). >>> >> No 3G cellphone service? > 3G at this location is marginal at best (stand on a hill and hold the phone up above your head.) > > That said, are there 3G radios that permit external antennas or are well suited to being sealed up in a weatherproof box and being placed on a pole/tower? > > 3G would get us around the 200-300MiB/day issue, but I'm fairly certain I'll be dealing with similar monthly caps. I can really hope for a wISP nearby, but so far my research hasn't turned up anything. Is there some wISP marketplace/directory about? > > The final option would be to unofficially put hardware on the roof of my office 50km away with some high-gain antennas, but the path is marginally LOS, I think I might need a very large tower at either end. > > -cjp www.wispa.org is probably the largest organization. Every state in the US has a broadband mapping project that should be able to tell you who is in the area and what options you have (assuming that you are in the US which might not be true). If there are no other providers around (or they don't do a good job) it's not that hard to build your own. It doesn't take a very large population density to make a viable business. Just don't try to build a wISP with 802.11x equipment. A properly built wISP network competes quite well with HFC networks in speed and reliability. The technology is evolving quickly with capacity and reliability making significant gains. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From John_Brzozowski at Cable.Comcast.com Sun Jun 12 12:23:02 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Sun, 12 Jun 2011 17:23:02 +0000 Subject: IPv6 day fun is beginning! In-Reply-To: Message-ID: You might want to consider 655 or 825 from Dlink and the Apple Airport Extreme and Time Capsule. We have had a pretty good experience with these models thus far. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 6/8/11 9:07 AM, "TJ" wrote: >Just FWIW: >US, Amazon, Dlink, DIR615, $35.45 ... > > >/TJ > > >On Wed, Jun 8, 2011 at 08:46, Mark Andrews wrote: > >> >> In message , Owen >>DeLong >> write >> s: >> > >> > On Jun 7, 2011, at 9:15 PM, Mark Andrews wrote: >> > >> > >=20 >> > > In message = >> > > > > .us>, John van Oppen writes: >> > >> I was wondering the same thing... we have v6 enabled to about >>700 = >> > users i=3D >> > >> n our native Ethernet to the home deployment here in Seattle. = >> > Unfortunat=3D >> > >> ely, user routers don't seem to often support v6 resulting in only >>= >> > about 2-=3D >> > >> 8% of users in most buildings using it, and most of those are just >>= >> > people p=3D >> > >> lugged directly into the wall jacks we provide without routers. >>I = >> > wonder =3D >> > >> how long it will take for everyone to upgrade their home routers. >> > >>=20 >> > >> John >> > >=20 >> > > If all the home CPE router vendors stopped shipping IPv4 only boxes, >> > > not that long. At the moment the price point for IPv6 CPE routers >> > > is still 2-3x the IPv4 only boxes when you can find one though not >> > > all of that difference is IPv6. The IPv6 boxes often have multiple >> > > radio and other extras. This shows that CPE vendors still see IPv6 >> > > as something *extra* and not something that should be *standard*. >> > >=20 >> > The D-Link DIR series v6 capables are not actually more than about a >>10% >> > premium over the corresponding ipv4-only competition. >> > >> > I see them in computer stores fairly regularly these days. >> > >> > Owen >> >> Wireless G Modem Router $79.00 v4 G >> N-150 $79.95 v4 G >> DIR-615 $129.00 v4/v6 G/N >> DIR-815 $199.95 v4/v6 G/N >> >> The IPv6 price point is still well above the IPv4 only price point. >> >> 1.00AUD = 1.06USD >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> From chipps at chipps.com Sun Jun 12 12:24:08 2011 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Sun, 12 Jun 2011 12:24:08 -0500 Subject: Yup; the Internet is screwed up. - WISPs Message-ID: <002301cc2925$897c3850$9c74a8f0$@chipps.com> You might contact SkyBeam out of Denver. They have been buying up most of the independent WISPs in my area. They seem to be expanding at a rapid rate. They currently rent my tower for one of their nodes. You might also look for a WISP mailing list to post the question on. I do not know what the most active one is currently. The WISP owners are always getting mad at each other and changing what list they subscribe to. Kenneth M. Chipps Ph.D. -----Original Message----- From: Christopher J. Pilkington [mailto:cjp at 0x1.net] Sent: Sunday, June 12, 2011 12:05 PM To: Roy Cc: nanog at nanog.org Subject: Re: Yup; the Internet is screwed up. On Jun 11, 2011, at 7:07 PM, Roy wrote: > On 6/11/2011 4:29 PM, Christopher Pilkington wrote: >> Options seem to be limited to HughesNet and dial for the moment, but >> things may change if I put a tower on the property. HughesNet seems >> to relax it's bandwidth cap between 2am and 7am, which is helpful, >> but still a great shift from what I'm used to at the current >> residence (15/2). >> > > No 3G cellphone service? 3G at this location is marginal at best (stand on a hill and hold the phone up above your head.) That said, are there 3G radios that permit external antennas or are well suited to being sealed up in a weatherproof box and being placed on a pole/tower? 3G would get us around the 200-300MiB/day issue, but I'm fairly certain I'll be dealing with similar monthly caps. I can really hope for a wISP nearby, but so far my research hasn't turned up anything. Is there some wISP marketplace/directory about? The final option would be to unofficially put hardware on the roof of my office 50km away with some high-gain antennas, but the path is marginally LOS, I think I might need a very large tower at either end. -cjp From mpalmer at hezmatt.org Sun Jun 12 12:33:07 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 13 Jun 2011 03:33:07 +1000 Subject: Yup; the Internet is screwed up. In-Reply-To: <8898C635-E8B4-457F-83E0-C567128B8B83@0x1.net> References: <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611101518.GL19622@leitl.org> <4DF3EE46.8040103@mompl.net> <8C59B815-B659-407C-A14B-6E87F0F1083F@oitc.com> <6047076084616721761@unknownmsgid> <4DF4115E.4030000@gmail.com> <8898C635-E8B4-457F-83E0-C567128B8B83@0x1.net> Message-ID: <20110612173307.GA7727@hezmatt.org> On Sun, Jun 12, 2011 at 11:04:46AM -0600, Christopher J. Pilkington wrote: > On Jun 11, 2011, at 7:07 PM, Roy wrote: > > > On 6/11/2011 4:29 PM, Christopher Pilkington wrote: > >> Options seem to be limited to HughesNet and dial for the moment, but > >> things may change if I put a tower on the property. HughesNet seems to > >> relax it's bandwidth cap between 2am and 7am, which is helpful, but > >> still a great shift from what I'm used to at the current residence > >> (15/2). > >> > > > > No 3G cellphone service? > > 3G at this location is marginal at best (stand on a hill and hold the > phone up above your head.) > > That said, are there 3G radios that permit external antennas or are well > suited to being sealed up in a weatherproof box and being placed on a > pole/tower? The little USB stick I just retired in favour of tethering (Huawei U160(?); I can dig up the model number if it's important) has a tiny antenna connection port. I've seen people on the train with a small flat antenna hooked up to these sorts of devices; I'd assume that there are big-ass antennas that are much more efficient and more suitable for permanent mounting somewhere useful. - Matt From jeff-kell at utc.edu Sun Jun 12 12:46:20 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 12 Jun 2011 13:46:20 -0400 Subject: IPv6 and DNS In-Reply-To: <20110612154402.GA13108@hezmatt.org> References: <20110612020408.GX13108@hezmatt.org> <20110612154402.GA13108@hezmatt.org> Message-ID: <4DF4FB6C.7000304@utc.edu> On 6/12/2011 11:44 AM, Matthew Palmer wrote: > I don't believe we were talking about DHCPv6, we were talking about SLAAC. > And I *still* think it's a better idea for the client to be registering > itself in DNS; the host knows what domain(s) it should be part of, and hence > which names refer to itself and should be updated with it's new address. Register with "what/which" DNS? If no DHCPv6 no DNS information has been acquired, so you're doing the magical anycast/multicast. Not a fan of self-registration, in IPv4 we have DHCP register the DDNS update; after all, it just handed out an address for a zone/domain that *it* knows for certain. The host "knows what domains it should be part of" ?? Perhaps a server or a fixed desktop, but otherwise (unless you're a big fan of ActiveDirectory anywhere) the domain is relative to the environment you just inherited. Letting any host register itself in my domain from any address/location is scary as heck :) Jeff From chipps at chipps.com Sun Jun 12 12:50:49 2011 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Sun, 12 Jun 2011 12:50:49 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF4F5B4.3080802@amplex.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611101518.GL19622@leitl.org> <4DF3EE46.8040103@mompl.net> <8C59B815-B659-407C-A14B-6E87F0F1083F@oitc.com> <6047076084616721761@unknownmsgid> <4DF4115E.4030000@gmail.com> <8898C635-E8B4-457F-83E0-C567128B8B83@0x1.net> <4DF4F5B4.3080802@amplex.net> Message-ID: <002401cc2929$444bad70$cce30850$@chipps.com> Good point. That is exactly how I got into the business. I had to have a T1 line run to the house to get enough bandwidth. At 425.33 a month, I decided to have some of my students setup a WISP at my place so the neighbors would pay for the data line instead of me. For equipment and software look at Mikrotik. Another option is the T1. If you can get an analog line, you should be able to get an ISDN or T1 line as these are typically tariffed services. -----Original Message----- From: Mark Radabaugh [mailto:mark at amplex.net] Sent: Sunday, June 12, 2011 12:22 PM To: Christopher J. Pilkington; nanog at nanog.org Subject: Re: Yup; the Internet is screwed up. On 6/12/11 1:04 PM, Christopher J. Pilkington wrote: > On Jun 11, 2011, at 7:07 PM, Roy wrote: > >> On 6/11/2011 4:29 PM, Christopher Pilkington wrote: >>> Options seem to be limited to HughesNet and dial for the moment, but >>> things may change if I put a tower on the property. HughesNet seems >>> to relax it's bandwidth cap between 2am and 7am, which is helpful, >>> but still a great shift from what I'm used to at the current >>> residence (15/2). >>> >> No 3G cellphone service? > 3G at this location is marginal at best (stand on a hill and hold the > phone up above your head.) > > That said, are there 3G radios that permit external antennas or are well suited to being sealed up in a weatherproof box and being placed on a pole/tower? > > 3G would get us around the 200-300MiB/day issue, but I'm fairly certain I'll be dealing with similar monthly caps. I can really hope for a wISP nearby, but so far my research hasn't turned up anything. Is there some wISP marketplace/directory about? > > The final option would be to unofficially put hardware on the roof of my office 50km away with some high-gain antennas, but the path is marginally LOS, I think I might need a very large tower at either end. > > -cjp www.wispa.org is probably the largest organization. Every state in the US has a broadband mapping project that should be able to tell you who is in the area and what options you have (assuming that you are in the US which might not be true). If there are no other providers around (or they don't do a good job) it's not that hard to build your own. It doesn't take a very large population density to make a viable business. Just don't try to build a wISP with 802.11x equipment. A properly built wISP network competes quite well with HFC networks in speed and reliability. The technology is evolving quickly with capacity and reliability making significant gains. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From smb at cs.columbia.edu Sun Jun 12 12:52:18 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 12 Jun 2011 13:52:18 -0400 Subject: IPv6 and DNS In-Reply-To: <4DF4FB6C.7000304@utc.edu> References: <20110612020408.GX13108@hezmatt.org> <20110612154402.GA13108@hezmatt.org> <4DF4FB6C.7000304@utc.edu> Message-ID: <5FE8217E-5E23-47C5-915C-76FB93787CAA@cs.columbia.edu> On Jun 12, 2011, at 1:46 20PM, Jeff Kell wrote: > On 6/12/2011 11:44 AM, Matthew Palmer wrote: >> I don't believe we were talking about DHCPv6, we were talking about SLAAC. >> And I *still* think it's a better idea for the client to be registering >> itself in DNS; the host knows what domain(s) it should be part of, and hence >> which names refer to itself and should be updated with it's new address. > > Register with "what/which" DNS? If no DHCPv6 no DNS information has > been acquired, so you're doing the magical anycast/multicast. > > Not a fan of self-registration, in IPv4 we have DHCP register the DDNS > update; after all, it just handed out an address for a zone/domain that > *it* knows for certain. > > The host "knows what domains it should be part of" ?? Perhaps a server > or a fixed desktop, but otherwise (unless you're a big fan of > ActiveDirectory anywhere) the domain is relative to the environment you > just inherited. > > Letting any host register itself in my domain from any address/location > is scary as heck :) > Not any host -- hosts you authorize to register in your zone, and give the proper authentication credentials. I want my hosts to register in my domain, even if they're getting credentials from a random hotel or hotspot DHCP server. There are two different models here. A DHCP server should have the sole right to register in its affiliated DNS servers (including especially the inverse map). A host should have the right -- not necessarily the sole right -- to register in a forward tree. --Steve Bellovin, https://www.cs.columbia.edu/~smb From bzs at world.std.com Sun Jun 12 13:02:59 2011 From: bzs at world.std.com (Barry Shein) Date: Sun, 12 Jun 2011 14:02:59 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> Message-ID: <19956.65363.445977.226978@world.std.com> On June 11, 2011 at 20:53 jlewis at lewis.org (Jon Lewis) wrote: > > Have you heard the joke...ISDN = I Still Don't kNow? For whatever reason, > BRI service is something the US telcos apparently never really wanted to > sell...perhaps because it might have cut into their T1 business. FWIW, ISDN is pretty old, standardized in 1988 but worked on for years before that. The BIG VISION of the telcos was that ISDN would carry the whole stack, particularly services like (business) e-mail. If you're really old you remember MCI Mail which was like 20c/message. They never seriously considered a public internet like we got when architecting ISDN. Consequently the whole thing was just too expensive to deliver as a last-mile connectivity-only product. They needed revenue from the rest of the stack to make it profitable. That said, ISDN was very cool in that it was switched which meant you "dialed" something, a lot like a POTS number. It was usually an actual POTS telephone number with some more digits but whatever. But it could establish a connection in about 50msec which meant you could be dropped, say for idle, hit a key and it'd redial and you'd never notice you were dropped. Try that with POTS dial-up! You could pretty much be dropped and redialed between keystrokes and never much notice. More importantly it meant you could have more than one ISDN "ISP", like dial-up (or voice for that matter) just "dial" a different number. There was discussion, people like Sen Ed Markey of MA was interested (ca 1992?), in trying to get the phone companies to embrace first ISDN (they were reluctant, I had it at home but you really had to know how to order it etc) and then some sort of next generation ISDN which would be faster, maybe 10x, and so on. The attraction of DSL was, among other things, that it was nailed down to one and only one service provider, you couldn't just "dial" some other provider like with ISDN. This was a very important fork in the history of last-mile services, when we went from mostly switched (dial-up, maybe ISDN) to nailed-up single vendor solutions. I'd love to see some sort of "switched" last-mile services again, introduce some competition into the system, tho most likely it'd be (more) virtual over some low-level broadband service. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From iljitsch at muada.com Sun Jun 12 13:12:02 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 12 Jun 2011 20:12:02 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110612134501.GA25078@ussenterprise.ufp.org> References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> Message-ID: <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> On 12 jun 2011, at 15:45, Leo Bicknell wrote: >> Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. > Huh? This is no worse than IPv4 where a host comes up and sends a > subnet-broadcast to get DHCP. The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing. From chipps at chipps.com Sun Jun 12 13:20:22 2011 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Sun, 12 Jun 2011 13:20:22 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <19956.65363.445977.226978@world.std.com> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <19956.65363.445977.226978@world.std.com> Message-ID: <002501cc292d$64895250$2d9bf6f0$@chipps.com> Sure its old and slow, but it is or at least was readily available to use poor country folk that cannot get DSL and so forth. The failback positions when all else is unavailable is analog, ISDN, or T1 from a landline, satellite or a WISP through the air with cellular data becoming more of an option. When I called AT&T to order the ISDN line years ago, their answer was - Huh, What, Do we sell that. -----Original Message----- From: Barry Shein [mailto:bzs at world.std.com] Sent: Sunday, June 12, 2011 1:03 PM To: Jon Lewis Cc: NANOG list Subject: Re: Yup; the Internet is screwed up. On June 11, 2011 at 20:53 jlewis at lewis.org (Jon Lewis) wrote: > > Have you heard the joke...ISDN = I Still Don't kNow? For whatever reason, > BRI service is something the US telcos apparently never really wanted to > sell...perhaps because it might have cut into their T1 business. FWIW, ISDN is pretty old, standardized in 1988 but worked on for years before that. The BIG VISION of the telcos was that ISDN would carry the whole stack, particularly services like (business) e-mail. If you're really old you remember MCI Mail which was like 20c/message. They never seriously considered a public internet like we got when architecting ISDN. Consequently the whole thing was just too expensive to deliver as a last-mile connectivity-only product. They needed revenue from the rest of the stack to make it profitable. That said, ISDN was very cool in that it was switched which meant you "dialed" something, a lot like a POTS number. It was usually an actual POTS telephone number with some more digits but whatever. But it could establish a connection in about 50msec which meant you could be dropped, say for idle, hit a key and it'd redial and you'd never notice you were dropped. Try that with POTS dial-up! You could pretty much be dropped and redialed between keystrokes and never much notice. More importantly it meant you could have more than one ISDN "ISP", like dial-up (or voice for that matter) just "dial" a different number. There was discussion, people like Sen Ed Markey of MA was interested (ca 1992?), in trying to get the phone companies to embrace first ISDN (they were reluctant, I had it at home but you really had to know how to order it etc) and then some sort of next generation ISDN which would be faster, maybe 10x, and so on. The attraction of DSL was, among other things, that it was nailed down to one and only one service provider, you couldn't just "dial" some other provider like with ISDN. This was a very important fork in the history of last-mile services, when we went from mostly switched (dial-up, maybe ISDN) to nailed-up single vendor solutions. I'd love to see some sort of "switched" last-mile services again, introduce some competition into the system, tho most likely it'd be (more) virtual over some low-level broadband service. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From tshaw at oitc.com Sun Jun 12 13:32:39 2011 From: tshaw at oitc.com (TR Shaw) Date: Sun, 12 Jun 2011 14:32:39 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: <002501cc292d$64895250$2d9bf6f0$@chipps.com> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <19956.65363.445977.226978@world.std.com> <002501cc292d$64895250$2d9bf6f0$@chipps.com> Message-ID: When I had mine years ago I was lucky that ISDN in FL was unmetered which was no the case in other locales. However it took forever to get it installed and working correctly. Bell South had to change out pairs and get a tech from 200 miles away to get it installed right. Today, the central office in my town doesn't even support ISDN any more. As for cellular data being an option I don't think so give the increasing data caps and extra fees for overage (which is probably why "the cloud" might have big issues for mobile users) I never liked cable as around here it slows down very noticeably when the kids get off school and they don't like giving out fixed IPs unless you get a "business account." ATTuniverse has its own issues and became only available around here last year. Its the only DSL option. So I use WISP even at home just south of the space center. Tom On Jun 12, 2011, at 2:20 PM, Kenneth M. Chipps Ph.D. wrote: > Sure its old and slow, but it is or at least was readily available to use > poor country folk that cannot get DSL and so forth. The failback positions > when all else is unavailable is analog, ISDN, or T1 from a landline, > satellite or a WISP through the air with cellular data becoming more of an > option. > > When I called AT&T to order the ISDN line years ago, their answer was - Huh, > What, Do we sell that. > > -----Original Message----- > From: Barry Shein [mailto:bzs at world.std.com] > Sent: Sunday, June 12, 2011 1:03 PM > To: Jon Lewis > Cc: NANOG list > Subject: Re: Yup; the Internet is screwed up. > > > On June 11, 2011 at 20:53 jlewis at lewis.org (Jon Lewis) wrote: >> >> Have you heard the joke...ISDN = I Still Don't kNow? For whatever > reason, > BRI service is something the US telcos apparently never really > wanted to > sell...perhaps because it might have cut into their T1 > business. > > FWIW, ISDN is pretty old, standardized in 1988 but worked on for years > before that. > > The BIG VISION of the telcos was that ISDN would carry the whole stack, > particularly services like (business) e-mail. If you're really old you > remember MCI Mail which was like 20c/message. They never seriously > considered a public internet like we got when architecting ISDN. > > Consequently the whole thing was just too expensive to deliver as a > last-mile connectivity-only product. They needed revenue from the rest of > the stack to make it profitable. > > That said, ISDN was very cool in that it was switched which meant you > "dialed" something, a lot like a POTS number. It was usually an actual POTS > telephone number with some more digits but whatever. > > But it could establish a connection in about 50msec which meant you could be > dropped, say for idle, hit a key and it'd redial and you'd never notice you > were dropped. Try that with POTS dial-up! You could pretty much be dropped > and redialed between keystrokes and never much notice. > > More importantly it meant you could have more than one ISDN "ISP", like > dial-up (or voice for that matter) just "dial" a different number. > > There was discussion, people like Sen Ed Markey of MA was interested (ca > 1992?), in trying to get the phone companies to embrace first ISDN (they > were reluctant, I had it at home but you really had to know how to order it > etc) and then some sort of next generation ISDN which would be faster, maybe > 10x, and so on. > > The attraction of DSL was, among other things, that it was nailed down to > one and only one service provider, you couldn't just "dial" some other > provider like with ISDN. > > This was a very important fork in the history of last-mile services, when we > went from mostly switched (dial-up, maybe ISDN) to nailed-up single vendor > solutions. > > I'd love to see some sort of "switched" last-mile services again, introduce > some competition into the system, tho most likely it'd be > (more) virtual over some low-level broadband service. > > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > > > > From rcarpen at network1.net Sun Jun 12 13:46:12 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Sun, 12 Jun 2011 14:46:12 -0400 (EDT) Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> Message-ID: <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> Prefix translation looks to be exactly what we need to do here. Thanks for all of the replies. -Randy On Jun 12, 2011, at 2:42, Seth Mos wrote: > > Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven: > >> >> I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines. > > So basically policy routing? > >> The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections. > > Yep that sounds like policy routing. > >> With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished? > > Sure there is NAT, you can use prefix translation to translate your Global Address Range from the redundant ISP to the Cable ISP Global address range when leaving that interface. I've run a similar setup with 3 independent ISPs with IPv6 netblocks. > > Whichever connection the traffic went out it got the right GUA mapped onto it. Note that this is 1:1 NAT and not N:1. > > In my case there was no primary GUA range, I used a ULA on the LAN side of things, and mapped the corresponding GUA onto it when leaving the network. I had 3 rules, 1 for each WAN and mapped the ULA/56 to the GUA/56. > > In your case you already have a primary connection of sorts, so I'd suggest using that on the LAN side and only map the other GUA onto it when it leaves the other interfaces. > > The policy routing rules on your firewall can make all the routing decissions for you. > > If you search google for "IPv6 network prefix translation" there will be a firewall listed that can do this somewhere in the middle of the page. > > Cheers, > > Seth > From deric.kwok2000 at gmail.com Sun Jun 12 13:46:58 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sun, 12 Jun 2011 14:46:58 -0400 Subject: ip 6 questions Message-ID: Hi Our company will prepare ipv6. I have the following questions We will apply ipv6 from ARIN and try to use it in hosting business 1/ Can we use it in our current AS which is using ipv4? If not. Do we have to apply new AS? 2/ Can arin not allow us to apply ipv4 for the future after we apply ipv6? 3/ Any advices to do ipv6 in hosting business Thank you for your help From dhc2 at dcrocker.net Sun Jun 12 14:05:10 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sun, 12 Jun 2011 12:05:10 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> Message-ID: <4DF50DE6.7010803@dcrocker.net> On 6/10/2011 7:04 AM, Scott Brim wrote: > The > Internet is now more important than electricity or water -- This being a silly Sunday, I'm rolling that around on my tongue and savoring it a bit. While the image of a desiccated user, still typing away, is appealing -- but possibly not all that remarkable, given recent reports of Internet addiction -- what's especially tasty is the idea of having an Internet connection that works without electricity... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From cmadams at hiwaay.net Sun Jun 12 14:31:37 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 12 Jun 2011 14:31:37 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <19956.65363.445977.226978@world.std.com> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <19956.65363.445977.226978@world.std.com> Message-ID: <20110612193137.GA8003@hiwaay.net> Once upon a time, Barry Shein said: > The attraction of DSL was, among other things, that it was nailed down > to one and only one service provider, you couldn't just "dial" some > other provider like with ISDN. When BellSouth switched their DSL from PVC-per-customer to PPPoE, it was set up with the ability for a single line to be "subscribed" to multiple providers. The domain in the username used for PPPoE authentication was to determine to which provider the session was connected. I don't know if that capability was ever used (or even actually available). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From eugen at imacandi.net Sun Jun 12 14:37:33 2011 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sun, 12 Jun 2011 22:37:33 +0300 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF3E933.4080809@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <4DF3E933.4080809@mompl.net> Message-ID: On Sun, Jun 12, 2011 at 01:16, Jeroen van Aart wrote: > Randy Bush wrote: >> >> some of us try to get work done from home. ?and anyone who has worked >> and/or lived in a first world country thinks american 'broadband' speeds >> are a joke, even for a home network. > > I understand, but I was referring to the average home internet connection. > But even for work 100Mbps seems a bit overkill for most purposes. Whole > offices work fine with a "mere" bonded T1 at 10Mbps. Admitted it's > symmetrical and is more stable. But regarding speed it's quite a bit slower > than the mentioned 100Mbps home internet. I need 100Mbs at home because I want to see a streamed movie NOW, not in a month because someone considers broadband a luxury :) Pretty simple usage scenario I might say. From cmadams at hiwaay.net Sun Jun 12 14:48:00 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 12 Jun 2011 14:48:00 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <4DF3E933.4080809@mompl.net> Message-ID: <20110612194800.GB8003@hiwaay.net> Once upon a time, Eugeniu Patrascu said: > I need 100Mbs at home because I want to see a streamed movie NOW, not > in a month because someone considers broadband a luxury :) > Pretty simple usage scenario I might say. The top profile for Blu-Ray is 36 megabits per second, and that is not used on most titles. Over-the-air HDTV is 19 megabits or less. Cable HD channels are often only 12-15 megabits per second. OTA and cable HD is typically MPEG2, and MPEG4 can reach similar quality in half the bandwidth, which means TV quality HD can be 6-10 megabits per second. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From nmaxpierson at gmail.com Sun Jun 12 14:50:58 2011 From: nmaxpierson at gmail.com (Max Pierson) Date: Sun, 12 Jun 2011 14:50:58 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <20110612193137.GA8003@hiwaay.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <4DF2AC2B.7070108@mompl.net> <19956.65363.445977.226978@world.std.com> <20110612193137.GA8003@hiwaay.net> Message-ID: >When BellSouth switched their DSL from PVC-per-customer to PPPoE I remember having to compress the config due to static pvc config on many of 7204/6 kit, the switch made it much more intuitive to manage. -- m On Sun, Jun 12, 2011 at 2:31 PM, Chris Adams wrote: > Once upon a time, Barry Shein said: > > The attraction of DSL was, among other things, that it was nailed down > > to one and only one service provider, you couldn't just "dial" some > > other provider like with ISDN. > > When BellSouth switched their DSL from PVC-per-customer to PPPoE, it was > set up with the ability for a single line to be "subscribed" to multiple > providers. The domain in the username used for PPPoE authentication was > to determine to which provider the session was connected. > > I don't know if that capability was ever used (or even actually > available). > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From dougb at dougbarton.us Sun Jun 12 15:08:37 2011 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 12 Jun 2011 13:08:37 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <97623D46-87FA-4C9A-8AF8-A3023A2FE38F@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com> <97623D46-87FA-4C9A-8AF8-A3023A2FE38F@muada.com> Message-ID: <4DF51CC5.70403@dougbarton.us> On 6/12/2011 4:01 AM, Iljitsch van Beijnum wrote: > IPv6 address configuration is a house of cards. Touch it and it all comes crashing down. DHCPv6 has a number of significant flaws, and the interaction between DHCPv6 and router advertisements only barely makes sense. Well, at least you're being honest here. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jra at baylink.com Sun Jun 12 15:11:28 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 12 Jun 2011 16:11:28 -0400 (EDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <20110612194800.GB8003@hiwaay.net> Message-ID: <10322446.186.1307909488897.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Chris Adams" > The top profile for Blu-Ray is 36 megabits per second, and that is > not used on most titles. Over-the-air HDTV is 19 megabits or less. > Cable HD channels are often only 12-15 megabits per second. Chris glances off, but doesn't quite say, that cable providers are prone to *reencode* OTA HDTV, leaving cable subscribers with a worse -- sometimes a *substantially* worse -- picture than they'd get from an OTA antenna. Bandwidth surfing is rarely so end-user visible. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From tom at ninjabadger.net Sun Jun 12 15:31:16 2011 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 12 Jun 2011 21:31:16 +0100 Subject: ip 6 questions In-Reply-To: References: Message-ID: <1307910676.2003.8.camel@teh-desktop> On Sun, 2011-06-12 at 14:46 -0400, Deric Kwok wrote: > We will apply ipv6 from ARIN and try to use it in hosting business > > 1/ Can we use it in our current AS which is using ipv4? If not. Do we > have to apply new AS? No, you can route IPv6 & IPv4 from the same ASN. > 2/ Can arin not allow us to apply ipv4 for the future after we apply ipv6? If you need IPv4, apply for it. You might have a *better* chance if you already have a plan to implement IPv6, than if you have not considered it. > 3/ Any advices to do ipv6 in hosting business Software. Plesk barely has IPv6 support (>10.2) and I'm yet to hear about it from CPanel. Furthermore connection tracking in RHEL/CentOS 5 is totally broken for IPv6 if you're using it for IPv4 also... But mostly: you just have to dive in and see what works/what doesn't. Just don't test it on your live servers! Tom From iljitsch at muada.com Sun Jun 12 16:11:34 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 12 Jun 2011 23:11:34 +0200 Subject: ip 6 questions In-Reply-To: References: Message-ID: <60C931C5-C592-4F3A-9E20-4FC568CFD1F5@muada.com> On 12 jun 2011, at 20:46, Deric Kwok wrote: > 1/ Can we use it in our current AS which is using ipv4? Yes. > 2/ Can arin not allow us to apply ipv4 for the future after we apply ipv6? They're going to do that anyway once they run out, but it's not like "you have v6 so you don't need more v4". > 3/ Any advices to do ipv6 in hosting business Read a good book. :-) There's also tons of informatin out there on the web and in meetings. For hosting you really want to think about how to set up your VLANs. Each customer in their own VLAN is ideal but not always possible, mostly depending on how IPv4 is set up. From cmadams at hiwaay.net Sun Jun 12 16:48:33 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 12 Jun 2011 16:48:33 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <10322446.186.1307909488897.JavaMail.root@benjamin.baylink.com> References: <20110612194800.GB8003@hiwaay.net> <10322446.186.1307909488897.JavaMail.root@benjamin.baylink.com> Message-ID: <20110612214833.GC8003@hiwaay.net> Once upon a time, Jay Ashworth said: > ----- Original Message ----- > > From: "Chris Adams" > > The top profile for Blu-Ray is 36 megabits per second, and that is > > not used on most titles. Over-the-air HDTV is 19 megabits or less. > > Cable HD channels are often only 12-15 megabits per second. > > Chris glances off, but doesn't quite say, that cable providers are prone > to *reencode* OTA HDTV, leaving cable subscribers with a worse -- sometimes > a *substantially* worse -- picture than they'd get from an OTA antenna. Well, the OTA providers are doing it to the network feeds first, so I don't see focusing on the cable providers doing it to the OTA providers as the sole source of quality issues. The OTA providers also reencode to add bugs, weather/breaking news crawls, etc., and they don't always do a good job of that before feeding the signal to the statmuxer. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bygg at cafax.se Sun Jun 12 23:51:44 2011 From: bygg at cafax.se (Johnny Eriksson) Date: Sun, 12 Jun 2011 23:51:44 WET DST Subject: Yup; the Internet is screwed up. In-Reply-To: Your message of Sun, 12 Jun 2011 12:05:10 -0700 Message-ID: dcrocker at bbiw.net wrote: > While the image of a desiccated user, still typing away, is appealing -- > but possibly not all that remarkable, given recent reports of Internet > addiction -- what's especially tasty is the idea of having an Internet > connection that works without electricity... About as useful as a phone that works without electricity. Oh, thats different, nevermind. > d/ --Johnny From seth.mos at dds.nl Sun Jun 12 17:09:04 2011 From: seth.mos at dds.nl (Seth Mos) Date: Mon, 13 Jun 2011 00:09:04 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110612100533.GA21879@srv03.cluenet.de> References: <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <20110610152629.GA26942@ussenterprise.ufp.org> <4DF39AAD.5050304@kl.net> <20110612100533.GA21879@srv03.cluenet.de> Message-ID: <7CBF0DEF-3E49-4618-A3D1-9EEC81984BE6@dds.nl> Op 12 jun 2011, om 12:05 heeft Daniel Roesen het volgende geschreven: > VRRP communications itself is via link-local addresses. There is a > requirement to have a link-local virtual address as well, but there > might be many more, e.g. global scope. In FreeBSD with pfSense I use CARP with a v6 addresses which are GUA, the isp routes my /48 to the GUA address, failover time when rebooting firewalls is in the order of seconds. I see no missed http requests and no existing requests drop. The servers behind it are also configured to use the LAN side GUA CARP ipv6 address as the default gateway. pfsync makes sure that traffic state is being kept. > > Otherwise a whole lot of IPv6 VRRP setups won't be working here. :) > We use global scope addresses as VRRP virtual router addresses. Indeed, same here. We have a open ticket iirc to patch our radvd daemon to also announce properly when active on a v6 CARP Address. It's that or being able to manually sending a GUA address as being the gateway. Wait, that sounds suspicously like trying to send a gateway bit by way of DHCP. Luckily servers are statically configured. But now comes the deal that I want all my client nodes on the corporate lan to also use the GUA address (which has stateful failover) for the gateway instead of the link local address of one of my CARP cluster nodes. Other options include crafting a link local address for the CARP address and make sure that radvd uses that. The backup carp node won't hear anything or be heard when the address has BACKUP status. It's on the todo list. Regards, Seth From kauer at biplane.com.au Sun Jun 12 18:56:59 2011 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 13 Jun 2011 09:56:59 +1000 Subject: IPv6 and DNS In-Reply-To: <20110612154402.GA13108@hezmatt.org> References: <20110612020408.GX13108@hezmatt.org> <20110612154402.GA13108@hezmatt.org> Message-ID: <1307923019.2282.47.camel@karl> On Mon, 2011-06-13 at 01:44 +1000, Matthew Palmer wrote: > And I *still* think it's a better idea for the client to be > registering itself in DNS; the host knows what domain(s) it should be > part of, and hence which names refer to itself and should be updated > with it's new address. Having tried that, we ended up doing it via DHCP (v4 at the time). We only had probably 15-20K hosts trying to register their names, but the results were sobering. At a rough estimate, one in a hundred was properly configured. We saw obscenities, random strings, thousand-byte names, empty names, invalid names, names with a hundred labels, "my name is Andrew" - you name it, it came and tried to register itself. And then there were the clients. Clients that tried as fast as they could to register their name dozens of times per second, clients that tried to register many names, clients that registered and then immediately deregistered their names, clients that never deregistered their names at all, clients that tried to register important names like "www.ourdomain", clients that had completely broken protocol support... Our logs were filling at thousands of lines per second. So we moved the job to the DHCP server, and most of the problems went away. The server got the desired name from the client, could check it for some level of sanity and could register it properly. The server could also deregister the names when the clients went away, or at least at the end of the lease period. Most hosts *did* speak the DHCP protocol adequately well. Instead of having to allow open slather, we could allow just two hosts to make TSIG-protected updates. The logs became useful again. So although YMMV, I can highly recommend letting your DHCP servers do DDNS instead of letting the clients do it themselves. No doubt it depends on a multitude of factors, not least being whether you actually use DHCP, but in general, it worked a LOT better for us. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mpalmer at hezmatt.org Sun Jun 12 20:03:26 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 13 Jun 2011 11:03:26 +1000 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> References: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> Message-ID: <20110613010326.GB7727@hezmatt.org> On Sun, Jun 12, 2011 at 08:12:02PM +0200, Iljitsch van Beijnum wrote: > On 12 jun 2011, at 15:45, Leo Bicknell wrote: > > >> Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. > > > Huh? This is no worse than IPv4 where a host comes up and sends a > > subnet-broadcast to get DHCP. > > The IPv4 host does this once and gets its lease. If there is no DHCPv6 > server then DHCPv6 clients would keep broadcasting forever. Not a good > thing. You're not working from comparable situations. An IPv4 network without a DHCP server will probably have lots of IPv4 hosts banging out broadcast packets constantly as well. - Matt -- A committee is a cul-de-sac down which ideas are lured and then quietly strangled. -- Sir Barnett Cocks (1907-1989) (QOTD 20 Feb 2003) From mpalmer at hezmatt.org Sun Jun 12 20:07:53 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 13 Jun 2011 11:07:53 +1000 Subject: IPv6 and DNS In-Reply-To: <4DF4FB6C.7000304@utc.edu> References: <20110612020408.GX13108@hezmatt.org> <20110612154402.GA13108@hezmatt.org> <4DF4FB6C.7000304@utc.edu> Message-ID: <20110613010753.GC7727@hezmatt.org> On Sun, Jun 12, 2011 at 01:46:20PM -0400, Jeff Kell wrote: > On 6/12/2011 11:44 AM, Matthew Palmer wrote: > > I don't believe we were talking about DHCPv6, we were talking about SLAAC. > > And I *still* think it's a better idea for the client to be registering > > itself in DNS; the host knows what domain(s) it should be part of, and hence > > which names refer to itself and should be updated with it's new address. > > Register with "what/which" DNS? If no DHCPv6 no DNS information has > been acquired, so you're doing the magical anycast/multicast. RFC6106, or local recursive resolver. Also, recursive resolution is not the same as DDNS registration with an authoritative server. > Not a fan of self-registration, in IPv4 we have DHCP register the DDNS > update; after all, it just handed out an address for a zone/domain that > *it* knows for certain. No, it handed out *an* *address*. Assuming that everything that wants an address also wants the whole shebang is a whole other issue. > The host "knows what domains it should be part of" ?? Perhaps a server > or a fixed desktop, but otherwise (unless you're a big fan of > ActiveDirectory anywhere) the domain is relative to the environment you > just inherited. No it isn't. If I want someone to talk to my laptop, and I happen to be roadwarrioring at a client site, do I want to say "hey, just hit floozy.hezmatt.org", or do I want to have to ask someone "what domain will my laptop be registered as?" and then work it out from there? > Letting any host register itself in my domain from any address/location > is scary as heck :) So don't do that, then. Only let hosts that you want to have in your domain register whatever their current address is. - Matt -- A polar bear is a rectangular bear after a coordinate transform. From mpalmer at hezmatt.org Sun Jun 12 20:16:40 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 13 Jun 2011 11:16:40 +1000 Subject: IPv6 and DNS In-Reply-To: <1307923019.2282.47.camel@karl> References: <20110612020408.GX13108@hezmatt.org> <20110612154402.GA13108@hezmatt.org> <1307923019.2282.47.camel@karl> Message-ID: <20110613011640.GD7727@hezmatt.org> On Mon, Jun 13, 2011 at 09:56:59AM +1000, Karl Auer wrote: > On Mon, 2011-06-13 at 01:44 +1000, Matthew Palmer wrote: > > And I *still* think it's a better idea for the client to be > > registering itself in DNS; the host knows what domain(s) it should be > > part of, and hence which names refer to itself and should be updated > > with it's new address. > > Having tried that, we ended up doing it via DHCP (v4 at the time). > > We only had probably 15-20K hosts trying to register their names, but > the results were sobering. At a rough estimate, one in a hundred was > properly configured. We saw obscenities, random strings, thousand-byte > names, empty names, invalid names, names with a hundred labels, "my name > is Andrew" - you name it, it came and tried to register itself. Why were you letting such ill-configured clients register themselves in your DNS? > And then there were the clients. Clients that tried as fast as they > could to register their name dozens of times per second, clients that > tried to register many names, clients that registered and then > immediately deregistered their names, clients that never deregistered > their names at all, clients that tried to register important names like > "www.ourdomain", clients that had completely broken protocol support... Ibid. > So we moved the job to the DHCP server, and most of the problems went > away. The server got the desired name from the client, could check it > for some level of sanity and could register it properly. The server > could also deregister the names when the clients went away, or at least > at the end of the lease period. Most hosts *did* speak the DHCP protocol > adequately well. Instead of having to allow open slather, we could allow > just two hosts to make TSIG-protected updates. The logs became useful > again. But if I come to roadwarrior in your network, I'd have to allow updates from your DHCP server, and your DHCP server would have to be sending those updates. Similarly, if your clients go roadwarrioring elsewhere, the same (or, rather, inverse) configuration would have to be done there. > So although YMMV, I can highly recommend letting your DHCP servers do > DDNS instead of letting the clients do it themselves. No doubt it > depends on a multitude of factors, not least being whether you actually > use DHCP, but in general, it worked a LOT better for us. If you've just got a single-location, never-goes-anywhere network and client list, sure you can just get the DHCP server to do the registration. But if you've got that setup, DDNS isn't needed at all -- your set of hosts, addresses, and names is fixed sufficiently that you can just statically allocate everything. - Matt From bicknell at ufp.org Sun Jun 12 20:29:18 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 12 Jun 2011 18:29:18 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> References: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> Message-ID: <20110613012918.GA47336@ussenterprise.ufp.org> In a message written on Sun, Jun 12, 2011 at 08:12:02PM +0200, Iljitsch van Beijnum wrote: > The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing. DHCP today uses an exponential backoff if there is no response, I don't see why that can't be kept in IPv6. Plus I wonder how long users would keep on machines that get no useable network connectivity. I really think the number of broadcast packets is a total non-issue. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mysidia at gmail.com Sun Jun 12 20:42:33 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 12 Jun 2011 20:42:33 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110613012918.GA47336@ussenterprise.ufp.org> References: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> <20110613012918.GA47336@ussenterprise.ufp.org> Message-ID: On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell wrote: > DHCP today uses an exponential backoff if there is no response, I don't > see why that can't be kept in IPv6. ?Plus I wonder how long users would > keep on machines that get no useable network connectivity. > > I really think the number of broadcast packets is a total non-issue. Rather than deem it a non-issue; I would say The impact of broadcast packets depends on the network they are transmitted over. If you have a Layer 2 domain with 50000 hosts on it; the number of per-host broadcast packets will be much more important than if you have a broadcast domain with 1000 hosts. This could have been (but was unfortunately not) mitigated in the v6 specs by adding options to DHCPv4 to configure IPv6 address and gateway at the same time IPv4 configuration is received, in lieu of using v6 based protocols for config; Requiring configuration to be grabbed _two_ times per host is inefficient -- ONE DHCP discovery for every host on the LAN (either RA+DHCPv6 or DHCPv4) would be more efficient. If v6 hosts are dual stack, and v4 information is already pulled from DHCP.... how much sense does it really make to need a second discovery process to find a v6 server to config the host, particularly when there exists possibility of conflicting options; DHCP can config some non-interface-specific things such as time zone, hostname, etc. There is a potential for greater issues on networks where the number of broadcasts may not have been an issue for IPv4; the IPv6 broadcast messages have a larger payload, because there are 96 more bits in an IPv6 address than an IPv4 address. The broadcasts for configuring IPv6 are incurred _on top_ of the broadcasts already existing for IPv4 on a dual stack network, since IPv6 hosts still have to config IPv4 simultaneously. -- -JH From cmadams at hiwaay.net Sun Jun 12 21:54:39 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 12 Jun 2011 21:54:39 -0500 Subject: Actual IPv6 test day issue Message-ID: <20110613025439.GB7540@hiwaay.net> So I found out I had an actual end-user issue related to IPv6 test day. My mother couldn't get to our webmail with her B&N Nook Color (based on Android 2.3). I went over and couldn't connect with my T-Mobile G2 (Android 2.2) either. Their connection is via DSL and does not have IPv6 configured, but they do have a D-Link DIR-825 wireless router (just running as a wireless bridge with DHCP disabled). The DIR-825 was running an older code, 2.02NA, which was "IPv6 ready"; it had router advertisements enabled (there was no config option to disable them). The problem was that while HTTP would work on Android, HTTPS would not (you'd just get the standard "page not available" error). It appears that there is a bug in Android that keeps it from falling back to IPv4 for HTTPS connections. I don't know if that's somebody's idea of an extra level of "security" or what. I upgraded the DIR-825 to 2.05NA, which doesn't have RA always enabled, and everything works now (on IPv4 only). I haven't had a chance to set up a more detailed test; I just figured I'd throw it out there to see if anybody else saw such. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mike.lyon at gmail.com Mon Jun 13 00:06:27 2011 From: mike.lyon at gmail.com (Mike Lyon) Date: Sun, 12 Jun 2011 22:06:27 -0700 Subject: Anyone from Charter on here? Message-ID: Howdy, Would someone with network clue at Charter hit me up offlist? Need some assistance and I can't get past your wonderful support personnel. Thanks! Mike From kauer at biplane.com.au Mon Jun 13 03:03:30 2011 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 13 Jun 2011 18:03:30 +1000 Subject: IPv6 and DNS In-Reply-To: <20110613011640.GD7727@hezmatt.org> References: <20110612020408.GX13108@hezmatt.org> <20110612154402.GA13108@hezmatt.org> <1307923019.2282.47.camel@karl> <20110613011640.GD7727@hezmatt.org> Message-ID: <1307952210.2282.68.camel@karl> On Mon, 2011-06-13 at 11:16 +1000, Matthew Palmer wrote: > Why were you letting such ill-configured clients register themselves in your > DNS? Some environments have a lot of control over individual hosts, and perhaps for such an environment, allowing hosts to register themselves would not be a problem. In our environment, we had little control over individual hosts, so centralising their registration through DHCP servers was a much more effective way to do things, for all the reasons I gave. > > And then there were the clients. [...] > Ibid. Matthew, did you read my message? This was the *point*. We had lots of poorly configured hosts, over which we could exercise little control. Faced with that situation, and seeing how poorly the hosts performed when allowed to (attempt to) register themselves in the DNS, we decided instead to allow DDNS only from our DHCP servers. That worked very well for us - especially as the vast majority of the hosts connected to our network didn't really need DNS names anyway. When a poorly configured host that did need a name failed to register itself, the owner/administrator of that host would eventually come to us, so the problem was sort of self-correcting. > But if I come to roadwarrior in your network, I'd have to allow updates from > your DHCP server, and your DHCP server would have to be sending those > updates. Similarly, if your clients go roadwarrioring elsewhere, the same > (or, rather, inverse) configuration would have to be done there. Yes, that would be true for any roadwarrior needing/wanting a DNS entry. But in our environment, we didn't have roadwarriors (at least none that needed DNS entries), so it wasn't a problem. If faced with that (and depending on the scale of the problem) I'd probably set up some sort of TSIG key distribution system and let the roadwarriors self-register... dunno. Not a problem I've personally had to solve. > If you've just got a single-location, never-goes-anywhere network and client > list, sure you can just get the DHCP server to do the registration. But if > you've got that setup, DDNS isn't needed at all -- your set of hosts, > addresses, and names is fixed sufficiently that you can just statically > allocate everything. Noooooo! Statically allocating everything in a network where there are 200-1000 DHCP and DNS-related changes every day? No way! While we had a negligible number of "road warriors" - people outside their enterprise networks getting address service from us or our people outside our enterprise network getting address service from others - we had PLENTY of churn inside our enterprise. People moving laptops from subnet to subnet, or moving labs or departments or other groupings around. There were still huge benefits to be had from an automated system. DHCP with DDNS is a great system. Of course it has limitations; I just wanted to point out its strengths. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From isabeldias1 at yahoo.com Mon Jun 13 08:40:21 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Mon, 13 Jun 2011 06:40:21 -0700 (PDT) Subject: ip 6 questions In-Reply-To: References: Message-ID: <998951.17928.qm@web121617.mail.ne1.yahoo.com> http://www.juniper.net/techpubs/software/erx/junose61/swconfig-routing-vol2/html/bgp-mpls-vpns-config15.html http://fengnet.com/book/Definitive%20MPLS%20Network%20Designs/ch01lev1sec6.html http://www.armware.dk/RFC/rfc/rfc4798.html http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.0/routing/command/reference/rr40crs1book_chapter1.html http://www.net.t-labs.tu-berlin.de/teaching/ss09/RL_labcourse/docs/05_juniper.pdf Standards and Technologies: * RFC 4271 Border Gateway Protocol 4 * RFC 4456 BGP Route Reflection * RFC 5065 Autonomous System Confederations for BGP * RFC 1997 BGP Communities Attribute * RFC 2385 TCP MD5 Authentication for BGPv4 * RFC 5492 Capabilities Advertisement with BGP-4 * RFC 2918 Route Refresh Capability * RFC 4760 Multiprotocol Extensions for BGP-4 * RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing * RFC 4893 BGP Support for Four-octet AS Number Space ? http://www.ipv6-es.com/03/documents/cisco/IPv6_over_MPLS.pdf ? ----- Original Message ---- From: Deric Kwok To: nanog list Sent: Sun, June 12, 2011 7:46:58 PM Subject: ip 6 questions Hi Our company will prepare ipv6.? I have the following questions We will apply ipv6 from ARIN and try to use it in hosting business 1/ Can we use it in our current AS which is using ipv4? If not. Do we have to apply new AS? 2/ Can arin not allow us to apply ipv4 for the future after we apply ipv6? 3/ Any advices to do ipv6 in hosting business Thank you for your help From wjhns61 at hardakers.net Mon Jun 13 09:18:37 2011 From: wjhns61 at hardakers.net (Wes Hardaker) Date: Mon, 13 Jun 2011 07:18:37 -0700 Subject: IPv6 day non-participants In-Reply-To: (George B.'s message of "Thu, 9 Jun 2011 12:21:12 -0700") References: Message-ID: >>>>> On Thu, 9 Jun 2011 12:21:12 -0700, "George B." said: GB> There is a reason for that. First of all, we (my employer) took this GB> as a brief test to simply see how much IPv6 traffic there really was, GB> and who and what would actually attempt to reach us by IPv6. The idea GB> here being to attempt to identify IPv6 native networks. Yep. I agree, there are many reasons why you wouldn't want to participate in a full set of tests. I never said otherwise! In fact, many (very much "most") sites didn't participate at all in IPv6 day, so certainly the ones that did get some kudos for playing at all. GB> The test did, however, expose a bug in a piece of vendor gear that was GB> catastrophic to the business service. And that's really the point: get up to speed, test things before hand as best you can, and then test everything you can. The whole point of the day was to expose problems (and successes)! You've exposed one and I'm sure are looking for fixes for it! My only real point is that you still probably don't know what problems exist with the DNS services if you didn't turn IPv6 support for DNS too. I do understand your hesitation, however, as it sounds like you were pretty sure there would be an issue. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From jmaimon at ttec.com Mon Jun 13 10:43:22 2011 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 13 Jun 2011 11:43:22 -0400 Subject: Streaming Message-ID: <4DF6301A.2040806@ttec.com> Is it just me tearing my hair out? From paul at paulstewart.org Mon Jun 13 10:51:38 2011 From: paul at paulstewart.org (Paul Stewart) Date: Mon, 13 Jun 2011 11:51:38 -0400 Subject: Streaming In-Reply-To: <4DF6301A.2040806@ttec.com> References: <4DF6301A.2040806@ttec.com> Message-ID: <005401cc29e1$c89b1990$59d14cb0$@org> Streaming the Windows version here just fine... -----Original Message----- From: Joe Maimon [mailto:jmaimon at ttec.com] Sent: Monday, June 13, 2011 11:43 AM To: North American Networking and Offtopic Gripes List Subject: Streaming Is it just me tearing my hair out? From springer at inlandnet.com Mon Jun 13 10:58:22 2011 From: springer at inlandnet.com (John Springer) Date: Mon, 13 Jun 2011 08:58:22 -0700 (PDT) Subject: Streaming In-Reply-To: <4DF6301A.2040806@ttec.com> References: <4DF6301A.2040806@ttec.com> Message-ID: <20110613085524.N61046@mail.inlandnet.com> Chromebook Flash 2 working OK in Pacific NW. Some tiling/fuzzing. Audio volume is kinda low. On Mon, 13 Jun 2011, Joe Maimon wrote: > Is it just me tearing my hair out? > > > From jmaimon at ttec.com Mon Jun 13 11:19:52 2011 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 13 Jun 2011 12:19:52 -0400 Subject: Streaming In-Reply-To: <20110613085524.N61046@mail.inlandnet.com> References: <4DF6301A.2040806@ttec.com> <20110613085524.N61046@mail.inlandnet.com> Message-ID: <4DF638A8.3080308@ttec.com> Much better now. Probably was just me. John Springer wrote: > Chromebook Flash 2 working OK in Pacific NW. Some tiling/fuzzing. Audio > volume is kinda low. > > On Mon, 13 Jun 2011, Joe Maimon wrote: > >> Is it just me tearing my hair out? >> >> >> > > From jra at baylink.com Mon Jun 13 11:23:24 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 13 Jun 2011 12:23:24 -0400 (EDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <20110612214833.GC8003@hiwaay.net> Message-ID: <14533680.212.1307982204702.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Chris Adams" > Well, the OTA providers are doing it to the network feeds first, so I > don't see focusing on the cable providers doing it to the OTA providers > as the sole source of quality issues. The OTA providers also reencode > to add bugs, weather/breaking news crawls, etc., and they don't always > do a good job of that before feeding the signal to the statmuxer. TTBOMK, no, the affils don't actually reencode the whole feed; there are boxes these days that can insert your bug without trashing the rest of the stream -- and I think their contract with the network *requires* them to run their primary streams as-had, though I can't produce a citation on that. Do you have a citation on this, Chris? I have a couple MythTV people on that list who work at network affils that I could ask. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From chipps at chipps.com Mon Jun 13 11:44:34 2011 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Mon, 13 Jun 2011 11:44:34 -0500 Subject: ATM Cell Capture File Request Message-ID: <007901cc29e9$2ed03ea0$8c70bbe0$@chipps.com> I need a capture file that can be opened in Wireshark that shows ATM cells to illustrate some lecture notes. The file the Wireshark site has does not show any detail for ATM, despite the file name. A search has uncovered no other file. GNS3 does not support ATM link captures. If anyone has such a thing they could share with me, please contact me offlist. Kenneth M. Chipps Ph.D. From sethm at rollernet.us Mon Jun 13 11:54:48 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 13 Jun 2011 09:54:48 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF48549.1090501@bowenvale.co.nz> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611100024.GT13108@hezmatt.org> <4DF3EA1C.1060708@mompl.net> <4DF48549.1090501@bowenvale.co.nz> Message-ID: <4DF640D8.7090903@rollernet.us> On 6/12/11 2:22 AM, Don Gould wrote: > 100mbit is not luxury, it's something my business needs all it's > customers to have to drive more uptake of my services. > > My customers already have 10/1 today. Now I need them to have 100/40 so > they have a reason to buy other CPE that in turn drives my business. > I have to ask, why not just give them symmetric speeds? I understand there are technical reasons why on DSL and cable you end up with asymmetric, but those don't apply to Ethernet delivery. ~Seth From cmadams at hiwaay.net Mon Jun 13 12:01:35 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 13 Jun 2011 12:01:35 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <14533680.212.1307982204702.JavaMail.root@benjamin.baylink.com> References: <20110612214833.GC8003@hiwaay.net> <14533680.212.1307982204702.JavaMail.root@benjamin.baylink.com> Message-ID: <20110613170135.GA9298@hiwaay.net> Once upon a time, Jay Ashworth said: > TTBOMK, no, the affils don't actually reencode the whole feed; there are > boxes these days that can insert your bug without trashing the rest of > the stream -- and I think their contract with the network *requires* them > to run their primary streams as-had, though I can't produce a citation > on that. > > Do you have a citation on this, Chris? I have a couple MythTV people > on that list who work at network affils that I could ask. Well, many/most have multiple channels in their digital stream, and they have to reencode to lower bitrates to fit them all in (different stations do better or worse jobs at this). Only one signal here just carries one channel. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From rzheng at gmail.com Mon Jun 13 12:25:12 2011 From: rzheng at gmail.com (Richard Zheng) Date: Mon, 13 Jun 2011 07:25:12 -1000 Subject: bgp feed to customer Message-ID: Hi, This is probably a typical setup for border router not speaking BGP, wonder how to handle it properly. Border router B is connected with customer router C. Router C wants default-only/partial/full routes. Router B can't or is not willing to handle it. Router C has a multihop EBGP session with a backbone router A. To get router B know the customer routes, router A redistributes them from EBGP to OSPF. The issue is redistribution from EBGP to OSPF works half way. OSPF database has the external routes, but forwarding address is set to Router A. So the routing loop occurs between A and B. I wonder if it is a design issue or configuration issue? Thanks, Richard ---------- -------------- ------------ | BGP rtr A | ============ | no-BGP rtr B | ============ | Customer C | ---------- -------------- ------------ From joelja at bogus.com Mon Jun 13 12:36:23 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 13 Jun 2011 10:36:23 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <8898C635-E8B4-457F-83E0-C567128B8B83@0x1.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611101518.GL19622@leitl.org> <4DF3EE46.8040103@mompl.net> <8C59B815-B659-407C-A14B-6E87F0F1083F@oitc.com> <6047076084616721761@unknownmsgid> <4DF4115E.4030000@gmail.com> <8898C635-E8B4-457F-83E0-C567128B8B83@0x1.net> Message-ID: <02178687-5CFF-4676-88BB-83CD57C291F2@bogus.com> On Jun 12, 2011, at 10:04 AM, Christopher J. Pilkington wrote: > On Jun 11, 2011, at 7:07 PM, Roy wrote: > >> On 6/11/2011 4:29 PM, Christopher Pilkington wrote: >>> Options seem to be limited to HughesNet and dial for the moment, but >>> things may change if I put a tower on the property. HughesNet seems to >>> relax it's bandwidth cap between 2am and 7am, which is helpful, but >>> still a great shift from what I'm used to at the current residence >>> (15/2). >>> >> >> No 3G cellphone service? > > 3G at this location is marginal at best (stand on a hill and hold the phone up above your head.) > > That said, are there 3G radios that permit external antennas or are well suited to > being sealed up in a weatherproof box and being placed on a pole/tower? there are... some specific to particular interface solutions. http://www.cisco.com/en/US/docs/routers/access/wireless/hardware/notes/ant3gom.html most expedient approach is a card with a non-fixes antenna (like the huawei usb sticks) a crc9 to sma adapter and the appropiate antenna. paired with a cradlepoint cpe and you're probably done for less than $200. > 3G would get us around the 200-300MiB/day issue, but I'm fairly certain I'll be dealing with similar monthly caps. I can really hope for a wISP nearby, but so far my research hasn't turned up anything. Is there some wISP marketplace/directory about? > > The final option would be to unofficially put hardware on the roof of my office 50km away with some high-gain antennas, but the path is marginally LOS, I think I might need a very large tower at either end. > > -cjp > From iljitsch at muada.com Mon Jun 13 12:36:50 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 13 Jun 2011 19:36:50 +0200 Subject: bgp feed to customer In-Reply-To: References: Message-ID: On 13 jun 2011, at 19:25, Richard Zheng wrote: > The issue is redistribution from EBGP to OSPF works half way. OSPF database > has the external routes, but forwarding address is set to Router A. So the > routing loop occurs between A and B. If the link to the customer is of a type that detects up/down quickly, the easiest way to get around this is to simply point a default to the customer interface at router B. Another option is running a separate OSPF instance between B and the customer. Or just ignore the issue that if/when the link to the customer goes down, router B doesn't notice and keeps forwarding packets into the void. You would want to make sure that the customer's prefix isn't propagated in OSPF, though, so the issue is limited to this one router, not the whole AS. From mike.lyon at gmail.com Mon Jun 13 12:44:30 2011 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 13 Jun 2011 10:44:30 -0700 Subject: Anyone from Charter on here? In-Reply-To: References: Message-ID: Thank you all for your quick responses! Contact has been made and we are good. Thank You, Mike On Sun, Jun 12, 2011 at 10:06 PM, Mike Lyon wrote: > Howdy, > > Would someone with network clue at Charter hit me up offlist? Need some > assistance and I can't get past your wonderful support personnel. > > Thanks! > Mike > > From lists at beatmixed.com Mon Jun 13 13:16:26 2011 From: lists at beatmixed.com (Matt Hite) Date: Mon, 13 Jun 2011 11:16:26 -0700 Subject: Streaming In-Reply-To: <4DF638A8.3080308@ttec.com> References: <4DF6301A.2040806@ttec.com> <20110613085524.N61046@mail.inlandnet.com> <4DF638A8.3080308@ttec.com> Message-ID: Now if only the slides were the full screen and the talking head was in the corner... otherwise the quality is fantastic! On Mon, Jun 13, 2011 at 9:19 AM, Joe Maimon wrote: > Much better now. Probably was just me. > > John Springer wrote: >> >> Chromebook Flash 2 working OK in Pacific NW. Some tiling/fuzzing. Audio >> volume is kinda low. >> >> On Mon, 13 Jun 2011, Joe Maimon wrote: >> >>> Is it just me tearing my hair out? >>> >>> >>> >> >> > > From rcarpen at network1.net Mon Jun 13 13:18:12 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 13 Jun 2011 14:18:12 -0400 (EDT) Subject: Presentation slides on video feed Message-ID: Does anyone know why the presentation slides keep going black after a few minutes for each presenter on the video feed? When a new presenter comes to the podium, their presentation appears, buy always goes black after a while. thanks, -Randy From joelja at bogus.com Mon Jun 13 13:19:12 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 13 Jun 2011 11:19:12 -0700 Subject: Streaming In-Reply-To: References: <4DF6301A.2040806@ttec.com> <20110613085524.N61046@mail.inlandnet.com> <4DF638A8.3080308@ttec.com> Message-ID: <6453D413-2E8D-4D4F-8F21-62B30D9D2D36@bogus.com> The slides are full screen on the FLV video. On Jun 13, 2011, at 11:16 AM, Matt Hite wrote: > Now if only the slides were the full screen and the talking head was > in the corner... otherwise the quality is fantastic! > > On Mon, Jun 13, 2011 at 9:19 AM, Joe Maimon wrote: >> Much better now. Probably was just me. >> >> John Springer wrote: >>> >>> Chromebook Flash 2 working OK in Pacific NW. Some tiling/fuzzing. Audio >>> volume is kinda low. >>> >>> On Mon, 13 Jun 2011, Joe Maimon wrote: >>> >>>> Is it just me tearing my hair out? >>>> >>>> >>>> >>> >>> >> >> > From paul at paulstewart.org Mon Jun 13 13:23:58 2011 From: paul at paulstewart.org (Paul Stewart) Date: Mon, 13 Jun 2011 14:23:58 -0400 Subject: Streaming In-Reply-To: <6453D413-2E8D-4D4F-8F21-62B30D9D2D36@bogus.com> References: <4DF6301A.2040806@ttec.com> <20110613085524.N61046@mail.inlandnet.com> <4DF638A8.3080308@ttec.com> <6453D413-2E8D-4D4F-8F21-62B30D9D2D36@bogus.com> Message-ID: <008001cc29f7$10864e40$3192eac0$@org> Not the FLV stream I'm watching (http://hidef.mich.net:1234) Big black box in upper left -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Monday, June 13, 2011 2:19 PM To: Matt Hite Cc: North American Networking and Offtopic Gripes List Subject: Re: Streaming The slides are full screen on the FLV video. On Jun 13, 2011, at 11:16 AM, Matt Hite wrote: > Now if only the slides were the full screen and the talking head was > in the corner... otherwise the quality is fantastic! > > On Mon, Jun 13, 2011 at 9:19 AM, Joe Maimon wrote: >> Much better now. Probably was just me. >> >> John Springer wrote: >>> >>> Chromebook Flash 2 working OK in Pacific NW. Some tiling/fuzzing. Audio >>> volume is kinda low. >>> >>> On Mon, 13 Jun 2011, Joe Maimon wrote: >>> >>>> Is it just me tearing my hair out? >>>> >>>> >>>> >>> >>> >> >> > From bill at herrin.us Mon Jun 13 14:34:23 2011 From: bill at herrin.us (William Herrin) Date: Mon, 13 Jun 2011 15:34:23 -0400 Subject: bgp feed to customer In-Reply-To: References: Message-ID: On Mon, Jun 13, 2011 at 1:25 PM, Richard Zheng wrote: > This is probably a typical setup for border router not speaking BGP, wonder > how to handle it properly. Border router B is connected with customer router > C. Router C wants default-only/partial/full routes. Router B can't or is not > willing to handle it. Router C has a multihop EBGP session with a backbone > router A. To get router B know the customer routes, router A redistributes > them from EBGP to OSPF. > > The issue is redistribution from EBGP to OSPF works half way. OSPF database > has the external routes, but forwarding address is set to Router A. So the > routing loop occurs between A and B. > > I wonder if it is a design issue or configuration issue? > > ?---------- ? ? ? ? ? ? ? ? ?-------------- ? ? ? ? ? ? ? ? ------------ > | BGP rtr A | ?============ | no-BGP rtr B | ?============ | Customer C | > ?---------- ? ? ? ? ? ? ? ? ?-------------- ? ? ? ? ? ? ? ? ------------ Hi Richard, Just a SWAG, but run IBGP on router B with just your internal routes (including the customer route) instead of exporting into OSPF? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jfbeam at gmail.com Mon Jun 13 14:50:09 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 13 Jun 2011 15:50:09 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110612134501.GA25078@ussenterprise.ufp.org> References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> Message-ID: On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell wrote: > In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch > van Beijnum wrote: >> Like I said before, that would pollute the network with many multicasts >> which can seriously degrade wifi performance. > > Huh? This is no worse than IPv4 where a host comes up and sends a > subnet-broadcast to get DHCP. Broadcast != Multicast. esp. when talking about wireless chipsets. I've yet to find a wifi chipset that didn't completely fuck-up when presented with even a low pps of multicast traffic. Broadcast traffic doesn't seem to bother them -- it doesn't attempt to filter them in any way, or really pay them any attention. If I had to guess, the chip firmware is individually transmitting multicast packets to each peer; a broadcast packet is sent once to all peers. I've not had any wireless networks disrupted by broadcast traffic -- and with Radware load balancers in the network, there are *plenty* of broadcasts (ARP). Just a few 100pps of multicast and the AP fails. (linksys, netgear, even cisco... all broadcom crap radios.) --Ricky From jim at impactbusiness.com Mon Jun 13 15:54:19 2011 From: jim at impactbusiness.com (Jim Gonzalez) Date: Mon, 13 Jun 2011 16:54:19 -0400 Subject: bgp feed to customer In-Reply-To: References: Message-ID: <00e301cc2a0c$170269b0$45073d10$@impactbusiness.com> -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Monday, June 13, 2011 3:34 PM To: Richard Zheng Cc: nanog at nanog.org Subject: Re: bgp feed to customer On Mon, Jun 13, 2011 at 1:25 PM, Richard Zheng wrote: > This is probably a typical setup for border router not speaking BGP, > wonder how to handle it properly. Border router B is connected with > customer router C. Router C wants default-only/partial/full routes. > Router B can't or is not willing to handle it. Router C has a multihop > EBGP session with a backbone router A. To get router B know the > customer routes, router A redistributes them from EBGP to OSPF. > > The issue is redistribution from EBGP to OSPF works half way. OSPF > database has the external routes, but forwarding address is set to > Router A. So the routing loop occurs between A and B. > > I wonder if it is a design issue or configuration issue? > > ?---------- ? ? ? ? ? ? ? ? ?-------------- ? ? ? ? ? ? ? ? > ------------ > | BGP rtr A | ?============ | no-BGP rtr B | ?============ | Customer > | C | > ?---------- ? ? ? ? ? ? ? ? ?-------------- ? ? ? ? ? ? ? ? > ------------ Hi Richard, Just a SWAG, but run IBGP on router B with just your internal routes (including the customer route) instead of exporting into OSPF? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 Hi Richard, Could you run a bgp session on Router B ? I had to do this once for a customer because we had layer 3 switches on the edge with routing. I configured 2 BGP sessions at the customer's router. The first session was between Customer C and Router B. I only sent the default route to the customer. The next session was ebgp multihop between Router A and Customer C with full routing. I did allow the customer to announce the /30 to Router B just so Router A could learn the return path or you could just static route the /30 from Router A Now if the link Breaks between Router B and Customer C BGP will drop both sessions. Thanks Jim Gonzalez From joelja at bogus.com Mon Jun 13 15:57:32 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 13 Jun 2011 13:57:32 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> Message-ID: On Jun 13, 2011, at 12:50 PM, Ricky Beam wrote: > On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell wrote: >> In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van Beijnum wrote: >>> Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. >> >> Huh? This is no worse than IPv4 where a host comes up and sends a >> subnet-broadcast to get DHCP. > > Broadcast != Multicast. esp. when talking about wireless chipsets. I've yet to find a wifi chipset that didn't completely fuck-up when presented with even a low pps of multicast traffic. Broadcast traffic doesn't seem to bother them -- it doesn't attempt to filter them in any way, or really pay them any attention. If I had to guess, the chip firmware is individually transmitting multicast packets to each peer; a broadcast packet is sent once to all peers. > > I've not had any wireless networks disrupted by broadcast traffic -- and with Radware load balancers in the network, there are *plenty* of broadcasts (ARP). Just a few 100pps of multicast and the AP fails. (linksys, netgear, even cisco... all broadcom crap radios.) by default the multicast rate is at the lowest supported rate on the ap which negatively impacts the performance of everything else. > --Ricky > From owen at delong.com Mon Jun 13 18:28:33 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Jun 2011 16:28:33 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <97623D46-87FA-4C9A-8AF8-A3023A2FE38F@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <1492E17B-1744-47CA-9A2C-8CC9190DCA94@muada.com> <97623D46-87FA-4C9A-8AF8-A3023A2FE38F@muada.com> Message-ID: <043F2E36-BBC9-4A5D-BCBB-7AF4DDFC0EB2@delong.com> On Jun 12, 2011, at 4:01 AM, Iljitsch van Beijnum wrote: > On 11 jun 2011, at 17:05, Owen DeLong wrote: > >>> Your doctor doesn't just give you the medicine you ask for either. > >> You are not talking about a doctor/patient scenario here where the doctor is an expert and the people asking for this have no >> medical training. Here, we are talking about requirements coming from network engineers that are every bit as skilled as you >> are in the field and every bit as capable of making informed decisions about the correct solution for their environment. > > It's true that the patient also knows some stuff here. > > There's a lot of bitching here on the NANOG list about how operators get no respect at the IETF. But that's a two-way street. There's also tons of people in operations who have no appreciation to what the IETF brings to the table. > > Operators tend to see issues in isolation, or at the very least only see the connections that are relevant to their environment. The IETF has to take into consideration all possible environments. Sometimes things that seem a clear win in a constrained environment could be a disaster if they were used all over the internet. > Sure, but, doing that for something that is only locally significant, such as RA/DHCP means that you should implement a true superset of the operational requirements so that operators can choose the tools that best fit their environment, rather than a rag tag set of incomplete tools that require operators to implement ALL of them in order to form a single complete solution and offer no flexibility on which set of solutions is chosen. Guess which one more accurately describes the current state of RA/DHCPv6 from an operator perspective? > You know what they say: a doctor who treats himself has a fool for a patient. > Yes, but, a doctor who accepts the word of another doctor without doing his own analysis is unlikely to be a patient for very long. Death has a way of terminating doctor patient relationships. >> Yes, I'm well familiar with your level of arrogance. > > Yes, I know I stick out like a sore thumb in these humble parts. > OK... Point taken. However... >>> BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like). > >> Good for you. Did you try proposing anything that was contrary to the current religion at the time or did you join >> the ivory tower biggots in supporting solutions that work better in theory than in operational reality and embrace >> their bold new failure to address major concerns (such as scalable routing) while focusing on irrelevant minutiae >> such as 8+8 vs. GSE? > > Judge for yourself: > > http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt > I'm sure that got reasonably well shouted down, but, it's close enough to a few pieces of IETF dogma that I suspect it probably didn't result in "fool, go home" style comments from too many places. > Let me wrap up this discussion with the following: > > IPv6 address configuration is a house of cards. Touch it and it all comes crashing down. DHCPv6 has a number of significant flaws, and the interaction between DHCPv6 and router advertisements only barely makes sense. All of this makes it seem like a good idea to tweak stuff to make it better, but in reality that's a mistake: it just means more opportunities for things to fail. What we need is to rethink the host configuration problem from the ground up, starting at the host and what it should do when it sees its interface come up. > I'm fine with that latter idea and it may well yield a better solution. However, in the operational world, we cannot wait for that and what we have today is not sufficiently adequate to meet real world requirements as they exist today. As such, we MUST modify what we have today in ways that extend it to have the capabilities that are required. I understand you find this distasteful. I even understand some of your reasons. I even agree with some of them. However, we do not have the option if we are to make IPv6 deployable in the enterprise of ignoring these requirements. These aren't situations that have existing workarounds and the administrators are simply opposed to doing things differently. These are situations where the fundamental operation of the network cannot be accomplished under IPv6 within the current organizational requirements. Asking organizations to restructure their networks is one thing. Asking them to also reorganize their organizational politics around that network restructuring is, well, "recipe for fail" seems like an understatement. > One model that seems attractive here is the on the iPhone uses, where you can modify the IP configuration on a per-wifi network basis. If we can apply this kind of logic to wired networks, too, then suddenly we're no longer limited to having one monolithic set of client side behavior that must always be followed, but we can be much more flexible. The real goal should be to have a way (or ways) for hosts to operate across a wide variety of environments with zeroconf. Having to build profiles for different networks is a great workaround for failures in that effort, but, it is not what I would call a good solution to the problem in general. Owen From owen at delong.com Mon Jun 13 19:26:27 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Jun 2011 17:26:27 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> Message-ID: On Jun 12, 2011, at 4:04 AM, Iljitsch van Beijnum wrote: > On 12 jun 2011, at 12:35, Daniel Roesen wrote: > >> Could you point to any RFC which implies or explicitly states that >> DHCPv6 MUST NOT be used in absence of RA with M and/or O=1? > > But what's the alternative? Always run DHCPv6 even if there are no router advertisements or router advertisements with O=0, M=0? > The alternative is as follows (can be done today without significant harm, only requires a couple of new DHCPv6 options and trivial changes to host DHCPv6 implementations): Interface is initialized. IPv6 is initialized on the interface. Interface builds link-local address. Link local DAD is performed (Failure: Shut down IPv6 on interface... Done.) Look for static configuration. If Found, Apply static configuration, end. Initialize Backoff Timer = 3 Initialize Tries = 0 LOOP A: Link Local->{All Routers,Link scope} Multicast ICMP RS packet is sent. Link Local->{All DHCP Servers, Link scope} Multicast DHCPv6 Solicit is sent Select(RA,DHCP while Backoff) Backoff*=1.5 if Backoff < 300 tries++ if (tries > 10 && !RA && !DHCP) Error, End repeat LOOP A if (!RA && !DHCP) if (RA) Process RA if (M || O) { if (DHCP) { Process DHCP as determined by {M,O} bits. End } LOOP B: DHCPv6 Solicit (as in Loop A) tries++ if (tries > 10 && !DHCP) Error, End repeat LOOP B if (!DHCP) process RA+DHCP according to M End } } if (DHCP) { # DHCP, but, no RA received LOOP C: Router Solicit (as in Loop A) tries++ repeat LOOP C if (tries < 5 && !RA) if (RA) { Process RA+DHCP according to {M,O} bits in RA. } else { Process DHCP as if RA received with no data and M bit } } } > Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. > I don't see how the above would do so. It's mostly compatible with what we have today and it would take a very very large number of hosts (generally in excess of most switches forwarding table capacities) to contribute significant network pollution. Additionally, the multicast rate would only be increased on hosts which had no static configuration and the network had no functional RA and/or DHCP services. > And networks without RAs are very common. We call those networks "IPv4-only networks". > Fair point. However, even in such a scenario, I don't believe that the traffic provided above (up to 20 multicast packets provided over 422 seconds worst case) would constitute the kind of problem you are describing. > And in the current situation DHCPv6 without router advertisements is pointless because you may get an address, but you have no place to send your packets. The point is that part of the solution needs to include adding routing information options to DHCPv6. That doesn't even require significant modification to the DHCP software, just definitions for new fields and a little bit of UI coding on the server and the ability to process the new options on the client. Owen From Kelly.Setzer at wnco.com Mon Jun 13 19:33:14 2011 From: Kelly.Setzer at wnco.com (Kelly Setzer) Date: Mon, 13 Jun 2011 19:33:14 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> <20110613012918.GA47336@ussenterprise.ufp.org> Message-ID: > -----Original Message----- > From: Jimmy Hess [mailto:mysidia at gmail.com] > Sent: Sunday, June 12, 2011 8:43 PM > To: nanog at nanog.org > Subject: Re: The stupidity of trying to "fix" DHCPv6 > > On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell wrote: > > DHCP today uses an exponential backoff if there is no response, I don't [snip] > This could have been (but was unfortunately not) mitigated in the v6 specs by > adding options to DHCPv4 to configure IPv6 address and gateway at the same > time IPv4 configuration is received, in lieu of using v6 based > protocols for config; [snip] I've observed that when the unwashed masses begin deploying new technologies, they have a terrible tendency to be disobedient, to change the rules, to revise specs. While the implementers implement and the operators operate, the professors profess to a quickly emptying lecture hall. I have great faith that the experienced and pragmatic people who have to work with IPv6 on a daily basis will resolve things like the DHCP6/RA imbroglio. IPv6 will be much different in a few years. As a host guy in an enterprise-type organization, I'm looking forward to what you and people like you will cook up. Kelly ******* CONFIDENTIALITY NOTICE ******* This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. From rzheng at gmail.com Mon Jun 13 19:37:21 2011 From: rzheng at gmail.com (Richard Zheng) Date: Mon, 13 Jun 2011 14:37:21 -1000 Subject: bgp feed to customer In-Reply-To: <00e301cc2a0c$170269b0$45073d10$@impactbusiness.com> References: <00e301cc2a0c$170269b0$45073d10$@impactbusiness.com> Message-ID: > > > Hi Richard, > Could you run a bgp session on Router B ? I had to do this once for > a customer because we had layer 3 switches on the edge with routing. I > configured 2 BGP sessions at the customer's router. The first session was > between Customer C and Router B. I only sent the default route to the > customer. The next session was ebgp multihop between Router A and Customer > C with full routing. I did allow the customer to announce the /30 to > Router B just so Router A could learn the return path or you could just > static route the /30 from Router A > > Now if the link Breaks between Router B and Customer C BGP will drop both > sessions. > > Thanks > Jim Gonzalez > > When Router A redistributes external routes to OSPF, it sets the next hop to itself. All the routers include Router B in the AS sends to traffic to Router A which sends to Router B and causes a loop. The root cause is the inability to set next-hop address for ospf route even though external routes have a 'forward address' field. It looks like that there are three solutions, (a), Router B talks EBGP with Router C and then redistribute to OSPF (b), Router B talks IBGP with Router A and then redistribute to OSPF, redistribution may not be necessary if you don't care traffic from other routers goes to Router A first, then to B and C. (c), Create a tunnel between Routers A and C so that A sends traffic to tunnel IP, instead router C Personally I prefer (b) because only one EBGP is required to the customer. I just need to figure out the IBGP config on Router A so that it only sends the customer routes instead of the whole table. Thanks, Richard From owen at delong.com Mon Jun 13 19:41:12 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Jun 2011 17:41:12 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> Message-ID: <377E4C6A-D179-4083-B3EF-5E71FE612113@delong.com> On Jun 12, 2011, at 11:12 AM, Iljitsch van Beijnum wrote: > On 12 jun 2011, at 15:45, Leo Bicknell wrote: > >>> Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. > >> Huh? This is no worse than IPv4 where a host comes up and sends a >> subnet-broadcast to get DHCP. > > The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing. > Which is no worse than the behavior of an IPv4 host on a network without a DHCP server. Owen From owen at delong.com Mon Jun 13 19:48:06 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Jun 2011 17:48:06 -0700 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> Message-ID: <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> The vastly better option is to obtain a prefix and ASN from ARIN and merely trade BGP with your upstream providers. Prefix translation comes with all the same disabilities that are present when you do this in IPv4. In IPv4, everyone's software expects you to have a broken network (NAT) and there is lots of extra code in all of the applications to work around this. In iPv6, it is not unlikely that this code will eventually get removed and you will then have a high level of application problems in your "prefix-translated" environment. Owen On Jun 12, 2011, at 11:46 AM, Randy Carpenter wrote: > Prefix translation looks to be exactly what we need to do here. Thanks for all of the replies. > > > -Randy > > On Jun 12, 2011, at 2:42, Seth Mos wrote: > >> >> Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven: >> >>> >>> I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines. >> >> So basically policy routing? >> >>> The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections. >> >> Yep that sounds like policy routing. >> >>> With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished? >> >> Sure there is NAT, you can use prefix translation to translate your Global Address Range from the redundant ISP to the Cable ISP Global address range when leaving that interface. I've run a similar setup with 3 independent ISPs with IPv6 netblocks. >> >> Whichever connection the traffic went out it got the right GUA mapped onto it. Note that this is 1:1 NAT and not N:1. >> >> In my case there was no primary GUA range, I used a ULA on the LAN side of things, and mapped the corresponding GUA onto it when leaving the network. I had 3 rules, 1 for each WAN and mapped the ULA/56 to the GUA/56. >> >> In your case you already have a primary connection of sorts, so I'd suggest using that on the LAN side and only map the other GUA onto it when it leaves the other interfaces. >> >> The policy routing rules on your firewall can make all the routing decissions for you. >> >> If you search google for "IPv6 network prefix translation" there will be a firewall listed that can do this somewhere in the middle of the page. >> >> Cheers, >> >> Seth >> From bicknell at ufp.org Mon Jun 13 19:54:53 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 13 Jun 2011 17:54:53 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <377E4C6A-D179-4083-B3EF-5E71FE612113@delong.com> References: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> <377E4C6A-D179-4083-B3EF-5E71FE612113@delong.com> Message-ID: <20110614005453.GA99359@ussenterprise.ufp.org> In a message written on Mon, Jun 13, 2011 at 05:41:12PM -0700, Owen DeLong wrote: > > The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing. > > > > Which is no worse than the behavior of an IPv4 host on a network without a DHCP server. I understand on some level why the IETF doesn't want DHCPv4 to be able to hand out IPv6 stuff, and doesn't want DHCPv6 to hand out IPv4 stuff. In the long run if you assume we transition to IPv6 and run only IPv6 for years after that it makes sense. However, I do think a single option is needed in both, "ProtocolsAvailable". Today it could have "4" or "6", or "4,6". In the future, who knows. The idea being if I am a dual stacked host and I do DHCPv4 and get back that only 4 is available, I might stop doing DHCPv6 or at least make my exponential backoff even more exponential. Similarly, if I get back "4,6", I might know to immediately try the other protocol as well. This would allow end stations to greatly optimize their behavior at all stages of deployment. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From rcarpen at network1.net Mon Jun 13 19:59:12 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 13 Jun 2011 20:59:12 -0400 (EDT) Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: <51465417-c720-4212-b779-c55e0b682f50@zimbra.network1.net> ----- Original Message ----- > The vastly better option is to obtain a prefix and ASN from ARIN and > merely trade BGP with your > upstream providers. This is precisely what we are doing on the main network. We just want to keep the general browsing traffic separated. > Prefix translation comes with all the same disabilities that are > present when you do this in IPv4. > > In IPv4, everyone's software expects you to have a broken network > (NAT) and there is lots of extra > code in all of the applications to work around this. > > In iPv6, it is not unlikely that this code will eventually get > removed and you will then have a high > level of application problems in your "prefix-translated" > environment. I am hoping that this will eventually become a moot point for this particular installation, but as it is, the cable modem is $50/month for 15 Mb/s, and adding 15 Mb/s to the main network would cost around $3,000/month. It is really hard to justify. If we could BGP via the cable modem, that would be great, but they won't allow it :) -Randy From Kelly.Setzer at wnco.com Mon Jun 13 20:17:57 2011 From: Kelly.Setzer at wnco.com (Kelly Setzer) Date: Mon, 13 Jun 2011 20:17:57 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110614005453.GA99359@ussenterprise.ufp.org> References: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> <377E4C6A-D179-4083-B3EF-5E71FE612113@delong.com> <20110614005453.GA99359@ussenterprise.ufp.org> Message-ID: > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Monday, June 13, 2011 7:55 PM > To: nanog at nanog.org > Subject: Re: The stupidity of trying to "fix" DHCPv6 > [snip] > I understand on some level why the IETF doesn't want DHCPv4 to be able to hand > out IPv6 stuff, and doesn't want DHCPv6 to hand out > IPv4 stuff. In the long run if you assume we transition to IPv6 and run only > IPv6 for years after that it makes sense. > > However, I do think a single option is needed in both, "ProtocolsAvailable". > Today it could have "4" or "6", or "4,6". [snip] DNS is "two-legged". DNS and DHCP are so intertwined from an operational perspective, I don't see how we'll get through this without DHCP becoming two-legged. > This would allow end stations to greatly optimize their behavior at all stages > of deployment. +1 Kelly ******* CONFIDENTIALITY NOTICE ******* This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. From jmaslak at antelope.net Mon Jun 13 21:04:41 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Mon, 13 Jun 2011 20:04:41 -0600 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <51465417-c720-4212-b779-c55e0b682f50@zimbra.network1.net> References: <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> <51465417-c720-4212-b779-c55e0b682f50@zimbra.network1.net> Message-ID: On Mon, Jun 13, 2011 at 6:59 PM, Randy Carpenter wrote: This is precisely what we are doing on the main network. We just want to > keep the general browsing traffic separated. > If you're worried about browsing traffic and not worried about occasional other things slipping through, set up Squid and WPAD on your network. Direct all general internet stuff (via WPAD) out the cheap connection, the business-critical traffic through the other traffic. Now things that don't listen to the WPAD configuration (basically anything but PC and Mac browsers) will go out your expensive connection. But it sounds like a little bit of leakage wouldn't be a huge problem. You could get a bit fancier and run DNS on the proxy server, so that the proxy uses itself for DNS resolution rather than the corporate DNS. That would let you do basic browsing while the corporate WAN is down. The proxy would be the only box on the cable modem segment. It would also need an interface on some internal LAN segment. Default route on it would be via the cable modem, with routes to everything internal on the internal interface. Make sure you set the cable modem IP as Squid's outbound IP, and make sure your WPAD file doesn't use this proxy for anything internal. Everything else inside the network would have a default route pointing at the corporate WAN and wouldn't know anything about the cable segment. The nice thing about this setup is that you don't have any address translation going on and only one IP per host. You can replace Squid with the proxy of your choice, doing as much or as little caching as you want to do (and other things if desired, like virus scanning, deep packet inspection, or content filtering - if your policy requires it). Make sure you talk to your legal and/or HR about what logs should be kept or removed from the proxy. You may also want to repress X-Forwarded-For headers to keep your internal network addressing hidden while browsing. Also remember to make sure the proxy is secure enough to trust as a firewall for your corporation - or put it behind a firewall that is secure enough. From owen at delong.com Mon Jun 13 21:24:34 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Jun 2011 19:24:34 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> <20110613012918.GA47336@ussenterprise.ufp.org> Message-ID: <67223B3E-6EDC-498A-B066-0A7CD90BC237@delong.com> On Jun 12, 2011, at 6:42 PM, Jimmy Hess wrote: > On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell wrote: >> DHCP today uses an exponential backoff if there is no response, I don't >> see why that can't be kept in IPv6. Plus I wonder how long users would >> keep on machines that get no useable network connectivity. >> >> I really think the number of broadcast packets is a total non-issue. > > Rather than deem it a non-issue; I would say The impact of broadcast packets > depends on the network they are transmitted over. > If you have a Layer 2 domain with 50000 hosts on it; the number of per-host > broadcast packets will be much more important than if you have a broadcast > domain with 1000 hosts. > If you have a layer 2 domain with 50,000 hosts on it, you probably did something very wrong in your network design to begin with. Likely you already have issues with forwarding table exhaustion on your L2 switching infrastructure. > This could have been (but was unfortunately not) mitigated in the v6 specs by > adding options to DHCPv4 to configure IPv6 address and gateway at the same > time IPv4 configuration is received, in lieu of using v6 based > protocols for config; > Doing so would have created a situation where it was virtually impossible to run IPv6 without IPv4. Clearly not a desirable outcome. > Requiring configuration to be grabbed _two_ times per host is inefficient -- ONE > DHCP discovery for every host on the LAN (either RA+DHCPv6 or DHCPv4) would > be more efficient. > Only if you assume that the world will never move beyond dual-stack to IPv6 monostack. This is an inherently bad assumption for a variety of reasons. What you are asking would be akin to asking for a DHCPv4 option to hand out IPX and Appletalk addresses too. It doesn't make sense for a wide variety of reasons even though you are correct that for a very narrow set of cases, it could provide a slight increase in efficiency. > If v6 hosts are dual stack, and v4 information is already pulled from > DHCP.... how much > sense does it really make to need a second discovery process to find a v6 server > to config the host, particularly when there exists possibility of > conflicting options; DHCP > can config some non-interface-specific things such as time zone, hostname, etc. > Just like v4 hosts, there are two classes of v6 hosts. Dual stack and mono-stack. The difference is that today, v4 mono-stack is much more common than v4 dual-stack and v6 dual-stack is much more common than v6 mono-stack. There will come a day (possibly many years from now) where v6 mono-stack will be more common than v6 dual-stack. > > There is a potential for greater issues on networks where the number > of broadcasts > may not have been an issue for IPv4; the IPv6 broadcast messages > have a larger > payload, because there are 96 more bits in an IPv6 address than an > IPv4 address. Unlikely that this would become a significant issue in the real world. The low frequency of requests, exponential backoff, and relatively small number of likely simultaneously affected hosts all add up to a very very low probability of significant bandwidth being used in this process. It's not like anyone does DHCP on a DS0. > The broadcasts for configuring IPv6 are incurred _on top_ of the broadcasts > already existing for IPv4 on a dual stack network, since IPv6 hosts > still have to config > IPv4 simultaneously. > Only if they need IPv4. Also, remember, the IPv6 packets aren't broadcasts. They are multicast and would go to the IPv6 All DHCP Servers Multicast group, not the All Nodes multicast group. Owen From bill at herrin.us Mon Jun 13 23:28:51 2011 From: bill at herrin.us (William Herrin) Date: Tue, 14 Jun 2011 00:28:51 -0400 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong wrote: > The vastly better option is to obtain a prefix and ASN from ARIN and merely trade BGP with your > upstream providers. My "(cheap) cable modem for general browsing" provider wouldn't even delegate RDNS; they'd only put PTRs in *their* servers. Swap BGP routes with them? Swell dream. This has become a common strategy: the cheap, fast, commodity service for the most-of-the-time that it's working and the most-of-the-stuff that it works for combined with the expensive and slow but reliable and full featured service for the mission critical apps. One of these isn't going to come with BGP and a PI prefix, and the technologies we deploy are going to have to deal with that. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From don at bowenvale.co.nz Tue Jun 14 01:59:41 2011 From: don at bowenvale.co.nz (Don Gould) Date: Tue, 14 Jun 2011 18:59:41 +1200 Subject: Yup; the Internet is screwed up. In-Reply-To: <4DF640D8.7090903@rollernet.us> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <20110611100024.GT13108@hezmatt.org> <4DF3EA1C.1060708@mompl.net> <4DF48549.1090501@bowenvale.co.nz> <4DF640D8.7090903@rollernet.us> Message-ID: <4DF706DD.7000007@bowenvale.co.nz> * 2.5GPON isn't symmetric. * DSL and cable can be symmetric. * Business reasons - providers don't want you hosting content at home, they want you hosting content in their data centers so they can charge for that space. So when a provider gets a 100/100 from a telco, it uses 90/10 dl to feed it's tails and 10/90 to push content back to the net of its server array. D On 14/06/2011 4:54 a.m., Seth Mattinen wrote: > On 6/12/11 2:22 AM, Don Gould wrote: >> 100mbit is not luxury, it's something my business needs all it's >> customers to have to drive more uptake of my services. >> >> My customers already have 10/1 today. Now I need them to have 100/40 so >> they have a reason to buy other CPE that in turn drives my business. >> > > I have to ask, why not just give them symmetric speeds? I understand > there are technical reasons why on DSL and cable you end up with > asymmetric, but those don't apply to Ethernet delivery. > > ~Seth > -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From owen at delong.com Tue Jun 14 03:00:22 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 01:00:22 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> Message-ID: <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> On Jun 13, 2011, at 12:50 PM, Ricky Beam wrote: > On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell wrote: >> In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van Beijnum wrote: >>> Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. >> >> Huh? This is no worse than IPv4 where a host comes up and sends a >> subnet-broadcast to get DHCP. > > Broadcast != Multicast. esp. when talking about wireless chipsets. I've yet to find a wifi chipset that didn't completely fuck-up when presented with even a low pps of multicast traffic. Broadcast traffic doesn't seem to bother them -- it doesn't attempt to filter them in any way, or really pay them any attention. If I had to guess, the chip firmware is individually transmitting multicast packets to each peer; a broadcast packet is sent once to all peers. > > I've not had any wireless networks disrupted by broadcast traffic -- and with Radware load balancers in the network, there are *plenty* of broadcasts (ARP). Just a few 100pps of multicast and the AP fails. (linksys, netgear, even cisco... all broadcom crap radios.) > > --Ricky You would need an AWFUL lot of hosts for this to add up to a few 100pps (or even 10pps) of multicast traffic. Owen From santino.codispoti at gmail.com Tue Jun 14 03:12:07 2011 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Tue, 14 Jun 2011 04:12:07 -0400 Subject: AUS? Message-ID: Is there a nanogish group that covers AUS? From surfer at mauigateway.com Tue Jun 14 03:17:25 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 14 Jun 2011 01:17:25 -0700 Subject: AUS? Message-ID: <20110614011725.4F21B96F@resin04.mta.everyone.net> --- santino.codispoti at gmail.com wrote: From: Santino Codispoti Is there a nanogish group that covers AUS? ---------------------------------- First hit on a search engine: "australia network operator group". www.ausnog.net scott From swmike at swm.pp.se Tue Jun 14 03:20:07 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 14 Jun 2011 10:20:07 +0200 (CEST) Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: On Tue, 14 Jun 2011, Owen DeLong wrote: > You would need an AWFUL lot of hosts for this to add up to a few 100pps > (or even 10pps) of multicast traffic. On the AMSIX peering LAN there is more than 100pps of ND traffic (at least there was when we checked). Since they do not do IPv6 multicast intelligent handling (MLD snooping I guess) certain highend (legacy) router platforms run into trouble because all these packets are punted to RP. Implementing access list that filtered all multicast traffic the linecard didn't actually subscribe to, solved the problem. From owen at delong.com Tue Jun 14 03:34:03 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 01:34:03 -0700 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: <38C64331-0152-4426-B809-DB8F85D62C45@delong.com> On Jun 13, 2011, at 9:28 PM, William Herrin wrote: > On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong wrote: >> The vastly better option is to obtain a prefix and ASN from ARIN and merely trade BGP with your >> upstream providers. > > My "(cheap) cable modem for general browsing" provider wouldn't even > delegate RDNS; they'd only put PTRs in *their* servers. Swap BGP > routes with them? Swell dream. > Or work around it with a free tunnel to a nearby tunnel service that does support BGP and will give you a /48. > This has become a common strategy: the cheap, fast, commodity service > for the most-of-the-time that it's working and the most-of-the-stuff > that it works for combined with the expensive and slow but reliable > and full featured service for the mission critical apps. One of these > isn't going to come with BGP and a PI prefix, and the technologies we > deploy are going to have to deal with that. > Yep. For IPv6, there are options. Owen From owen at delong.com Tue Jun 14 03:41:06 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 01:41:06 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: On Jun 14, 2011, at 1:20 AM, Mikael Abrahamsson wrote: > On Tue, 14 Jun 2011, Owen DeLong wrote: > >> You would need an AWFUL lot of hosts for this to add up to a few 100pps (or even 10pps) of multicast traffic. > > On the AMSIX peering LAN there is more than 100pps of ND traffic (at least there was when we checked). Since they do not do IPv6 multicast intelligent handling (MLD snooping I guess) certain highend (legacy) router platforms run into trouble because all these packets are punted to RP. > > Implementing access list that filtered all multicast traffic the linecard didn't actually subscribe to, solved the problem. ND would be a far more frequent occurrence than DHCP requests. Also, I tend to doubt that ANYONE would do DHCP on an exchange point network, so, it's not exactly an applicable example environment. Owen From swmike at swm.pp.se Tue Jun 14 03:48:23 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 14 Jun 2011 10:48:23 +0200 (CEST) Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: On Tue, 14 Jun 2011, Owen DeLong wrote: > ND would be a far more frequent occurrence than DHCP requests. Of course, it was only partly related to the discussion, most likely the network which has problem with multicast would break first because of ND, not because of DHCPv6 requests. > Also, I tend to doubt that ANYONE would do DHCP on an exchange point > network, so, it's not exactly an applicable example environment. It's the largest IPv6 enabled L2 domain I've experienced :P -- Mikael Abrahamsson email: swmike at swm.pp.se From bicknell at ufp.org Tue Jun 14 07:01:21 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 14 Jun 2011 05:01:21 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: <20110614120121.GA24168@ussenterprise.ufp.org> In a message written on Tue, Jun 14, 2011 at 10:20:07AM +0200, Mikael Abrahamsson wrote: > On the AMSIX peering LAN there is more than 100pps of ND traffic (at least > there was when we checked). Since they do not do IPv6 multicast > intelligent handling (MLD snooping I guess) certain highend (legacy) > router platforms run into trouble because all these packets are punted to > RP. Note that an exchange point LAN is a bit of an odd duck. RA's are supposed to be disabled. There is no DHCP. Rather, the ND behavior is casued by people statically configuring BGP sessions and then a participant leaving. So ND (or even ARP) tries over and over to find the missing participant. The thing to investigate here is if ND rate limiting is implemented correctly by the vendors involved, similar to ARP rate limiting. I'm not sure if there are standards requirements that could be in play as well. I'm not sure this has anything to do with the RA/DHCP issues... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jasongurtz at npumail.com Tue Jun 14 08:17:39 2011 From: jasongurtz at npumail.com (Jason Gurtz) Date: Tue, 14 Jun 2011 09:17:39 -0400 Subject: Is a postmaster from csod.com/cornerstoneondemand.com present? Message-ID: la4prd4.mx.csod.com seems to be having trouble saying helo/ehlo and disconnects after our welcome banner Users think we're blocking training registration emails from your large wholesale energy customer in the N.E. area; we're not. Please get in touch. 860.823.4118 if email fails. ~JasonG From iljitsch at muada.com Tue Jun 14 09:01:25 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 14 Jun 2011 16:01:25 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: On 14 jun 2011, at 10:20, Mikael Abrahamsson wrote: > On the AMSIX peering LAN there is more than 100pps of ND traffic (at least there was when we checked). Since they do not do IPv6 multicast intelligent handling (MLD snooping I guess) certain highend (legacy) router platforms run into trouble because all these packets are punted to RP. That is really pathetic. I thought that any Ethernet chip built the previous decade could filter 64 or so multicast addresses in hardware. Only when you're subscribed to more multicast groups than what your Ethernet chip can filter in hardware does the software for an IPv4-only system have to encounter IPv6 multicasts, or an IPv6 system random neighbor solicitations, which are load balanced over a wide range of multicast addresses just for this reason. Also strange that there would be this much neighbor discovery traffic, probably the same reason AMS-IX used to have 15 kbps of ARP traffic: stale BGP peerings to addresses that no longer exist. From jra at baylink.com Tue Jun 14 09:18:39 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 14 Jun 2011 10:18:39 -0400 (EDT) Subject: AUS? In-Reply-To: Message-ID: <33498675.268.1308061119568.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Santino Codispoti" > Is there a nanogish group that covers AUS? As it happens, we have a page *just* for this list at outages.org... and Oz is, as you might expect, the first item on the list: http://www.outages.org/index.php/Network_ops_group_websites Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From rps at maine.edu Tue Jun 14 10:12:08 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 14 Jun 2011 11:12:08 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <4DF26EB7.70502@netwolves.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> Message-ID: Wow, I don't recall making it personal? I have broken networks before by connecting miss-configured devices, by the way, and I was a moron for doing so. I don't base my network design decisions around preventing people with full access to configure the network breaking it; but rather restrict the level of access people have and impingement sane policies on when and how changes are made; like most of the people on this list. The point was you shouldn't base protocol design around the possibility that someone might tell it to do something you don't want it to do; otherwise you'll end up with a one-size-fits-all protocol that has zero flexibility (and might not even be functional at all). Similar problems existed in IPv4; but over time networks evolved and better protection methods became available. The days of the dumb switch are over; and at the price and performance of today's switches we should expect features like RA guard and MLD snooping to be standard. We threw out Ethernet hubs a decade or two ago for good reason, and there was resistance then too. On a side note, if you're going to resort to direct personal attacks, maybe you shouldn't be doing so while representing your company. Everything on NANOG is archived and sticks around for a very, very long time. Ray On Fri, Jun 10, 2011 at 3:21 PM, Steve Clark wrote: > On 06/10/2011 09:37 AM, Ray Soucy wrote: > > You really didn't just write an entire post saying that RA is bad > because if a moron of a network engineer plugs an incorrectly > configured device into a production network it may cause problems, did > you? > > > You are the moron - this stuff happens and wishing it didn't doesn't stop > it. Get a clue! > > Honestly. This whole argument is getting ridiculous. > > On Fri, Jun 10, 2011 at 9:32 AM, Leo Bicknell wrote: > > In a message written on Fri, Jun 10, 2011 at 01:03:01PM +0000, Bjoern A. > Zeeb wrote: > > On Jun 10, 2011, at 10:10 AM, sthaug at nethelp.no wrote: > > Several large operators have said, repeatedly, that they want to use > DHCPv6 without RA. I disagree that this is stupid. > > I wonder if it's just a "violation" of rule #1: stop thinking legacy! > > People are used to what they have done for a decade or two. ?It's hard to > see the change and results in "why is this all so different and > complicated?". > It's hard to open ones mind for the new, but it is essential to do with new > technology. > > The problem in this case is that the failure modes are significantly > different. ?Some folks have learned this the hard way. > > It's a very easy scenario to reconstruct. ?Consider the "branch > office router" in a typical corporate enviornment. ?We're talking > a device with one WAN port, and one LAN port. ?Configure it for > dual stack, speaking IPv4, and in IPv4 configure it the typical > corporate way with a "DHCP Helper" forwarding requests over the WAN > to a central DHCP server. ?In IPv6, configure it with RA's, the > supposed "better" way. > > Now, take the 100% working branch router and have it sent back to > corporate. ?Maybe they got a bigger router, maybe the office closed. > A network engineer gets the router and is tasked with making it > ready to redeploy. > > The network engineer plugs it into the switch on his desktop, plugs in a > serial cable, turns it on and steps out to get a coffee while it boots. > He's planning to erase the configuration and then load new software over > the network. > > As soon as the router boots the IPv6 network fails for all the users on > his subnet. ?IPv4 keeps working fine. > > Oops. > > What happened? ?Well, the router sent IPv6 RA's as soon as it came > up, and every workstation instantly started using them. ?In IPv4, > the router received DHCPv4 requests and forwarded them per the > helper address, except that its WAN port is down, and thus it in > fact didn't send them anywhere. > > The important points: > > - IPv4 "failed safe" with the DHCP config. ?This "rogue device" will > ?never disrupt the IPv4 configuration. ?DHCP snooping isn't even needed > ?in your switches, since it never returns a response. > > - IPv6 "failed immediately" with the RA configuration. ?What's worse is > ?if you simply turn the device off after you realized you took down the > ?entire network devices will continue to be broken for 2-4 hours until > ?the RA's time out. ?The only method to mitigate is to deploy RA guard > ?on all of your switches, which probably means replacing 100% of your > ?hardware with new stuff that can do that, and then deploying new > ?features. > > The fact of the matter is that the failure modes of these two > protocols are vastly different operationally. ?The DHCP failure > semantics are not only better understood, but cause less disruption > to the network. ?Even a properly rouge DHCP server will only damage > _new_ clients coming up on a network, existing folks will work just > fine. ?Contrast with RA's which instantly break 100% of the users. > > Even more annoying is that if I use RA's for the default gateway, > I still have to run DHCPv6 anyway. ?If I don't my boxes don't have > DNS servers, NTP servers, know where to tftpboot, etc. ?It's not a > choice of one or the other, it's I always run DHCPv6, do I need > RA's or not. > > Given the failure modes I would much prefer to run with RA's turned off > completely, and have DHCPv6 able to provide a default gateway just as it > works in IPv4. > > My opinion comes not from "thinking legacy", indeed my employer has been > fully dual stacked since 2003. ?My opinion comes from the fact that in > the 8 years of operational experience we have RA's are significantly > more fragile, and IMHO not ready for widespread IPv6 deployment. > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > > > > > > -- > Stephen?Clark > NetWolves > Sr.?Software?Engineer?III > Phone:?813-579-3200 > Fax:?813-882-0209 > Email:?steve.clark at netwolves.com > http://www.netwolves.com > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Tue Jun 14 11:02:18 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 09:02:18 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: On Jun 14, 2011, at 1:48 AM, Mikael Abrahamsson wrote: > On Tue, 14 Jun 2011, Owen DeLong wrote: > >> ND would be a far more frequent occurrence than DHCP requests. > > Of course, it was only partly related to the discussion, most likely the network which has problem with multicast would break first because of ND, not because of DHCPv6 requests. > >> Also, I tend to doubt that ANYONE would do DHCP on an exchange point network, so, it's not exactly an applicable example environment. > > It's the largest IPv6 enabled L2 domain I've experienced :P > Indeed, it tends to be a perversely large L2 domain, but, not one where DHCP would likely occur. That was kind of my point. You are unlikely to encounter such a large L2 domain outside of an exchange point. Owen From nick at foobar.org Tue Jun 14 11:15:34 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 14 Jun 2011 17:15:34 +0100 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> Message-ID: <4DF78926.6080209@foobar.org> On 14/06/2011 16:12, Ray Soucy wrote: > The point was you shouldn't base protocol design around the > possibility that someone might tell it to do something you don't want > it to do; otherwise you'll end up with a one-size-fits-all protocol > that has zero flexibility (and might not even be functional at all). sensible engineering dictates that design should aim to be fail-safe. I.e. not "failsafe" in the common usage of the term (= doesn't fail), but rather cogniscent of the fact that all systems fail from time to time, and when they do, they ought to fail in such a way that the collateral damage is minimised. This principal is recodified in various ways ("be liberal in what you accept", etc), but the underlying idea is the same. In IPv6-land, we appear not to have learned the lessons from ipv4 history, and our vendors aren't yet shipping switches with native RA- and DHCPv6- guard (yes, there are some exceptions to the former). Nick From nick at foobar.org Tue Jun 14 11:18:17 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 14 Jun 2011 17:18:17 +0100 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: <4DF789C9.8090500@foobar.org> On 14/06/2011 17:02, Owen DeLong wrote: > That was kind of my point. You are unlikely to encounter such a large L2 domain outside of an > exchange point. Indeed so. Apart from large enterprise LANs. And campus LANs. And badly designed large service provider LANs. And other types of large L2 domains. But apart from those exceptions, you'll never see large L2 domains outside of an IXP. Nick From rps at maine.edu Tue Jun 14 11:41:46 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 14 Jun 2011 12:41:46 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <4DF78926.6080209@foobar.org> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> Message-ID: The energy in this thread should be focused on switch vendors to actually implement L2 security features for IPv6, which is usually an easy upgrade; rather than calling for all host implementations of IPv6 to work differently; which will take a decade to implement and be a band-aid at best; not a good long-term design for the protocol. I think that was the original spirit of this thread. Full static assignment is always an option if you don't want to use RA or DHCPv6. Presenting suggestions in the form of an RFC draft would be more useful than ranting about it for the 100th time on-list. At least then you could point to something that can actually be worked on constructively; rather than a lot of straw-man arguments because you don't personally like the way things are currently done. If you get a bad DHCP server on the network it can take hours to undo the damage thanks to lease times; if you get bad RA you can usually fix the problem as soon as you find it. Apples and Oranges, really. If connecting the rogue DHCP server doesn't obviously break things when connected, you might not even notice it until it's too late. More responsive to change is better in my opinion. I hate having to wait hours or days for changes to propagate; it feels like the 1990s, or the days of mainframes and batch jobs. On Tue, Jun 14, 2011 at 12:15 PM, Nick Hilliard wrote: > On 14/06/2011 16:12, Ray Soucy wrote: >> >> The point was you shouldn't base protocol design around the >> possibility that someone might tell it to do something you don't want >> it to do; otherwise you'll end up with a one-size-fits-all protocol >> that has zero flexibility (and might not even be functional at all). > > sensible engineering dictates that design should aim to be fail-safe. ?I.e. > not "failsafe" in the common usage of the term (= doesn't fail), but rather > cogniscent of the fact that all systems fail from time to time, and when > they do, they ought to fail in such a way that the collateral damage is > minimised. ?This principal is recodified in various ways ("be liberal in > what you accept", etc), but the underlying idea is the same. > > In IPv6-land, we appear not to have learned the lessons from ipv4 history, > and our vendors aren't yet shipping switches with native RA- and DHCPv6- > guard (yes, there are some exceptions to the former). > > Nick > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From alvarezp at alvarezp.ods.org Tue Jun 14 11:44:14 2011 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Tue, 14 Jun 2011 09:44:14 -0700 Subject: IPv6 - a noobs prespective In-Reply-To: References: Message-ID: On Wed, 09 Feb 2011 03:00:27 -0800, Robert Lusby wrote: > I am however *terrified* of making that move. There is so many new > phrases, words, things to think about etc You fears will significantly lower after you set up a separate lab and play with it. With something as simple as a switch you can make a simple IPv6-only network. Try to replicate your current network in the lab as far as you can, using the "new" concepts and techniques and understand the current state of the art (read that as RA+DHCPv6, etc.) Get your pings right. This will automatically get you to dual-stacking, as in "how do I make both protocols work in the same physical network?". They just do. At this point the problem stops belonging to the network infrastructure and it passes on to the application servers and hosts. (And ask your ISP to support IPv6). Good luck. -- Octavio. From rps at maine.edu Tue Jun 14 12:04:11 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 14 Jun 2011 13:04:11 -0400 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: Today you're probably correct. If you want to have more than one provider reliably you pretty much need to be doing BGP; or have some sort of primary-backup setup to fail over from one to the other; or give each host a global address from each provider (really not desirable in the majority of networks). I think in the long term telling everyone to jump into the BGP table is not sustainable; and not operationally consistent with the majority of SMB networks. A better solution; and the one I think that will be adopted in the long term as soon as vendors come into the fold, is to swap out RFC1918 with ULA addressing, and swap out PAT with NPT; then use policy routing to handle load balancing and failover the way most "dual WAN" multifunction firewalls do today. Example: Each provider provides a 48-bit prefix; Internally you use a ULA prefix; and setup prefix translation so that the prefix gets swapped appropriately for each uplink interface. This provides the benefits of "NAT" used today; without the drawback of having to do funky port rewriting and restricting incoming traffic to mapped assignments or UPnP. The firewall keeps track of if a connection is up or down and keeps policy routing up to date; You can choose to set it up to either load balance per-flow or as a primary and backup interface. You can handle DNS by using RFC 2136 updates for a sub-domain with a short TTL on a hosted server to keep names up to date in the event of a link drop. This doesn't require cooperation from the provider; it doesn't require knowledge of routing protocols; and it is easy to understand for people used to the "NAT" environment. Last time I checked, Linux still needs some work to handle ECMP routing for IPv6, but once that is in place; combined with patches for Network Prefix Translation (NPT), it should be trivial to implement. My guess is within the next year we'll see something pop up that does this. Ray On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong wrote: > The vastly better option is to obtain a prefix and ASN from ARIN and merely trade BGP with your > upstream providers. > > Prefix translation comes with all the same disabilities that are present when you do this in IPv4. > > In IPv4, everyone's software expects you to have a broken network (NAT) and there is lots of extra > code in all of the applications to work around this. > > In iPv6, it is not unlikely that this code will eventually get removed and you will then have a high > level of application problems in your "prefix-translated" environment. > > Owen > > On Jun 12, 2011, at 11:46 AM, Randy Carpenter wrote: > >> Prefix translation looks to be exactly what we need to do here. Thanks for all of the replies. >> >> >> -Randy >> >> On Jun 12, 2011, at 2:42, Seth Mos wrote: >> >>> >>> Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven: >>> >>>> >>>> I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines. >>> >>> So basically policy routing? >>> >>>> The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections. >>> >>> Yep that sounds like policy routing. >>> >>>> With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished? >>> >>> Sure there is NAT, you can use prefix translation to translate your Global Address Range from the redundant ISP to the Cable ISP Global address range when leaving that interface. I've run a similar setup with 3 independent ISPs with IPv6 netblocks. >>> >>> Whichever connection the traffic went out it got the right GUA mapped onto it. Note that this is 1:1 NAT and not N:1. >>> >>> In my case there was no primary GUA range, I used a ULA on the LAN side of things, and mapped the corresponding GUA onto it when leaving the network. I had 3 rules, 1 for each WAN and mapped the ULA/56 to the GUA/56. >>> >>> In your case you already have a primary connection of sorts, so I'd suggest using that on the LAN side and only map the other GUA onto it when it leaves the other interfaces. >>> >>> The policy routing rules on your firewall can make all the routing decissions for you. >>> >>> If you search google for "IPv6 network prefix translation" there will be a firewall listed that can do this somewhere in the middle of the page. >>> >>> Cheers, >>> >>> Seth >>> > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From bill at herrin.us Tue Jun 14 12:28:28 2011 From: bill at herrin.us (William Herrin) Date: Tue, 14 Jun 2011 13:28:28 -0400 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: On Tue, Jun 14, 2011 at 1:04 PM, Ray Soucy wrote: > I think in the long term telling everyone to jump into the BGP table > is not sustainable; and not operationally consistent with the majority > of SMB networks. > > A better solution; and the one I think that will be adopted in the > long term as soon as vendors come into the fold, is to swap out > RFC1918 with ULA addressing, and swap out PAT with NPT; then use > policy routing to handle load balancing and failover the way most > "dual WAN" multifunction firewalls do today. > > Example: > > Each provider provides a 48-bit prefix; > > Internally you use a ULA prefix; and setup prefix translation so that > the prefix gets swapped appropriately for each uplink interface. ?This > provides the benefits of "NAT" used today; without the drawback of > having to do funky port rewriting and restricting incoming traffic to > mapped assignments or UPnP. Hi Ray, There's a nuance here you've missed. There are two main reasons for ULA inside the network: 1. Address stability (simplifies network management) 2. Source obfuscation (improves the depth of the security plan) Option 1: Obfuscation desired. ULA inside. NAT/PAT at both borders. You don't use prefix translation here because prefix translation does little obfuscation: it has a 1:1 relationship with each individual host and still reveals the internal routing structure. Option 2: Stability, no obfuscation desired. ULA inside, prefix translation at both borders. Option 3: Neither stability nor obfuscation required. GUA from one of the providers inside. Prefix translation to the other provider for the connections desired out that border. Giving the hosts real GUA addresses maximizes application compatibility. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rps at maine.edu Tue Jun 14 12:34:26 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 14 Jun 2011 13:34:26 -0400 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: I try to avoid the Obfuscation argument when I can. I've seen people try to be smart by telling Law Enforcement that they don't keep logs and can't point to which host was a problem behind a NAT box, only to see Law Enforcement take all the PCs instead of the one in question. So it's always made me nervous. As for the security value; I think it's more a privacy value than anything. But you can accomplish almost the same thing by having those hosts use a web proxy; which you likely want to be doing anyway so you can scan content for threats. I personally have no desire for it; but if someone wants to implement it I won't stop them. On Tue, Jun 14, 2011 at 1:28 PM, William Herrin wrote: > On Tue, Jun 14, 2011 at 1:04 PM, Ray Soucy wrote: >> I think in the long term telling everyone to jump into the BGP table >> is not sustainable; and not operationally consistent with the majority >> of SMB networks. >> >> A better solution; and the one I think that will be adopted in the >> long term as soon as vendors come into the fold, is to swap out >> RFC1918 with ULA addressing, and swap out PAT with NPT; then use >> policy routing to handle load balancing and failover the way most >> "dual WAN" multifunction firewalls do today. >> >> Example: >> >> Each provider provides a 48-bit prefix; >> >> Internally you use a ULA prefix; and setup prefix translation so that >> the prefix gets swapped appropriately for each uplink interface. ?This >> provides the benefits of "NAT" used today; without the drawback of >> having to do funky port rewriting and restricting incoming traffic to >> mapped assignments or UPnP. > > Hi Ray, > > There's a nuance here you've missed. > > There are two main reasons for ULA inside the network: > > 1. Address stability (simplifies network management) > 2. Source obfuscation (improves the depth of the security plan) > > Option 1: Obfuscation desired. > > ULA inside. NAT/PAT at both borders. You don't use prefix translation > here because prefix translation does little obfuscation: it has a 1:1 > relationship with each individual host and still reveals the internal > routing structure. > > Option 2: Stability, no obfuscation desired. > > ULA inside, prefix translation at both borders. > > Option 3: Neither stability nor obfuscation required. > > GUA from one of the providers inside. Prefix translation to the other > provider for the connections desired out that border. Giving the hosts > real GUA addresses maximizes application compatibility. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Tue Jun 14 12:36:39 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 10:36:39 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <4DF789C9.8090500@foobar.org> References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> <4DF789C9.8090500@foobar.org> Message-ID: On Jun 14, 2011, at 9:18 AM, Nick Hilliard wrote: > On 14/06/2011 17:02, Owen DeLong wrote: >> That was kind of my point. You are unlikely to encounter such a large L2 domain outside of an >> exchange point. > > Indeed so. Apart from large enterprise LANs. And campus LANs. And badly designed large service provider LANs. And other types of large L2 domains. But apart from those exceptions, you'll never see large L2 domains outside of an IXP. > > Nick Even on large enterprise LANS, campus LANs, and badly designed large service provider LANs, you don't tend to have the kind of perversely large L2 environment that is present at AMSIX. Also, as was pointed out, they have a rather unique situation of stale peering sessions continuously banging away at ND and ARP. Owen From Valdis.Kletnieks at vt.edu Tue Jun 14 12:38:27 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 14 Jun 2011 13:38:27 -0400 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: Your message of "Tue, 14 Jun 2011 13:04:11 EDT." References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: <23751.1308073107@turing-police.cc.vt.edu> On Tue, 14 Jun 2011 13:04:11 EDT, Ray Soucy said: > A better solution; and the one I think that will be adopted in the > long term as soon as vendors come into the fold, is to swap out > RFC1918 with ULA addressing, and swap out PAT with NPT; then use > policy routing to handle load balancing and failover the way most > "dual WAN" multifunction firewalls do today. > > Example: > > Each provider provides a 48-bit prefix; > > Internally you use a ULA prefix; and setup prefix translation so that > the prefix gets swapped appropriately for each uplink interface. This > provides the benefits of "NAT" used today; without the drawback of > having to do funky port rewriting and restricting incoming traffic to > mapped assignments or UPnP. Why do people insist on creating solutions where each host has exactly one IPv6 address, instead of letting each host have *three* (in this case) - a ULA and two provider-prefixed addresses? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rcarpen at network1.net Tue Jun 14 12:43:32 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Jun 2011 13:43:32 -0400 (EDT) Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: Message-ID: <87b1d099-c907-41bd-aeb3-6ed54f2f0386@zimbra.network1.net> > Hi Ray, > > There's a nuance here you've missed. > > There are two main reasons for ULA inside the network: > > 1. Address stability (simplifies network management) > 2. Source obfuscation (improves the depth of the security plan) > > Option 1: Obfuscation desired. > > ULA inside. NAT/PAT at both borders. You don't use prefix translation > here because prefix translation does little obfuscation: it has a 1:1 > relationship with each individual host and still reveals the internal > routing structure. > > Option 2: Stability, no obfuscation desired. > > ULA inside, prefix translation at both borders. > > Option 3: Neither stability nor obfuscation required. > > GUA from one of the providers inside. Prefix translation to the other > provider for the connections desired out that border. Giving the > hosts > real GUA addresses maximizes application compatibility. Why doesn't GUA give you address stability? I would think that it would provide the best stability. And in terms of obfuscation, why couldn't we use DHCPv6 to give reasonably random addresses? Also, I don't see how prefix translation reveals my internal routing structure. I don't really see the point in ULA. It just seems like "The Return of RFC 1918, Part II, the Sequel" -Randy From rcarpen at network1.net Tue Jun 14 12:44:55 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 14 Jun 2011 13:44:55 -0400 (EDT) Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <23751.1308073107@turing-police.cc.vt.edu> Message-ID: <9d311909-beee-42ec-b420-1a72e15dfb03@zimbra.network1.net> > Why do people insist on creating solutions where each host has > exactly one IPv6 > address, instead of letting each host have *three* (in this case) - a > ULA and > two provider-prefixed addresses? > How does the upstream router control which address/path the client host use to route? -Randy From owen at delong.com Tue Jun 14 12:41:26 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 10:41:26 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> Message-ID: On Jun 14, 2011, at 9:41 AM, Ray Soucy wrote: > The energy in this thread should be focused on switch vendors to > actually implement L2 security features for IPv6, which is usually an > easy upgrade; rather than calling for all host implementations of IPv6 > to work differently; which will take a decade to implement and be a > band-aid at best; not a good long-term design for the protocol. > No, the energy in this thread needs to be directed to both of those issues. However, your characterization of the needed behavior and the time to deploy it is not entirely accurate. What is needed is: - Native RA Guard in switches - Native DHCPv6 Snooping in switches - Native RA Guard in WAPs - Native DHCPv6 Snooping in WAPs - Additional options to DHCPv6 for Routing Information - Eventual changes to host DHCPv6 Client behavior so that DHCP does occur when RA not present. > I think that was the original spirit of this thread. > No, the original spirit of the thread revolved around the last 2 items in the above list. The first 4 have been discussed and already resolved at the IETF level and are merely awaiting vendor implementation. > Full static assignment is always an option if you don't want to use RA > or DHCPv6. > Sure, but, the issue is people that don't want to use RA, but, want to use DHCPv6. > If you get a bad DHCP server on the network it can take hours to undo > the damage thanks to lease times; if you get bad RA you can usually > fix the problem as soon as you find it. Apples and Oranges, really. > If connecting the rogue DHCP server doesn't obviously break things > when connected, you might not even notice it until it's too late. > There's actually no reason this couldn't be done with DHCPv6, too, but, it's not there currently. > More responsive to change is better in my opinion. I hate having to > wait hours or days for changes to propagate; it feels like the 1990s, > or the days of mainframes and batch jobs. > Then use RA and move on. However, please understand that yours is not the only environment and that there are real-world scenarios where having the router-guys dictate the host configuration is considered unacceptable at best. Owen > On Tue, Jun 14, 2011 at 12:15 PM, Nick Hilliard wrote: >> On 14/06/2011 16:12, Ray Soucy wrote: >>> >>> The point was you shouldn't base protocol design around the >>> possibility that someone might tell it to do something you don't want >>> it to do; otherwise you'll end up with a one-size-fits-all protocol >>> that has zero flexibility (and might not even be functional at all). >> >> sensible engineering dictates that design should aim to be fail-safe. I.e. >> not "failsafe" in the common usage of the term (= doesn't fail), but rather >> cogniscent of the fact that all systems fail from time to time, and when >> they do, they ought to fail in such a way that the collateral damage is >> minimised. This principal is recodified in various ways ("be liberal in >> what you accept", etc), but the underlying idea is the same. >> >> In IPv6-land, we appear not to have learned the lessons from ipv4 history, >> and our vendors aren't yet shipping switches with native RA- and DHCPv6- >> guard (yes, there are some exceptions to the former). >> >> Nick >> >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ From owen at delong.com Tue Jun 14 12:48:16 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 10:48:16 -0700 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: Actually, a vastly inferior solution, but, it does have the attraction of being able to continue to ignore the need for scalable routing for several more years. In reality, we need to solve the scalable routing problem at some point and having everyone jump into the IPv6 BGP world for multihoming would be sustainable long enough for that problem to get solved if resources were focused on it. Owen On Jun 14, 2011, at 10:04 AM, Ray Soucy wrote: > Today you're probably correct. If you want to have more than one > provider reliably you pretty much need to be doing BGP; or have some > sort of primary-backup setup to fail over from one to the other; or > give each host a global address from each provider (really not > desirable in the majority of networks). > > I think in the long term telling everyone to jump into the BGP table > is not sustainable; and not operationally consistent with the majority > of SMB networks. > > A better solution; and the one I think that will be adopted in the > long term as soon as vendors come into the fold, is to swap out > RFC1918 with ULA addressing, and swap out PAT with NPT; then use > policy routing to handle load balancing and failover the way most > "dual WAN" multifunction firewalls do today. > > Example: > > Each provider provides a 48-bit prefix; > > Internally you use a ULA prefix; and setup prefix translation so that > the prefix gets swapped appropriately for each uplink interface. This > provides the benefits of "NAT" used today; without the drawback of > having to do funky port rewriting and restricting incoming traffic to > mapped assignments or UPnP. > > The firewall keeps track of if a connection is up or down and keeps > policy routing up to date; > > You can choose to set it up to either load balance per-flow or as a > primary and backup interface. > > You can handle DNS by using RFC 2136 updates for a sub-domain with a > short TTL on a hosted server to keep names up to date in the event of > a link drop. > > This doesn't require cooperation from the provider; it doesn't require > knowledge of routing protocols; and it is easy to understand for > people used to the "NAT" environment. > > Last time I checked, Linux still needs some work to handle ECMP > routing for IPv6, but once that is in place; combined with patches for > Network Prefix Translation (NPT), it should be trivial to implement. > > My guess is within the next year we'll see something pop up that does this. > > Ray > > On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong wrote: >> The vastly better option is to obtain a prefix and ASN from ARIN and merely trade BGP with your >> upstream providers. >> >> Prefix translation comes with all the same disabilities that are present when you do this in IPv4. >> >> In IPv4, everyone's software expects you to have a broken network (NAT) and there is lots of extra >> code in all of the applications to work around this. >> >> In iPv6, it is not unlikely that this code will eventually get removed and you will then have a high >> level of application problems in your "prefix-translated" environment. >> >> Owen >> >> On Jun 12, 2011, at 11:46 AM, Randy Carpenter wrote: >> >>> Prefix translation looks to be exactly what we need to do here. Thanks for all of the replies. >>> >>> >>> -Randy >>> >>> On Jun 12, 2011, at 2:42, Seth Mos wrote: >>> >>>> >>>> Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven: >>>> >>>>> >>>>> I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines. >>>> >>>> So basically policy routing? >>>> >>>>> The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections. >>>> >>>> Yep that sounds like policy routing. >>>> >>>>> With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished? >>>> >>>> Sure there is NAT, you can use prefix translation to translate your Global Address Range from the redundant ISP to the Cable ISP Global address range when leaving that interface. I've run a similar setup with 3 independent ISPs with IPv6 netblocks. >>>> >>>> Whichever connection the traffic went out it got the right GUA mapped onto it. Note that this is 1:1 NAT and not N:1. >>>> >>>> In my case there was no primary GUA range, I used a ULA on the LAN side of things, and mapped the corresponding GUA onto it when leaving the network. I had 3 rules, 1 for each WAN and mapped the ULA/56 to the GUA/56. >>>> >>>> In your case you already have a primary connection of sorts, so I'd suggest using that on the LAN side and only map the other GUA onto it when it leaves the other interfaces. >>>> >>>> The policy routing rules on your firewall can make all the routing decissions for you. >>>> >>>> If you search google for "IPv6 network prefix translation" there will be a firewall listed that can do this somewhere in the middle of the page. >>>> >>>> Cheers, >>>> >>>> Seth >>>> >> >> >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ From rps at maine.edu Tue Jun 14 12:52:47 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 14 Jun 2011 13:52:47 -0400 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <23751.1308073107@turing-police.cc.vt.edu> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> <23751.1308073107@turing-police.cc.vt.edu> Message-ID: It's a security and operational issue. The perception is that it's easier to monitor, manage, and filter one address per host instead of 3. For most in the enterprise world it's a non-starter to have that setup; even if that perception is a false one. Not sure I have the energy to re-hash the tired old NAT debate though. ;-) On Tue, Jun 14, 2011 at 1:38 PM, wrote: > On Tue, 14 Jun 2011 13:04:11 EDT, Ray Soucy said: > >> A better solution; and the one I think that will be adopted in the >> long term as soon as vendors come into the fold, is to swap out >> RFC1918 with ULA addressing, and swap out PAT with NPT; then use >> policy routing to handle load balancing and failover the way most >> "dual WAN" multifunction firewalls do today. >> >> Example: >> >> Each provider provides a 48-bit prefix; >> >> Internally you use a ULA prefix; and setup prefix translation so that >> the prefix gets swapped appropriately for each uplink interface. ?This >> provides the benefits of "NAT" used today; without the drawback of >> having to do funky port rewriting and restricting incoming traffic to >> mapped assignments or UPnP. > > Why do people insist on creating solutions where each host has exactly one IPv6 > address, instead of letting each host have *three* (in this case) - a ULA and > two provider-prefixed addresses? > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Tue Jun 14 12:50:15 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 10:50:15 -0700 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: <1E9A9B76-A0A7-453F-9ACB-46924DB01732@delong.com> On Jun 14, 2011, at 10:28 AM, William Herrin wrote: > On Tue, Jun 14, 2011 at 1:04 PM, Ray Soucy wrote: >> I think in the long term telling everyone to jump into the BGP table >> is not sustainable; and not operationally consistent with the majority >> of SMB networks. >> >> A better solution; and the one I think that will be adopted in the >> long term as soon as vendors come into the fold, is to swap out >> RFC1918 with ULA addressing, and swap out PAT with NPT; then use >> policy routing to handle load balancing and failover the way most >> "dual WAN" multifunction firewalls do today. >> >> Example: >> >> Each provider provides a 48-bit prefix; >> >> Internally you use a ULA prefix; and setup prefix translation so that >> the prefix gets swapped appropriately for each uplink interface. This >> provides the benefits of "NAT" used today; without the drawback of >> having to do funky port rewriting and restricting incoming traffic to >> mapped assignments or UPnP. > > Hi Ray, > > There's a nuance here you've missed. > > There are two main reasons for ULA inside the network: > > 1. Address stability (simplifies network management) > 2. Source obfuscation (improves the depth of the security plan) > > Option 1: Obfuscation desired. > > ULA inside. NAT/PAT at both borders. You don't use prefix translation > here because prefix translation does little obfuscation: it has a 1:1 > relationship with each individual host and still reveals the internal > routing structure. > > Option 2: Stability, no obfuscation desired. > > ULA inside, prefix translation at both borders. > > Option 3: Neither stability nor obfuscation required. > > GUA from one of the providers inside. Prefix translation to the other > provider for the connections desired out that border. Giving the hosts > real GUA addresses maximizes application compatibility. > If you're going to go with option 3, why not just put both GUA on the hosts and set up proper rules for source address selection to control the outbound preferences? Owen From rps at maine.edu Tue Jun 14 13:00:21 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 14 Jun 2011 14:00:21 -0400 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: I think that's a market problem rather than a routing problem. In the long term, If we had separation of L2 and L3 service providers there would be very, very few who need L3 redundancy; and that amount would be fine using BGP. Metro Ethernet services are making it a bit easier to accomplish this; but every ISP wants you to use them for everything so it's still a challenge. I would really like to see L2 optical services being treated as a public utility; and you just purchase your L3 from any provider you want. Prices would go down because we wouldn't be wasting money on building identical fiber paths, and bandwidth would go up. Have a problem with your current ISP? The switch to a different one can be done with a phone call; you don't even need to have a technician sent out. Maine recently started the ground work for that by making a new class of Public Utility for Dark Fiber, but it doesn't allow them to light it up. On Tue, Jun 14, 2011 at 1:48 PM, Owen DeLong wrote: > Actually, a vastly inferior solution, but, it does have the attraction of > being able to continue to ignore the need for scalable routing for several > more years. > > In reality, we need to solve the scalable routing problem at some point > and having everyone jump into the IPv6 BGP world for multihoming > would be sustainable long enough for that problem to get solved if > resources were focused on it. > > Owen > > On Jun 14, 2011, at 10:04 AM, Ray Soucy wrote: > >> Today you're probably correct. ?If you want to have more than one >> provider reliably you pretty much need to be doing BGP; or have some >> sort of primary-backup setup to fail over from one to the other; or >> give each host a global address from each provider (really not >> desirable in the majority of networks). >> >> I think in the long term telling everyone to jump into the BGP table >> is not sustainable; and not operationally consistent with the majority >> of SMB networks. >> >> A better solution; and the one I think that will be adopted in the >> long term as soon as vendors come into the fold, is to swap out >> RFC1918 with ULA addressing, and swap out PAT with NPT; then use >> policy routing to handle load balancing and failover the way most >> "dual WAN" multifunction firewalls do today. >> >> Example: >> >> Each provider provides a 48-bit prefix; >> >> Internally you use a ULA prefix; and setup prefix translation so that >> the prefix gets swapped appropriately for each uplink interface. ?This >> provides the benefits of "NAT" used today; without the drawback of >> having to do funky port rewriting and restricting incoming traffic to >> mapped assignments or UPnP. >> >> The firewall keeps track of if a connection is up or down and keeps >> policy routing up to date; >> >> You can choose to set it up to either load balance per-flow or as a >> primary and backup interface. >> >> You can handle DNS by using RFC 2136 updates for a sub-domain with a >> short TTL on a hosted server to keep names up to date in the event of >> a link drop. >> >> This doesn't require cooperation from the provider; it doesn't require >> knowledge of routing protocols; and it is easy to understand for >> people used to the "NAT" environment. >> >> Last time I checked, Linux still needs some work to handle ECMP >> routing for IPv6, but once that is in place; combined with patches for >> Network Prefix Translation (NPT), it should be trivial to implement. >> >> My guess is within the next year we'll see something pop up that does this. >> >> Ray >> >> On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong wrote: >>> The vastly better option is to obtain a prefix and ASN from ARIN and merely trade BGP with your >>> upstream providers. >>> >>> Prefix translation comes with all the same disabilities that are present when you do this in IPv4. >>> >>> In IPv4, everyone's software expects you to have a broken network (NAT) and there is lots of extra >>> code in all of the applications to work around this. >>> >>> In iPv6, it is not unlikely that this code will eventually get removed and you will then have a high >>> level of application problems in your "prefix-translated" environment. >>> >>> Owen >>> >>> On Jun 12, 2011, at 11:46 AM, Randy Carpenter wrote: >>> >>>> Prefix translation looks to be exactly what we need to do here. Thanks for all of the replies. >>>> >>>> >>>> -Randy >>>> >>>> On Jun 12, 2011, at 2:42, Seth Mos wrote: >>>> >>>>> >>>>> Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven: >>>>> >>>>>> >>>>>> I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines. >>>>> >>>>> So basically policy routing? >>>>> >>>>>> The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections. >>>>> >>>>> Yep that sounds like policy routing. >>>>> >>>>>> With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished? >>>>> >>>>> Sure there is NAT, you can use prefix translation to translate your Global Address Range from the redundant ISP to the Cable ISP Global address range when leaving that interface. I've run a similar setup with 3 independent ISPs with IPv6 netblocks. >>>>> >>>>> Whichever connection the traffic went out it got the right GUA mapped onto it. Note that this is 1:1 NAT and not N:1. >>>>> >>>>> In my case there was no primary GUA range, I used a ULA on the LAN side of things, and mapped the corresponding GUA onto it when leaving the network. I had 3 rules, 1 for each WAN and mapped the ULA/56 to the GUA/56. >>>>> >>>>> In your case you already have a primary connection of sorts, so I'd suggest using that on the LAN side and only map the other GUA onto it when it leaves the other interfaces. >>>>> >>>>> The policy routing rules on your firewall can make all the routing decissions for you. >>>>> >>>>> If you search google for "IPv6 network prefix translation" there will be a firewall listed that can do this somewhere in the middle of the page. >>>>> >>>>> Cheers, >>>>> >>>>> Seth >>>>> >>> >>> >>> >> >> >> >> -- >> Ray Soucy >> >> Epic Communications Specialist >> >> Phone: +1 (207) 561-3526 >> >> Networkmaine, a Unit of the University of Maine System >> http://www.networkmaine.net/ > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From ben at bjencks.net Tue Jun 14 13:00:35 2011 From: ben at bjencks.net (Ben Jencks) Date: Tue, 14 Jun 2011 14:00:35 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> Message-ID: <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote: > Then use RA and move on. However, please understand that yours > is not the only environment and that there are real-world scenarios > where having the router-guys dictate the host configuration is considered > unacceptable at best. This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying. -Ben From rps at maine.edu Tue Jun 14 13:14:25 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 14 Jun 2011 14:14:25 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> Message-ID: > On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote: > What is needed is: > > - Native RA Guard in switches > - Native DHCPv6 Snooping in switches > - Native RA Guard in WAPs > - Native DHCPv6 Snooping in WAPs > - Additional options to DHCPv6 for Routing Information > - Eventual changes to host DHCPv6 Client behavior so that > DHCP does occur when RA not present. Agree 100% Especially with the last one; DHCPv6 clients shouldn't even be started unless they see the M flag set; but that's an implementation challenge. Would probably include something analogous to ARP inspection for neighbor discovery; and that router implementations are modified so that once full, the neighbor table won't throw out known associations in favor of unknown associations to mitigate the denial of service attack vector present when using 64-bit prefixes. Perhaps DAD flooding protection too. It's a "new" protocol, so it will take a while for all these things to be worked out and become standard. On Tue, Jun 14, 2011 at 2:00 PM, Ben Jencks wrote: > This has always confused me. What aspect of host configuration is the router providing that's so > problematic? The prefix, which has to match on the router and host in order for anything to work > anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to > configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to > know it all anyway, that I'm having trouble understanding what environment would find this so > horrifying. And This. Really, people make way too big a deal about RA, and I think most of it comes from the lack of vendor support for filtering of rouge RA and the fact that Windows ICS happily sends them out. I still blame vendors; this design has been known for a long time now and they still haven't come up to speed, in part because people spend their time complaining on NANOG instead of to their sales rep. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From james.harr at gmail.com Tue Jun 14 13:30:53 2011 From: james.harr at gmail.com (James Harr) Date: Tue, 14 Jun 2011 13:30:53 -0500 Subject: IPv6 - a noobs prespective In-Reply-To: References: Message-ID: Really -- just go play with it. I started by setting up a tunnelbroker.net account at home. A majority of the packet slapping functionality of routers work just fine. It's when you get into things like applications, load balancing, NAT64/DNS64 where things start to get a little buggy. And you'll never get to those things unless there's some basic IPv6 on your network already. At work, we started by deploying it across the routers, but not to any end hosts. This way we can turn IPv6 on/off to specific end-host VLANs without much effort. Currently, our techs and one enthusiastic end user group have IPv6 and it seems to be running well. After the basics, it's going through one application/service at a time and getting it on IPv6. On Tue, Jun 14, 2011 at 11:44 AM, Octavio Alvarez wrote: > > On Wed, 09 Feb 2011 03:00:27 -0800, Robert Lusby wrote: > >> I am however *terrified* of making that move. There is so many new phrases, words, things to think about etc > > You fears will significantly lower after you set up a separate lab and > play with it. With something as simple as a switch you can make a simple > IPv6-only network. Try to replicate your current network in the lab as > far as you can, using the "new" concepts and techniques and understand > the current state of the art (read that as RA+DHCPv6, etc.) Get your > pings right. > > This will automatically get you to dual-stacking, as in "how do I make > both protocols work in the same physical network?". They just do. At > this point the problem stops belonging to the network infrastructure > and it passes on to the application servers and hosts. > > (And ask your ISP to support IPv6). > > Good luck. > > -- > Octavio. > -- ^[:wq^M From joelja at bogus.com Tue Jun 14 14:44:24 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 14 Jun 2011 12:44:24 -0700 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <23751.1308073107@turing-police.cc.vt.edu> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> <23751.1308073107@turing-police.cc.vt.edu> Message-ID: On Jun 14, 2011, at 10:38 AM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 14 Jun 2011 13:04:11 EDT, Ray Soucy said: > >> A better solution; and the one I think that will be adopted in the >> long term as soon as vendors come into the fold, is to swap out >> RFC1918 with ULA addressing, and swap out PAT with NPT; then use >> policy routing to handle load balancing and failover the way most >> "dual WAN" multifunction firewalls do today. >> >> Example: >> >> Each provider provides a 48-bit prefix; >> >> Internally you use a ULA prefix; and setup prefix translation so that >> the prefix gets swapped appropriately for each uplink interface. This >> provides the benefits of "NAT" used today; without the drawback of >> having to do funky port rewriting and restricting incoming traffic to >> mapped assignments or UPnP. > > Why do people insist on creating solutions where each host has exactly one IPv6 > address, instead of letting each host have *three* (in this case) - a ULA and > two provider-prefixed addresses? and a link-local From jfbeam at gmail.com Tue Jun 14 15:15:11 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 14 Jun 2011 16:15:11 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: On Tue, 14 Jun 2011 12:02:18 -0400, Owen DeLong wrote: > That was kind of my point. You are unlikely to encounter such a large L2 > domain outside of an exchange point. I've seen such large networks in private industry (and governements, not just the US) several times. And IPv6 has been designed (poorly, it would now appear) for huge "LAN"s -- LANs are supposed to be /64, after all. One of them "had" to have such stupid large L2 domains because they used RIP (v1) EVERYWHERE. (all networks had to be /22's) They made a god aweful mess trying to switch to OSPF, got fined by a three letter regulatory agency, and are probably still running RIPv1 to this day. From bicknell at ufp.org Tue Jun 14 15:25:13 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 14 Jun 2011 13:25:13 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> References: <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> Message-ID: <20110614202513.GA49062@ussenterprise.ufp.org> In a message written on Tue, Jun 14, 2011 at 02:00:35PM -0400, Ben Jencks wrote: > This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying. The problem for most folks is that it becomes an "in addition to" thing to support, troubleshoot, and debug. To make that ok, you have to look at the cost/benefits. I urge everyone in this thread to try a simple experiment. Configure an IPv6 segment in your lab. Make sure there is no IPv4 on it, not on the router, and that the IPv4 stack (to the extent possible) is disabled on the hosts. Now try to use one of the hosts to access IPv6 content. You'll find the box does SLAAC just fine and gets an address. You'll find RA's provide a default gateway and can get your packets out to the world. You'll also find absolutely nothing works, at a bare minimum because you have no DNS servers. People aren't noticing this today because they are dual stack, and end up reaching their DNS servers from IPv4 DHCP information over IPv4 transport. They may then get AAAA's, and use IPv6 after that. Your box is dead in the water. How do you get DNS servers? Today the answer is to run DHCPv6. Of course if you need other options (netboot information, NTP servers, domain controllers, and so on) you also need DHCPv6 to get a functioning box. So just like in IPv4, IPv6 requires DHCP to have a functioning end user box. DHCP remains a hard requirement. The odd part now is that in IPv4 DHCP carries the default gateway, while in IPv6 land you must also run Router Advertisements on your router and have the host listen to them. The industry has taken a robust single protocol solution and turned it into a dual, co-dependent protocol situation. The IETF is working on one solution, which is to add DNS information to the RA's! So now you'll configure your routers to hand out DNS servers to clients, and then everything else (NTP servers, Domain Controllers, etc) in DHCP! What I and others are suggesting is the other way around, how about we just put a default route in DHCPv6 like we did in v4, and forget all about RA's so we're back to a single protocol solution? Beyond that it is important to notice that the failure modes and attack vectors for RA's and DHCP are different. I argue DHCP is "better", but I also realize that's a very subjective judgment. That said, there are cases where people may prefer DHCP's robustness and/or failure modes, and cases where people might prefer RA's. Lastly, there's a hidden bit here many people haven't dealt with yet in lab networks. In IPv4 critical environments it's typical to use HSRP or VRRP to provide a single gateway across two routers. The IPv6 way to do this is to have both advertise RA's, possibly with different priorities. Depending on your environment this may or may not be as "feature rich" for you. For instance RA's timers aren't as adjustable (as they depend on end hosts), and I don't know of any vendor who implements interface tracking for RA's the way it is done with HSRP/VRRP. We need more folks using IPv6 in production to find this stuff. If you spin up a dual stacked box in the lab with a single router RA's work great, DHCPv4 gives you DNS, and you'll never notice any issues. Run a dual-router IPv6 only production network for some end users, and you'll notice some differences, and I think find that some of those differences are deficiencies. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jfbeam at gmail.com Tue Jun 14 15:30:11 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 14 Jun 2011 16:30:11 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: On Tue, 14 Jun 2011 04:00:22 -0400, Owen DeLong wrote: > You would need an AWFUL lot of hosts for this to add up to a few 100pps > (or even 10pps) of multicast traffic. You're missing the point... most WAPs are horrible with multicast. It doesn't matter if it's v4 or v6, at L2, multicast is multicast. At 100pps the WAP disappears from the network. "It's dead, Jim!" In many cases, a single multicast packet is enough to disrupt traffic flow as the AP stops to fire the multicast frame, individually, at each associated peer. As others have pointed out, IPv6 uses multicast all over the place. DHCPv6 is just one of many sources. All we're saying is DHCPv6 should be like DHCPv4... have a backoff period and eventually give up entirely. (yes, there are v4 agents that continue to try, i.e. restart every 5min, etc.) From matt.addison at lists.evilgeni.us Tue Jun 14 15:55:29 2011 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Tue, 14 Jun 2011 16:55:29 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> Message-ID: On Tue, Jun 14, 2011 at 12:41, Ray Soucy wrote: > > The energy in this thread should be focused on switch vendors to > actually implement L2 security features for IPv6, which is usually an > easy upgrade; rather than calling for all host implementations of IPv6 > to work differently; which will take a decade to implement and be a > band-aid at best; not a good long-term design for the protocol. There was a thread on this subject over on ipv6-ops (Hello to the list and RA guard evasion technique) recently which outlined some of the problems currently facing vendors and implementing those 'easy upgrade' L2 security features. Due to the current state of host stacks with regards to fragment reassembly it's almost impossible to implement easily on a layer 2 device without exposing yourself to other DoS possibilities. There're also some I-Ds which cover the issues: http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt ~Matt From ben at bjencks.net Tue Jun 14 16:01:24 2011 From: ben at bjencks.net (Ben Jencks) Date: Tue, 14 Jun 2011 17:01:24 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110614202513.GA49062@ussenterprise.ufp.org> References: <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <20110614202513.GA49062@ussenterprise.ufp.org> Message-ID: <5A1E9F84-99F5-47AD-B8B2-6BB0E12CAABD@bjencks.net> On Jun 14, 2011, at 4:25 PM, Leo Bicknell wrote: > In a message written on Tue, Jun 14, 2011 at 02:00:35PM -0400, Ben Jencks wrote: >> This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying. > [snipped long explanation that you do in fact need DNS servers] > > So just like in IPv4, IPv6 requires DHCP to have a functioning end user > box. DHCP remains a hard requirement. The odd part now is that in IPv4 > DHCP carries the default gateway, while in IPv6 land you must also run > Router Advertisements on your router and have the host listen to them. > > The industry has taken a robust single protocol solution and turned it > into a dual, co-dependent protocol situation. I'm just not seeing how this actually adds more configuration overhead. Rather than looking at a protocol count, try looking at the number of actual items you need to configure and where they get configured. This is actually *smaller* in IPv6, because the DHCPv6 server doesn't need to know what the default gateways are anymore (I have no problem with a routing information option, but that's optional, not *needed*). The fact that the information is distributed over different protocols seems to make a lot of people really pissed off, but seems ancillary to the actual issues of what information is configured where and what options are available. > > The IETF is working on one solution, which is to add DNS information to > the RA's! So now you'll configure your routers to hand out DNS servers > to clients, and then everything else (NTP servers, Domain Controllers, > etc) in DHCP! I agree, that's never seemed like a good idea. > What I and others are suggesting is the other way around, how about we > just put a default route in DHCPv6 like we did in v4, and forget all > about RA's so we're back to a single protocol solution? > > Beyond that it is important to notice that the failure modes and attack > vectors for RA's and DHCP are different. I argue DHCP is "better", but > I also realize that's a very subjective judgment. That said, there > are cases where people may prefer DHCP's robustness and/or failure > modes, and cases where people might prefer RA's. There are differences in failure modes, but I'd argue that's not enough justification to fragment the configuration options. If there are two overlapping ways to configure things, then I'd bet that all but the most mainstream or high-end implementations will have poor support for at least one. That was the one you chose? Too bad, you have to support both now. So much for the "operator choice" you keep arguing for. > Lastly, there's a hidden bit here many people haven't dealt with > yet in lab networks. In IPv4 critical environments it's typical > to use HSRP or VRRP to provide a single gateway across two routers. > The IPv6 way to do this is to have both advertise RA's, possibly > with different priorities. Erm, I thought the IPv6 way to do it was to use IPv6 VRRP... I've heard of some vendor bugs on it, but it's implemented. Multiple routers sending RAs can be useful, but not for the same kind of HA that VRRP is designed for. -Ben From valas at gatech.edu Tue Jun 14 16:14:50 2011 From: valas at gatech.edu (Vytautas Valancius) Date: Tue, 14 Jun 2011 17:14:50 -0400 Subject: Routing study - take 2 Message-ID: Hi NANOG, >From June 20th to July 20th Georgia Tech will conduct an Internet routing study using AS-PATH poisoning. We will insert AS numbers into one of our announcements to route around some networks. The study will *only* affect the the Georgia Tech prefix 184.164.224.0/21. The prefix serves *no active users* for the duration of study. We will always start AS-PATH with our own AS 47065. We will limit ourselves to 10 announcement changes per hour. Similar studies were done before (e.g. by Randy Bush et al.: http://www.psg.com/~olaf/measurements/as3130/visibility.pdf). If, for any reason, you want us not to taint our prefix with you AS number, please opt-out at any time at: http://www.surveymonkey.com/s/WGLV6QR Regards, Vytautas Valancius http://valas.gtnoise.net/ Georgia Tech From bicknell at ufp.org Tue Jun 14 16:24:48 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 14 Jun 2011 14:24:48 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <5A1E9F84-99F5-47AD-B8B2-6BB0E12CAABD@bjencks.net> References: <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <20110614202513.GA49062@ussenterprise.ufp.org> <5A1E9F84-99F5-47AD-B8B2-6BB0E12CAABD@bjencks.net> Message-ID: <20110614212448.GA51745@ussenterprise.ufp.org> In a message written on Tue, Jun 14, 2011 at 05:01:24PM -0400, Ben Jencks wrote: > > Lastly, there's a hidden bit here many people haven't dealt with > > yet in lab networks. In IPv4 critical environments it's typical > > to use HSRP or VRRP to provide a single gateway across two routers. > > The IPv6 way to do this is to have both advertise RA's, possibly > > with different priorities. > > Erm, I thought the IPv6 way to do it was to use IPv6 VRRP... I've heard of some vendor bugs on it, but it's implemented. You can do VRRPv6 (now, finally, on some platforms). However, the standard way this works is, wait for it, advertising the default gateway via RA's! At least you can static route to the VRRPv6 address and that works without RA's. Again, it would be nice to give out the address in DHCPv6 and not need RA's at all, but alas there is no default route field in DHCPv6. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From seth.mos at dds.nl Tue Jun 14 16:42:20 2011 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 14 Jun 2011 23:42:20 +0200 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: <6BF40C70-0A67-439A-90DC-D427CF5CE541@dds.nl> Op 14 jun 2011, om 19:04 heeft Ray Soucy het volgende geschreven: > My guess is within the next year we'll see something pop up that does this. Ehm, It's already here, you searched google right? I finished it 4 months ago. And a number of commercial platforms already support it. Although Owen doesn't like it much. I really wish there was a more bomb proof "lite" version of the BGP protocol. - One that has proper authentication not based on a single MD5. - One that does not allow the client side to define the networks. - That will only support default routes, it's easier if it can not carry the world. I think a evolved version of ebgp multihop is workable, but you'd still need some lightweight form of hooking back into the BGP table. Ideally, ISPs could deploy a number of these route "guides" that would inject the proper route into the real BGP table, but by then it is filtered and the ISP has proper control over what ends up in it. Some ISPs could mark this up as a luxury version. Perhaps a form of PI bound to country (Exchange) would be a workable solution. So request a piece of "country PI" that is delegated explicitly to the roaming guide(s). Regards, Seth From jra at baylink.com Tue Jun 14 16:47:53 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 14 Jun 2011 17:47:53 -0400 (EDT) Subject: AUS? In-Reply-To: <33498675.268.1308061119568.JavaMail.root@benjamin.baylink.com> Message-ID: <12808779.280.1308088073670.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Ashworth" > http://www.outages.org/index.php/Network_ops_group_websites And silly me, I didn't *check the link* before posting that. Fixed now. Sorry for the noise. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From owen at delong.com Tue Jun 14 16:46:04 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 14:46:04 -0700 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> <23751.1308073107@turing-police.cc.vt.edu> Message-ID: <66644F61-071D-44D9-B594-8F7FCEB45CCD@delong.com> On Jun 14, 2011, at 10:52 AM, Ray Soucy wrote: > It's a security and operational issue. > > The perception is that it's easier to monitor, manage, and filter one > address per host instead of 3. For most in the enterprise world it's > a non-starter to have that setup; even if that perception is a false > one. > Yes... The key word there is perception. The question is whether it makes more sense to put effort into correcting mis-perceptions or to put the effort into providing workarounds which provide a sub-par networking experience to the end user. IMNSHO, it is better to put effort into education. I'm surprised to find someone from a .EDU on the opposite side of that thought. One would normally expect them to favor the idea of education over hackery. > Not sure I have the energy to re-hash the tired old NAT debate though. ;-) > That sound you hear is me breathing a sigh of relief. I will continue to do it as long as it remains necessary, but, I'm tired of it too. Owen > On Tue, Jun 14, 2011 at 1:38 PM, wrote: >> On Tue, 14 Jun 2011 13:04:11 EDT, Ray Soucy said: >> >>> A better solution; and the one I think that will be adopted in the >>> long term as soon as vendors come into the fold, is to swap out >>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use >>> policy routing to handle load balancing and failover the way most >>> "dual WAN" multifunction firewalls do today. >>> >>> Example: >>> >>> Each provider provides a 48-bit prefix; >>> >>> Internally you use a ULA prefix; and setup prefix translation so that >>> the prefix gets swapped appropriately for each uplink interface. This >>> provides the benefits of "NAT" used today; without the drawback of >>> having to do funky port rewriting and restricting incoming traffic to >>> mapped assignments or UPnP. >> >> Why do people insist on creating solutions where each host has exactly one IPv6 >> address, instead of letting each host have *three* (in this case) - a ULA and >> two provider-prefixed addresses? >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ From khelms at ispalliance.net Tue Jun 14 16:57:01 2011 From: khelms at ispalliance.net (Scott Helms) Date: Tue, 14 Jun 2011 17:57:01 -0400 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <66644F61-071D-44D9-B594-8F7FCEB45CCD@delong.com> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> <23751.1308073107@turing-police.cc.vt.edu> <66644F61-071D-44D9-B594-8F7FCEB45CCD@delong.com> Message-ID: <4DF7D92D.9030808@ispalliance.net> > Yes... The key word there is perception. The question is whether it makes > more sense to put effort into correcting mis-perceptions or to put the effort > into providing workarounds which provide a sub-par networking experience > to the end user. > > IMNSHO, it is better to put effort into education. I'm surprised to find someone > from a .EDU on the opposite side of that thought. One would normally expect > them to favor the idea of education over hackery. > There are few things harder on the planet than changing perception and one of the few is changing human behavior. NAT is normal for many/most enterprises and the thought of trying to explain sub-par networking to most business leaders makes my teeth hurt. Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From owen at delong.com Tue Jun 14 16:55:58 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 14:55:58 -0700 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> Message-ID: On Jun 14, 2011, at 11:00 AM, Ray Soucy wrote: > I think that's a market problem rather than a routing problem. In the > long term, If we had separation of L2 and L3 service providers there > would be very, very few who need L3 redundancy; and that amount would > be fine using BGP. > ROFLMAO... You're joking, right? Oh, you're serious... OK... I encourage my competitors to try that. > Metro Ethernet services are making it a bit easier to accomplish this; > but every ISP wants you to use them for everything so it's still a > challenge. > I would still want L3 redundancy and I can't imagine any of my clients choosing to go with diverse L2 paths to the same L3 provider as a valid complete solution for redundancy. > I would really like to see L2 optical services being treated as a > public utility; and you just purchase your L3 from any provider you > want. Prices would go down because we wouldn't be wasting money on > building identical fiber paths, and bandwidth would go up. Have a > problem with your current ISP? The switch to a different one can be > done with a phone call; you don't even need to have a technician sent > out. > Agreed, but, that doesn't change the fact that L3 redundancy is still a requirement for a growing (not shrinking) number of organizations. That's not a market issue, that _IS_ a routing issue. The good news on that front, however, is that if we get from o(10+) prefixes per organization to o(2) prefixes per organization, we get a dramatically smaller routing table with iPv6 fully deployed and can accommodate a pretty hefty number of additional organizations in IPv6. > Maine recently started the ground work for that by making a new class > of Public Utility for Dark Fiber, but it doesn't allow them to light > it up. > It's been done in Sweden and is being done in AU as well. I've been advocating an independent monopoly LMI non-profit available to all higher tier service providers on an equal basis for years. Glad to see it's starting to finally catch on in a couple of places. Owen > On Tue, Jun 14, 2011 at 1:48 PM, Owen DeLong wrote: >> Actually, a vastly inferior solution, but, it does have the attraction of >> being able to continue to ignore the need for scalable routing for several >> more years. >> >> In reality, we need to solve the scalable routing problem at some point >> and having everyone jump into the IPv6 BGP world for multihoming >> would be sustainable long enough for that problem to get solved if >> resources were focused on it. >> >> Owen >> >> On Jun 14, 2011, at 10:04 AM, Ray Soucy wrote: >> >>> Today you're probably correct. If you want to have more than one >>> provider reliably you pretty much need to be doing BGP; or have some >>> sort of primary-backup setup to fail over from one to the other; or >>> give each host a global address from each provider (really not >>> desirable in the majority of networks). >>> >>> I think in the long term telling everyone to jump into the BGP table >>> is not sustainable; and not operationally consistent with the majority >>> of SMB networks. >>> >>> A better solution; and the one I think that will be adopted in the >>> long term as soon as vendors come into the fold, is to swap out >>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use >>> policy routing to handle load balancing and failover the way most >>> "dual WAN" multifunction firewalls do today. >>> >>> Example: >>> >>> Each provider provides a 48-bit prefix; >>> >>> Internally you use a ULA prefix; and setup prefix translation so that >>> the prefix gets swapped appropriately for each uplink interface. This >>> provides the benefits of "NAT" used today; without the drawback of >>> having to do funky port rewriting and restricting incoming traffic to >>> mapped assignments or UPnP. >>> >>> The firewall keeps track of if a connection is up or down and keeps >>> policy routing up to date; >>> >>> You can choose to set it up to either load balance per-flow or as a >>> primary and backup interface. >>> >>> You can handle DNS by using RFC 2136 updates for a sub-domain with a >>> short TTL on a hosted server to keep names up to date in the event of >>> a link drop. >>> >>> This doesn't require cooperation from the provider; it doesn't require >>> knowledge of routing protocols; and it is easy to understand for >>> people used to the "NAT" environment. >>> >>> Last time I checked, Linux still needs some work to handle ECMP >>> routing for IPv6, but once that is in place; combined with patches for >>> Network Prefix Translation (NPT), it should be trivial to implement. >>> >>> My guess is within the next year we'll see something pop up that does this. >>> >>> Ray >>> >>> On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong wrote: >>>> The vastly better option is to obtain a prefix and ASN from ARIN and merely trade BGP with your >>>> upstream providers. >>>> >>>> Prefix translation comes with all the same disabilities that are present when you do this in IPv4. >>>> >>>> In IPv4, everyone's software expects you to have a broken network (NAT) and there is lots of extra >>>> code in all of the applications to work around this. >>>> >>>> In iPv6, it is not unlikely that this code will eventually get removed and you will then have a high >>>> level of application problems in your "prefix-translated" environment. >>>> >>>> Owen >>>> >>>> On Jun 12, 2011, at 11:46 AM, Randy Carpenter wrote: >>>> >>>>> Prefix translation looks to be exactly what we need to do here. Thanks for all of the replies. >>>>> >>>>> >>>>> -Randy >>>>> >>>>> On Jun 12, 2011, at 2:42, Seth Mos wrote: >>>>> >>>>>> >>>>>> Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven: >>>>>> >>>>>>> >>>>>>> I have an interesting situation at a business that I am working on. We currently have the office set up with redundant connections for their mission critical servers and such, and also have a (cheap) cable modem for general browsing on client machines. >>>>>> >>>>>> So basically policy routing? >>>>>> >>>>>>> The interesting part is that the client machines need to access some customer networks via the main redundant network, so we have a firewall set up to route those connections via the redundant connections, and everything else via the cheaper, faster cable modem. NAT is used on both outbound connections. >>>>>> >>>>>> Yep that sounds like policy routing. >>>>>> >>>>>>> With IPv6, we are having some trouble coming up with a way to do this. Since there is no NAT, does anyone have any ideas as to how this could be accomplished? >>>>>> >>>>>> Sure there is NAT, you can use prefix translation to translate your Global Address Range from the redundant ISP to the Cable ISP Global address range when leaving that interface. I've run a similar setup with 3 independent ISPs with IPv6 netblocks. >>>>>> >>>>>> Whichever connection the traffic went out it got the right GUA mapped onto it. Note that this is 1:1 NAT and not N:1. >>>>>> >>>>>> In my case there was no primary GUA range, I used a ULA on the LAN side of things, and mapped the corresponding GUA onto it when leaving the network. I had 3 rules, 1 for each WAN and mapped the ULA/56 to the GUA/56. >>>>>> >>>>>> In your case you already have a primary connection of sorts, so I'd suggest using that on the LAN side and only map the other GUA onto it when it leaves the other interfaces. >>>>>> >>>>>> The policy routing rules on your firewall can make all the routing decissions for you. >>>>>> >>>>>> If you search google for "IPv6 network prefix translation" there will be a firewall listed that can do this somewhere in the middle of the page. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Seth >>>>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Ray Soucy >>> >>> Epic Communications Specialist >>> >>> Phone: +1 (207) 561-3526 >>> >>> Networkmaine, a Unit of the University of Maine System >>> http://www.networkmaine.net/ >> >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ From owen at delong.com Tue Jun 14 17:08:30 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 15:08:30 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> Message-ID: On Jun 14, 2011, at 11:14 AM, Ray Soucy wrote: >> On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote: >> What is needed is: >> >> - Native RA Guard in switches >> - Native DHCPv6 Snooping in switches >> - Native RA Guard in WAPs >> - Native DHCPv6 Snooping in WAPs >> - Additional options to DHCPv6 for Routing Information >> - Eventual changes to host DHCPv6 Client behavior so that >> DHCP does occur when RA not present. > > Agree 100% > > Especially with the last one; DHCPv6 clients shouldn't even be started > unless they see the M flag set; but that's an implementation > challenge. That's the current broken behavior. The goal is to correct that problem. > > Would probably include something analogous to ARP inspection for > neighbor discovery; and that router implementations are modified so > that once full, the neighbor table won't throw out known associations > in favor of unknown associations to mitigate the denial of service > attack vector present when using 64-bit prefixes. Perhaps DAD > flooding protection too. It's a "new" protocol, so it will take a > while for all these things to be worked out and become standard. > That would also likely be good, but, I don't think that requires IETF effort. > On Tue, Jun 14, 2011 at 2:00 PM, Ben Jencks wrote: > >> This has always confused me. What aspect of host configuration is the router providing that's so >> problematic? The prefix, which has to match on the router and host in order for anything to work >> anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to >> configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to >> know it all anyway, that I'm having trouble understanding what environment would find this so >> horrifying. > > And This. > > Really, people make way too big a deal about RA, and I think most of > it comes from the lack of vendor support for filtering of rouge RA and > the fact that Windows ICS happily sends them out. > No, that is not the only place it comes from. There are real world networks that don't have a good solution with RA because RA assumes that link==subnet and that simply isn't true in all cases. > I still blame vendors; this design has been known for a long time now > and they still haven't come up to speed, in part because people spend > their time complaining on NANOG instead of to their sales rep. > Believe me, I've done both. Owen > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ From owen at delong.com Tue Jun 14 17:05:59 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 15:05:59 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> Message-ID: <9E01B76D-3723-4CB9-92F8-87B85699839E@delong.com> On Jun 14, 2011, at 11:00 AM, Ben Jencks wrote: > On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote: > >> Then use RA and move on. However, please understand that yours >> is not the only environment and that there are real-world scenarios >> where having the router-guys dictate the host configuration is considered >> unacceptable at best. > > This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying. > > -Ben Imagine this scenario... [RA] [RB] [RC] [RD] | | | | [-+---+---+---+---+----+---+---+---+---+---+---+---+---+---+-] | | | | | | | | | | | [AR] [AP] [ACCTG] [D1] | [D2] | [D3] | [W1] [W2] [L1] [R1] AR is Accts Receivable AP is Accts Payable ACCTG is the Accts server D1-D3 are developer workstations. W1-W2 are internal application web servers L1 is the lobby computer (badging kiosk) R1 is the Receptionist. RA, RB are routers which are run by IT and connect off to the IT subnets in the main building. RC, RD are routers which are run by the DEV group and connect off to the DEV group subnets in the main building. See... This is an oversimplification, but, these things happen in the real world. The desire is for the AR/AP/ACCTG/L1/R1 hosts to use the RA/RB prefixes and default gateways. Currently that's done by the DHCP server knowing which MAC addresses to expect for those systems. Everything else gets shunted to the DEV network. Yes, the right solution would be to at least separate the VLANs and clean up this mess. However, due to software packages that need to talk to each other over common local broadcast across that boundary, this isn't possible in this particular organization (don't get me started on the bad software, but, that's what there is.) There are large varieties of other situations where having the router supply prefix and default gateway information on the theory that all routers on a link are created equal and anyone on a link may use any router (priority doesn't help here because the goal is to have different hosts use different sets of gateways). Which prefix does "the prefix" have to match? How, using RA, do you assign the RC/RD prefix(es) to the D1-D3 hosts and the RA/RB prefix(es) to everything else (or vice versa)? Sometimes link != subnet. Owen From owen at delong.com Tue Jun 14 17:16:10 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 15:16:10 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: <6CB36F07-7C0E-46BB-B614-88D1CB56F3D4@delong.com> On Jun 14, 2011, at 1:15 PM, Ricky Beam wrote: > On Tue, 14 Jun 2011 12:02:18 -0400, Owen DeLong wrote: >> That was kind of my point. You are unlikely to encounter such a large L2 domain outside of an exchange point. > > I've seen such large networks in private industry (and governements, not just the US) several times. And IPv6 has been designed (poorly, it would now appear) for huge "LAN"s -- LANs are supposed to be /64, after all. > > One of them "had" to have such stupid large L2 domains because they used RIP (v1) EVERYWHERE. (all networks had to be /22's) They made a god aweful mess trying to switch to OSPF, got fined by a three letter regulatory agency, and are probably still running RIPv1 to this day. The point of /64 is to support automatic configuration and incredibly sparse host addressing. It is not intended to create stupidly large broadcast domains. A /22 is probably about the upper limit of a sane broadcast domain, but, even with a /22 or 1022 nodes max, each sending a packet every 10 seconds you don't get to 100s of PPS, you get 102.2pps. Owen From owen at delong.com Tue Jun 14 17:25:10 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 15:25:10 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: <78A7D0C8-4D23-4847-BE89-C2A74DE80D4F@delong.com> On Jun 14, 2011, at 1:30 PM, Ricky Beam wrote: > On Tue, 14 Jun 2011 04:00:22 -0400, Owen DeLong wrote: >> You would need an AWFUL lot of hosts for this to add up to a few 100pps (or even 10pps) of multicast traffic. > > You're missing the point... most WAPs are horrible with multicast. It doesn't matter if it's v4 or v6, at L2, multicast is multicast. > > At 100pps the WAP disappears from the network. "It's dead, Jim!" In many cases, a single multicast packet is enough to disrupt traffic flow as the AP stops to fire the multicast frame, individually, at each associated peer. > > As others have pointed out, IPv6 uses multicast all over the place. DHCPv6 is just one of many sources. > > All we're saying is DHCPv6 should be like DHCPv4... have a backoff period and eventually give up entirely. (yes, there are v4 agents that continue to try, i.e. restart every 5min, etc.) Dude... I said that from the beginning. Point is that DHCPv6 isn't going to be the thing that pushes your AP over the edge. Owen From iljitsch at muada.com Tue Jun 14 17:44:22 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 15 Jun 2011 00:44:22 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <9E01B76D-3723-4CB9-92F8-87B85699839E@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <9E01B76D-3723-4CB9-92F8-87B85699839E@delong.com> Message-ID: <60B7F9A9-17FC-473F-9FD8-E118F52514FE@muada.com> On 15 jun 2011, at 0:05, Owen DeLong wrote: > Yes, the right solution would be to at least separate the VLANs and clean up this > mess. However, due to software packages that need to talk to each other over > common local broadcast across that boundary, this isn't possible in this particular > organization (don't get me started on the bad software, but, that's what there is.) Strange that you don't apply the logic of "the existing software is what there is" to the code deep inside hundreds of millions of hosts, but rather to obscure stuff that presumably hardly anyone uses. If changing this software is so hard, what these people need is some filtering switches so the application multicasts get forwarded but the IP provisioning multicasts don't. No standards action required. BTW, does this broken software run over IPv6, anyway? From owen at delong.com Tue Jun 14 17:43:09 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 15:43:09 -0700 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <4DF7D92D.9030808@ispalliance.net> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> <23751.1308073107@turing-police.cc.vt.edu> <66644F61-071D-44D9-B594-8F7FCEB45CCD@delong.com> <4DF7D92D.9030808@ispalliance.net> Message-ID: <3FEC542C-B8D6-4531-AC0C-9F4ADEED8DE1@delong.com> On Jun 14, 2011, at 2:57 PM, Scott Helms wrote: > >> Yes... The key word there is perception. The question is whether it makes >> more sense to put effort into correcting mis-perceptions or to put the effort >> into providing workarounds which provide a sub-par networking experience >> to the end user. >> >> IMNSHO, it is better to put effort into education. I'm surprised to find someone >> from a .EDU on the opposite side of that thought. One would normally expect >> them to favor the idea of education over hackery. >> > > There are few things harder on the planet than changing perception and one of the few is changing human behavior. NAT is normal for many/most enterprises and the thought of trying to explain sub-par networking to most business leaders makes my teeth hurt. > It only took us about 15 years to change behavior to NAT by default, so, I'm betting that if we do the right thing and put in the effort, in 15 years, we can have a nice NAT-free network. Personally, I think it's worth it. I have very little trouble explaining sub-par networking to most of them. Usually it goes something like this... Remember when your IT department came to you with projections of enormous savings on telephone costs in 2003 and your company did their first foray into VOIP? Yeah, that's a good example of sub-par networking. Owen From owen at delong.com Tue Jun 14 17:40:15 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 15:40:15 -0700 Subject: Question about migrating to IPv6 with multiple upstreams. In-Reply-To: <6BF40C70-0A67-439A-90DC-D427CF5CE541@dds.nl> References: <5346c432-e1a2-4319-8592-6305b2e215b1@zimbra.network1.net> <9D8AED84-6BC6-4795-8A7E-CCEB70D24BE2@dds.nl> <235F63FB-5C21-44B4-9F67-4B561E9B91D6@network1.net> <74D9DFDA-E891-4937-920C-0DEDD7A0802E@delong.com> <6BF40C70-0A67-439A-90DC-D427CF5CE541@dds.nl> Message-ID: On Jun 14, 2011, at 2:42 PM, Seth Mos wrote: > > Op 14 jun 2011, om 19:04 heeft Ray Soucy het volgende geschreven: > >> My guess is within the next year we'll see something pop up that does this. > > Ehm, It's already here, you searched google right? > > I finished it 4 months ago. And a number of commercial platforms already support it. Although Owen doesn't like it much. > > I really wish there was a more bomb proof "lite" version of the BGP protocol. > - One that has proper authentication not based on a single MD5. > - One that does not allow the client side to define the networks. > - That will only support default routes, it's easier if it can not carry the world. > Bullet 1: You're in luck... In IPv6, you can run BGP/IPSEC. Works today. Bullet 2: Not sure how you'd do that, but, since the "client side" can't control what the upstream side accepts, I'm not sure why that matters. Bullet 3: You have the option of doing that in BGP today, but, I don't know of any versions of BGP that are so limited other than by memory constraints. > I think a evolved version of ebgp multihop is workable, but you'd still need some lightweight form of hooking back into the BGP table. > Not sure what you mean by this. Pretty simple, really... ISP advertises default and accepts prefixes with a simple prefix filter. accepts default and advertises own prefixes. Done. Works today. Can mostly be fire-and-forget, even. > Ideally, ISPs could deploy a number of these route "guides" that would inject the proper route into the real BGP table, but by then it is filtered and the ISP has proper control over what ends up in it. Some ISPs could mark this up as a luxury version. > Why not just do it as part of the customer interface configuration on the edge router? Why add the complication of an extra box somewhere else to manage? > Perhaps a form of PI bound to country (Exchange) would be a workable solution. So request a piece of "country PI" that is delegated explicitly to the roaming guide(s). > Country PI is fail for a number of reasons. Owen From jfbeam at gmail.com Tue Jun 14 19:50:11 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 14 Jun 2011 20:50:11 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <6CB36F07-7C0E-46BB-B614-88D1CB56F3D4@delong.com> References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> <6CB36F07-7C0E-46BB-B614-88D1CB56F3D4@delong.com> Message-ID: On Tue, 14 Jun 2011 18:16:10 -0400, Owen DeLong wrote: > The point of /64 is to support automatic configuration and incredibly > sparse host addressing. > It is not intended to create stupidly large broadcast domains. Several IETF (and NANOG) discussions say otherwise. While current hardware doesn't handle thousands of hosts, the protocol was designed for a future where that's not true. (there's a future where *everything* is network enabled... microwave oven, doorbell, weed whacker, everything.) > A /22 is probably about the upper limit of a sane broadcast domain, but, > even with a /22 > or 1022 nodes max, each sending a packet every 10 seconds you don't get > to 100s of PPS, > you get 102.2pps. As I said, DHCP isn't the only source of traffic. Setup a 1000 node network today (just IPv4), and you will see a great deal of broadcast traffic (unless those nodes aren't doing anything.) With IPv6, it's all multicast (v6 doesn't have a "broadcast address") hinged on switches filtering the traffic away from where it doesn't need to be. The all-too-common Best Buy $20 white box ethernet switch does no multicast filtering at all. Pretty much all wireless hardware sucks at multicast - period. These are not things that can be fixed with a simple software update... if the silicon doesn't do it, *it doesn't do it*. From jfbeam at gmail.com Tue Jun 14 20:00:11 2011 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 14 Jun 2011 21:00:11 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <60B7F9A9-17FC-473F-9FD8-E118F52514FE@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <9E01B76D-3723-4CB9-92F8-87B85699839E@delong.com> <60B7F9A9-17FC-473F-9FD8-E118F52514FE@muada.com> Message-ID: On Tue, 14 Jun 2011 18:44:22 -0400, Iljitsch van Beijnum wrote: > BTW, does this broken software run over IPv6, anyway? Poorly designed network plus poorly designed software... I don't know which chicken came first, and it doesn't matter. IPv6 is totally different barnyard. Build the v6 network properly -- one gateway (one router, vrrp, whatever) -- and retool the software properly. IPv6 doesn't have a broadcast address; as such if the software is setup to use an appropriate multicast target (presumably in "user defined" space), then it'll talk to exactly the right machines, and it's routable. --Ricky From brett at the-watsons.org Tue Jun 14 20:29:30 2011 From: brett at the-watsons.org (Brett Watson) Date: Tue, 14 Jun 2011 18:29:30 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <20110610134744.GA20607@ussenterprise.ufp.org> <06E52A77-C65C-41C5-B7B0-5770C4A810C7@muada.com> <20110610142802.GA21261@ussenterprise.ufp.org> <20110610144751.GA25027@ussenterprise.ufp.org> <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> Message-ID: On Jun 10, 2011, at 7:03 PM, Owen DeLong wrote: > I see no reason that additional DHCPv6 options would have to fragment the installed > base or perpetuate the lack of agreed upon DHCPv6 behavior. In fact, I think that > adding these options could allow for a set of rules that would be acceptable to all > and would allow administrators to make choices based on the needs of their > environments. Indeed, and agreed. I've got a number of large, multi-national enterprise customers who are in this very situation, they need the options because they're trying to get away from a lot of nasty, inherited, legacy configurations. The only way they can safely migrate from those is if we (well, IETF, via RFC, and then vendors) provide them the options to be flexible. This thread is somewhat like the DLV/DNSSEC thread on dns-operations. Some are arguing DLV should die, but frankly it's giving operators options to *migrate* to DNSSEC rather than making forklift changes in their networks. I'd simply like to see the option of doing RA, or not, or DHCP with option.routers, etc. >> People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. >> > > There were a lot of people who tried to "show up" at the IETF 10 years ago and talk > about this stuff from an operational perspective. They were basically told that operators > don't know what they want and they should shut up and go away and let real men > do the work. Indeed, again. I stopped going to IETF (for good or ill) in 1997 or so, but still following the mailing lists. I haven't been since, but sounds like this is still the status quo. -b From dedelman at iname.com Tue Jun 14 22:08:18 2011 From: dedelman at iname.com (Dave Edelman) Date: Tue, 14 Jun 2011 23:08:18 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <9E01B76D-3723-4CB9-92F8-87B85699839E@delong.com> <60B7F9A9-17FC-473F-9FD8-E118F52514FE@muada.com> Message-ID: <00b601cc2b09$7a3f98b0$6ebeca10$@iname.com> > > BTW, does this broken software run over IPv6, anyway? > > Poorly designed network plus poorly designed software... I don't know which > chicken came first, and it doesn't matter. > > IPv6 is totally different barnyard. Build the v6 network properly -- one > gateway (one router, vrrp, whatever) -- and retool the software properly. > IPv6 doesn't have a broadcast address; as such if the software is setup to use > an appropriate multicast target (presumably in "user defined" space), then > it'll talk to exactly the right machines, and it's routable. > When I was young and the earth was still cooling, I attended my very first University level Computer and Information Science lecture. There was the normal administatrivia followed by a discussion of how lucky we were to be in the generation of programmers who would address the Year 2K problem. Just to set expectations that was 1969 (okay the earth was actually getting warmer) more than three decades before the event. Somehow I remember a bit of a scramble to get everything ready on the evening. Fast forward a few years and a bunch of us are going to see a very similar event, foretold well in advance and not addressed until the last minute. The parallels are amazing, many very large corporations will need to fix (notice the future tense) a ton of software that is not IPv6 ready and the last time any of it was reviewed was for Y2K and that guy is long since gone and it is written in a language that no one understands and testing will require at least one of each type of environment (IPv4, IPv6, Dual-Stack, ArcNet ^H^H^H^H^H^H) --Dave (How many sick days do I have left?) From joelja at bogus.com Tue Jun 14 23:43:22 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 14 Jun 2011 21:43:22 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <377E4C6A-D179-4083-B3EF-5E71FE612113@delong.com> References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> <377E4C6A-D179-4083-B3EF-5E71FE612113@delong.com> Message-ID: <6D5F9460-7ED2-4CAC-802B-6E72F8CF903B@bogus.com> On Jun 13, 2011, at 5:41 PM, Owen DeLong wrote: > > On Jun 12, 2011, at 11:12 AM, Iljitsch van Beijnum wrote: > >> On 12 jun 2011, at 15:45, Leo Bicknell wrote: >> >>>> Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. >> >>> Huh? This is no worse than IPv4 where a host comes up and sends a >>> subnet-broadcast to get DHCP. >> >> The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing. >> > > Which is no worse than the behavior of an IPv4 host on a network without a DHCP server. An ipv4 host will in most cases configure itself with a link-local address. A possibly surprising number of people consider this broken, when in fact it's working. the possiblity that autoconfiguration of networks would occur when no routers or dhcp servers exist has some utility just as it did when windows started doing this with ipv4 circa 1998. > Owen > > > From ryan.finnesey at HarrierInvestments.com Wed Jun 15 00:33:49 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 14 Jun 2011 22:33:49 -0700 Subject: Thank you Microsoft (and others) In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CE46011@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <001201cc25f9$82a72be0$87f583a0$@com><4E6F2271-264F-4C6D-8881-1BE537A194AF@puck.nether.net><218A1779A7A0984894CBD218EFF84AC45D9765@CEXMB003.nmes.lcl> <0AB09EDBCD1C484EBE45978D62F3513C3CE46011@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03B2560C@EXVBE005-2.exch005intermedia.net> Hi Chris Does Azure support IPv6 at this time? Cheers Ryan -----Original Message----- From: Christopher Palmer [mailto:Christopher.Palmer at microsoft.com] Sent: Friday, June 10, 2011 2:20 PM To: Murphy, Jay, DOH; Jared Mauch; Shahid Shafi Cc: NANOG list Subject: RE: Thank you Microsoft (and others) Thank you for the thanks :) We'll be leaving the www.xbox.com web properties online indefinitely. We're holding on other properties but are moving forward at a brisk pace. Best, Chris -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Friday, June 10, 2011 9:49 AM To: Jared Mauch; Shahid Shafi Cc: NANOG list Subject: RE: Thank you Microsoft (and others) I've been saved by the sound of Microsoft. ~Jay "We move the information that moves your world." ?Engineering is about finding the sweet spot between what's solvable and what isn't." ?Good engineering demands that we understand what we?re doing and why, keep an open mind, and learn from experience.? Radia Perlman P Please consider the environment before printing e-mail -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Wednesday, June 08, 2011 7:20 PM To: Shahid Shafi Cc: NANOG list Subject: Thank you Microsoft (and others) I think it's important to thank Microsoft for leaving sites like xbox IPv6 enabled. Hope many other participants leave it on as well. I think it's a certain sign of the maturity of the protocol and networks at this stage of the game. I have observed some traffic step-down in the network, but it's not entirely clear if it's lowered to levels pre-v6-day. Looking forward to those sharing data at NANOG next week. (I'm not convinced the data I have is worth sharing, but will send it over to the nanogpc soon enough..) - Jared On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: > I dont think ISOC dashboard is updating any more. Google is no longer > advertising AAAA but dashboard still shows green and TTLs were short > on those records. From ryan.finnesey at HarrierInvestments.com Wed Jun 15 00:33:51 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 14 Jun 2011 22:33:51 -0700 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <4DEF9047.5090404@nac.net> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> I think this would be helpful. Cheers Ryan -----Original Message----- From: Ryan Pavely [mailto:paradox at nac.net] Sent: Wednesday, June 08, 2011 11:08 AM To: nanog at nanog.org Subject: Re: So... is it time to do IPv6 day monthy yet? I was thinking the same thing. Good call :) Ryan Pavely Net Access Corporation http://www.nac.net/ On 6/8/2011 10:40 AM, Jay Ashworth wrote: > It certainly sounds like it might be. > > Cheers, > -- jra > From owen at delong.com Wed Jun 15 00:33:09 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 22:33:09 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <60B7F9A9-17FC-473F-9FD8-E118F52514FE@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <9E01B76D-3723-4CB9-92F8-87B85699839E@delong.com> <60B7F9A9-17FC-473F-9FD8-E118F52514FE@muada.com> Message-ID: <11F2E1DF-F4A0-437B-A302-997A0283BACB@delong.com> On Jun 14, 2011, at 3:44 PM, Iljitsch van Beijnum wrote: > On 15 jun 2011, at 0:05, Owen DeLong wrote: > >> Yes, the right solution would be to at least separate the VLANs and clean up this >> mess. However, due to software packages that need to talk to each other over >> common local broadcast across that boundary, this isn't possible in this particular >> organization (don't get me started on the bad software, but, that's what there is.) > > Strange that you don't apply the logic of "the existing software is what there is" to the code deep inside hundreds of millions of hosts, but rather to obscure stuff that presumably hardly anyone uses. > > If changing this software is so hard, what these people need is some filtering switches so the application multicasts get forwarded but the IP provisioning multicasts don't. No standards action required. > > BTW, does this broken software run over IPv6, anyway? No, but, it require the v4 stack on the hosts to be on the same link, which means that the v6 stack will also be on the same link. There are less broken scenarios, too. Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS vendors to make changes because experience has shown that they are more willing to do so than vertical software vendors. As such, yes, I'd like to see some harmless extensions added to DHCPv6 that solve some real world problems. Owen From owen at delong.com Wed Jun 15 00:41:41 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 22:41:41 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <9E01B76D-3723-4CB9-92F8-87B85699839E@delong.com> <60B7F9A9-17FC-473F-9FD8-E118F52514FE@muada.com> Message-ID: <318DB7A4-AD69-4132-905E-E7EA488733F1@delong.com> On Jun 14, 2011, at 6:00 PM, Ricky Beam wrote: > On Tue, 14 Jun 2011 18:44:22 -0400, Iljitsch van Beijnum wrote: >> BTW, does this broken software run over IPv6, anyway? > > Poorly designed network plus poorly designed software... I don't know which chicken came first, and it doesn't matter. > > IPv6 is totally different barnyard. Build the v6 network properly -- one gateway (one router, vrrp, whatever) -- and retool the software properly. IPv6 doesn't have a broadcast address; as such if the software is setup to use an appropriate multicast target (presumably in "user defined" space), then it'll talk to exactly the right machines, and it's routable. > > --Ricky Sounds great, but, sometimes proprietary vertical software is a lot harder to move forward than you might think. Owen From owen at delong.com Wed Jun 15 00:40:56 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2011 22:40:56 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> <6CB36F07-7C0E-46BB-B614-88D1CB56F3D4@delong.com> Message-ID: On Jun 14, 2011, at 5:50 PM, Ricky Beam wrote: > On Tue, 14 Jun 2011 18:16:10 -0400, Owen DeLong wrote: >> The point of /64 is to support automatic configuration and incredibly sparse host addressing. >> It is not intended to create stupidly large broadcast domains. > > Several IETF (and NANOG) discussions say otherwise. While current hardware doesn't handle thousands of hosts, the protocol was designed for a future where that's not true. (there's a future where *everything* is network enabled... microwave oven, doorbell, weed whacker, everything.) > Sure, but, that future still doesn't need stupidly large numbers of hosts on a common link. >> A /22 is probably about the upper limit of a sane broadcast domain, but, even with a /22 >> or 1022 nodes max, each sending a packet every 10 seconds you don't get to 100s of PPS, >> you get 102.2pps. > > As I said, DHCP isn't the only source of traffic. Setup a 1000 node network today (just IPv4), and you will see a great deal of broadcast traffic (unless those nodes aren't doing anything.) With IPv6, it's all multicast (v6 doesn't have a "broadcast address") hinged on switches filtering the traffic away from where it doesn't need to be. The all-too-common Best Buy $20 white box ethernet switch does no multicast filtering at all. Pretty much all wireless hardware sucks at multicast - period. These are not things that can be fixed with a simple software update... if the silicon doesn't do it, *it doesn't do it*. Depends on a number of factors. Yes, there are lots of issues. However, they aren't caused by the small number of additional packets from DHCP. Owen From iljitsch at muada.com Wed Jun 15 00:56:07 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 15 Jun 2011 07:56:07 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <11F2E1DF-F4A0-437B-A302-997A0283BACB@delong.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <9E01B76D-3723-4CB9-92F8-87B85699839E@delong.com> <60B7F9A9-17FC-473F-9FD8-E118F52514FE@muada.com> <11F2E1DF-F4A0-437B-A302-997A0283BACB@delong.com> Message-ID: <5A802C48-E4D0-4012-84FC-6FE843BA907E@muada.com> On 15 jun 2011, at 7:33, Owen DeLong wrote: > Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS vendors to make changes > because experience has shown that they are more willing to do so than vertical software vendors. > As such, yes, I'd like to see some harmless extensions added to DHCPv6 that solve some real world > problems. BTW, as long as you're making harmless changes: not putting a hard line end just _after_ 80 characters would make your messages easier to read. As established before, all of this is not harmless and OS vendors (not sure what you're talking about with BIOS) aren't all that willing to make changes, at least not on short timescales. It seems to me that the easiest solution to work around broken IPv4-only software isn't messing with the IPv6 protocol stack, but to create an IPv4 overlay on top of IPv6 that seems like a big IPv4 broadcast domain despite going through IPv6 routers. Actually this would also be quite useful in hosting environments where it would be easy to give every IPv6 customer their own VLAN but the IPv4 subnets are entangled. From jra at baylink.com Wed Jun 15 01:06:26 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 15 Jun 2011 02:06:26 -0400 (EDT) Subject: OT: Sign of the Coming Apocalypse Message-ID: <13513708.308.1308117986049.JavaMail.root@benjamin.baylink.com> (that's next winter, right?) I've just seen a TV ad for Duke Nukem Forever, in a Hulu airing of The Daily Show. Cheers, -- jr 'Finally??' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From joshua.klubi at gmail.com Wed Jun 15 05:38:48 2011 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Wed, 15 Jun 2011 10:38:48 +0000 Subject: OT: Sign of the Coming Apocalypse In-Reply-To: <13513708.308.1308117986049.JavaMail.root@benjamin.baylink.com> References: <13513708.308.1308117986049.JavaMail.root@benjamin.baylink.com> Message-ID: finally after waiting for it 4ever Joshua On Wed, Jun 15, 2011 at 6:06 AM, Jay Ashworth wrote: > (that's next winter, right?) > > I've just seen a TV ad for Duke Nukem Forever, in a Hulu airing of > The Daily Show. > > Cheers, > -- jr 'Finally??' a > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 > 1274 > > From nanog at jima.tk Wed Jun 15 07:32:27 2011 From: nanog at jima.tk (Jima) Date: Wed, 15 Jun 2011 07:32:27 -0500 Subject: ip 6 questions In-Reply-To: <1307910676.2003.8.camel@teh-desktop> References: <1307910676.2003.8.camel@teh-desktop> Message-ID: <4DF8A65B.8050502@jima.tk> On 06/12/2011 03:31 PM, Tom Hill wrote: > On Sun, 2011-06-12 at 14:46 -0400, Deric Kwok wrote: >> We will apply ipv6 from ARIN and try to use it in hosting business >> >> 1/ Can we use it in our current AS which is using ipv4? If not. Do we >> have to apply new AS? > > No, you can route IPv6& IPv4 from the same ASN. > >> 2/ Can arin not allow us to apply ipv4 for the future after we apply ipv6? > > If you need IPv4, apply for it. You might have a *better* chance if you > already have a plan to implement IPv6, than if you have not considered > it. > >> 3/ Any advices to do ipv6 in hosting business > > Software. Plesk barely has IPv6 support (>10.2) and I'm yet to hear > about it from CPanel. FWIW: http://go.cpanel.net/ipv6 -- TL;DR: not there yet. Jima From cb.list6 at gmail.com Wed Jun 15 09:36:48 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 15 Jun 2011 07:36:48 -0700 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> Message-ID: On Jun 14, 2011 10:36 PM, "Ryan Finnesey" < ryan.finnesey at harrierinvestments.com> wrote: > > I think this would be helpful. > Agreed. You don't need anybody's permission, kick it off. The last v6day was an isoc effort, there can be a separate nanog effort or your own. Cb > Cheers > Ryan > > > -----Original Message----- > From: Ryan Pavely [mailto:paradox at nac.net] > Sent: Wednesday, June 08, 2011 11:08 AM > To: nanog at nanog.org > Subject: Re: So... is it time to do IPv6 day monthy yet? > > I was thinking the same thing. Good call :) > > Ryan Pavely > Net Access Corporation > http://www.nac.net/ > > > On 6/8/2011 10:40 AM, Jay Ashworth wrote: > > It certainly sounds like it might be. > > > > Cheers, > > -- jra > > > From dot at dotat.at Wed Jun 15 09:52:13 2011 From: dot at dotat.at (Tony Finch) Date: Wed, 15 Jun 2011 15:52:13 +0100 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: Ricky Beam wrote: > > And IPv6 has been designed (poorly, it would now appear) for huge "LAN"s > -- LANs are supposed to be /64, after all. Ethernet is not designed for huge LANs. If you want that you need to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/ Tony. -- f.anthony.n.finch http://dotat.at/ Fisher, German Bight: Southerly or southwesterly backing southeasterly, 3 or 4, occasionally 5 in Fisher at first, increasing 5 or 6 in Fisher later. Slight, increasing moderate in Fisher. Rain later. Moderate or good, occasionally poor later. From nanog at jima.tk Wed Jun 15 10:22:12 2011 From: nanog at jima.tk (Jima) Date: Wed, 15 Jun 2011 10:22:12 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110614202513.GA49062@ussenterprise.ufp.org> References: <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <20110614202513.GA49062@ussenterprise.ufp.org> Message-ID: <4DF8CE24.1020000@jima.tk> On 06/14/2011 03:25 PM, Leo Bicknell wrote: > I urge everyone in this thread to try a simple experiment. Configure > an IPv6 segment in your lab. Make sure there is no IPv4 on it, not > on the router, and that the IPv4 stack (to the extent possible) is > disabled on the hosts. Now try to use one of the hosts to access IPv6 > content. Been there, done that, fairly happily -- with both Windows 7 and Linux (Fedora 13 or 14, I forget). > You'll find the box does SLAAC just fine and gets an address. You'll > find RA's provide a default gateway and can get your packets out to the > world. You'll also find absolutely nothing works, at a bare minimum > because you have no DNS servers. Err, no, that's not universally true. The version of NetworkManager in recent-ish Fedora and Ubuntu (can't attest to other distros) supports the RDNSS field in RAs (available in radvd since 1.0, ~2006-11-01). You do need to explicitly disable IPv4 in NM, however, or it'll consider the lack of DHCPv4 to be a general network failure. RHEL 5 won't work without manually configuring a DNS address; everything I've heard indicates that RHEL 6 supports RDNSS, however. Windows 7 is a bit of an odd duck; without any defined DNS servers it defaults to the following (deprecated) site-local addresses: fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 Adding a route/config for those on your actual DNS server(s) allows Windows to get working DNS, as well. (I don't recall if I had to explicitly disable IPv4 to get IPv6-only working, though.) I will agree that Windows XP is more or less dead in the water in your defined scenario (I've heard you can shoehorn IPv6 DNS servers into its config, but it's not trivial; I haven't confirmed this); I haven't tested Vista but I believe its behavior is probably closer to 7 than XP. > The IETF is working on one solution, which is to add DNS information to > the RA's! So now you'll configure your routers to hand out DNS servers > to clients, and then everything else (NTP servers, Domain Controllers, > etc) in DHCP! Oh, oops; you did touch upon this. You might want to let the people who've implemented RDNSS in software know that the IETF is working on it. I'm sure that'll be a relief. Jima From dmburgess at linktechs.net Wed Jun 15 10:46:05 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Wed, 15 Jun 2011 10:46:05 -0500 Subject: OT: Sign of the Coming Apocalypse References: <13513708.308.1308117986049.JavaMail.root@benjamin.baylink.com> Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50547C29B@ltiserver.lti.local> Mine got delivered to my office yesterday! :) Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > -----Original Message----- > From: Joshua William Klubi [mailto:joshua.klubi at gmail.com] > Sent: Wednesday, June 15, 2011 4:39 AM > To: Jay Ashworth > Cc: NANOG > Subject: Re: OT: Sign of the Coming Apocalypse > > finally after waiting for it 4ever > > Joshua > > On Wed, Jun 15, 2011 at 6:06 AM, Jay Ashworth wrote: > > > (that's next winter, right?) > > > > I've just seen a TV ad for Duke Nukem Forever, in a Hulu airing of The > > Daily Show. > > > > Cheers, > > -- jr 'Finally??' a > > -- > > Jay R. Ashworth Baylink > > jra at baylink.com > > Designer The Things I Think RFC > > 2100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > > DII > > St Petersburg FL USA http://photo.imageinc.us +1 727 647 > > 1274 > > > > From iljitsch at muada.com Wed Jun 15 10:52:39 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 15 Jun 2011 17:52:39 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: On 15 jun 2011, at 16:52, Tony Finch wrote: > Ethernet is not designed for huge LANs. If you want that you need > to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/ Hm: "Our object is to design a communication system which can grow smoothly to accommodate several buildings full of personal computers and the facilities needed for their support." Ethernet: Distributed Packet Switching for Local Computer Networks Robert M. Metcalfe and David R. Boggs Communications of the ACM Volume 19 Issue 7, July 1976 From bicknell at ufp.org Wed Jun 15 11:39:06 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 15 Jun 2011 09:39:06 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <4DF8CE24.1020000@jima.tk> References: <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <20110614202513.GA49062@ussenterprise.ufp.org> <4DF8CE24.1020000@jima.tk> Message-ID: <20110615163906.GA99062@ussenterprise.ufp.org> In a message written on Wed, Jun 15, 2011 at 10:22:12AM -0500, Jima wrote: > Oh, oops; you did touch upon this. You might want to let the people > who've implemented RDNSS in software know that the IETF is working on > it. I'm sure that'll be a relief. Maybe I'm missing something, but the last update on this was RFC 5006 I think, which is marked as "experimental", and I thought the IETF still had a working group discussing it. That is, I didn't think it was a finalized standard yet. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From iljitsch at muada.com Wed Jun 15 11:45:32 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 15 Jun 2011 18:45:32 +0200 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110615163906.GA99062@ussenterprise.ufp.org> References: <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <20110614202513.GA49062@ussenterprise.ufp.org> <4DF8CE24.1020000@jima.tk> <20110615163906.GA99062@ussenterprise.ufp.org> Message-ID: <0E0AB5D9-B84F-400B-93DC-EF946AA48C16@muada.com> On 15 jun 2011, at 18:39, Leo Bicknell wrote: > Maybe I'm missing something, but the last update on this was RFC > 5006 I think, which is marked as "experimental", and I thought the > IETF still had a working group discussing it. You missed the upgrade to proposed standard: http://tools.ietf.org/html/rfc6106 > That is, I didn't think it was a finalized standard yet. The IETF rarely gets around to bringing something from proposed standard to standard. For instance, HTTP and BGP aren't standards either. From james at cs.fiu.edu Wed Jun 15 11:47:43 2011 From: james at cs.fiu.edu (James Grace) Date: Wed, 15 Jun 2011 12:47:43 -0400 Subject: Consequences of BGP Peering with Private Addresses Message-ID: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> Hey All, So we're running out of peering space in our /24 and we were considering using private /30's for new peerings. Are there any horrific consequences to picking up this practice? Cheers, James From patrick at ianai.net Wed Jun 15 11:54:11 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 15 Jun 2011 12:54:11 -0400 Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> References: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> Message-ID: <5A7E91C7-96EA-48DC-8420-9A676C12650C@ianai.net> On Jun 15, 2011, at 12:47 PM, James Grace wrote: > So we're running out of peering space in our /24 and we were considering using private /30's for new peerings. Are there any horrific consequences to picking up this practice? "Horrific"? How about: "Most peers won't bring up a session." What happens if the peer is using 1918 space internally? -- TTFN, patrick From nick at foobar.org Wed Jun 15 11:54:41 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 15 Jun 2011 17:54:41 +0100 Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> References: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> Message-ID: <4DF8E3D1.3040700@foobar.org> On 15/06/2011 17:47, James Grace wrote: > So we're running out of peering space in our /24 and we were considering > using private /30's for new peerings. Are there any horrific > consequences to picking up this practice? yes. it causes nasty problems if you use urpf (as you should), in particular with pmtu discovery and traceroute. Nick From cb.list6 at gmail.com Wed Jun 15 11:56:52 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 15 Jun 2011 09:56:52 -0700 Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> References: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> Message-ID: On Wed, Jun 15, 2011 at 9:47 AM, James Grace wrote: > Hey All, > > So we're running out of peering space in our /24 and we were considering using private /30's for new peerings. ?Are there any horrific consequences to picking up this practice? > You can reclaim space by switching your peerings to /31s where possible. If you go down the private space route, make sure you and your peers know about "next hop self" Cameron From isabeldias1 at yahoo.com Wed Jun 15 11:59:31 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Wed, 15 Jun 2011 09:59:31 -0700 (PDT) Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> Message-ID: <799580.73222.qm@web121602.mail.ne1.yahoo.com> IPv4? IPv6? are you planning to do NAT or PAT? Are you using a bogous ASN 64512 through 65534 to be used for private purposes? /30 -> 4 addresses/2 hosts -> you can't do a mesh configuration w/ that subnet mask.......... --- On Wed, 6/15/11, James Grace wrote: > From: James Grace > Subject: Consequences of BGP Peering with Private Addresses > To: nanog at nanog.org > Date: Wednesday, June 15, 2011, 6:47 PM > Hey All, > > So we're running out of peering space in our /24 and we > were considering using private /30's for new peerings.? > Are there any horrific consequences to picking up this > practice? > > Cheers, > James > > > From sthaug at nethelp.no Wed Jun 15 12:04:44 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 15 Jun 2011 19:04:44 +0200 (CEST) Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: Message-ID: <20110615.190444.78802531.sthaug@nethelp.no> > > Ethernet is not designed for huge LANs. If you want that you need > > to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/ > > Hm: > > "Our object is to design a communication system which can grow smoothly to accommodate several buildings full of personal computers and the facilities needed for their support." > > Ethernet: Distributed Packet Switching for Local Computer Networks > Robert M. Metcalfe and David R. Boggs > Communications of the ACM Volume 19 Issue 7, July 1976 So let's change it slightly: Ethernet is not designed for huge broadcast domains. How big is huge? To some degree it depends on how broadcast "chatty" the protocols used are - but there's also the matter of having a size which makes it possible to troubleshoot. Personally I'd prefer an upper limit of a few hundred computers. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From isabeldias1 at yahoo.com Wed Jun 15 12:07:27 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Wed, 15 Jun 2011 10:07:27 -0700 (PDT) Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: <5A7E91C7-96EA-48DC-8420-9A676C12650C@ianai.net> Message-ID: <622902.9247.qm@web121605.mail.ne1.yahoo.com> i guess you have a lot of ibgp sessions ..........:-) bgp finite state model http://www.inetdaemon.com/tutorials/internet/ip/routing/bgp/operation/finite_state_model.shtml http://docs.google.com/viewer?a=v&q=cache:C5Rq3DV63akJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.71.3908%26rep%3Drep1%26type%3Dpdf+BGP+finite+machine&hl=en&gl=uk&pid=bl&srcid=ADGEESiwviFqLXrhPybI3RwpVftr_qlgTSZbIzw2b6rlIEAKE8pqIN-D_2BpJIDacMx18AVSBpZtVAYLoPiUcsLbzDOVAcH9whrXJqB8zFm6R7ImuKNoC8dkYD_OHliYNrldoLGde9Hc&sig=AHIEtbQa0Typ1WE3rB9ztWZaYFIA8t-mag http://tools.ietf.org/html/rfc4271 --- On Wed, 6/15/11, Patrick W. Gilmore wrote: > From: Patrick W. Gilmore > Subject: Re: Consequences of BGP Peering with Private Addresses > To: "NANOG list" > Date: Wednesday, June 15, 2011, 6:54 PM > On Jun 15, 2011, at 12:47 PM, James > Grace wrote: > > > So we're running out of peering space in our /24 and > we were considering using private /30's for new > peerings.? Are there any horrific consequences to > picking up this practice? > > "Horrific"?? How about: "Most peers won't bring up a > session." > > What happens if the peer is using 1918 space internally? > > -- > TTFN, > patrick > > > From Valdis.Kletnieks at vt.edu Wed Jun 15 12:21:57 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 15 Jun 2011 13:21:57 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: Your message of "Wed, 15 Jun 2011 19:04:44 +0200." <20110615.190444.78802531.sthaug@nethelp.no> References: <20110615.190444.78802531.sthaug@nethelp.no> Message-ID: <14504.1308158517@turing-police.cc.vt.edu> On Wed, 15 Jun 2011 19:04:44 +0200, sthaug at nethelp.no said: > How big is huge? To some degree it depends on how broadcast "chatty" > the protocols used are - but there's also the matter of having a > size which makes it possible to troubleshoot. Personally I'd prefer > an upper limit of a few hundred computers. And whatever you do, don't be like one med school and build a flat net so big that spanning tree won't converge. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nathan at atlasnetworks.us Wed Jun 15 12:26:19 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 15 Jun 2011 17:26:19 +0000 Subject: SORBs Human Message-ID: <8C26A4FDAE599041A13EB499117D3C286B498EB1@ex-mb-1.corp.atlasnetworks.us> Could a human being from SORBs please contact me off-list? Your robot isn't functional, and you are listing one of our ARIN allocations as dynamic, when it is not. (Yes, I know that 'no one uses' SORBs. Customers don't care.) Nathan From nanog at jima.tk Wed Jun 15 12:29:09 2011 From: nanog at jima.tk (Jima) Date: Wed, 15 Jun 2011 12:29:09 -0500 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <0E0AB5D9-B84F-400B-93DC-EF946AA48C16@muada.com> References: <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <20110614202513.GA49062@ussenterprise.ufp.org> <4DF8CE24.1020000@jima.tk> <20110615163906.GA99062@ussenterprise.ufp.org> <0E0AB5D9-B84F-400B-93DC-EF946AA48C16@muada.com> Message-ID: <4DF8EBE5.4000805@jima.tk> On 06/15/2011 11:45 AM, Iljitsch van Beijnum wrote: > On 15 jun 2011, at 18:39, Leo Bicknell wrote: > >> Maybe I'm missing something, but the last update on this was RFC >> 5006 I think, which is marked as "experimental", and I thought the >> IETF still had a working group discussing it. > > You missed the upgrade to proposed standard: > > http://tools.ietf.org/html/rfc6106 > >> That is, I didn't think it was a finalized standard yet. > > The IETF rarely gets around to bringing something from proposed standard to standard. For instance, HTTP and BGP aren't standards either. Thanks for the citation, right. I also probably should also have cited http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems -- the notable holdouts to RDNSS (that support DHCPv6) seem to be Windows, Solaris, AIX, and IBM i. Unfortunate. Jima From lstewart at superb.net Wed Jun 15 13:24:01 2011 From: lstewart at superb.net (Landon Stewart) Date: Wed, 15 Jun 2011 11:24:01 -0700 Subject: Eircom Networks (of Ireland) contact me off list please Message-ID: EHLO Folks, Can someone from Eircom please contact me? -- Landon Stewart SuperbHosting.Net by Superb Internet Corp. Toll Free (US/Canada): 888-354-6128 x 4199 Direct: 206-438-5879 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From ken at sizone.org Wed Jun 15 14:06:58 2011 From: ken at sizone.org (Ken Chase) Date: Wed, 15 Jun 2011 15:06:58 -0400 Subject: SORBs Human In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B498EB1@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C286B498EB1@ex-mb-1.corp.atlasnetworks.us> Message-ID: <20110615190658.GB20668@sizone.org> On Wed, Jun 15, 2011 at 05:26:19PM +0000, Nathan Eisenberg said: >Could a human being from SORBs please contact me off-list? Your robot isn't functional, and you are listing one of our ARIN allocations as dynamic, when it is not. > >(Yes, I know that 'no one uses' SORBs. Customers don't care.) > >Nathan we've been thru this. please respect the sacrifices previous humans have made on our collective behalf. google nanog + sorbs. let's move this project forward, perhaps hiring a skiptracer and a negotiator to be very persuasive in person to fix sorbs once and for all. anyone who uses sorbs as a filter is breaking internets. tell your customers target's admins. /kc -- Ken Chase - ken at sizone.org Toronto CANADA From jeroen at mompl.net Wed Jun 15 14:14:15 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 15 Jun 2011 12:14:15 -0700 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: References: <4DEF40C8.3020502@unfix.org> Message-ID: <4DF90487.1030600@mompl.net> Octavio Alvarez wrote: > In fact. Although a website of mine worked flawlessly in a dual-stack > but it did NOT in an IPv6-only environment. Unfortunately, the problem > has to be fixed in the DNS provider, which though supporting AAAA > records was enough to "support IPv6". Why not run your own nameserver if it is your website assuming you own the domain? Out of curiosity, what are the options you need to use to properly enable bind for IPv6? To me it appears there isn't that much to it, it almost works out of the box with 1 or 2 things turned on. Then you just add the appropriate zone files or records. Am I missing something blatantly obvious that will break it? > dig -6 +trace is our friend here. How would you apply this command to determine correct IPv6 resolving? Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From sethm at rollernet.us Wed Jun 15 14:24:44 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 15 Jun 2011 12:24:44 -0700 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: <4DF90487.1030600@mompl.net> References: <4DEF40C8.3020502@unfix.org> <4DF90487.1030600@mompl.net> Message-ID: <4DF906FC.8040905@rollernet.us> On 6/15/2011 12:14, Jeroen van Aart wrote: > Octavio Alvarez wrote: >> In fact. Although a website of mine worked flawlessly in a dual-stack >> but it did NOT in an IPv6-only environment. Unfortunately, the problem >> has to be fixed in the DNS provider, which though supporting AAAA >> records was enough to "support IPv6". > > Why not run your own nameserver if it is your website assuming you own > the domain? > > Out of curiosity, what are the options you need to use to properly > enable bind for IPv6? To me it appears there isn't that much to it, it > almost works out of the box with 1 or 2 things turned on. Then you just > add the appropriate zone files or records. Am I missing something > blatantly obvious that will break it? > listen-on-v6 { any; }; Simple as that. Indicate individual addresses, if preferred. Or switch to a DNS provider that has made this monumental configuration effort. ~Seth From jeroen at mompl.net Wed Jun 15 14:32:09 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 15 Jun 2011 12:32:09 -0700 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: <4DF906FC.8040905@rollernet.us> References: <4DEF40C8.3020502@unfix.org> <4DF90487.1030600@mompl.net> <4DF906FC.8040905@rollernet.us> Message-ID: <4DF908B9.7040108@mompl.net> Seth Mattinen wrote: > listen-on-v6 { any; }; Yeah that's what I did. But I keep reading about how these big name companies messed it up in some subtle or not so subtle way and I keep thinking I must have missed something. Because surely those big companies can't find it that difficult, can they? :-) > Simple as that. Indicate individual addresses, if preferred. Or switch > to a DNS provider that has made this monumental configuration effort. I'd rather have the fuzzy warm feeling of accomplishment of IPv6 enabling my own nameserver. Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From sethm at rollernet.us Wed Jun 15 14:38:44 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 15 Jun 2011 12:38:44 -0700 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: <4DF908B9.7040108@mompl.net> References: <4DEF40C8.3020502@unfix.org> <4DF90487.1030600@mompl.net> <4DF906FC.8040905@rollernet.us> <4DF908B9.7040108@mompl.net> Message-ID: <4DF90A44.5000502@rollernet.us> On 6/15/2011 12:32, Jeroen van Aart wrote: > Seth Mattinen wrote: >> listen-on-v6 { any; }; > > Yeah that's what I did. But I keep reading about how these big name > companies messed it up in some subtle or not so subtle way and I keep > thinking I must have missed something. Because surely those big > companies can't find it that difficult, can they? :-) > >> Simple as that. Indicate individual addresses, if preferred. Or switch >> to a DNS provider that has made this monumental configuration effort. > > I'd rather have the fuzzy warm feeling of accomplishment of IPv6 > enabling my own nameserver. > I can send you a copy of my config offlist if you'd like; there's really nothing to it and it's been going along fine for as long as I can remember. In the simple case of answering on a v6 address I can't see how that could go wrong unless the network it was on had other IPv6 failings. ~Seth From bicknell at ufp.org Wed Jun 15 15:41:33 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 15 Jun 2011 13:41:33 -0700 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: <4DF908B9.7040108@mompl.net> References: <4DEF40C8.3020502@unfix.org> <4DF90487.1030600@mompl.net> <4DF906FC.8040905@rollernet.us> <4DF908B9.7040108@mompl.net> Message-ID: <20110615204133.GA10495@ussenterprise.ufp.org> In a message written on Wed, Jun 15, 2011 at 12:32:09PM -0700, Jeroen van Aart wrote: > Seth Mattinen wrote: > >listen-on-v6 { any; }; > > Yeah that's what I did. But I keep reading about how these big name > companies messed it up in some subtle or not so subtle way and I keep > thinking I must have missed something. Because surely those big > companies can't find it that difficult, can they? :-) But you see, those big companies didn't have a place in the Excel spreadsheet for DNS changes to indicate an IPv6 address, so the DNS team couldn't submit the right information to the Firewall team, but it all doesn't matter because the network team hadn't actually made IPv6 work yet as there was no business case. No, I'm not cynical. :) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jeroen at mompl.net Wed Jun 15 15:48:51 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 15 Jun 2011 13:48:51 -0700 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: <20110615204133.GA10495@ussenterprise.ufp.org> References: <4DEF40C8.3020502@unfix.org> <4DF90487.1030600@mompl.net> <4DF906FC.8040905@rollernet.us> <4DF908B9.7040108@mompl.net> <20110615204133.GA10495@ussenterprise.ufp.org> Message-ID: <4DF91AB3.6020107@mompl.net> Leo Bicknell wrote: > but it all doesn't matter because the network team hadn't actually > made IPv6 work yet as there was no business case. Ahhh, ok, well at least I know I did it right the first time. > No, I'm not cynical. :) It probably reflects daily practice for many big organisations, sadly. Luckily I can configure dns, firewall/routing and (ipv6) networking myself, so no need of passing along spreadsheets (besides I really hate spreadsheets). Seth Mattinen wrote: > I can send you a copy of my config offlist if you'd like; there's really > nothing to it and it's been going along fine for as long as I can That won't be necessary, thanks. I think I have configured it correctly and created the correct IPv6 records. Just wanted to make sure. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From marka at isc.org Wed Jun 15 17:05:14 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 16 Jun 2011 08:05:14 +1000 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: Your message of "Wed, 15 Jun 2011 13:48:51 MST." <4DF91AB3.6020107@mompl.net> References: <4DEF40C8.3020502@unfix.org> <4DF90487.1030600@mompl.net> <4DF906FC.8040905@rollernet.us> <4DF908B9.7040108@mompl.net> <20110615204133.GA10495@ussenterprise.ufp.org> <4DF91AB3.6020107@mompl.net> Message-ID: <20110615220514.AD2F910CCA4C@drugs.dv.isc.org> In message <4DF91AB3.6020107 at mompl.net>, Jeroen van Aart writes: > Leo Bicknell wrote: > > but it all doesn't matter because the network team hadn't actually > > made IPv6 work yet as there was no business case. > > Ahhh, ok, well at least I know I did it right the first time. > > > No, I'm not cynical. :) > > It probably reflects daily practice for many big organisations, sadly. > Luckily I can configure dns, firewall/routing and (ipv6) networking > myself, so no need of passing along spreadsheets (besides I really hate > spreadsheets). > > Seth Mattinen wrote: > > I can send you a copy of my config offlist if you'd like; there's really > > nothing to it and it's been going along fine for as long as I can > > That won't be necessary, thanks. I think I have configured it correctly > and created the correct IPv6 records. Just wanted to make sure. > > Greetings, > Jeroen > > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > You tell named to listen on IPv6 (listen-on-v6). It already uses IPv6 to make queries unless you turned it off on the command line with "named -4". To go IPv6 only on a dual stack machine use "named -6". You add AAAA records to the zones for the nameservers. You update your glue records in the parent zone to include AAAA records as well as A records. You add IPv6 address to resolv.conf or equivalent (DHCPv6, the new RA option). You can mark non-local ula's as bogus and your one local ulas as good in named.conf. servers fc00::/7 { bogus yes; }; servers fdxx:xxxx:xxxx::/48 { bogus no; }; If you are only using IPv6 internally servers ::/0 { bogus yes; }; servers { bogus no; }; You should also be doing this at the routing level. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dr at cluenet.de Wed Jun 15 17:47:57 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 16 Jun 2011 00:47:57 +0200 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: <20110615220514.AD2F910CCA4C@drugs.dv.isc.org> References: <4DEF40C8.3020502@unfix.org> <4DF90487.1030600@mompl.net> <4DF906FC.8040905@rollernet.us> <4DF908B9.7040108@mompl.net> <20110615204133.GA10495@ussenterprise.ufp.org> <4DF91AB3.6020107@mompl.net> <20110615220514.AD2F910CCA4C@drugs.dv.isc.org> Message-ID: <20110615224757.GA25879@srv03.cluenet.de> On Thu, Jun 16, 2011 at 08:05:14AM +1000, Mark Andrews wrote: > You tell named to listen on IPv6 (listen-on-v6). It already uses IPv6 > to make queries unless you turned it off on the command line with "named -4". > To go IPv6 only on a dual stack machine use "named -6". > You add AAAA records to the zones for the nameservers. > You update your glue records in the parent zone to include AAAA records > as well as A records. > You add IPv6 address to resolv.conf or equivalent (DHCPv6, the new RA option). > > You can mark non-local ula's as bogus and your one local ulas as good in > named.conf. And you check all your ACLs and TSIG server definitions etc. because suddenly zone transfers, DNS UPDATEs and other stuff (rndc!) might magically use IPv6 and don't match your ACLs etc. anymore. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From kauer at biplane.com.au Wed Jun 15 18:06:14 2011 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 16 Jun 2011 09:06:14 +1000 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: <1308179174.2566.279.camel@karl> On Wed, 2011-06-15 at 17:52 +0200, Iljitsch van Beijnum wrote: > "Our object is to design a communication system which can grow smoothly to accommodate several buildings full of personal computers and the facilities needed for their support." > > Ethernet: Distributed Packet Switching for Local Computer Networks > Robert M. Metcalfe and David R. Boggs > Communications of the ACM Volume 19 Issue 7, July 1976 To be fair, though, the concept of "large LAN" might have changed a little since 1976... and "buildings full" is not exactly a precise unit of measurement. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From conte at isoc.org Wed Jun 15 18:35:08 2011 From: conte at isoc.org (Steve Conte) Date: Wed, 15 Jun 2011 16:35:08 -0700 Subject: IETF Fellowship Announcement (IETF 82 and 83) Message-ID: Dear Colleagues, The Internet Society has announced that it is inviting applications for its latest Internet Society Fellowships to the IETF, part of its Next Generation Leaders (NGL) programme (www.InternetSociety.org/Leaders). The Fellowship programme allows engineers from developing countries to attend an Internet Engineering Task Force (IETF) meeting. As you know, the IETF is the Internet's premier standards-making body, responsible for the development of protocols used in IP-based networks. IETF participants represent an international community of network designers, operators, vendors, and researchers involved in the technical operation of the Internet and the continuing evolution of Internet architecture. Fellowships will be awarded through a competitive application process. The Internet Society is currently accepting fellowship applications for the next two IETF meetings: * IETF 82, 13 - 18 Nov 2011, Taipei, TW * IETF 83, 25 - 30 March, Paris, FR http://www.isoc.org/educpillar/fellowship/index.php Fellowship applications for both IETF meetings are due by 15 July 2011. Please note that this fellowship is aimed at individuals from developing regions that possess a solid level of technical education and enough knowledge about concrete areas of IETF work to follow and benefit from the meeting?s technical discussions. I encourage you to pass on information about this program to individuals involved in your network that have a keen interest in the Internet standardisation activities of the IETF. The Internet Society Fellowships to the IETF are sponsored by Afilias, Google, Microsoft, and Intel. The Internet Society?s Next Generation Leaders programme is sponsored by Nominet Trust, the Association Fran?aise pour le Nommage Internet en Coop?ration (AFNIC), SIDN, and the European Commission. If you have questions, please do not hesitate to contact Steve Conte . Kind Regards, Steve Conte Internet Society ----- Steve Conte conte at isoc.org From nanog at deman.com Wed Jun 15 18:50:48 2011 From: nanog at deman.com (Michael DeMan) Date: Wed, 15 Jun 2011 16:50:48 -0700 Subject: good geographic for servers reaching the South East Asia market Message-ID: Hi All, I guess this is a bit off-topic since this is the North American network operators group, but I was wondering if anybody had much experience with fiber infrastructure in the South East Asia area. For reference, generally the WikiPedia entry on South East Asia describes the service delivery area: http://en.wikipedia.org/wiki/Southeast_Asia Basically looking for tips on what cities/countries/locations have as much (mostly submarine cabling in this case?) fiber connectivity and redundancy. From there I can trim down where to begin looking specifically at data centers and colocation options. Also, if anybody offhand has any tips on political stability and/or the risk of some kind of unwanted censorship by a given country, that would be helpful as well. Feel free to post back on-list or off-list. Thanks, - Michael DeMan From cgriffin at ufl.edu Wed Jun 15 21:51:52 2011 From: cgriffin at ufl.edu (Chris Griffin) Date: Wed, 15 Jun 2011 22:51:52 -0400 Subject: Large jump in global table prefix count? Message-ID: Anyone else notice a rather large jump in the global table size? We just gained around 20K prefixes in just the last few hours. From http://www.cidr-report.org/as2.0/#General_Status Top 20 Net Increased Routes per Originating AS Prefixes Change ASnum AS Description 19227 115->19342 AS15557 LDCOMNET NEUF CEGETEL (formerly LDCOM NETWORKS) Tnx Chris -- Chris Griffin cgriffin at ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 From Valdis.Kletnieks at vt.edu Wed Jun 15 22:05:38 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 15 Jun 2011 23:05:38 -0400 Subject: Large jump in global table prefix count? In-Reply-To: Your message of "Wed, 15 Jun 2011 22:51:52 EDT." References: Message-ID: <5177.1308193538@turing-police.cc.vt.edu> On Wed, 15 Jun 2011 22:51:52 EDT, Chris Griffin said: > Prefixes Change ASnum AS Description > 19227 115->19342 AS15557 LDCOMNET NEUF CEGETEL (formerly LDCOM NETWORKS) Somehow, I get the feeling that a network engineer at AS15557 is about to have a very bad work shift. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ops.lists at gmail.com Wed Jun 15 22:06:09 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 16 Jun 2011 08:36:09 +0530 Subject: good geographic for servers reaching the South East Asia market In-Reply-To: References: Message-ID: Singapore, with a fallback / DR location in say Hong Kong. [Or vice versa depending on what parts of south east asia you want .. for india, singapore would be your best bet] On Thu, Jun 16, 2011 at 5:20 AM, Michael DeMan wrote: > > For reference, generally the WikiPedia entry on South East Asia describes the service delivery area: > http://en.wikipedia.org/wiki/Southeast_Asia > > Basically looking for tips on what cities/countries/locations have as much (mostly submarine cabling in this case?) fiber connectivity and redundancy. ?From there I can trim down where to begin looking specifically at data centers and colocation options. -- Suresh Ramasubramanian (ops.lists at gmail.com) From bobbyjim at gmail.com Wed Jun 15 22:50:11 2011 From: bobbyjim at gmail.com (Bobby Mac) Date: Wed, 15 Jun 2011 22:50:11 -0500 Subject: Firehost as a cloud provider Message-ID: Anyone have experience with Firehost? I have a personal site that I am considering hosting with them and due to the content, am worried about security but don't want to spend the cycles building NIDs and HIDs for myself. I due need PCI compliance as well. If things take off, I'll look at a dedicated server solution but cloud for things while they are in beta seems to fit. Thanks, Bobbyjim From mobile at g7obs.net Thu Jun 16 05:00:35 2011 From: mobile at g7obs.net (Mike Simkins) Date: Thu, 16 Jun 2011 11:00:35 +0100 Subject: Large jump in global table prefix count? In-Reply-To: <5177.1308193538@turing-police.cc.vt.edu> References: <5177.1308193538@turing-police.cc.vt.edu> Message-ID: <4DF9D443.9080007@g7obs.net> I can only see about 450 right now - perhaps they fixed it On 16/06/11 04:05, Valdis.Kletnieks at vt.edu wrote: > On Wed, 15 Jun 2011 22:51:52 EDT, Chris Griffin said: >> Prefixes Change ASnum AS Description >> 19227 115->19342 AS15557 LDCOMNET NEUF CEGETEL (formerly LDCOM NETWORKS) > Somehow, I get the feeling that a network engineer at AS15557 is about to have > a very bad work shift. ;) From jsw at inconcepts.biz Thu Jun 16 06:09:04 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 16 Jun 2011 07:09:04 -0400 Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> References: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> Message-ID: On Wed, Jun 15, 2011 at 12:47 PM, James Grace wrote: > So we're running out of peering space in our /24 and we were considering using private /30's for new peerings. ?Are there any horrific consequences to picking up this practice? I agree with other posters that this is not a good practice. Is it somehow not possible for you to obtain additional address space? Can you not use neighbor-assigned /30s more frequently to avoid exhausting your existing allocation? For eBGP neighbors, I would sooner use non-unique /30s than utilize RFC1918 space. While this would not allow for correct reverse DNS, and traceroute would be less obvious, it has fewer disadvantages than assigning RFC1918 for your peer link-nets. You will need to re-write next-hop towards iBGP neighbors, though (using next-hop-self or translating to internal numbers for routing protocol use) and you should not re-use the same /30 twice on the same ASBR. This may sound crazy, and it is certainly not an ideal way of doing things; but it is an alternative worth consideration as networks exhaust their available IPv4. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From leigh.porter at ukbroadband.com Thu Jun 16 06:30:35 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 16 Jun 2011 11:30:35 +0000 Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: References: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu>, Message-ID: ________________________________________ From: Jeff Wheeler [jsw at inconcepts.biz] >This may sound crazy, and it is certainly not an ideal way of doing >things; but it is an alternative worth consideration as networks >exhaust their available IPv4. I have not followed this whole thread, but did anybody suggest just using IPv6 for this? -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From tom at ninjabadger.net Thu Jun 16 07:44:01 2011 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 16 Jun 2011 13:44:01 +0100 Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: References: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> , Message-ID: <1308228246.1996.11.camel@teh-desktop> On Thu, 2011-06-16 at 11:30 +0000, Leigh Porter wrote: > I have not followed this whole thread, but did anybody suggest just > using IPv6 for this? I was going to mention this, but it's only the neighbor address that is IPv6. You still need an IPv4 next-hop and that is where the issue is in using RFC1918 within this scenario. Tom From outsider at scarynet.org Thu Jun 16 07:58:43 2011 From: outsider at scarynet.org (Alexander Maassen) Date: Thu, 16 Jun 2011 14:58:43 +0200 Subject: OT: Sign of the Coming Apocalypse In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50547C29B@ltiserver.lti.local> References: <13513708.308.1308117986049.JavaMail.root@benjamin.baylink.com> <13175F96BDC3B34AB1425BAE905B3CE50547C29B@ltiserver.lti.local> Message-ID: <4DF9FE03.2040607@scarynet.org> We europeans had it the 10th already! Hail to the king baby :) Op 15-6-2011 17:46, Dennis Burgess schreef: > Mine got delivered to my office yesterday! :) > > Dennis Burgess, Mikrotik Certified Trainer > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270 Website: http://www.linktechs.net > LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > > >> -----Original Message----- >> From: Joshua William Klubi [mailto:joshua.klubi at gmail.com] >> Sent: Wednesday, June 15, 2011 4:39 AM >> To: Jay Ashworth >> Cc: NANOG >> Subject: Re: OT: Sign of the Coming Apocalypse >> >> finally after waiting for it 4ever >> >> Joshua >> >> On Wed, Jun 15, 2011 at 6:06 AM, Jay Ashworth wrote: >> >>> (that's next winter, right?) >>> >>> I've just seen a TV ad for Duke Nukem Forever, in a Hulu airing of > The >>> Daily Show. >>> >>> Cheers, >>> -- jr 'Finally??' a >>> -- >>> Jay R. Ashworth Baylink >>> jra at baylink.com >>> Designer The Things I Think > RFC >>> 2100 >>> Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover >>> DII >>> St Petersburg FL USA http://photo.imageinc.us +1 > 727 647 >>> 1274 >>> >>> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From snabb at epipe.com Thu Jun 16 08:21:11 2011 From: snabb at epipe.com (Janne Snabb) Date: Thu, 16 Jun 2011 13:21:11 +0000 (UTC) Subject: good geographic for servers reaching the South East Asia market In-Reply-To: References: Message-ID: Hello from Cambodia. I am familiar with the situation in Cambodia and some surrounding countries. On Wed, 15 Jun 2011, Michael DeMan wrote: > Basically looking for tips on what cities/countries/locations > have as much (mostly submarine cabling in this case?) fiber > connectivity and redundancy. From there I can trim down where to > begin looking specifically at data centers and colocation options. Hong Kong, Singapore (and Taiwan). Hong Kong is the best choice for some countries in the region: countries such as Cambodia and Vietnam have their uplinks mostly through Hong Kong. Singapore is the best choice for others: Thailand, Malaysia and Indonesia have good connectivity to Singapore. Taiwan I would place as the 3rd option. No other realistic options exist in the region beyond that... US west coast is often the best option if you are not prepared to spend a lot of money (but check your upstream's peering with major SEA providers first). > Also, if anybody offhand has any tips on political stability > and/or the risk of some kind of unwanted censorship by a given > country, that would be helpful as well. All countries within the region are unsafe when it comes to censorship. Hong Kong is probably the only nearby place which does not openly practice censorship currently, but I would not count on that as it is just a (autonomous) province of China. -- Janne Snabb / EPIPE Communications snabb at epipe.com - http://epipe.com/ From leigh.porter at ukbroadband.com Thu Jun 16 08:28:24 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 16 Jun 2011 13:28:24 +0000 Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: <1308228246.1996.11.camel@teh-desktop> References: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> , , <1308228246.1996.11.camel@teh-desktop> Message-ID: And that will teach me not to read the thread! -- Leigh ________________________________________ From: Tom Hill [tom at ninjabadger.net] Sent: 16 June 2011 13:46 To: nanog at nanog.org Subject: RE: Consequences of BGP Peering with Private Addresses On Thu, 2011-06-16 at 11:30 +0000, Leigh Porter wrote: > I have not followed this whole thread, but did anybody suggest just > using IPv6 for this? I was going to mention this, but it's only the neighbor address that is IPv6. You still need an IPv4 next-hop and that is where the issue is in using RFC1918 within this scenario. Tom ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From asr at latency.net Thu Jun 16 08:33:32 2011 From: asr at latency.net (Adam Rothschild) Date: Thu, 16 Jun 2011 09:33:32 -0400 Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: References: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> Message-ID: Also absent from this discussion is that the RIRs are still issuing address space, and interface addressing is perfectly reasonable justification. -a From ispbuilder at gmail.com Thu Jun 16 10:20:04 2011 From: ispbuilder at gmail.com (Mike) Date: Thu, 16 Jun 2011 12:20:04 -0300 Subject: Clueful Rogers sales rep? Message-ID: <4DFA1F24.9050406@gmail.com> I need to find a clueful Rogers sales rep, if anyone has suggestions, please send them my way. thanks! From rps at maine.edu Thu Jun 16 13:24:28 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 16 Jun 2011 14:24:28 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110615.190444.78802531.sthaug@nethelp.no> References: <20110615.190444.78802531.sthaug@nethelp.no> Message-ID: The beauty of Ethernet is that it's simple. "Ethernet" has evolved considerably, and continues to do so. It's not really fair to make comments about it's sociability and talk about it as if it were still in the state it was 20 years ago: "Ethernet doesn't scale because of collisions and exponential backoff" We got around large collision domains by replacing hubs with switches, effectively shrinking the collision domain to the link between the host and the switch (and only in half-duplex). "Ethernet doesn't scale because of large amounts of broadcast traffic." We started to introduce multicast, and multicast-aware switches in IPv4; in IPv6 there is no broadcast traffic. We won't be able to scale networks up until we can turn off IPv4, but once we can IPv6 will be able to grow much larger in terms of per-LAN. The best practice of no more than 512 per broadcast domain will seem very outdated at that point; especially when you add in multicast flood protection, the available bandwidth goes up, and performance of network interfaces improves. The link you pointed to is talking about flat networks of tens of thousands of hosts; that might be excessive right now... But I can certainly see an IPv6-only LAN (with some filtering to make sure ARP and IPv4 traffic is dropped at the port) scaling easily to thousands of hosts with today's hardware. I know the post is a little off topic; but as someone who's met Metcalfe several times I think it's only fair to not make Ethernet out to be the only thing preventing scaleability of networks. On Wed, Jun 15, 2011 at 1:04 PM, wrote: >> > Ethernet is not designed for huge LANs. If you want that you need >> > to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/ >> >> Hm: >> >> "Our object is to design a communication system which can grow smoothly to accommodate several buildings full of personal computers and the facilities needed for their support." >> >> Ethernet: Distributed Packet Switching for Local Computer Networks >> Robert M. Metcalfe and David R. Boggs >> Communications of the ACM Volume 19 Issue 7, July 1976 > > So let's change it slightly: Ethernet is not designed for huge > broadcast domains. > > How big is huge? To some degree it depends on how broadcast "chatty" > the protocols used are - but there's also the matter of having a > size which makes it possible to troubleshoot. Personally I'd prefer > an upper limit of a few hundred computers. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Thu Jun 16 13:30:05 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Jun 2011 11:30:05 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <745E3D5F-F183-4805-9492-D369C50776E7@delong.com> Message-ID: <9A9330C7-4FAC-49E9-8F06-876F79C2E879@delong.com> On Jun 15, 2011, at 8:52 AM, Iljitsch van Beijnum wrote: > On 15 jun 2011, at 16:52, Tony Finch wrote: > >> Ethernet is not designed for huge LANs. If you want that you need >> to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/ > > Hm: > > "Our object is to design a communication system which can grow smoothly to accommodate several buildings full of personal computers and the facilities needed for their support." > > Ethernet: Distributed Packet Switching for Local Computer Networks > Robert M. Metcalfe and David R. Boggs > Communications of the ACM Volume 19 Issue 7, July 1976 If you take that to mean that they intended to support all of that within a single ethernet broadcast domain, then, they most definitely failed. If you take that to mean that they intend it to be a technology which, with multiple ethernet segments, connected by routers, could scale to meet that goal, then, yes, they succeeded. Owen From owen at delong.com Thu Jun 16 13:31:32 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Jun 2011 11:31:32 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110615163906.GA99062@ussenterprise.ufp.org> References: <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <20110614202513.GA49062@ussenterprise.ufp.org> <4DF8CE24.1020000@jima.tk> <20110615163906.GA99062@ussenterprise.ufp.org> Message-ID: On Jun 15, 2011, at 9:39 AM, Leo Bicknell wrote: > In a message written on Wed, Jun 15, 2011 at 10:22:12AM -0500, Jima wrote: >> Oh, oops; you did touch upon this. You might want to let the people >> who've implemented RDNSS in software know that the IETF is working on >> it. I'm sure that'll be a relief. > > Maybe I'm missing something, but the last update on this was RFC > 5006 I think, which is marked as "experimental", and I thought the > IETF still had a working group discussing it. > > That is, I didn't think it was a finalized standard yet. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ Many of the most widely used technologies on the internet do not become finalized standards at the IETF level until long after they have been in widespread use. Owen From sthaug at nethelp.no Thu Jun 16 13:37:12 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 16 Jun 2011 20:37:12 +0200 (CEST) Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <20110615.190444.78802531.sthaug@nethelp.no> Message-ID: <20110616.203712.74753647.sthaug@nethelp.no> > "Ethernet doesn't scale because of large amounts of broadcast traffic." > > We started to introduce multicast, and multicast-aware switches in > IPv4; in IPv6 there is no broadcast traffic. We won't be able to > scale networks up until we can turn off IPv4, In other words, probably not for another decade at least? > but once we can IPv6 > will be able to grow much larger in terms of per-LAN. The best > practice of no more than 512 per broadcast domain will seem very > outdated at that point; especially when you add in multicast flood > protection, the available bandwidth goes up, and performance of > network interfaces improves. Yes and no. If you remove the broadcast traffic you can *in theory* scale higher. However, this does nothing for the difficulty of L2 troubleshooting, which is a real problem in large flat L2 networks. > The link you pointed to is talking about flat networks of tens of > thousands of hosts; that might be excessive right now... But I can > certainly see an IPv6-only LAN (with some filtering to make sure ARP > and IPv4 traffic is dropped at the port) scaling easily to thousands > of hosts with today's hardware. I'm afraid I remain sceptical, unless we come up with significantly improved methods for L2 troubleshooting. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From rps at maine.edu Thu Jun 16 14:08:37 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 16 Jun 2011 15:08:37 -0400 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <20110616.203712.74753647.sthaug@nethelp.no> References: <20110615.190444.78802531.sthaug@nethelp.no> <20110616.203712.74753647.sthaug@nethelp.no> Message-ID: Are you not using managed switches? It takes me about 1 second to find exactly which device and which port a device is connected to. Once you know that; you have a pretty nice collection of statistics and log messages that usually tell you exactly what is wrong. Or am I missing something? On Thu, Jun 16, 2011 at 2:37 PM, wrote: >> "Ethernet doesn't scale because of large amounts of broadcast traffic." >> >> We started to introduce multicast, and multicast-aware switches in >> IPv4; in IPv6 there is no broadcast traffic. ?We won't be able to >> scale networks up until we can turn off IPv4, > > In other words, probably not for another decade at least? > >> but once we can IPv6 >> will be able to grow much larger in terms of per-LAN. ? The best >> practice of no more than 512 per broadcast domain will seem very >> outdated at that point; especially when you add in multicast flood >> protection, the available bandwidth goes up, and performance of >> network interfaces improves. > > Yes and no. If you remove the broadcast traffic you can *in theory* > scale higher. However, this does nothing for the difficulty of L2 > troubleshooting, which is a real problem in large flat L2 networks. > >> The link you pointed to is talking about flat networks of tens of >> thousands of hosts; that might be excessive right now... ?But I can >> certainly see an IPv6-only LAN (with some filtering to make sure ARP >> and IPv4 traffic is dropped at the port) scaling easily to thousands >> of hosts with today's hardware. > > I'm afraid I remain sceptical, unless we come up with significantly > improved methods for L2 troubleshooting. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Thu Jun 16 14:14:50 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Jun 2011 12:14:50 -0700 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: <4DF908B9.7040108@mompl.net> References: <4DEF40C8.3020502@unfix.org> <4DF90487.1030600@mompl.net> <4DF906FC.8040905@rollernet.us> <4DF908B9.7040108@mompl.net> Message-ID: <1944CD30-EA1B-4B67-A78C-94867DBDB77F@delong.com> On Jun 15, 2011, at 12:32 PM, Jeroen van Aart wrote: > Seth Mattinen wrote: >> listen-on-v6 { any; }; > > Yeah that's what I did. But I keep reading about how these big name companies messed it up in some subtle or not so subtle way and I keep thinking I must have missed something. Because surely those big companies can't find it that difficult, can they? :-) > Well... You may also need to put IPv6 glue records into the upstream DNS servers, depending on whether your nameservers live within the same zone or not. Owen From sthaug at nethelp.no Thu Jun 16 14:39:23 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 16 Jun 2011 21:39:23 +0200 (CEST) Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: References: <20110616.203712.74753647.sthaug@nethelp.no> Message-ID: <20110616.213923.41632535.sthaug@nethelp.no> > Are you not using managed switches? Certainly. > It takes me about 1 second to find exactly which device and which port > a device is connected to. Once you know that; you have a pretty nice > collection of statistics and log messages that usually tell you > exactly what is wrong. Here is where we differ. In my universe, finding which device and port has a particular MAC address is only a small part of L2 troubleshooting. In any case, I guess we'll find out in a decade or so how popular large flat L2 networks are going to be. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From cgrundemann at gmail.com Thu Jun 16 15:06:15 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 16 Jun 2011 14:06:15 -0600 Subject: AAAA on various websites, but they all forgot to enable them on their nameservers.... In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 12:15, Schiller, Heather A wrote: > ...yes, there is a serious lack of v6 enabled eyeballs. ?But it's also > not clear to me from Akamai's stats just how many of the sites they host > are v6 enabled. 2? 12? 500? I remember it being stated that ~40 of their customers would participate in Wv6 Day, but I obviously don't speak for Akamai and I can't find a pointer to that info now... ~Chris > > ?--heather > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From owen at delong.com Thu Jun 16 15:11:09 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Jun 2011 13:11:09 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <6D5F9460-7ED2-4CAC-802B-6E72F8CF903B@bogus.com> References: <51851769-D812-4EEE-84A0-F463B7E852AB@delong.com> <205054C9-A2C7-41D7-8BE9-4D032399BD3C@delong.com> <6F4A16E2-5401-4182-948A-E78C32D619F3@delong.com> <20110612103544.GA25062@srv03.cluenet.de> <20110612134501.GA25078@ussenterprise.ufp.org> <1D63E941-92FA-408F-8F10-63A73077EF0E@muada.com> <377E4C6A-D179-4083-B3EF-5E71FE612113@delong.com> <6D5F9460-7ED2-4CAC-802B-6E72F8CF903B@bogus.com> Message-ID: <5F87D484-C54F-475A-ADB7-3D8A0774B191@delong.com> On Jun 14, 2011, at 9:43 PM, Joel Jaeggli wrote: > > On Jun 13, 2011, at 5:41 PM, Owen DeLong wrote: > >> >> On Jun 12, 2011, at 11:12 AM, Iljitsch van Beijnum wrote: >> >>> On 12 jun 2011, at 15:45, Leo Bicknell wrote: >>> >>>>> Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. >>> >>>> Huh? This is no worse than IPv4 where a host comes up and sends a >>>> subnet-broadcast to get DHCP. >>> >>> The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing. >>> >> >> Which is no worse than the behavior of an IPv4 host on a network without a DHCP server. > > An ipv4 host will in most cases configure itself with a link-local address. A possibly surprising number of people consider this broken, when in fact it's working. the possiblity that autoconfiguration of networks would occur when no routers or dhcp servers exist has some utility just as it did when windows started doing this with ipv4 circa 1998. > Yes, so will an IPv6 host. I'm not understanding your point here. The point of the conversation is that the DHCPv6 packets going out on a network without a DHCPv6 server would be no worse than the DHCPv4 packets on a network without a DHCPv4 server today. Owen From owen at delong.com Thu Jun 16 15:18:52 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Jun 2011 13:18:52 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <5A802C48-E4D0-4012-84FC-6FE843BA907E@muada.com> References: <4DF104C4.8050107@foobar.org> <20110610.121037.74748867.sthaug@nethelp.no> <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <9E01B76D-3723-4CB9-92F8-87B85699839E@delong.com> <60B7F9A9-17FC-473F-9FD8-E118F52514FE@muada.com> <11F2E1DF-F4A0-437B-A302-997A0283BACB@delong.com> <5A802C48-E4D0-4012-84FC-6FE843BA907E@muada.com> Message-ID: On Jun 14, 2011, at 10:56 PM, Iljitsch van Beijnum wrote: > On 15 jun 2011, at 7:33, Owen DeLong wrote: > >> Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS vendors to make changes >> because experience has shown that they are more willing to do so than vertical software vendors. > >> As such, yes, I'd like to see some harmless extensions added to DHCPv6 that solve some real world >> problems. > > BTW, as long as you're making harmless changes: not putting a hard line end just _after_ 80 characters would make your messages easier to read. > OK... Line endings removed per your request. > As established before, all of this is not harmless and OS vendors (not sure what you're talking about with BIOS) aren't all that willing to make changes, at least not on short timescales. > It is harmless. Adding routing information options to DHCPv6 does not in any way harm existing implementations. Adding the ability to simultaneously request DHCP information and RA is a tiny amount of additional traffic on the network (thus also harmless). When I talk about BIOS, I'm taking into account that some DHCP implementations are in the PXE for diskless booting and installation processes, etc. Admittedly, I'm not sure how many BIOS contain IPv6 capability for this as yet anyway, but, it is an area that must eventually get implemented. > It seems to me that the easiest solution to work around broken IPv4-only software isn't messing with the IPv6 protocol stack, but to create an IPv4 overlay on top of IPv6 that seems like a big IPv4 broadcast domain despite going through IPv6 routers. > I'm not sure how you propose creating an IPv4 broadcast domain that isn't an iPv6 link. I mean the theory sounds great, but, in practice, it seems rather far-fetched. > Actually this would also be quite useful in hosting environments where it would be easy to give every IPv6 customer their own VLAN but the IPv4 subnets are entangled. Indeed, if it were even remotely possible. Owen From joelja at bogus.com Thu Jun 16 18:23:38 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 16 Jun 2011 16:23:38 -0700 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: <14504.1308158517@turing-police.cc.vt.edu> References: <20110615.190444.78802531.sthaug@nethelp.no> <14504.1308158517@turing-police.cc.vt.edu> Message-ID: <5E937A01-1F49-48F8-940E-128E9884DE71@bogus.com> On Jun 15, 2011, at 10:21 AM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 15 Jun 2011 19:04:44 +0200, sthaug at nethelp.no said: > >> How big is huge? To some degree it depends on how broadcast "chatty" >> the protocols used are - but there's also the matter of having a >> size which makes it possible to troubleshoot. Personally I'd prefer >> an upper limit of a few hundred computers. > > And whatever you do, don't be like one med school and build a flat net > so big that spanning tree won't converge. ;) by the time you throw trill and vpls into the mix it may be a common or pseudo-common broadcast domain but it's not flat. From nanog at deman.com Thu Jun 16 18:43:25 2011 From: nanog at deman.com (Michael DeMan) Date: Thu, 16 Jun 2011 16:43:25 -0700 Subject: good geographic for servers reaching the South East Asia market In-Reply-To: References: Message-ID: <2004905D-764B-4367-B5C8-FFEE6AC9D71F@deman.com> Hi, I wanted to thank everybody for their feedback. Everything seems to correlate with what I have heard - generally Hong Kong and Singapore are the major hubs, with Tokyo even being an option even though it is not 'geographically' close and also possibly there are options in Malaysia. I think I have what I need for this. I am just a worker-bee on this project getting preliminary information for a potential project by a client next year, which may not or may not even be a 'go' anyway. Out of curiosity, I stumbled across this kind of cool map of submarine cables - does anybody know if it is very accurate or up to date? If nothing else, it is kind of fun to play with since you can slide around and zoom in/out with it and stuff. http://www.cablemap.info/ - Mike On Jun 15, 2011, at 4:50 PM, Michael DeMan wrote: > Hi All, > > I guess this is a bit off-topic since this is the North American network operators group, but I was wondering if anybody had much experience with fiber infrastructure in the South East Asia area. > > For reference, generally the WikiPedia entry on South East Asia describes the service delivery area: > http://en.wikipedia.org/wiki/Southeast_Asia > > Basically looking for tips on what cities/countries/locations have as much (mostly submarine cabling in this case?) fiber connectivity and redundancy. From there I can trim down where to begin looking specifically at data centers and colocation options. > > Also, if anybody offhand has any tips on political stability and/or the risk of some kind of unwanted censorship by a given country, that would be helpful as well. > > Feel free to post back on-list or off-list. > > Thanks, > > - Michael DeMan > > > > > > From marka at isc.org Thu Jun 16 18:47:30 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 17 Jun 2011 09:47:30 +1000 Subject: The stupidity of trying to "fix" DHCPv6 In-Reply-To: Your message of "Thu, 16 Jun 2011 11:31:32 MST." References: <20110610133243.GA19449@ussenterprise.ufp.org> <4DF26EB7.70502@netwolves.com> <4DF78926.6080209@foobar.org> <5E6F93FB-0FDA-4B23-BDD3-977369955B3E@bjencks.net> <20110614202513.GA49062@ussenterprise.ufp.org> <4DF8CE24.1020000@jima.tk> <20110615163906.GA99062@ussenterprise.ufp.org> Message-ID: <20110616234730.34C7010D5068@drugs.dv.isc.org> In message , Owen DeLong write s: > > On Jun 15, 2011, at 9:39 AM, Leo Bicknell wrote: > > > In a message written on Wed, Jun 15, 2011 at 10:22:12AM -0500, Jima wrote: > >> Oh, oops; you did touch upon this. You might want to let the people > >> who've implemented RDNSS in software know that the IETF is working on > >> it. I'm sure that'll be a relief. > > > > Maybe I'm missing something, but the last update on this was RFC > > 5006 I think, which is marked as "experimental", and I thought the > > IETF still had a working group discussing it. > > > > That is, I didn't think it was a finalized standard yet. > > > > -- > > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > > PGP keys at http://www.ufp.org/~bicknell/ > > Many of the most widely used technologies on the internet do not become > finalized standards at the IETF level until long after they have been in > widespread use. > > Owen But very few are "experimental" and stay that way. Many stay at "proposed standard". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gaurab at lahai.com Thu Jun 16 20:33:09 2011 From: gaurab at lahai.com (Gaurab Raj Upadhaya) Date: Fri, 17 Jun 2011 02:33:09 +0100 Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> References: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> Message-ID: <4DFAAED5.2090605@lahai.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/15/11 5:47 PM, James Grace wrote: > So we're running out of peering space in our /24 and we were > considering using private /30's for new peerings. Are there any > horrific consequences to picking up this practice? This might summarize it nicely. http://www.ietf.org/id/draft-kirkham-private-ip-sp-cores-04.txt - -gaurab - -- http://www.gaurab.org.np/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk36rtUACgkQSo7fU26F3X3WzQCcC0Hv62BTNK111mRs16ISJQ7o ZfcAn05LoQuFTshG22QYLOmwdLnNm3GY =vZI7 -----END PGP SIGNATURE----- From ops.lists at gmail.com Thu Jun 16 21:35:33 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 17 Jun 2011 08:05:33 +0530 Subject: good geographic for servers reaching the South East Asia market In-Reply-To: <2004905D-764B-4367-B5C8-FFEE6AC9D71F@deman.com> References: <2004905D-764B-4367-B5C8-FFEE6AC9D71F@deman.com> Message-ID: I wouldn't recommend malaysia when singapore is available next door with excellent connectivity region wide On Fri, Jun 17, 2011 at 5:13 AM, Michael DeMan wrote: > > > I wanted to thank everybody for their feedback. ?Everything seems to correlate with what I have heard - generally Hong Kong and Singapore are the major hubs, with Tokyo even being an option even though it is not 'geographically' close and also possibly there are options in Malaysia. > > I think I have what I need for this. ?I am just a worker-bee on this project getting preliminary information for a potential project by a client next year, which may not or may not even be a 'go' anyway. > > Out of curiosity, I stumbled across this kind of cool map of submarine cables - does anybody know if it is very accurate or up to date? ?If nothing else, it is kind of fun to play with since you can slide around and zoom in/out with it and stuff. > > http://www.cablemap.info/ > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From nanog at deman.com Thu Jun 16 22:22:08 2011 From: nanog at deman.com (Michael DeMan) Date: Thu, 16 Jun 2011 20:22:08 -0700 Subject: good geographic for servers reaching the South East Asia market In-Reply-To: References: Message-ID: <58CB1AC4-BEFE-4FBC-9069-6F7B00807EEE@deman.com> Hi Janne, Any thoughts about Malaysia? The outfit I am working for on this right now already has manufacturing facilities there and it would be easier for them to do it in-country. I would guess that probably everything from Kuala Lampur area is trunked via Singapore anyway? - mike On Jun 16, 2011, at 6:21 AM, Janne Snabb wrote: > Hello from Cambodia. I am familiar with the situation in Cambodia > and some surrounding countries. > > On Wed, 15 Jun 2011, Michael DeMan wrote: > >> Basically looking for tips on what cities/countries/locations >> have as much (mostly submarine cabling in this case?) fiber >> connectivity and redundancy. From there I can trim down where to >> begin looking specifically at data centers and colocation options. > > Hong Kong, Singapore (and Taiwan). > > Hong Kong is the best choice for some countries in the region: > countries such as Cambodia and Vietnam have their uplinks mostly > through Hong Kong. > > Singapore is the best choice for others: Thailand, Malaysia and > Indonesia have good connectivity to Singapore. > > Taiwan I would place as the 3rd option. > > No other realistic options exist in the region beyond that... US > west coast is often the best option if you are not prepared to spend > a lot of money (but check your upstream's peering with major SEA > providers first). > >> Also, if anybody offhand has any tips on political stability >> and/or the risk of some kind of unwanted censorship by a given >> country, that would be helpful as well. > > All countries within the region are unsafe when it comes to censorship. > Hong Kong is probably the only nearby place which does not openly > practice censorship currently, but I would not count on that as > it is just a (autonomous) province of China. > > -- > Janne Snabb / EPIPE Communications > snabb at epipe.com - http://epipe.com/ From ryan.finnesey at HarrierInvestments.com Thu Jun 16 22:33:55 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Thu, 16 Jun 2011 20:33:55 -0700 Subject: Clueful Rogers sales rep? In-Reply-To: <4DFA1F24.9050406@gmail.com> References: <4DFA1F24.9050406@gmail.com> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03C1A422@EXVBE005-2.exch005intermedia.net> Daniela Moloney Daniela.Moloney at rci.rogers.com Cheers Ryan -----Original Message----- From: Mike [mailto:ispbuilder at gmail.com] Sent: Thursday, June 16, 2011 11:20 AM To: nanog at nanog.org Subject: Clueful Rogers sales rep? I need to find a clueful Rogers sales rep, if anyone has suggestions, please send them my way. thanks! From jkrembs at fairpoint.com Fri Jun 17 08:06:36 2011 From: jkrembs at fairpoint.com (Krembs, Jesse) Date: Fri, 17 Jun 2011 09:06:36 -0400 Subject: NANOG 52 Stream Archives? Message-ID: Dear All For those of us that missed the show, is it possible to view the NANOG 52 streams anywhere? Jesse Krembs - Data Network Architecture & Planning FairPoint Communications | 800 Hinesburg Rd, South Burlington, VT 05403 | jkrembs at fairpoint.com www.FairPoint.com | 802.951.1519 office | 802.735.4886 cell _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media. From sergevautour at yahoo.ca Fri Jun 17 08:08:13 2011 From: sergevautour at yahoo.ca (Serge Vautour) Date: Fri, 17 Jun 2011 06:08:13 -0700 (PDT) Subject: IPv6 BGP communities Message-ID: <499402.79882.qm@web121418.mail.ne1.yahoo.com> Hello, I'm looking at re-writing our IPv4 BGP policies for IPv6. Does anyone see a problem with re-using the same BGP community values? If we use AS:110 for LP 110 under IPv4, can I just use AS:110 for LP 110 under IPv6? Technically it works - at least I haven't seen a problem in my initial tests. It sure would make everything easier than assigning new values. Is there a BCP for this? Thanks, Serge From deric.kwok2000 at gmail.com Fri Jun 17 11:34:20 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Fri, 17 Jun 2011 12:34:20 -0400 Subject: whoi modify question Message-ID: Hi My boss wants me to resign part of ip /25 to customer For the whois record to this customer, how can I do it? Thank you From darden at armc.org Fri Jun 17 11:57:58 2011 From: darden at armc.org (Darden, Patrick S.) Date: Fri, 17 Jun 2011 12:57:58 -0400 Subject: whoi modify question In-Reply-To: Message-ID: The short answer is you can't. ARIN only cares about /24s or bigger. If the network were a /24 or larger, then your customer would need to get an ASN (autonomous system number) and then you could register the network to them. More info here: https://www.arin.net --Patrick Darden -----Original Message----- From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] Sent: Friday, June 17, 2011 12:34 PM To: nanog list Subject: whoi modify question Hi My boss wants me to resign part of ip /25 to customer For the whois record to this customer, how can I do it? Thank you From joelja at bogus.com Fri Jun 17 12:01:16 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 17 Jun 2011 10:01:16 -0700 Subject: whoi modify question In-Reply-To: References: Message-ID: https://www.arin.net/resources/request/reassignments.html On Jun 17, 2011, at 9:34 AM, Deric Kwok wrote: > Hi > > My boss wants me to resign part of ip /25 to customer > > For the whois record to this customer, how can I do it? > > Thank you > From joelja at bogus.com Fri Jun 17 12:03:23 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 17 Jun 2011 10:03:23 -0700 Subject: whoi modify question In-Reply-To: References: Message-ID: <496A2889-6BA3-4109-8E1D-DDF772432357@bogus.com> On Jun 17, 2011, at 9:57 AM, Darden, Patrick S. wrote: > > The short answer is you can't. ARIN only cares about /24s or bigger. If the network were a /24 or larger, then your customer would need to get an ASN (autonomous system number) and then you could register the network to them. negative, blocks are swiped at /29 and larger. > More info here: https://www.arin.net > > --Patrick Darden > > > -----Original Message----- > From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] > Sent: Friday, June 17, 2011 12:34 PM > To: nanog list > Subject: whoi modify question > > > Hi > > My boss wants me to resign part of ip /25 to customer > > For the whois record to this customer, how can I do it? > > Thank you > > > From darden at armc.org Fri Jun 17 12:09:33 2011 From: darden at armc.org (Patrick Darden) Date: Fri, 17 Jun 2011 13:09:33 -0400 Subject: whoi modify question In-Reply-To: <496A2889-6BA3-4109-8E1D-DDF772432357@bogus.com> References: <496A2889-6BA3-4109-8E1D-DDF772432357@bogus.com> Message-ID: <4DFB8A4D.5040503@armc.org> My mistake. Apologies. Here is the relevant section: "ARIN requires organizations to submit information for all IPv4 reassignments of /29 and larger and IPv6 reassignments of /56 or shorter prefix within seven days of the subdelegation. For IPv4 blocks of /30 or longer prefix, ISPs may choose to provide utilization data via SWIP (Shared WHOIS Project) or manually upon request. There are special reporting requirements for residential cable ISPs and residential customers. Organizations may only submit reassignment data for records within their allocated blocks. " --p On 06/17/2011 01:03 PM, Joel Jaeggli wrote: > On Jun 17, 2011, at 9:57 AM, Darden, Patrick S. wrote: > > >> The short answer is you can't. ARIN only cares about /24s or bigger. If the network were a /24 or larger, then your customer would need to get an ASN (autonomous system number) and then you could register the network to them. > negative, blocks are swiped at /29 and larger. > >> More info here: https://www.arin.net >> >> --Patrick Darden >> >> >> -----Original Message----- >> From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] >> Sent: Friday, June 17, 2011 12:34 PM >> To: nanog list >> Subject: whoi modify question >> >> >> Hi >> >> My boss wants me to resign part of ip /25 to customer >> >> For the whois record to this customer, how can I do it? >> >> Thank you >> >> >> From cscora at apnic.net Fri Jun 17 13:47:37 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Jun 2011 04:47:37 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201106171847.p5HIlbg1001486@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 18 Jun, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 360387 Prefixes after maximum aggregation: 163564 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 178868 Total ASes present in the Internet Routing Table: 37921 Prefixes per ASN: 9.50 Origin-only ASes present in the Internet Routing Table: 31627 Origin ASes announcing only one prefix: 15197 Transit ASes present in the Internet Routing Table: 5136 Transit-only ASes present in the Internet Routing Table: 131 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 818 Unregistered ASNs in the Routing Table: 441 Number of 32-bit ASNs allocated by the RIRs: 1463 Number of 32-bit ASNs visible in the Routing Table: 1158 Prefixes from 32-bit ASNs in the Routing Table: 2676 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 141 Number of addresses announced to Internet: 2488807488 Equivalent to 148 /8s, 88 /16s and 48 /24s Percentage of available address space announced: 67.1 Percentage of allocated address space announced: 67.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.0 Total number of prefixes smaller than registry allocations: 150087 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 89629 Total APNIC prefixes after maximum aggregation: 30149 APNIC Deaggregation factor: 2.97 Prefixes being announced from the APNIC address blocks: 86121 Unique aggregates announced from the APNIC address blocks: 36875 APNIC Region origin ASes present in the Internet Routing Table: 4482 APNIC Prefixes per ASN: 19.21 APNIC Region origin ASes announcing only one prefix: 1246 APNIC Region transit ASes present in the Internet Routing Table: 706 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 46 Number of APNIC addresses announced to Internet: 620285216 Equivalent to 36 /8s, 248 /16s and 205 /24s Percentage of available APNIC address space announced: 78.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 140967 Total ARIN prefixes after maximum aggregation: 72104 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 112897 Unique aggregates announced from the ARIN address blocks: 46236 ARIN Region origin ASes present in the Internet Routing Table: 14446 ARIN Prefixes per ASN: 7.82 ARIN Region origin ASes announcing only one prefix: 5520 ARIN Region transit ASes present in the Internet Routing Table: 1524 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 818669312 Equivalent to 48 /8s, 203 /16s and 231 /24s Percentage of available ARIN address space announced: 65.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 85734 Total RIPE prefixes after maximum aggregation: 48818 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 79180 Unique aggregates announced from the RIPE address blocks: 52437 RIPE Region origin ASes present in the Internet Routing Table: 15722 RIPE Prefixes per ASN: 5.04 RIPE Region origin ASes announcing only one prefix: 7850 RIPE Region transit ASes present in the Internet Routing Table: 2477 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 855 Number of RIPE addresses announced to Internet: 477374720 Equivalent to 28 /8s, 116 /16s and 41 /24s Percentage of available RIPE address space announced: 76.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 33067 Total LACNIC prefixes after maximum aggregation: 7539 LACNIC Deaggregation factor: 4.39 Prefixes being announced from the LACNIC address blocks: 32170 Unique aggregates announced from the LACNIC address blocks: 16905 LACNIC Region origin ASes present in the Internet Routing Table: 1468 LACNIC Prefixes per ASN: 21.91 LACNIC Region origin ASes announcing only one prefix: 438 LACNIC Region transit ASes present in the Internet Routing Table: 262 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 241 Number of LACNIC addresses announced to Internet: 84924928 Equivalent to 5 /8s, 15 /16s and 218 /24s Percentage of available LACNIC address space announced: 56.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8091 Total AfriNIC prefixes after maximum aggregation: 1965 AfriNIC Deaggregation factor: 4.12 Prefixes being announced from the AfriNIC address blocks: 6390 Unique aggregates announced from the AfriNIC address blocks: 1967 AfriNIC Region origin ASes present in the Internet Routing Table: 465 AfriNIC Prefixes per ASN: 13.74 AfriNIC Region origin ASes announcing only one prefix: 143 AfriNIC Region transit ASes present in the Internet Routing Table: 101 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 24250368 Equivalent to 1 /8s, 114 /16s and 8 /24s Percentage of available AfriNIC address space announced: 36.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2457 9500 924 Korea Telecom (KIX) 17974 1879 465 43 PT TELEKOMUNIKASI INDONESIA 7545 1538 301 85 TPG Internet Pty Ltd 4755 1478 634 168 TATA Communications formerly 24560 1153 336 187 Bharti Airtel Ltd., Telemedia 7552 1143 1064 7 Vietel Corporation 9583 1079 80 510 Sify Limited 4808 1048 2090 300 CNCGROUP IP network: China169 9829 1042 879 56 BSNL National Internet Backbo 17488 950 190 101 Hathway IP Over Cable Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3629 3819 250 bellsouth.net, inc. 18566 1913 365 237 Covad Communications 1785 1796 681 122 PaeTec Communications, Inc. 4323 1660 1081 397 Time Warner Telecom 6478 1634 296 275 AT&T Worldnet Services 20115 1522 1526 640 Charter Communications 19262 1493 4936 308 Verizon Global Networks 7018 1363 7054 889 AT&T WorldNet Services 22773 1338 2897 85 Cox Communications, Inc. 7029 1312 790 297 Alltel Information Services, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 524 107 182 BILISIM TELEKOM 6830 513 1780 320 UPC Distribution Services 3292 466 2078 401 TDC Tele Danmark 20940 462 135 354 Akamai Technologies European 29049 449 33 46 AzerSat LLC. 8866 445 134 26 Bulgarian Telecommunication C 12479 434 593 7 Uni2 Autonomous System 3320 420 8151 367 Deutsche Telekom AG 8551 404 354 44 Bezeq International 3301 398 1839 347 TeliaNet Sweden Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1522 278 155 TVCABLE BOGOTA 28573 1279 993 78 NET Servicos de Comunicao S.A 8151 1269 2729 363 UniNet S.A. de C.V. 7303 990 506 170 Telecom Argentina Stet-France 6503 741 354 73 AVANTEL, S.A. 14420 683 55 82 CORPORACION NACIONAL DE TELEC 22047 572 322 17 VTR PUNTO NET S.A. 3816 532 231 95 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 27947 499 53 52 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 795 147 37 LINKdotNET AS number 8452 763 445 11 TEDATA 15475 526 74 8 Nile Online 36992 304 415 14 Etisalat MISR 3741 265 937 226 The Internet Solution 6713 241 215 13 Itissalat Al-MAGHRIB 33776 215 12 11 Starcomms Nigeria Limited 24835 211 78 10 RAYA Telecom - Egypt 29571 192 17 11 Ci Telecom Autonomous system 16637 150 441 86 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3629 3819 250 bellsouth.net, inc. 23456 2676 661 1448 32-bit ASN transition 4766 2457 9500 924 Korea Telecom (KIX) 18566 1913 365 237 Covad Communications 17974 1879 465 43 PT TELEKOMUNIKASI INDONESIA 1785 1796 681 122 PaeTec Communications, Inc. 4323 1660 1081 397 Time Warner Telecom 6478 1634 296 275 AT&T Worldnet Services 7545 1538 301 85 TPG Internet Pty Ltd 10620 1522 278 155 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 1879 1836 PT TELEKOMUNIKASI INDONESIA 18566 1913 1676 Covad Communications 1785 1796 1674 PaeTec Communications, Inc. 4766 2457 1533 Korea Telecom (KIX) 7545 1538 1453 TPG Internet Pty Ltd 10620 1522 1367 TVCABLE BOGOTA 6478 1634 1359 AT&T Worldnet Services 4755 1478 1310 TATA Communications formerly 4323 1660 1263 Time Warner Telecom 22773 1338 1253 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 27.0.128.0/17 7514 Media Exchange, Inc. 31.132.8.0/21 15478 White Market Media SRL 31.132.32.0/20 15478 White Market Media SRL 41.190.32.0/23 31856 CABSAS Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:22 /9:12 /10:28 /11:81 /12:231 /13:462 /14:801 /15:1394 /16:11951 /17:5841 /18:9796 /19:19380 /20:26032 /21:26006 /22:34385 /23:33300 /24:187515 /25:1093 /26:1270 /27:729 /28:41 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2232 3629 bellsouth.net, inc. 18566 1870 1913 Covad Communications 6478 1597 1634 AT&T Worldnet Services 10620 1412 1522 TVCABLE BOGOTA 23456 1328 2676 32-bit ASN transition 11492 1090 1136 Cable One 7011 1059 1159 Citizens Utilities 7029 1059 1312 Alltel Information Services, 1785 1050 1796 PaeTec Communications, Inc. 22773 856 1338 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:286 2:43 4:16 5:1 6:3 8:335 12:1973 13:1 14:464 15:15 16:3 17:8 20:10 23:11 24:1653 27:790 31:444 32:64 33:4 34:2 37:1 38:734 40:103 41:2508 42:2 44:3 46:976 47:3 49:188 50:409 52:13 54:2 55:4 56:2 57:32 58:845 59:472 60:387 61:1181 62:1050 63:1935 64:3944 65:2271 66:3860 67:1889 68:1089 69:3026 70:723 71:376 72:1886 74:2377 75:319 76:339 77:881 78:707 79:460 80:1113 81:846 82:493 83:461 84:667 85:1082 86:581 87:757 88:333 89:1530 90:208 91:3855 92:530 93:1049 94:1294 95:838 96:445 97:249 98:879 99:36 101:70 103:79 106:7 107:14 108:71 109:1006 110:606 111:709 112:303 113:399 114:540 115:668 116:962 117:677 118:826 119:1145 120:312 121:669 122:1628 123:941 124:1267 125:1235 128:247 129:174 130:165 131:578 132:111 133:21 134:214 135:48 136:216 137:138 138:300 139:113 140:480 141:238 142:403 143:413 144:489 145:54 146:451 147:211 148:610 149:247 150:171 151:190 152:332 153:180 154:4 155:398 156:195 157:352 158:138 159:389 160:319 161:208 162:313 163:162 164:500 165:352 166:532 167:423 168:740 169:156 170:838 171:77 172:1 173:1621 174:602 175:362 176:135 177:160 178:1000 180:892 181:19 182:476 183:220 184:302 185:1 186:1241 187:731 188:857 189:907 190:4898 192:5856 193:4956 194:3492 195:3032 196:1221 197:24 198:3596 199:3945 200:5542 201:1501 202:8319 203:8407 204:4188 205:2348 206:2686 207:2815 208:3927 209:3463 210:2689 211:1424 212:2006 213:1726 214:773 215:69 216:4933 217:1643 218:545 219:365 220:1202 221:491 222:354 223:159 End of report From efinley.lists at gmail.com Fri Jun 17 13:55:07 2011 From: efinley.lists at gmail.com (Elliot Finley) Date: Fri, 17 Jun 2011 12:55:07 -0600 Subject: Business Ethernet Services Message-ID: Anyone using a CPE that is reliable and costs <= $300 ? features needed: SFP for uplink, QnQ, basic layer 2 functionality. If you're using something with the above parameters and you like it, please share. :) Thanks, Elliot From deric.kwok2000 at gmail.com Fri Jun 17 14:01:20 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Fri, 17 Jun 2011 15:01:20 -0400 Subject: whoi modify question In-Reply-To: <4DFB8A4D.5040503@armc.org> References: <496A2889-6BA3-4109-8E1D-DDF772432357@bogus.com> <4DFB8A4D.5040503@armc.org> Message-ID: Thank you all ls whois only done from ARIN website? How about my rwhois server? Everytime I apply the ip. ARIN needs us to do the whois server How can I do referral? any info? Thank you again On Fri, Jun 17, 2011 at 1:09 PM, Patrick Darden wrote: > > My mistake. ?Apologies. ?Here is the relevant section: > > "ARIN requires organizations to submit information for all IPv4 > reassignments of /29 and larger and IPv6 reassignments of /56 or shorter > prefix within seven days of the subdelegation. For IPv4 blocks of /30 or > longer prefix, ISPs may choose to provide utilization data via SWIP (Shared > WHOIS Project) or manually upon request. There are special reporting > requirements for residential cable ISPs and residential customers. > ?Organizations may only submit reassignment data for records within their > allocated blocks. " > > --p > > On 06/17/2011 01:03 PM, Joel Jaeggli wrote: >> >> On Jun 17, 2011, at 9:57 AM, Darden, Patrick S. wrote: >> >> >>> >>> The short answer is you can't. ?ARIN only cares about /24s or bigger. ?If >>> the network were a /24 or larger, then your customer would need to get an >>> ASN (autonomous system number) and then you could register the network to >>> them. >> >> negative, blocks are swiped at /29 and larger. >> >>> More info here: https://www.arin.net >>> >>> --Patrick Darden >>> >>> >>> -----Original Message----- >>> From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] >>> Sent: Friday, June 17, 2011 12:34 PM >>> To: nanog list >>> Subject: whoi modify question >>> >>> >>> Hi >>> >>> My boss wants me to resign part of ip /25 to customer >>> >>> For the whois record to this customer, how can I do it? >>> >>> Thank you >>> >>> >>> > From heather.schiller at verizonbusiness.com Fri Jun 17 14:19:01 2011 From: heather.schiller at verizonbusiness.com (Schiller, Heather A) Date: Fri, 17 Jun 2011 19:19:01 +0000 Subject: NANOG 52 Stream Archives? In-Reply-To: References: Message-ID: Eventually they will be posted here: http://nanog.org/presentations/archive/index.php With a few exceptions -- the FCC presentation was not recorded. The breakout sessions aren't typically recorded either. --heather -----Original Message----- From: Krembs, Jesse [mailto:jkrembs at fairpoint.com] Sent: Friday, June 17, 2011 9:07 AM To: nanog at nanog.org Subject: NANOG 52 Stream Archives? Dear All For those of us that missed the show, is it possible to view the NANOG 52 streams anywhere? Jesse Krembs - Data Network Architecture & Planning FairPoint Communications | 800 Hinesburg Rd, South Burlington, VT 05403 | jkrembs at fairpoint.com www.FairPoint.com | 802.951.1519 office | 802.735.4886 cell _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media. From wavetossed at googlemail.com Fri Jun 17 15:18:49 2011 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 17 Jun 2011 13:18:49 -0700 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> Message-ID: > The last v6day was an isoc effort, there can be a separate nanog effort or > your own. It does make a lot of sense for NANOG (perhaps jointly with RIPE and other NOGs) to organize monthly IPv6 days with a theme or focus for each month. If you have a focus, then you can recruit a lot of IPv6 testers to try out certain things on IPv6 day and get a more thorough test and more feedback Skip July and August because it takes time to get this organized, and then start the next one on September the 8th or thereabouts. For instance, one month could focus on full IPv6 DNS support, but maybe not right away. A nice easy start would be to deal with IPv6 peering and weird paths that result from tunnels. That is the kind of thing that would work good with a lot of testers participating and an application that traces IPv4 and IPv6 paths and measures hop count, latency, packet loss. In conjunction with the monthly IPv6 day, NANOG should set up a blog page or similar to publicly collect incident reports and solutions. From bross at pobox.com Fri Jun 17 15:27:06 2011 From: bross at pobox.com (Brandon Ross) Date: Fri, 17 Jun 2011 16:27:06 -0400 (EDT) Subject: whoi modify question In-Reply-To: <4DFB8A4D.5040503@armc.org> References: <496A2889-6BA3-4109-8E1D-DDF772432357@bogus.com> <4DFB8A4D.5040503@armc.org> Message-ID: On Fri, 17 Jun 2011, Patrick Darden wrote: > My mistake. Apologies. It happens, but: > On 06/17/2011 01:03 PM, Joel Jaeggli wrote: >> On Jun 17, 2011, at 9:57 AM, Darden, Patrick S. wrote: >> >>> The short answer is you can't. ARIN only cares about /24s or bigger. If >>> the network were a /24 or larger, then your customer would need to get an >>> ASN (autonomous system number) and then you could register the network to >>> them. I'm afraid there's also no requirement at all for an ASN regardless of the size of your address block. ASNs are required for running BGP. You can easily static route even a /8 (and I've done it on occasion). -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From jra at baylink.com Fri Jun 17 16:04:25 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 17:04:25 -0400 (EDT) Subject: ICANN to allow commercial gTLDs Message-ID: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> Aw, Jeezus. No. Just, no. http://tech.slashdot.org/story/11/06/17/202245/ Cjeers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From morrowc.lists at gmail.com Fri Jun 17 16:14:02 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 17 Jun 2011 17:14:02 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> Message-ID: too late... someone sign up for .nanog! On Fri, Jun 17, 2011 at 5:04 PM, Jay Ashworth wrote: > Aw, Jeezus. > > No. ?Just, no. > > ?http://tech.slashdot.org/story/11/06/17/202245/ > > Cjeers, > -- jra > -- > Jay R. Ashworth ? ? ? ? ? ? ? ? ?Baylink ? ? ? ? ? ? ? ? ? ? ? jra at baylink.com > Designer ? ? ? ? ? ? ? ? ? ? The Things I Think ? ? ? ? ? ? ? ? ? ? ? RFC 2100 > Ashworth & Associates ? ? http://baylink.pitas.com ? ? ? ? 2000 Land Rover DII > St Petersburg FL USA ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 727 647 1274 > > From mikea at mikea.ath.cx Fri Jun 17 16:16:23 2011 From: mikea at mikea.ath.cx (mikea) Date: Fri, 17 Jun 2011 16:16:23 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> Message-ID: <20110617211623.GD38065@mikea.ath.cx> On Fri, Jun 17, 2011 at 05:04:25PM -0400, Jay Ashworth wrote: > Aw, Jeezus. > > No. Just, no. > > http://tech.slashdot.org/story/11/06/17/202245/ Yeah. Maybe ICANN needs its own special TLD: .idiots? -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From drc at virtualized.org Fri Jun 17 16:21:00 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Jun 2011 11:21:00 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> Message-ID: <60CD072E-8323-4CC0-A060-00A89990A0B2@virtualized.org> On Jun 17, 2011, at 11:04 AM, Jay Ashworth wrote: > Aw, Jeezus. > > No. Just, no. > > http://tech.slashdot.org/story/11/06/17/202245/ You just learned about this now? Regards, -drc From jbaino at gmail.com Fri Jun 17 16:21:04 2011 From: jbaino at gmail.com (Jeremy) Date: Fri, 17 Jun 2011 16:21:04 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110617211623.GD38065@mikea.ath.cx> References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> <20110617211623.GD38065@mikea.ath.cx> Message-ID: well, crap. That's all I have to say :( On Fri, Jun 17, 2011 at 4:16 PM, mikea wrote: > On Fri, Jun 17, 2011 at 05:04:25PM -0400, Jay Ashworth wrote: > > Aw, Jeezus. > > > > No. Just, no. > > > > http://tech.slashdot.org/story/11/06/17/202245/ > > Yeah. Maybe ICANN needs its own special TLD: .idiots? > > -- > Mike Andrews, W5EGO > mikea at mikea.ath.cx > Tired old sysadmin > > From jra at baylink.com Fri Jun 17 16:23:08 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 17:23:08 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <60CD072E-8323-4CC0-A060-00A89990A0B2@virtualized.org> Message-ID: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "David Conrad" > On Jun 17, 2011, at 11:04 AM, Jay Ashworth wrote: > > Aw, Jeezus. > > > > No. Just, no. > > > > http://tech.slashdot.org/story/11/06/17/202245/ > > You just learned about this now? In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 months or so; where should I have seen it? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From dougb at dougbarton.us Fri Jun 17 16:30:16 2011 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 17 Jun 2011 14:30:16 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> Message-ID: <4DFBC768.6020602@dougbarton.us> On 06/17/2011 14:23, Jay Ashworth wrote: > ----- Original Message ----- >> From: "David Conrad" > >> On Jun 17, 2011, at 11:04 AM, Jay Ashworth wrote: >>> Aw, Jeezus. >>> >>> No. Just, no. >>> >>> http://tech.slashdot.org/story/11/06/17/202245/ >> >> You just learned about this now? > > In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 > months or so; where should I have seen it? More things on heaven and earth Horatio ... -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jbarnard at nwic.ca Fri Jun 17 16:31:06 2011 From: jbarnard at nwic.ca (Joel Barnard) Date: Fri, 17 Jun 2011 17:31:06 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> Message-ID: <00dc01cc2d35$de5dd630$9b198290$@nwic.ca> I hope they've considered what will happen if you go to http://localhost/ or http://pcname/ Is that the local networks pcname, or the gTld pcname? Are we going to have to start using a specially reserved .local gTld? Joel Barnard Niagara Wireless Internet Co. -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Friday, June 17, 2011 5:14 PM To: Jay Ashworth Cc: NANOG Subject: Re: ICANN to allow commercial gTLDs too late... someone sign up for .nanog! On Fri, Jun 17, 2011 at 5:04 PM, Jay Ashworth wrote: > Aw, Jeezus. > > No. ?Just, no. > > ?http://tech.slashdot.org/story/11/06/17/202245/ > > Cjeers, > -- jra > -- > Jay R. Ashworth ? ? ? ? ? ? ? ? ?Baylink ? ? ? ? ? ? ? ? ? ? ? > jra at baylink.com Designer ? ? ? ? ? ? ? ? ? ? The Things I Think ? ? ? ? ? ? ? ? ? ? ? > RFC 2100 Ashworth & Associates ? ? http://baylink.pitas.com ? ? ? ? > 2000 Land Rover DII St Petersburg FL USA ? ? ?http://photo.imageinc.us ? ? ? ? ? ? > +1 727 647 1274 > > From drc at virtualized.org Fri Jun 17 16:33:50 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Jun 2011 11:33:50 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 17, 2011, at 11:23 AM, Jay Ashworth wrote: >>> http://tech.slashdot.org/story/11/06/17/202245/ >> You just learned about this now? > In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 > months or so; where should I have seen it? New TLDs have been discussed now for over a decade. Press (both technical and popular) on ICANN activities have ratcheted up significantly recently, particularly with the approval of .XXX (which was recently discussed here on NANOG: http://mailman.nanog.org/pipermail/nanog/2011-March/034488.html). Not blaming/accusing, just surprised this would be a surprise. I guess I've been living in the layer9 cloud too long.... Regards, -drc From zaid at zaidali.com Fri Jun 17 16:42:33 2011 From: zaid at zaidali.com (Zaid Ali) Date: Fri, 17 Jun 2011 14:42:33 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> Message-ID: <3D49F5B5-0F60-4FE8-9DC1-1F8D2C31D023@zaidali.com> On Jun 17, 2011, at 2:23 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "David Conrad" > >> On Jun 17, 2011, at 11:04 AM, Jay Ashworth wrote: >>> Aw, Jeezus. >>> >>> No. Just, no. >>> >>> http://tech.slashdot.org/story/11/06/17/202245/ >> >> You just learned about this now? > > In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 > months or so; where should I have seen it? Just an example, it has hit main stream media http://globalpublicsquare.blogs.cnn.com/2011/03/17/who-runs-the-internet/ Or you could have gone to one of the many free iCANN meetings where you can hear about this till your ears go blue. It has only been a topic for discussion for about 10 years :) but of course if it's not on NANOG it can't be true. Zaid From paul at paulgraydon.co.uk Fri Jun 17 16:44:07 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 17 Jun 2011 11:44:07 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> Message-ID: <4DFBCAA7.6000800@paulgraydon.co.uk> On 06/17/2011 11:33 AM, David Conrad wrote: > On Jun 17, 2011, at 11:23 AM, Jay Ashworth wrote: >>>> http://tech.slashdot.org/story/11/06/17/202245/ >>> You just learned about this now? >> In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 >> months or so; where should I have seen it? > New TLDs have been discussed now for over a decade. Press (both technical and popular) on ICANN activities have ratcheted up significantly recently, particularly with the approval of .XXX (which was recently discussed here on NANOG: http://mailman.nanog.org/pipermail/nanog/2011-March/034488.html). Not blaming/accusing, just surprised this would be a surprise. I guess I've been living in the layer9 cloud too long.... > > Regards, > -drc I've seen the stuff about adding a few extra TLDs, like XXX. I haven't seen any references until now of them considering doing it on a commercial basis. I don't mind new TLDs, but company ones are crazy and going to lead to a confusing and messy internet. Paul From jleq96 at gmail.com Fri Jun 17 16:48:43 2011 From: jleq96 at gmail.com (John LeCoque) Date: Fri, 17 Jun 2011 16:48:43 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: <4DFBCAA7.6000800@paulgraydon.co.uk> References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> <4DFBCAA7.6000800@paulgraydon.co.uk> Message-ID: If ICANN continues this stupidity, perhaps it will finally be feasible for an alternate DNS root to gain a following? Although that would lead to a fractured DNS system, which really isn't in the best interests of anybody. On Fri, Jun 17, 2011 at 4:44 PM, Paul Graydon wrote: > On 06/17/2011 11:33 AM, David Conrad wrote: > >> On Jun 17, 2011, at 11:23 AM, Jay Ashworth wrote: >> >>> http://tech.slashdot.org/**story/11/06/17/202245/ >>>>> >>>> You just learned about this now? >>>> >>> In fact I did. I certainly haven't seen it mentioned on NANOG in the >>> last 6 >>> months or so; where should I have seen it? >>> >> New TLDs have been discussed now for over a decade. Press (both technical >> and popular) on ICANN activities have ratcheted up significantly recently, >> particularly with the approval of .XXX (which was recently discussed here on >> NANOG: http://mailman.nanog.org/**pipermail/nanog/2011-March/** >> 034488.html). >> Not blaming/accusing, just surprised this would be a surprise. I guess I've >> been living in the layer9 cloud too long.... >> >> Regards, >> -drc >> > I've seen the stuff about adding a few extra TLDs, like XXX. I haven't > seen any references until now of them considering doing it on a commercial > basis. I don't mind new TLDs, but company ones are crazy and going to lead > to a confusing and messy internet. > > Paul > > From bensons at queuefull.net Fri Jun 17 16:54:59 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 17 Jun 2011 16:54:59 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: <60CD072E-8323-4CC0-A060-00A89990A0B2@virtualized.org> References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> <60CD072E-8323-4CC0-A060-00A89990A0B2@virtualized.org> Message-ID: On Jun 17, 2011, at 4:21 PM, David Conrad wrote: > On Jun 17, 2011, at 11:04 AM, Jay Ashworth wrote: >> Aw, Jeezus. >> >> No. Just, no. >> >> http://tech.slashdot.org/story/11/06/17/202245/ > > You just learned about this now? On a related topic, the US DoJ recently wrote a letter suggesting that DNS registry/registrar vertical integration might not be a good idea (from an anti-trust perspective). http://www.icann.org/en/correspondence/strickling-to-dengate-thrush-16jun11-en.pdf Cheers, -Benson From zaid at zaidali.com Fri Jun 17 16:53:54 2011 From: zaid at zaidali.com (Zaid Ali) Date: Fri, 17 Jun 2011 14:53:54 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <4DFBCAA7.6000800@paulgraydon.co.uk> References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> <4DFBCAA7.6000800@paulgraydon.co.uk> Message-ID: On Jun 17, 2011, at 2:44 PM, Paul Graydon wrote: > On 06/17/2011 11:33 AM, David Conrad wrote: >> On Jun 17, 2011, at 11:23 AM, Jay Ashworth wrote: >>>>> http://tech.slashdot.org/story/11/06/17/202245/ >>>> You just learned about this now? >>> In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 >>> months or so; where should I have seen it? >> New TLDs have been discussed now for over a decade. Press (both technical and popular) on ICANN activities have ratcheted up significantly recently, particularly with the approval of .XXX (which was recently discussed here on NANOG: http://mailman.nanog.org/pipermail/nanog/2011-March/034488.html). Not blaming/accusing, just surprised this would be a surprise. I guess I've been living in the layer9 cloud too long.... >> >> Regards, >> -drc > I've seen the stuff about adding a few extra TLDs, like XXX. I haven't seen any references until now of them considering doing it on a commercial basis. I don't mind new TLDs, but company ones are crazy and going to lead to a confusing and messy internet. > > Paul > There has been a lot of work put into this. I suggest you start looking at the application guide book http://www.icann.org/en/topics/new-gtlds/dag-en.htm If folks have been debating about this for 10 years then you can be assured the concerns of a messy internet have been brought up. Don't tell me folks will have an existential moment about IDN's and gTLD. Zaid From jra at baylink.com Fri Jun 17 16:54:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 17:54:47 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <00dc01cc2d35$de5dd630$9b198290$@nwic.ca> Message-ID: <22653040.608.1308347687356.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joel Barnard" > I hope they've considered what will happen if you go to > http://localhost/ or > http://pcname/ > > Is that the local networks pcname, or the gTld pcname? > Are we going to have to start using a specially reserved .local gTld? No, of *course* ICANN didn't give any engineering thought to it. Cause the engineers? Are all *here*. And David Conrad's apparently the only guy who's heard about it. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Fri Jun 17 16:59:06 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 17:59:06 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <21961578.610.1308347946923.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "David Conrad" > On Jun 17, 2011, at 11:23 AM, Jay Ashworth wrote: > >>> http://tech.slashdot.org/story/11/06/17/202245/ > >> You just learned about this now? > > In fact I did. I certainly haven't seen it mentioned on NANOG in the > > last 6 months or so; where should I have seen it? > > New TLDs have been discussed now for over a decade. Press (both > technical and popular) on ICANN activities have ratcheted up > significantly recently, particularly with the approval of .XXX (which > was recently discussed here on NANOG: > http://mailman.nanog.org/pipermail/nanog/2011-March/034488.html). Not > blaming/accusing, just surprised this would be a surprise. I guess > I've been living in the layer9 cloud too long.... FFS, David. I didn't say "new gTLDs". I said, rather specifically, "commercial gTLDs", IE: gTLDs *proprietary to a specific commercial enterprise*. http:///www.apple And no, I had not heard *any noise* that anyone was seriously considering this up until this announcement. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From cidr-report at potaroo.net Fri Jun 17 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Jun 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201106172200.p5HM01QA019365@wattle.apnic.net> BGP Update Report Interval: 09-Jun-11 -to- 16-Jun-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15557 251419 12.5% 13.0 -- LDCOMNET NEUF CEGETEL (formerly LDCOM NETWORKS) 2 - AS7184 203062 10.1% 3562.5 -- Universidad Verecruzana 3 - AS9198 59219 2.9% 160.9 -- KAZTELECOM-AS JSC Kazakhtelecom 4 - AS5434 38538 1.9% 313.3 -- NURSAT-ALA-AS Nursat-Almaty 5 - AS9829 32330 1.6% 38.7 -- BSNL-NIB National Internet Backbone 6 - AS17974 22978 1.1% 12.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 7 - AS11492 18977 0.9% 26.5 -- CABLEONE - CABLE ONE, INC. 8 - AS19743 18491 0.9% 3081.8 -- 9 - AS32528 17081 0.8% 2846.8 -- ABBOTT Abbot Labs 10 - AS9498 15336 0.8% 19.2 -- BBIL-AP BHARTI Airtel Ltd. 11 - AS23091 14466 0.7% 2411.0 -- Universidad Autonoma Chapingo 12 - AS33475 12895 0.6% 90.2 -- RSN-1 - RockSolid Network, Inc. 13 - AS45595 10294 0.5% 50.2 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 14 - AS24560 10191 0.5% 9.1 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 15 - AS3320 9726 0.5% 389.0 -- DTAG Deutsche Telekom AG 16 - AS7552 9303 0.5% 10.7 -- VIETEL-AS-AP Vietel Corporation 17 - AS7029 9229 0.5% 6.5 -- WINDSTREAM - Windstream Communications Inc 18 - AS27738 8898 0.4% 26.2 -- Ecuadortelecom S.A. 19 - AS11915 8438 0.4% 127.8 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 20 - AS15399 7923 0.4% 101.6 -- WANANCHI-KE TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7184 203062 10.1% 3562.5 -- Universidad Verecruzana 2 - AS19743 18491 0.9% 3081.8 -- 3 - AS32528 17081 0.8% 2846.8 -- ABBOTT Abbot Labs 4 - AS3454 7559 0.4% 2519.7 -- Universidad Autonoma de Nuevo Leon 5 - AS23091 14466 0.7% 2411.0 -- Universidad Autonoma Chapingo 6 - AS28519 5578 0.3% 1859.3 -- Universidad Autonoma de Guadalajara, A.C. 7 - AS31815 2626 0.1% 1313.0 -- MEDIATEMPLE - Media Temple, Inc. 8 - AS28493 1304 0.1% 1304.0 -- Universidad Pedagogica Nacional 9 - AS49600 937 0.1% 937.0 -- LASEDA La Seda de Barcelona, S.A 10 - AS33260 3742 0.2% 935.5 -- HOSTASAURUS - Hostasaurus, Inc. 11 - AS17408 3541 0.2% 885.2 -- ABOVE-AS-AP AboveNet Communications Taiwan 12 - AS44967 6158 0.3% 879.7 -- TASIO Tasio Ltd 13 - AS25090 858 0.0% 858.0 -- EOS-AS Energie Ouest Suisse Autonomous System 14 - AS56204 2628 0.1% 657.0 -- NETMAX-NP Anam Nagar 15 - AS51236 638 0.0% 638.0 -- OLIMPKZ-NET Olimp KZ LLC. 16 - AS38464 3008 0.1% 601.6 -- GLOBAL-NP GISPL ISP/NSP Of Nepal 17 - AS4613 1195 0.1% 597.5 -- MOS-NP Mercantile Office Systems 18 - AS17770 5824 0.3% 582.4 -- SUNTEL-WOW Suntel Limited 19 - AS38750 567 0.0% 567.0 -- TDS-AS-ID Telemedia Dinamika Sarana, PT 20 - AS9849 4360 0.2% 545.0 -- CWD-AS Office of the president TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 11888 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 91.217.214.0/24 9588 0.4% AS3320 -- DTAG Deutsche Telekom AG 3 - 130.36.34.0/24 8537 0.4% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 8535 0.4% AS32528 -- ABBOTT Abbot Labs 5 - 200.23.202.0/24 7552 0.3% AS3454 -- Universidad Autonoma de Nuevo Leon 6 - 148.226.145.0/24 3787 0.2% AS7184 -- Universidad Verecruzana 7 - 148.226.152.0/24 3779 0.2% AS7184 -- Universidad Verecruzana 8 - 148.226.60.0/24 3778 0.2% AS7184 -- Universidad Verecruzana 9 - 148.226.147.0/24 3777 0.2% AS7184 -- Universidad Verecruzana 10 - 148.226.61.0/24 3777 0.2% AS7184 -- Universidad Verecruzana 11 - 148.226.149.0/24 3775 0.2% AS7184 -- Universidad Verecruzana 12 - 148.226.62.0/24 3775 0.2% AS7184 -- Universidad Verecruzana 13 - 148.226.128.0/24 3773 0.2% AS7184 -- Universidad Verecruzana 14 - 148.226.50.0/24 3772 0.2% AS7184 -- Universidad Verecruzana 15 - 148.226.46.0/24 3771 0.2% AS7184 -- Universidad Verecruzana 16 - 148.226.35.0/24 3770 0.2% AS7184 -- Universidad Verecruzana 17 - 148.226.144.0/24 3769 0.2% AS7184 -- Universidad Verecruzana 18 - 148.226.156.0/24 3768 0.2% AS7184 -- Universidad Verecruzana 19 - 148.226.37.0/24 3768 0.2% AS7184 -- Universidad Verecruzana 20 - 148.226.36.0/24 3767 0.2% AS7184 -- Universidad Verecruzana Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 17 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Jun 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201106172200.p5HM00eE019359@wattle.apnic.net> This report has been generated at Fri Jun 17 21:12:10 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 10-06-11 362401 212969 11-06-11 362865 212988 12-06-11 362894 212811 13-06-11 362781 212889 14-06-11 362958 213010 15-06-11 363109 213677 16-06-11 363872 213478 17-06-11 363542 214276 AS Summary 38008 Number of ASes in routing system 16019 Number of ASes announcing only one prefix 3626 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109862144 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 17Jun11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 363650 214229 149421 41.1% All ASes AS6389 3626 257 3369 92.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2457 934 1523 62.0% KIXS-AS-KR Korea Telecom AS18566 1913 493 1420 74.2% COVAD - Covad Communications Co. AS4323 1661 399 1262 76.0% TWTC - tw telecom holdings, inc. AS22773 1338 94 1244 93.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1493 308 1185 79.4% VZGNI-TRANSIT - Verizon Online LLC AS6478 1634 456 1178 72.1% ATT-INTERNET3 - AT&T Services, Inc. AS4755 1479 385 1094 74.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1799 761 1038 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS7552 1143 117 1026 89.8% VIETEL-AS-AP Vietel Corporation AS28573 1258 268 990 78.7% NET Servicos de Comunicao S.A. AS10620 1523 669 854 56.1% Telmex Colombia S.A. AS18101 935 145 790 84.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7545 1538 752 786 51.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS24560 1153 390 763 66.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4808 1052 339 713 67.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS8151 1270 558 712 56.1% Uninet S.A. de C.V. AS7303 990 310 680 68.7% Telecom Argentina S.A. AS3356 1119 457 662 59.2% LEVEL3 Level 3 Communications AS17488 950 316 634 66.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS14420 683 82 601 88.0% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS17676 666 70 596 89.5% GIGAINFRA Softbank BB Corp. AS22561 933 356 577 61.8% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 977 420 557 57.0% GBLX Global Crossing Ltd. AS22047 572 32 540 94.4% VTR BANDA ANCHA S.A. AS4780 749 214 535 71.4% SEEDNET Digital United Inc. AS7011 1159 628 531 45.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS855 643 118 525 81.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS15475 526 8 518 98.5% NOL AS4804 586 87 499 85.2% MPX-AS Microplex PTY LTD Total 37825 10423 27402 72.4% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 27.0.128.0/17 AS7514 MEX Media EXchange, Inc. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.22.32.0/19 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.229.102.0/23 AS8237 DATAWAY-AS dataway GmbH, Zurich, Switzerland 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 131.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.72.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.100.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.161.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.221.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.157.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.184.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.191.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 134.175.0.0/16 AS14576 RHNL-NET - Righthosting.com 134.175.0.0/19 AS12124 THORN - Thorn Communications 138.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.36.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.94.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.97.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.99.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.117.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.118.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.122.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.185.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.186.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.219.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 143.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.137.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.208.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.101.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.102.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.103.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.156.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.166.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.167.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.168.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.169.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.170.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.171.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.172.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.173.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.174.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.175.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.200.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.201.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.203.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.206.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.207.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.230.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.235.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.236.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.237.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.240.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.241.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.242.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.243.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.248.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.252.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.253.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 161.10.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.18.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.22.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.138.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.140.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.212.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.57.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.58.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.60.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.61.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.62.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.63.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.116.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.90.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.181.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.194.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.195.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.196.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.197.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.227.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.228.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.78.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.79.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.80.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.81.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.82.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.83.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.84.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.150.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 176.74.200.0/21 AS35768 MSLINK-AS MTK-ERA Autonomous System 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 191.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.158.25.0/24 AS2717 CUMMINS-AS1 - Cummins Engine Co. Inc. 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.5.192.0/19 AS10076 ASN-ERDEMNET # AS-ERDEMNET CONVERTED TO ASN-ERDEMNET FOR RPSL COMPLIANCE ERDEMNET ISP 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.101.0/24 AS45645 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.63.80.0/24 AS9557 PKTELECOM-AS-PK Paknet Limited Merged into PTCL 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.147.110.0/24 AS45165 203.147.111.0/24 AS45165 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.190.32.0/22 AS24564 204.10.232.0/21 AS33150 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From patrick at ianai.net Fri Jun 17 17:00:25 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 17 Jun 2011 18:00:25 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: <4DFBCAA7.6000800@paulgraydon.co.uk> References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> <4DFBCAA7.6000800@paulgraydon.co.uk> Message-ID: <1A160B62-14AF-4072-BCDD-DE034C4A2171@ianai.net> On Jun 17, 2011, at 5:44 PM, Paul Graydon wrote: > On 06/17/2011 11:33 AM, David Conrad wrote: >> On Jun 17, 2011, at 11:23 AM, Jay Ashworth wrote: >>>>> http://tech.slashdot.org/story/11/06/17/202245/ >>>> You just learned about this now? >>> In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 >>> months or so; where should I have seen it? >> New TLDs have been discussed now for over a decade. Press (both technical and popular) on ICANN activities have ratcheted up significantly recently, particularly with the approval of .XXX (which was recently discussed here on NANOG: http://mailman.nanog.org/pipermail/nanog/2011-March/034488.html). Not blaming/accusing, just surprised this would be a surprise. I guess I've been living in the layer9 cloud too long.... >> >> Regards, >> -drc > I've seen the stuff about adding a few extra TLDs, like XXX. I haven't seen any references until now of them considering doing it on a commercial basis. I don't mind new TLDs, but company ones are crazy and going to lead to a confusing and messy internet. Yeah, 'cause it's not messy & confusing already.... The Internet is a business, ICANN wants money (despite their non-profit status - check out how much the execs get paid). Companies want $FOO. They get $FOO, because they PAY FOR THE INTERNET. Without them, we all don't have jobs. As for calling ICANN stupid, thinking this will help fracture the 'Net, I think you are all confused. I think the NANOG community has become (OK, always was) a bit of an echo chamber. Trust me when I say we are the minority. Most people think very differently, and we better accept that if we hope to affect things outside our little group. -- TTFN, patrick From jra at baylink.com Fri Jun 17 17:02:09 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 18:02:09 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <3D49F5B5-0F60-4FE8-9DC1-1F8D2C31D023@zaidali.com> Message-ID: <32195481.612.1308348129152.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Zaid Ali" > Just an example, it has hit main stream media > http://globalpublicsquare.blogs.cnn.com/2011/03/17/who-runs-the-internet/ The issue we're presently discussing *is not mentioned in that article*. > Or you could have gone to one of the many free iCANN meetings where > you can hear about this till your ears go blue. It has only been a > topic for discussion for about 10 years :) but of course if it's not > on NANOG it can't be true. Course not. :-) Notwithstanding that, globally resolvable valid DNS names *with no dots in them* are going to break a fair amount of software which assumes that's an invalid case, and that is in fact a *different* situation, not triggered by the expansion of the *generic* gTLD space. So, like DRC, your response isn't to my actual point. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From zaid at zaidali.com Fri Jun 17 17:06:05 2011 From: zaid at zaidali.com (Zaid Ali) Date: Fri, 17 Jun 2011 15:06:05 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> <60CD072E-8323-4CC0-A060-00A89990A0B2@virtualized.org> Message-ID: On Jun 17, 2011, at 2:54 PM, Benson Schliesser wrote: > > On Jun 17, 2011, at 4:21 PM, David Conrad wrote: > >> On Jun 17, 2011, at 11:04 AM, Jay Ashworth wrote: >>> Aw, Jeezus. >>> >>> No. Just, no. >>> >>> http://tech.slashdot.org/story/11/06/17/202245/ >> >> You just learned about this now? > > On a related topic, the US DoJ recently wrote a letter suggesting that DNS registry/registrar vertical integration might not be a good idea (from an anti-trust perspective). > > http://www.icann.org/en/correspondence/strickling-to-dengate-thrush-16jun11-en.pdf > > Cheers, > -Benson And before that, a need for a comprehensive economic study http://forum.icann.org/lists/5gtld-guide/msg00013.html See a pattern? Zaid From jra at baylink.com Fri Jun 17 17:09:26 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 18:09:26 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <16722429.614.1308348566630.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Benson Schliesser" > On a related topic, the US DoJ recently wrote a letter suggesting that > DNS registry/registrar vertical integration might not be a good idea > (from an anti-trust perspective). > > http://www.icann.org/en/correspondence/strickling-to-dengate-thrush-16jun11-en.pdf Y'know, I thought I'd covered that point in my DNS NOI comments (now, lo, 14 years old: http://www.merit.edu/mail.archives/nanog/1997-07/msg00156.html but as it turns out, I had apparently confused "registrar" and "registry" -- not as mortal a sin then as it would be now -- so I can't actually point to an answer to that question. I do *have* an answer: yes; separating them is a good idea. I appeared to have the opposite answer in those comments; I was miscalling a registry a registrar, which is why it looked like that. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From zaid at zaidali.com Fri Jun 17 17:12:13 2011 From: zaid at zaidali.com (Zaid Ali) Date: Fri, 17 Jun 2011 15:12:13 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <22653040.608.1308347687356.JavaMail.root@benjamin.baylink.com> References: <22653040.608.1308347687356.JavaMail.root@benjamin.baylink.com> Message-ID: <308203E5-6BD0-4D2F-834A-D72401A1418B@zaidali.com> On Jun 17, 2011, at 2:54 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Joel Barnard" > >> I hope they've considered what will happen if you go to >> http://localhost/ or >> http://pcname/ >> >> Is that the local networks pcname, or the gTld pcname? >> Are we going to have to start using a specially reserved .local gTld? > > No, of *course* ICANN didn't give any engineering thought to it. Cause the > engineers? Are all *here*. And David Conrad's apparently the only guy > who's heard about it. :-) I have seen many NANOG folks at ICANN meetings discussing this and also active on ALAC so David isn't the only guy. Also do a search on the list and you will find threads dating back. http://article.gmane.org/gmane.org.operators.nanog/56728/match=gTLDs Zaid From jaap at NLnetLabs.nl Fri Jun 17 17:13:10 2011 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Sat, 18 Jun 2011 00:13:10 +0200 Subject: ICANN to allow commercial gTLDs In-Reply-To: <21961578.610.1308347946923.JavaMail.root@benjamin.baylink.com> References: <21961578.610.1308347946923.JavaMail.root@benjamin.baylink.com> Message-ID: <201106172213.p5HMDAGA057461@bartok.nlnetlabs.nl> And no, I had not heard *any noise* that anyone was seriously considering this up until this announcement. Overhere it got mentioned in the local news paper a couple of times. jaap From jra at baylink.com Fri Jun 17 17:13:42 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 18:13:42 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <1A160B62-14AF-4072-BCDD-DE034C4A2171@ianai.net> Message-ID: <13646138.616.1308348822044.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Patrick W. Gilmore" > As for calling ICANN stupid, thinking this will help fracture the > 'Net, I think you are all confused. I think the NANOG community has > become (OK, always was) a bit of an echo chamber. Trust me when I say > we are the minority. Most people think very differently, and we better > accept that if we hope to affect things outside our little group. We may be the minority, but my experience is we have a pretty good record at spotting where the pinch points might come up in proposed expansions/ changes. http://apple/ is going to break a bunch of shit. (Ok, it might or might not break actual browsers, but I have seen "require at least one dot or assume it's not a domain name" in *lots* of code; the inability to put sjobs at apple in your address book will not be popular.) Interstate-level traffic engineering types are not a big political bloc, either... but no one ignores them when building Interstates. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Fri Jun 17 17:14:57 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 18:14:57 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <308203E5-6BD0-4D2F-834A-D72401A1418B@zaidali.com> Message-ID: <14425713.618.1308348897011.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Zaid Ali" > I have seen many NANOG folks at ICANN meetings discussing this and > also active on ALAC so David isn't the only guy. Also do a search on > the list and you will find threads dating back. > > http://article.gmane.org/gmane.org.operators.nanog/56728/match=gTLDs Noted. Retracted on that point. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From fred at cisco.com Fri Jun 17 17:29:08 2011 From: fred at cisco.com (Fred Baker) Date: Fri, 17 Jun 2011 15:29:08 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> Message-ID: <80804D70-5B17-4381-8BB9-1B33347D275A@cisco.com> On Jun 17, 2011, at 2:33 PM, David Conrad wrote: > On Jun 17, 2011, at 11:23 AM, Jay Ashworth wrote: >>>> http://tech.slashdot.org/story/11/06/17/202245/ >>> You just learned about this now? >> In fact I did. I certainly haven't seen it mentioned on NANOG in the last 6 >> months or so; where should I have seen it? > > New TLDs have been discussed now for over a decade. Press (both technical and popular) on ICANN activities have ratcheted up significantly recently, particularly with the approval of .XXX (which was recently discussed here on NANOG: http://mailman.nanog.org/pipermail/nanog/2011-March/034488.html). Not blaming/accusing, just surprised this would be a surprise. I guess I've been living in the layer9 cloud too long.... Yes. Since ICANN was formed, they have periodically come to the IETF to ask how many TLDs we thought the system could support. On the basis of the SLD count (if example.com is a domain name and ".com" is a TLD, "example" is an SLD) within recognized gTLDs like .com, I would have to say that a properly maintained database can handle a very large number of names in a flat name space. That said, that does not imply that the DNS should be replaced with a flat namespace; there's this "scaling" thing that competent people think about. What I told them, periodically, as IETF Chair, was that the number of TLDs in the network was largely a business discussion. If a potential TLD came forth with a business plan that made sense, fine, and if the business plan didn't pencil out, there was no sense in adding the TLD. Given the number of times they asked, that wasn't a satisfactory response; they wanted a number. In this case, I would look at it this way. Imagine that ICANN wanted to go into the business of selling SLDs in competition with .com etc. How would they go about it? There are two obvious ways: they could create a new TLD such as ".icann" and sell names like "example.icann". Or, the could start selling TLDs on the open market. The really nice thing from their perspective would be that they don't need to maintain the database, bandwidth, or putzpower needed to supply the service - they already have a set of root zone operators that have volunteered to do so. So, they make money on the names and deliver the service for free. Pencils out for them, I suppose. > Regards, > -drc > > From jra at baylink.com Fri Jun 17 17:33:12 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 18:33:12 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <80804D70-5B17-4381-8BB9-1B33347D275A@cisco.com> Message-ID: <30049498.622.1308349992330.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Fred Baker" > Yes. Since ICANN was formed, they have periodically come to the IETF > to ask how many TLDs we thought the system could support. On the basis > of the SLD count (if example.com is a domain name and ".com" is a TLD, > "example" is an SLD) within recognized gTLDs like .com, I would have > to say that a properly maintained database can handle a very large > number of names in a flat name space. That said, that does not imply > that the DNS should be replaced with a flat namespace; there's this > "scaling" thing that competent people think about. > > What I told them, periodically, as IETF Chair, was that the number of > TLDs in the network was largely a business discussion. If a potential > TLD came forth with a business plan that made sense, fine, and if the > business plan didn't pencil out, there was no sense in adding the TLD. > Given the number of times they asked, that wasn't a satisfactory > response; they wanted a number. > > In this case, I would look at it this way. Imagine that ICANN wanted > to go into the business of selling SLDs in competition with .com etc. > How would they go about it? There are two obvious ways: they could > create a new TLD such as ".icann" and sell names like "example.icann". > Or, the could start selling TLDs on the open market. The really nice > thing from their perspective would be that they don't need to maintain > the database, bandwidth, or putzpower needed to supply the service - > they already have a set of root zone operators that have volunteered > to do so. So, they make money on the names and deliver the service for > free. And that's fine... but it still doesn't forsee the idea that a registry *could be it's own -- and only -- client*. For me, the engineering problem remains *single-component FQDNs*. I can't itemize the code they'll break, but I'm quite certain there's a lot. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From owen at delong.com Fri Jun 17 18:18:49 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Jun 2011 16:18:49 -0700 Subject: IPv6 BGP communities In-Reply-To: <499402.79882.qm@web121418.mail.ne1.yahoo.com> References: <499402.79882.qm@web121418.mail.ne1.yahoo.com> Message-ID: I think it actually makes complete sense to use the same BGP communities for the same purposes regardless of address family. Owen On Jun 17, 2011, at 6:08 AM, Serge Vautour wrote: > Hello, > > I'm looking at re-writing our IPv4 BGP policies for IPv6. Does anyone see a > problem with re-using the same BGP community values? If we use AS:110 for LP 110 > under IPv4, can I just use AS:110 for LP 110 under IPv6? Technically it works - > at least I haven't seen a problem in my initial tests. It sure would make > everything easier than assigning new values. Is there a BCP for this? > > Thanks, > Serge > From johnl at iecc.com Fri Jun 17 18:29:51 2011 From: johnl at iecc.com (John Levine) Date: 17 Jun 2011 23:29:51 -0000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <32195481.612.1308348129152.JavaMail.root@benjamin.baylink.com> Message-ID: <20110617232951.14681.qmail@joyce.lan> >Notwithstanding that, globally resolvable valid DNS names *with no dots >in them* are going to break a fair amount of software which assumes that's >an invalid case, and that is in fact a *different* situation, not triggered >by the expansion of the *generic* gTLD space. Just to be sure I understand, you're saying that since you haven't been paying attention until now, nobody else in the entire world could possible have thought about this? I happen to agree that adding vast numbers of new TLDs is a terrible idea more for administrative and social than technical reasons, but this is the first you've heard about it, you really haven't been paying attention. R's, John From bicknell at ufp.org Fri Jun 17 18:52:23 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Jun 2011 16:52:23 -0700 Subject: IPv6 BGP communities In-Reply-To: <499402.79882.qm@web121418.mail.ne1.yahoo.com> References: <499402.79882.qm@web121418.mail.ne1.yahoo.com> Message-ID: <20110617235223.GA31147@ussenterprise.ufp.org> In a message written on Fri, Jun 17, 2011 at 06:08:13AM -0700, Serge Vautour wrote: > I'm looking at re-writing our IPv4 BGP policies for IPv6. Does anyone see a > problem with re-using the same BGP community values? If we use AS:110 for LP 110 > under IPv4, can I just use AS:110 for LP 110 under IPv6? Technically it works - > at least I haven't seen a problem in my initial tests. It sure would make > everything easier than assigning new values. Is there a BCP for this? Some of us run BGP implementations that allow us to process IPv4 and IPv6 routes in the exact same route policy. On behalf of that group I urge you to use the same communities where the meaning is in fact the same, because if you don't you'll double the work for that group when they have to write separate route policy. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From drc at virtualized.org Fri Jun 17 19:13:41 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Jun 2011 14:13:41 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <21961578.610.1308347946923.JavaMail.root@benjamin.baylink.com> References: <21961578.610.1308347946923.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 17, 2011, at 11:59 AM, Jay Ashworth wrote: > FFS, David. I didn't say "new gTLDs". I said, rather specifically, > "commercial gTLDs", IE: gTLDs *proprietary to a specific commercial > enterprise*. http:///www.apple The third message (by Eric Brunner-Williams) in the thread I referenced mentions "trademark" or "brand" TLDs: "Finally, because pancakes are calling, the very complainants of squatting and defensive registration (the 1Q million-in-revenue every applicant for an "open", now "standard" registry places in its bizplan), the Intellectual Property Stakeholder Group is also an advocate for trademark TLDs, arguing that possession of $fee and a registry platform contract (there is now a niche industry of boutique ".brand" operators-in-waiting) and a $bond establishes an absolute right to a label in the IANA root. So, rather than memorizing the digits of Pi, for some later public recitation, one could start reciting brand names, for some later public recitation, for as long as there is a single unified root." See http://mailman.nanog.org/pipermail/nanog/2011-March/034692.html for full context. I didn't bother looking further. > And no, I had not heard *any noise* that anyone was seriously considering > this up until this announcement. Interesting data point. Regards, -drc From drc at virtualized.org Fri Jun 17 19:19:40 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Jun 2011 14:19:40 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <22653040.608.1308347687356.JavaMail.root@benjamin.baylink.com> References: <22653040.608.1308347687356.JavaMail.root@benjamin.baylink.com> Message-ID: <27100748-F707-4B16-95C8-2895485FB6D1@virtualized.org> On Jun 17, 2011, at 11:54 AM, Jay Ashworth wrote: >> I hope they've considered what will happen if you go to >> http://localhost/ or >> http://pcname/ >> >> Is that the local networks pcname, or the gTld pcname? >> Are we going to have to start using a specially reserved .local gTld? > > No, of *course* ICANN didn't give any engineering thought to it. Cause the > engineers? Are all *here*. Perhaps relevant: http://www.icann.org/en/committees/security/sac045.pdf > And David Conrad's apparently the only guy who's heard about it. :-) When I used to go to ICANN meetings (haven't been to one in years), there were always a number of folks from the RIR community there, which at least in the ARIN region, tends to have non-trivial intersection with the NANOG community. I would be quite surprised if I was "the only guy who's heard about it". Regards, -drc From jra at baylink.com Fri Jun 17 19:33:08 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 20:33:08 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110617232951.14681.qmail@joyce.lan> Message-ID: <22308707.634.1308357188484.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Levine" > I happen to agree that adding vast numbers of new TLDs is a terrible > idea more for administrative and social than technical reasons, but > this is the first you've heard about it, you really haven't been > paying attention. John, yes, I've been paying attention to the TLD space since Chris Ambler *first* put in his .web proposal -- what is that; 15 years now? 20? This is the first I've heard of *the possibility of TLD registrars being end-user internal/exclusive*. People have made jokes about company TLDs in the past, sure, but no, I never heard any specific discussion about it actually happening; I invite citations. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Fri Jun 17 19:37:11 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 20:37:11 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <13002116.636.1308357431779.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "David Conrad" > "Finally, because pancakes are calling, the very complainants of > squatting and defensive registration (the 1Q million-in-revenue every > applicant for an "open", now "standard" registry places in its > bizplan), the Intellectual Property Stakeholder Group is also an > advocate for trademark TLDs, arguing that possession of $fee and a > registry platform contract (there is now a niche industry of boutique > ".brand" operators-in-waiting) and a $bond establishes an absolute > right to a label in the IANA root. > > So, rather than memorizing the digits of Pi, for some later public > recitation, one could start reciting brand names, for some later > public recitation, for as long as there is a single unified root." > > See http://mailman.nanog.org/pipermail/nanog/2011-March/034692.html > for full context. That's an *amazingly* oblique and de minimis reference to the topic on point, couched in Eric's usually opaque language, and buried in a thread I'd long since stopped paying attention to by that point; my apologies to you for not having seen it, since you seem to feel that's material. Cheers, -- jr 'I wouldn't call it a datapoint, though' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From johnl at iecc.com Fri Jun 17 19:40:58 2011 From: johnl at iecc.com (John Levine) Date: 18 Jun 2011 00:40:58 -0000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <22308707.634.1308357188484.JavaMail.root@benjamin.baylink.com> Message-ID: <20110618004058.17116.qmail@joyce.lan> >This is the first I've heard of *the possibility of TLD registrars being >end-user internal/exclusive*. People around ICANN have been arguing about the registry/registrar split for years, and whether to have special rules for TLDs where one party would own all the names. Really. If this is the first you've heard about it, you haven't been paying attention. Or, I suppose, you might be claiming that David and I are just lying. R's, John From joelja at bogus.com Fri Jun 17 19:43:11 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 17 Jun 2011 17:43:11 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <22308707.634.1308357188484.JavaMail.root@benjamin.baylink.com> References: <22308707.634.1308357188484.JavaMail.root@benjamin.baylink.com> Message-ID: <85838CB1-B3F9-4916-8786-19C13D835613@bogus.com> On Jun 17, 2011, at 5:33 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "John Levine" > >> I happen to agree that adding vast numbers of new TLDs is a terrible >> idea more for administrative and social than technical reasons, but >> this is the first you've heard about it, you really haven't been >> paying attention. > > John, yes, I've been paying attention to the TLD space since Chris Ambler > *first* put in his .web proposal -- what is that; 15 years now? 20? > > This is the first I've heard of *the possibility of TLD registrars being > end-user internal/exclusive*. > > People have made jokes about company TLDs in the past, sure, but no, I > never heard any specific discussion about it actually happening; I invite > citations. http://www.icann.org/en/topics/new-gtlds/consultation-outreach-en.htm > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > From jra at baylink.com Fri Jun 17 20:07:23 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 21:07:23 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <21342046.644.1308359243408.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joel Jaeggli" > >> http://www.icann.org/en/topics/new-gtlds/consultation-outreach-en.htm > > > > That page doesn't appear to discuss the specific topic I'm talking about, > > and for the 9th or 10th time, I *know* they've been talking about expanding > > the root; I approved that message back in 1997, as posted earlier. > > It does. > > The process as described in 2009 places no lower bound on the > narrowness of the community which a gtld proposes to serve. > > 1.2.2 Community-Based Designation > All applicants are required to designate whether their > application is community-based. > > 1.2.2.1 Definitions2 > > For purposes of this Applicant Guidebook, a communitybased gTLD is a > gTLD that is operated for the benefit of a > defined community consisting of a restricted population. > > An applicant designating its application as communitybased will be > asked to substantiate its status as > representative of the community it names in the > application, and additional information may be requested > in the event of a comparative evaluation (refer to Section > 4.2 of Module 4). An applicant for a community-based > gTLD is expected to: > > 1. Demonstrate an ongoing relationship with a defined > community that consists of a restricted population. > 2. Have applied for a gTLD string strongly and specifically > related to the community named in the application. > 3. Have proposed dedicated registration and use policies > for registrants in its proposed gTLD. > 4. Have its application endorsed in writing by an > established institution representing the community it > has named. > > For purposes of differentiation, an application that has not > been designated as community-based will be referred to > hereinafter in this document as an open gTLD. An open > gTLD can be used for any purpose consistent with the > requirements of the application and evaluation criteria, > and with the registry agreement. An open gTLD may or > may not have a formal relationship with an exclusive > registrant or user population. It may or may not employ > eligibility or use restrictions I will concur with your assertion that it is *possible to infer* that Apple running a .apple registry for its own internal commercial purposes would fit their definition of "community"... but the phrasing of the restrictions they place on it makes it pretty clear, at least to me, that the people who wrote it weren't thinking about that possible use case. All of their restrictions/instructions become tautologies in that limiting case, do they not? And indeed: who arbitrates trademark conflicts, in what is now *necessarily* a global collision space? Forbidding the registration of gTLDs which conflict with trademarks registered with any national authority would seem to be only minimally sane, to me... but that's orthogonal to whether the issue's come up in specific detail, of course. My apologies for not reading deeper into your citation, though I'm not sure I would have caught that section as a response to me anyway. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From marka at isc.org Fri Jun 17 20:11:15 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 18 Jun 2011 11:11:15 +1000 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: Your message of "Fri, 17 Jun 2011 13:18:49 MST." References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> Message-ID: <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> In message , Michael Dillon writes: > > The last v6day was an isoc effort, there can be a separate nanog effort or > > your own. > > It does make a lot of sense for NANOG (perhaps jointly with RIPE and > other NOGs) to organize monthly IPv6 days with a theme or focus for > each month. If you have a focus, then you can recruit a lot of IPv6 > testers to try out certain things on IPv6 day and get a more thorough > test and more feedback > > Skip July and August because it takes time to get this organized, and > then start the next one on September the 8th or thereabouts. > > For instance, one month could focus on full IPv6 DNS support, but > maybe not right away. A nice easy start would be to deal with IPv6 > peering and weird paths that result from tunnels. That is the kind of > thing that would work good with a lot of testers participating and an > application that traces IPv4 and IPv6 paths and measures hop count, > latency, packet loss. > > In conjunction with the monthly IPv6 day, NANOG should set up a blog > page or similar to publicly collect incident reports and solutions. I really don't know why anyone is worried about advertising AAAA records for authoritative nameservers. It just works. Recursive nameservers have been dealing with authoritative nameservers having IPv6 addresses for well over a decade now. This includes dealing with them being unreachable. DNS/UDP is not like HTTP/TCP. You don't have connect timeouts to worry about. Recursive nameservers have much shorter timeouts as they need to deal with IPv4 nameservers not being reachable. They also have to do all this re-trying within 3 or so seconds or else the stub clients will have timed out. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mysidia at gmail.com Fri Jun 17 20:25:28 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 17 Jun 2011 20:25:28 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: <30049498.622.1308349992330.JavaMail.root@benjamin.baylink.com> References: <80804D70-5B17-4381-8BB9-1B33347D275A@cisco.com> <30049498.622.1308349992330.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, Jun 17, 2011 at 5:33 PM, Jay Ashworth wrote: > For me, the engineering problem remains *single-component FQDNs*. ?I > can't itemize the code they'll break, but I'm quite certain there's a lot. Perhaps we could get an update to the relevant RFCs.. clarifying that only NS records may be dotless in the root namespace? As in -- No hostnames A, MX, or CNAME at the TLD level. The notion of a single-component FQDN would be quite a breakage for the basic concept of using both FQDNs and Unqualified names. Consider you have a hostname on your lan called "foobar", and someone registers .foobar and lists an @ A in the foobar zone. So... does "http://foobar" go to your LAN server? If yes, then .foobar's @ record is worthless. If no, then you have a security problem.... when .foobar is suddenly registered without you knowing, and the @ A gets pointed to a 'credentials stealing' site. > Cheers, > -- jra -- -JH From johnl at iecc.com Fri Jun 17 20:33:28 2011 From: johnl at iecc.com (John Levine) Date: 18 Jun 2011 01:33:28 -0000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <20110618013328.18875.qmail@joyce.lan> >The notion of a single-component FQDN would be quite a breakage for >the basic concept of using both FQDNs and Unqualified names. Well, you know, there's a guy whose email address has been n at ai for many years. People have varying amounts of success sending him mail. R's, John From drc at virtualized.org Fri Jun 17 20:36:20 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Jun 2011 15:36:20 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <13002116.636.1308357431779.JavaMail.root@benjamin.baylink.com> References: <13002116.636.1308357431779.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 17, 2011, at 2:37 PM, Jay Ashworth wrote: > That's an *amazingly* oblique and de minimis reference to the topic on > point, couched in Eric's usually opaque language, Eric's writing style does take a bit of getting used to, but I usually find it enlightening (albeit occasionally in an existential way) :-). > and buried in a thread I'd long since stopped paying attention to by that point; It was the third message in the thread. > my apologies to you for not having seen it, since you seem to feel that's material. No need to apologize. As I said, I've been in layer 9 too long so I figured the whole .brand thing was common knowledge. Sounds like ICANN should have a liaison to the NANOG world (perhaps the ARIN region ASO AC members can't do that?). Regards, -drc From jra at baylink.com Fri Jun 17 20:38:33 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 21:38:33 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <15662374.650.1308361113003.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "David Conrad" > On Jun 17, 2011, at 2:37 PM, Jay Ashworth wrote: > > That's an *amazingly* oblique and de minimis reference to the topic > > on point, couched in Eric's usually opaque language, > > Eric's writing style does take a bit of getting used to, but I usually > find it enlightening (albeit occasionally in an existential way) :-). Nicely put. > > and buried in a thread I'd long since stopped paying attention to by > > that point; > > It was the third message in the thread. Yeah, I stopped after the first one. > > my apologies to you for not having seen it, since you seem to feel > > that's material. > > No need to apologize. As I said, I've been in layer 9 too long so I > figured the whole .brand thing was common knowledge. Sounds like ICANN > should have a liaison to the NANOG world (perhaps the ARIN region ASO > AC members can't do that?). I enter layers 8 and 9 only at gunpoint. (It's people, and money, ascending, right?) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Fri Jun 17 20:47:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 21:47:47 -0400 (EDT) Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110618013328.18875.qmail@joyce.lan> Message-ID: <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Levine" > >The notion of a single-component FQDN would be quite a breakage for > >the basic concept of using both FQDNs and Unqualified names. > > Well, you know, there's a guy whose email address has been n at ai for > many years. People have varying amounts of success sending him mail. My Zimbra UI says it "might be invalid"; the default postfix config inside it tries to send it to n at ai.baylink.com, and complains because the domain won't resolve. If I'm reading 3.2.4 of 2822 properly (that notation is one I'm not entirely familiar with, and should be), that really is a valid 2822 address, as odd as it sounds. Clearly, it's semantics are unexpected, though. I guess I should go hang a bug on it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From joelja at bogus.com Fri Jun 17 20:48:25 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 17 Jun 2011 18:48:25 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <13646138.616.1308348822044.JavaMail.root@benjamin.baylink.com> References: <13646138.616.1308348822044.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 17, 2011, at 3:13 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Patrick W. Gilmore" > >> As for calling ICANN stupid, thinking this will help fracture the >> 'Net, I think you are all confused. I think the NANOG community has >> become (OK, always was) a bit of an echo chamber. Trust me when I say >> we are the minority. Most people think very differently, and we better >> accept that if we hope to affect things outside our little group. > > We may be the minority, but my experience is we have a pretty good record > at spotting where the pinch points might come up in proposed expansions/ > changes. > > http://apple/ is going to break a bunch of shit. > > (Ok, it might or might not break actual browsers, but I have seen "require at > least one dot or assume it's not a domain name" in *lots* of code; the > inability to put sjobs at apple in your address book will not be popular.) All fully qualified domain names have a trailing dot so that you know where the root is. At least as parsed internally by your resolver... :~ jjaeggli$ dig com ; <<>> DiG 9.6.0-APPLE-P2 <<>> com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;com. IN A ;; AUTHORITY SECTION: com. 705 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1308361302 1800 900 604800 86400 ;; Query time: 257 msec ;; SERVER: 192.168.46.1#53(192.168.46.1) ;; WHEN: Fri Jun 17 18:45:34 2011 ;; MSG SIZE rcvd: 94 yeah code based on faulty assumptions is going to break, it generally does... one semi-related anecdote, Last time I ran an ietf meeting that did dynamic dns registration (circa 2005), some people discovered the corprate firewalls would let them in if the reverse entry for their ip address was in the form host.domain.meeting.ietf.org, clearly that's really hard to subvert. > Interstate-level traffic engineering types are not a big political bloc, > either... but no one ignores them when building Interstates. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > From cloos at jhcloos.com Fri Jun 17 20:42:54 2011 From: cloos at jhcloos.com (James Cloos) Date: Fri, 17 Jun 2011 21:42:54 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: (Jeremy's message of "Fri, 17 Jun 2011 16:21:04 -0500") References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> <20110617211623.GD38065@mikea.ath.cx> Message-ID: >>>>> "J" == Jeremy writes: J> well, crap. That's all I have to say :( Didn't you mean .crap ? ;-/ -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From jra at baylink.com Fri Jun 17 21:00:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 22:00:47 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <22037285.658.1308362447241.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joel Jaeggli" > On Jun 17, 2011, at 3:13 PM, Jay Ashworth wrote: > > http://apple/ is going to break a bunch of shit. > > All fully qualified domain names have a trailing dot so that you know > where the root is. At least as parsed internally by your resolver... Sure. And Apple's gonna make sure they put that trailing dot in their ads and links and stuff... and their users will, without fail, remember to type it. :-) Oh, it is Friday night, isn't it? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From owen at delong.com Fri Jun 17 21:04:19 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Jun 2011 19:04:19 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <13002116.636.1308357431779.JavaMail.root@benjamin.baylink.com> Message-ID: <23892D49-AD8A-4B16-B2A9-49D356CEC3AD@delong.com> On Jun 17, 2011, at 6:36 PM, David Conrad wrote: > On Jun 17, 2011, at 2:37 PM, Jay Ashworth wrote: >> That's an *amazingly* oblique and de minimis reference to the topic on >> point, couched in Eric's usually opaque language, > > Eric's writing style does take a bit of getting used to, but I usually find it enlightening (albeit occasionally in an existential way) :-). > >> and buried in a thread I'd long since stopped paying attention to by that point; > > It was the third message in the thread. > >> my apologies to you for not having seen it, since you seem to feel that's material. > > No need to apologize. As I said, I've been in layer 9 too long so I figured the whole .brand thing was common knowledge. Sounds like ICANN should have a liaison to the NANOG world (perhaps the ARIN region ASO AC members can't do that?). > > Regards, > -drc > I really don't think that namespace issues are part of the role for the ASO AC. This is clearly a problem for ICANN's disaster-ridden domain-name side, and not for the ASO/NRO side of things. Frankly, it hadn't occurred to me that ICANN would actually do this, but, now that it's happening, it doesn't really surprise me. Operationally, it's a horrible idea, but, most of us in layers 1-4 stopped paying much attention to the disasters happening at ICANN for DNS along time ago as we sort of came to believe that we didn't have enough money to bribe^h^h^h^h^hinfluence the right people in a sufficiently meaningful way to make our voices heard. Owen From drc at virtualized.org Fri Jun 17 21:09:40 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Jun 2011 16:09:40 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <22037285.658.1308362447241.JavaMail.root@benjamin.baylink.com> References: <22037285.658.1308362447241.JavaMail.root@benjamin.baylink.com> Message-ID: <3EB37668-D8EC-48BE-9306-A9AF38C424EB@virtualized.org> On Jun 17, 2011, at 4:00 PM, Jay Ashworth wrote: >> On Jun 17, 2011, at 3:13 PM, Jay Ashworth wrote: >>> http://apple/ is going to break a bunch of shit. >> >> All fully qualified domain names have a trailing dot so that you know >> where the root is. At least as parsed internally by your resolver... > > Sure. And Apple's gonna make sure they put that trailing dot in their > ads and links and stuff... and their users will, without fail, remember > to type it. :-) I suspect the folks who spend $185K + yearly fees will be able to afford engineering staff that will point out that a naked TLD is unlikely to work for the great unwashed masses. And if they don't, they'll get exactly what they deserve. What I suspect you'll more likely see will be macbook.apple or japan.cisco or copyright-enforcement.universal. Maybe. Regards, -drc From owen at delong.com Fri Jun 17 21:06:12 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Jun 2011 19:06:12 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <15662374.650.1308361113003.JavaMail.root@benjamin.baylink.com> References: <15662374.650.1308361113003.JavaMail.root@benjamin.baylink.com> Message-ID: <652EBF84-2DEA-496F-9A49-35D6443673FF@delong.com> On Jun 17, 2011, at 6:38 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "David Conrad" > >> On Jun 17, 2011, at 2:37 PM, Jay Ashworth wrote: >>> That's an *amazingly* oblique and de minimis reference to the topic >>> on point, couched in Eric's usually opaque language, >> >> Eric's writing style does take a bit of getting used to, but I usually >> find it enlightening (albeit occasionally in an existential way) :-). > > Nicely put. > >>> and buried in a thread I'd long since stopped paying attention to by >>> that point; >> >> It was the third message in the thread. > > Yeah, I stopped after the first one. > >>> my apologies to you for not having seen it, since you seem to feel >>> that's material. >> >> No need to apologize. As I said, I've been in layer 9 too long so I >> figured the whole .brand thing was common knowledge. Sounds like ICANN >> should have a liaison to the NANOG world (perhaps the ARIN region ASO >> AC members can't do that?). > > I enter layers 8 and 9 only at gunpoint. (It's people, and money, > ascending, right?) > I believe 8-10 are financial, political, religious (ascending), but, I suspect that the layer ordering at those levels may be organization and/or astronomical-phenomenon[1] dependent. Owen [1] May vary based on e.g. phase of the moon, time of day, etc. From drc at virtualized.org Fri Jun 17 21:13:00 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Jun 2011 16:13:00 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <23892D49-AD8A-4B16-B2A9-49D356CEC3AD@delong.com> References: <13002116.636.1308357431779.JavaMail.root@benjamin.baylink.com> <23892D49-AD8A-4B16-B2A9-49D356CEC3AD@delong.com> Message-ID: On Jun 17, 2011, at 4:04 PM, Owen DeLong wrote: > I really don't think that namespace issues are part of the role for the ASO AC. Why do you think there is an ASO? > This is clearly a problem for ICANN's disaster-ridden domain-name side, and not > for the ASO/NRO side of things. Because there is clearly no inter-relation between domains and address and the operation of the Internet. > Operationally, it's a horrible idea, but, > most of us in layers 1-4 stopped paying much attention to the disasters happening > at ICANN for DNS along time ago as we sort of came to believe that we didn't have > enough money to bribe^h^h^h^h^hinfluence the right people in a sufficiently > meaningful way to make our voices heard. Aren't you one of the folks who state that if you don't participate in PPML then you have no reason to criticize ARIN policies? Regards, -drc From bicknell at ufp.org Fri Jun 17 21:18:44 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Jun 2011 19:18:44 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <80804D70-5B17-4381-8BB9-1B33347D275A@cisco.com> <30049498.622.1308349992330.JavaMail.root@benjamin.baylink.com> Message-ID: <20110618021844.GA35629@ussenterprise.ufp.org> In a message written on Fri, Jun 17, 2011 at 08:25:28PM -0500, Jimmy Hess wrote: > Perhaps we could get an update to the relevant RFCs.. clarifying that > only NS records may be dotless in the root namespace? > > As in -- No hostnames A, MX, or CNAME at the TLD level. I suspect some are already eyeing competitive advantage here. After all, if the root can return your A (MX, CNAME, TXT, RP, whatever) you are guaranteed one DNS query to resolve your name, one RTT to a DNS server, etc. Given the roots are well distributed, with several massively anycasted..... Shaving a DNS lookup or two every now and then is key to some peoples business models. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From owen at delong.com Fri Jun 17 21:18:41 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Jun 2011 19:18:41 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <3EB37668-D8EC-48BE-9306-A9AF38C424EB@virtualized.org> References: <22037285.658.1308362447241.JavaMail.root@benjamin.baylink.com> <3EB37668-D8EC-48BE-9306-A9AF38C424EB@virtualized.org> Message-ID: <30A79BCB-1E9E-4F27-90E8-5269FD70DBF0@delong.com> On Jun 17, 2011, at 7:09 PM, David Conrad wrote: > On Jun 17, 2011, at 4:00 PM, Jay Ashworth wrote: >>> On Jun 17, 2011, at 3:13 PM, Jay Ashworth wrote: >>>> http://apple/ is going to break a bunch of shit. >>> >>> All fully qualified domain names have a trailing dot so that you know >>> where the root is. At least as parsed internally by your resolver... >> >> Sure. And Apple's gonna make sure they put that trailing dot in their >> ads and links and stuff... and their users will, without fail, remember >> to type it. :-) > > I suspect the folks who spend $185K + yearly fees will be able to afford > engineering staff that will point out that a naked TLD is unlikely to > work for the great unwashed masses. And if they don't, they'll get exactly > what they deserve. > That won't stop them from building zone files that look like this: @ IN SOA ... NS ... ... A ... AAAA ... www A ... AAAA ... Sure, they'll advertise www.apple, but, you better believe that they'll take whatever lands at http://apple and you can certainly count on the fact that any mal-actors that get control of one of these TLDs (whether they paid the $185k or not) will take full advantage of the situation and its security risks. > What I suspect you'll more likely see will be macbook.apple or > japan.cisco or copyright-enforcement.universal. > Sure, you'll see all of that, TOO. They're not mutually exclusive. > Maybe. > Almost certainly. Owen From owen at delong.com Fri Jun 17 21:25:30 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Jun 2011 19:25:30 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <13002116.636.1308357431779.JavaMail.root@benjamin.baylink.com> <23892D49-AD8A-4B16-B2A9-49D356CEC3AD@delong.com> Message-ID: <6065C14D-00B5-4FC4-A157-39BCAC06AEC1@delong.com> On Jun 17, 2011, at 7:13 PM, David Conrad wrote: > On Jun 17, 2011, at 4:04 PM, Owen DeLong wrote: >> I really don't think that namespace issues are part of the role for the ASO AC. > > Why do you think there is an ASO? > To coordinate numberspace issues between the IANA and the RIRs. >> This is clearly a problem for ICANN's disaster-ridden domain-name side, and not >> for the ASO/NRO side of things. > > Because there is clearly no inter-relation between domains and address and the > operation of the Internet. > Oh, there is tremendous inter-relation. However, making a mess and then punting it to the ASO is an entirely different matter. >> Operationally, it's a horrible idea, but, >> most of us in layers 1-4 stopped paying much attention to the disasters happening >> at ICANN for DNS along time ago as we sort of came to believe that we didn't have >> enough money to bribe^h^h^h^h^hinfluence the right people in a sufficiently >> meaningful way to make our voices heard. > > Aren't you one of the folks who state that if you don't participate in PPML then > you have no reason to criticize ARIN policies? > It doesn't cost anything to participate in PPML. Owen From jra at baylink.com Fri Jun 17 21:40:22 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 22:40:22 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <30A79BCB-1E9E-4F27-90E8-5269FD70DBF0@delong.com> Message-ID: <29272713.660.1308364822544.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Owen DeLong" > That won't stop them from building zone files that look like this: > > > @ IN SOA ... > NS ... > ... > A ... > AAAA ... > www A ... > AAAA ... > > Sure, they'll advertise www.apple, but, you better believe that > they'll take whatever lands at http://apple and you can certainly > count on the fact that any mal-actors that get control of one of > these TLDs (whether they paid the $185k or not) will take full > advantage of the situation and its security risks. Not necessarily, Owen. Remember: Since we're *in the TLD space* now, you can't capture the unmodified domain *without adding records to the root*: apple.com and www.apple.com are in the same zone file apple. and www.apple. are *not* -- and the root operators may throw their hands up in the air if anyone asks them to have anything in their zone except glue -- rightly, I think; it's not a degree of complexity that's compatible with the required stability of the root zone. Especially since the root zone actually lives in 14 different places. No, anything that requires the root zone to be fluid[1] is going to cause even more fundamental engineering problems than I've been positing so far tonight. Cheers, -- jra [1]requiring updates in anything smaller than days. How often does the root zone actually change; anyone got a pointer to stats on that? -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From internet at cable-lynx.net Fri Jun 17 21:41:38 2011 From: internet at cable-lynx.net (internet at cable-lynx.net) Date: Sat, 18 Jun 2011 02:41:38 +0000 Subject: NANOG Digest, Vol 41, Issue 114 In-Reply-To: References: Message-ID: <2146829810-1308364900-cardhu_decombobulator_blackberry.rim.net-69270912-@b18.c10.bise6.blackberry> Sent wirelessly from my BlackBerry device on the Bell network. Envoy? sans fil par mon terminal mobile BlackBerry sur le r?seau de Bell.s -----Original Message----- From: nanog-request at nanog.org Date: Sat, 18 Jun 2011 01:07:27 To: Reply-To: nanog at nanog.org Subject: NANOG Digest, Vol 41, Issue 114 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: IPv6 BGP communities (Owen DeLong) 2. Re: ICANN to allow commercial gTLDs (John Levine) 3. Re: IPv6 BGP communities (Leo Bicknell) 4. Re: ICANN to allow commercial gTLDs (David Conrad) 5. Re: ICANN to allow commercial gTLDs (David Conrad) 6. Re: ICANN to allow commercial gTLDs (Jay Ashworth) 7. Re: ICANN to allow commercial gTLDs (Jay Ashworth) 8. Re: ICANN to allow commercial gTLDs (John Levine) 9. Re: ICANN to allow commercial gTLDs (Joel Jaeggli) 10. Re: ICANN to allow commercial gTLDs (Jay Ashworth) ---------------------------------------------------------------------- Message: 1 Date: Fri, 17 Jun 2011 16:18:49 -0700 From: Owen DeLong Subject: Re: IPv6 BGP communities To: Serge Vautour Cc: nanog at nanog.org Message-ID: Content-Type: text/plain; charset=us-ascii I think it actually makes complete sense to use the same BGP communities for the same purposes regardless of address family. Owen On Jun 17, 2011, at 6:08 AM, Serge Vautour wrote: > Hello, > > I'm looking at re-writing our IPv4 BGP policies for IPv6. Does anyone see a > problem with re-using the same BGP community values? If we use AS:110 for LP 110 > under IPv4, can I just use AS:110 for LP 110 under IPv6? Technically it works - > at least I haven't seen a problem in my initial tests. It sure would make > everything easier than assigning new values. Is there a BCP for this? > > Thanks, > Serge > ------------------------------ Message: 2 Date: 17 Jun 2011 23:29:51 -0000 From: "John Levine" Subject: Re: ICANN to allow commercial gTLDs To: nanog at nanog.org Message-ID: <20110617232951.14681.qmail at joyce.lan> Content-Type: text/plain; charset=utf-8 >Notwithstanding that, globally resolvable valid DNS names *with no dots >in them* are going to break a fair amount of software which assumes that's >an invalid case, and that is in fact a *different* situation, not triggered >by the expansion of the *generic* gTLD space. Just to be sure I understand, you're saying that since you haven't been paying attention until now, nobody else in the entire world could possible have thought about this? I happen to agree that adding vast numbers of new TLDs is a terrible idea more for administrative and social than technical reasons, but this is the first you've heard about it, you really haven't been paying attention. R's, John ------------------------------ Message: 3 Date: Fri, 17 Jun 2011 16:52:23 -0700 From: Leo Bicknell Subject: Re: IPv6 BGP communities To: nanog at nanog.org Message-ID: <20110617235223.GA31147 at ussenterprise.ufp.org> Content-Type: text/plain; charset="us-ascii" In a message written on Fri, Jun 17, 2011 at 06:08:13AM -0700, Serge Vautour wrote: > I'm looking at re-writing our IPv4 BGP policies for IPv6. Does anyone see a > problem with re-using the same BGP community values? If we use AS:110 for LP 110 > under IPv4, can I just use AS:110 for LP 110 under IPv6? Technically it works - > at least I haven't seen a problem in my initial tests. It sure would make > everything easier than assigning new values. Is there a BCP for this? Some of us run BGP implementations that allow us to process IPv4 and IPv6 routes in the exact same route policy. On behalf of that group I urge you to use the same communities where the meaning is in fact the same, because if you don't you'll double the work for that group when they have to write separate route policy. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://mailman.nanog.org/pipermail/nanog/attachments/20110617/a91469c7/attachment-0001.pgp ------------------------------ Message: 4 Date: Fri, 17 Jun 2011 14:13:41 -1000 From: David Conrad Subject: Re: ICANN to allow commercial gTLDs To: Jay Ashworth Cc: NANOG Message-ID: Content-Type: text/plain; charset=us-ascii On Jun 17, 2011, at 11:59 AM, Jay Ashworth wrote: > FFS, David. I didn't say "new gTLDs". I said, rather specifically, > "commercial gTLDs", IE: gTLDs *proprietary to a specific commercial > enterprise*. http:///www.apple The third message (by Eric Brunner-Williams) in the thread I referenced mentions "trademark" or "brand" TLDs: "Finally, because pancakes are calling, the very complainants of squatting and defensive registration (the 1Q million-in-revenue every applicant for an "open", now "standard" registry places in its bizplan), the Intellectual Property Stakeholder Group is also an advocate for trademark TLDs, arguing that possession of $fee and a registry platform contract (there is now a niche industry of boutique ".brand" operators-in-waiting) and a $bond establishes an absolute right to a label in the IANA root. So, rather than memorizing the digits of Pi, for some later public recitation, one could start reciting brand names, for some later public recitation, for as long as there is a single unified root." See http://mailman.nanog.org/pipermail/nanog/2011-March/034692.html for full context. I didn't bother looking further. > And no, I had not heard *any noise* that anyone was seriously considering > this up until this announcement. Interesting data point. Regards, -drc ------------------------------ Message: 5 Date: Fri, 17 Jun 2011 14:19:40 -1000 From: David Conrad Subject: Re: ICANN to allow commercial gTLDs To: Jay Ashworth Cc: NANOG Message-ID: <27100748-F707-4B16-95C8-2895485FB6D1 at virtualized.org> Content-Type: text/plain; charset=us-ascii On Jun 17, 2011, at 11:54 AM, Jay Ashworth wrote: >> I hope they've considered what will happen if you go to >> http://localhost/ or >> http://pcname/ >> >> Is that the local networks pcname, or the gTld pcname? >> Are we going to have to start using a specially reserved .local gTld? > > No, of *course* ICANN didn't give any engineering thought to it. Cause the > engineers? Are all *here*. Perhaps relevant: http://www.icann.org/en/committees/security/sac045.pdf > And David Conrad's apparently the only guy who's heard about it. :-) When I used to go to ICANN meetings (haven't been to one in years), there were always a number of folks from the RIR community there, which at least in the ARIN region, tends to have non-trivial intersection with the NANOG community. I would be quite surprised if I was "the only guy who's heard about it". Regards, -drc ------------------------------ Message: 6 Date: Fri, 17 Jun 2011 20:33:08 -0400 (EDT) From: Jay Ashworth Subject: Re: ICANN to allow commercial gTLDs To: NANOG Message-ID: <22308707.634.1308357188484.JavaMail.root at benjamin.baylink.com> Content-Type: text/plain; charset=utf-8 ----- Original Message ----- > From: "John Levine" > I happen to agree that adding vast numbers of new TLDs is a terrible > idea more for administrative and social than technical reasons, but > this is the first you've heard about it, you really haven't been > paying attention. John, yes, I've been paying attention to the TLD space since Chris Ambler *first* put in his .web proposal -- what is that; 15 years now? 20? This is the first I've heard of *the possibility of TLD registrars being end-user internal/exclusive*. People have made jokes about company TLDs in the past, sure, but no, I never heard any specific discussion about it actually happening; I invite citations. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ------------------------------ Message: 7 Date: Fri, 17 Jun 2011 20:37:11 -0400 (EDT) From: Jay Ashworth Subject: Re: ICANN to allow commercial gTLDs To: NANOG Message-ID: <13002116.636.1308357431779.JavaMail.root at benjamin.baylink.com> Content-Type: text/plain; charset=utf-8 ----- Original Message ----- > From: "David Conrad" > "Finally, because pancakes are calling, the very complainants of > squatting and defensive registration (the 1Q million-in-revenue every > applicant for an "open", now "standard" registry places in its > bizplan), the Intellectual Property Stakeholder Group is also an > advocate for trademark TLDs, arguing that possession of $fee and a > registry platform contract (there is now a niche industry of boutique > ".brand" operators-in-waiting) and a $bond establishes an absolute > right to a label in the IANA root. > > So, rather than memorizing the digits of Pi, for some later public > recitation, one could start reciting brand names, for some later > public recitation, for as long as there is a single unified root." > > See http://mailman.nanog.org/pipermail/nanog/2011-March/034692.html > for full context. That's an *amazingly* oblique and de minimis reference to the topic on point, couched in Eric's usually opaque language, and buried in a thread I'd long since stopped paying attention to by that point; my apologies to you for not having seen it, since you seem to feel that's material. Cheers, -- jr 'I wouldn't call it a datapoint, though' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ------------------------------ Message: 8 Date: 18 Jun 2011 00:40:58 -0000 From: "John Levine" Subject: Re: ICANN to allow commercial gTLDs To: nanog at nanog.org Message-ID: <20110618004058.17116.qmail at joyce.lan> Content-Type: text/plain; charset=utf-8 >This is the first I've heard of *the possibility of TLD registrars being >end-user internal/exclusive*. People around ICANN have been arguing about the registry/registrar split for years, and whether to have special rules for TLDs where one party would own all the names. Really. If this is the first you've heard about it, you haven't been paying attention. Or, I suppose, you might be claiming that David and I are just lying. R's, John ------------------------------ Message: 9 Date: Fri, 17 Jun 2011 17:43:11 -0700 From: Joel Jaeggli Subject: Re: ICANN to allow commercial gTLDs To: Jay Ashworth Cc: NANOG Message-ID: <85838CB1-B3F9-4916-8786-19C13D835613 at bogus.com> Content-Type: text/plain; charset=us-ascii On Jun 17, 2011, at 5:33 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "John Levine" > >> I happen to agree that adding vast numbers of new TLDs is a terrible >> idea more for administrative and social than technical reasons, but >> this is the first you've heard about it, you really haven't been >> paying attention. > > John, yes, I've been paying attention to the TLD space since Chris Ambler > *first* put in his .web proposal -- what is that; 15 years now? 20? > > This is the first I've heard of *the possibility of TLD registrars being > end-user internal/exclusive*. > > People have made jokes about company TLDs in the past, sure, but no, I > never heard any specific discussion about it actually happening; I invite > citations. http://www.icann.org/en/topics/new-gtlds/consultation-outreach-en.htm > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > ------------------------------ Message: 10 Date: Fri, 17 Jun 2011 21:07:23 -0400 (EDT) From: Jay Ashworth Subject: Re: ICANN to allow commercial gTLDs To: NANOG Message-ID: <21342046.644.1308359243408.JavaMail.root at benjamin.baylink.com> Content-Type: text/plain; charset=utf-8 ----- Original Message ----- > From: "Joel Jaeggli" > >> http://www.icann.org/en/topics/new-gtlds/consultation-outreach-en.htm > > > > That page doesn't appear to discuss the specific topic I'm talking about, > > and for the 9th or 10th time, I *know* they've been talking about expanding > > the root; I approved that message back in 1997, as posted earlier. > > It does. > > The process as described in 2009 places no lower bound on the > narrowness of the community which a gtld proposes to serve. > > 1.2.2 Community-Based Designation > All applicants are required to designate whether their > application is community-based. > > 1.2.2.1 Definitions2 > > For purposes of this Applicant Guidebook, a communitybased gTLD is a > gTLD that is operated for the benefit of a > defined community consisting of a restricted population. > > An applicant designating its application as communitybased will be > asked to substantiate its status as > representative of the community it names in the > application, and additional information may be requested > in the event of a comparative evaluation (refer to Section > 4.2 of Module 4). An applicant for a community-based > gTLD is expected to: > > 1. Demonstrate an ongoing relationship with a defined > community that consists of a restricted population. > 2. Have applied for a gTLD string strongly and specifically > related to the community named in the application. > 3. Have proposed dedicated registration and use policies > for registrants in its proposed gTLD. > 4. Have its application endorsed in writing by an > established institution representing the community it > has named. > > For purposes of differentiation, an application that has not > been designated as community-based will be referred to > hereinafter in this document as an open gTLD. An open > gTLD can be used for any purpose consistent with the > requirements of the application and evaluation criteria, > and with the registry agreement. An open gTLD may or > may not have a formal relationship with an exclusive > registrant or user population. It may or may not employ > eligibility or use restrictions I will concur with your assertion that it is *possible to infer* that Apple running a .apple registry for its own internal commercial purposes would fit their definition of "community"... but the phrasing of the restrictions they place on it makes it pretty clear, at least to me, that the people who wrote it weren't thinking about that possible use case. All of their restrictions/instructions become tautologies in that limiting case, do they not? And indeed: who arbitrates trademark conflicts, in what is now *necessarily* a global collision space? Forbidding the registration of gTLDs which conflict with trademarks registered with any national authority would seem to be only minimally sane, to me... but that's orthogonal to whether the issue's come up in specific detail, of course. My apologies for not reading deeper into your citation, though I'm not sure I would have caught that section as a response to me anyway. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 41, Issue 114 ************************************** From brunner at nic-naa.net Fri Jun 17 19:51:19 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Fri, 17 Jun 2011 20:51:19 -0400 Subject: ICANN to allow commercial gTLDs Message-ID: <201106180051.p5I0pJSo033034@nic-naa.net> howdy all from a cold room 100km north of the equator. > ... > That's an *amazingly* oblique and de minimis reference to the topic on > point, couched in Eric's usually opaque language ... > ... i'm reading this from the meeting room where the generic names supporting organization council is meeting (saturday is gnso policy day), in what i've heard is disneyland with a death penalty. two things i think "of note" have occured in the past week+: 1. the deparment of commerce summarized (first round!) notice and comment period (see the apa or ask an admin practitioner near you or read fox, a worthwhile activity in its own right -- google "+fox +administrative-law") on the iana function contract, and 2. the department of justice responded to the department of commerce request for guidance on competition policy issues and the icann board resolution of november last to end structural separation in the competitive market created through the competitive registrar testbed in 2000. i read each as notice from the usg that the drift, or direction, depending on one's point of view, of a 501(c)(3) to which rule making may have been delegated, is subject to correction. so did anyone have a question or is my epistolary stylistic genius sufficient as topic of general interest? -e From jra at baylink.com Fri Jun 17 22:02:56 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 23:02:56 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <201106180051.p5I0pJSo033034@nic-naa.net> Message-ID: <26906340.664.1308366176097.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: brunner at nic-naa.net > howdy all from a cold room 100km north of the equator. > > > ... > > That's an *amazingly* oblique and de minimis reference to the topic > > on point, couched in Eric's usually opaque language ... > > ... > > i'm reading this from the meeting room where the generic names supporting > organization council is meeting (saturday is gnso policy day), in what > i've heard is disneyland with a death penalty. > > two things i think "of note" have occured in the past week+: > > 1. the deparment of commerce summarized (first round!) notice and > comment period (see the apa or ask an admin practitioner near you or read fox, > a worthwhile activity in its own right -- google "+fox > +administrative-law") on the iana function contract, and > > 2. the department of justice responded to the department of commerce > request for guidance on competition policy issues and the icann board > resolution of november last to end structural separation in the competitive > market created through the competitive registrar testbed in 2000. > > i read each as notice from the usg that the drift, or direction, > depending on one's point of view, of a 501(c)(3) to which rule making may have > been delegated, is subject to correction. > > so did anyone have a question or is my epistolary stylistic genius > sufficient as topic of general interest? ... and he talked for 45 minutes, and no one understood a word that he said. :-) I *think* you're saying that the USG may decide that it wants to piss the world off even further, by deciding that it's made a mistake delegating things to ICANN, and *taking them back*; is that roughly where you're going? Cheers, -- jr 'anyotherkindathing you got to say pertaining to and about the crime 'a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From brunner at nic-naa.net Fri Jun 17 20:08:00 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Fri, 17 Jun 2011 21:08:00 -0400 Subject: ICANN to allow commercial gTLDs Message-ID: <201106180108.p5I180um033109@nic-naa.net> >> so did anyone have a question or is my epistolary stylistic genius >> sufficient as topic of general interest? > ... and he talked for 45 minutes, and no one understood a word that he said. i'm happy to leave the reportage and issue analysis to those better informed. you look to be someone better informed. please, type away. -e From owen at delong.com Fri Jun 17 22:02:41 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Jun 2011 20:02:41 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <29272713.660.1308364822544.JavaMail.root@benjamin.baylink.com> References: <29272713.660.1308364822544.JavaMail.root@benjamin.baylink.com> Message-ID: <067C757A-61B6-4432-88B4-73DE48CAB83A@delong.com> On Jun 17, 2011, at 7:40 PM, Jay Ashworth wrote: > ---- Original Message ----- >> From: "Owen DeLong" > >> That won't stop them from building zone files that look like this: >> >> >> @ IN SOA ... >> NS ... >> ... >> A ... >> AAAA ... >> www A ... >> AAAA ... >> >> Sure, they'll advertise www.apple, but, you better believe that >> they'll take whatever lands at http://apple and you can certainly >> count on the fact that any mal-actors that get control of one of >> these TLDs (whether they paid the $185k or not) will take full >> advantage of the situation and its security risks. > > Not necessarily, Owen. Remember: Since we're *in the TLD space* now, > you can't capture the unmodified domain *without adding records to the > root*: > You can, actually... It is perfectly valid for example, in COM to have: delong.com. IN NS ns.delong.org. IN NS ns2.delong.org. and have ns/ns2 .delong.org. return the following: delong.com. IN SOA ....... IN NS ns.delong.org. ns2.delong.org. A 192.159.10.2 AAAA 2620:0:930::200:2 www IN A 192.159.10.7 AAAA 2620:0:930::400:7 Why would this not work equally well for APPLE where the root zone would have: apple. IN NS ...... IN NS ...... Where you would then have the detail (as above in the delong.com zone file) contained in the apple. zone file on the specified authoritative nameservers? > apple.com and www.apple.com are in the same zone file apple and www.apple are in the same zone file to that extent as well. apple.com is a delegation from .com just as apple is a delegation from . > apple. and www.apple. are *not* -- and the root operators may throw > their hands up in the air if anyone asks them to have anything in their > zone except glue -- rightly, I think; it's not a degree of complexity > that's compatible with the required stability of the root zone. > Sir, either you are very confused, or, I am. I am saying that TLDs behave with the same delegation rules as SLDs, which I believe to be correct. You are claiming that TLDs are in some way magical and that the ability to delegate begins at SLDs. I think the fact that there is data in the COM zone separate from the root indicates that I am correct. > Especially since the root zone actually lives in 14 different places. > But the root zone would still only contain delegation and possibly glue. Everything else would still be in the zone file, just like a subdelegation of COM for apple.com, but, this would be a subdelegation of . for apple. > No, anything that requires the root zone to be fluid[1] is going to cause even > more fundamental engineering problems than I've been positing so far tonight. > I agree, but, this doesn't require that to happen. It might cause it to happen without root zone operator intervention (which may be worse), but, it doesn't require the root zone operators to cooperate beyond delegating the TLDs which seems pretty much assured by the current announcement. Owen From owen at delong.com Fri Jun 17 21:07:26 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Jun 2011 19:07:26 -0700 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> Message-ID: On Jun 17, 2011, at 6:11 PM, Mark Andrews wrote: > > In message , Michael Dillon writes: >>> The last v6day was an isoc effort, there can be a separate nanog effort or >>> your own. >> >> It does make a lot of sense for NANOG (perhaps jointly with RIPE and >> other NOGs) to organize monthly IPv6 days with a theme or focus for >> each month. If you have a focus, then you can recruit a lot of IPv6 >> testers to try out certain things on IPv6 day and get a more thorough >> test and more feedback >> >> Skip July and August because it takes time to get this organized, and >> then start the next one on September the 8th or thereabouts. >> >> For instance, one month could focus on full IPv6 DNS support, but >> maybe not right away. A nice easy start would be to deal with IPv6 >> peering and weird paths that result from tunnels. That is the kind of >> thing that would work good with a lot of testers participating and an >> application that traces IPv4 and IPv6 paths and measures hop count, >> latency, packet loss. >> >> In conjunction with the monthly IPv6 day, NANOG should set up a blog >> page or similar to publicly collect incident reports and solutions. > > I really don't know why anyone is worried about advertising AAAA > records for authoritative nameservers. It just works. Recursive > nameservers have been dealing with authoritative nameservers having > IPv6 addresses for well over a decade now. This includes dealing > with them being unreachable. > > DNS/UDP is not like HTTP/TCP. You don't have connect timeouts to > worry about. Recursive nameservers have much shorter timeouts as > they need to deal with IPv4 nameservers not being reachable. They > also have to do all this re-trying within 3 or so seconds or else > the stub clients will have timed out. > Ah, but, with IPv6 records, you are much more likely to end up with a TRUNC result and a TCP query than with IPv4. Owen From owen at delong.com Fri Jun 17 22:06:23 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Jun 2011 20:06:23 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <21342046.644.1308359243408.JavaMail.root@benjamin.baylink.com> References: <21342046.644.1308359243408.JavaMail.root@benjamin.baylink.com> Message-ID: <559C9BE3-9EF9-455B-AB6B-AC9A76E16553@delong.com> On Jun 17, 2011, at 6:07 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Joel Jaeggli" > >>>> http://www.icann.org/en/topics/new-gtlds/consultation-outreach-en.htm >>> >>> That page doesn't appear to discuss the specific topic I'm talking about, >>> and for the 9th or 10th time, I *know* they've been talking about expanding >>> the root; I approved that message back in 1997, as posted earlier. >> >> It does. >> >> The process as described in 2009 places no lower bound on the >> narrowness of the community which a gtld proposes to serve. >> >> 1.2.2 Community-Based Designation >> All applicants are required to designate whether their >> application is community-based. >> >> 1.2.2.1 Definitions2 >> >> For purposes of this Applicant Guidebook, a communitybased gTLD is a >> gTLD that is operated for the benefit of a >> defined community consisting of a restricted population. >> >> An applicant designating its application as communitybased will be >> asked to substantiate its status as >> representative of the community it names in the >> application, and additional information may be requested >> in the event of a comparative evaluation (refer to Section >> 4.2 of Module 4). An applicant for a community-based >> gTLD is expected to: >> >> 1. Demonstrate an ongoing relationship with a defined >> community that consists of a restricted population. >> 2. Have applied for a gTLD string strongly and specifically >> related to the community named in the application. >> 3. Have proposed dedicated registration and use policies >> for registrants in its proposed gTLD. >> 4. Have its application endorsed in writing by an >> established institution representing the community it >> has named. >> >> For purposes of differentiation, an application that has not >> been designated as community-based will be referred to >> hereinafter in this document as an open gTLD. An open >> gTLD can be used for any purpose consistent with the >> requirements of the application and evaluation criteria, >> and with the registry agreement. An open gTLD may or >> may not have a formal relationship with an exclusive >> registrant or user population. It may or may not employ >> eligibility or use restrictions > > I will concur with your assertion that it is *possible to infer* that > Apple running a .apple registry for its own internal commercial purposes > would fit their definition of "community"... but the phrasing of the > restrictions they place on it makes it pretty clear, at least to me, > that the people who wrote it weren't thinking about that possible > use case. > > All of their restrictions/instructions become tautologies in that limiting > case, do they not? > > And indeed: who arbitrates trademark conflicts, in what is now *necessarily* > a global collision space? Forbidding the registration of gTLDs which > conflict with trademarks registered with any national authority would seem > to be only minimally sane, to me... but that's orthogonal to whether > the issue's come up in specific detail, of course. > Forgetting even the individual nation issues, within the US, there are so many different trademark namespaces that you can have multiple organizations with the same name. For example: MacDonald's would likely get title to .macdonalds under the new rules, right? Well... Which MacDonald's? 1. The fast food chain 2. O.C. MacDonald's Plumbing Supply 3. MacDonald and Sons Paving Systems 4. MacDonald and Madison Supply Company 5. etc. All of them have legitimate non-conflicting trademarks on the name MacDonald's (or at least could, I admit I made some of them up). I said when this mess first started that mapping trademarks to DNS would only lead to dysfunction. It did. Now the dysfunction is becoming all-encompassing. It will be interesting to watch the worlds IP lawyers (IP as in Intellectual Property, not Internet Protocol) eat their young over these issues for the next several decades. Owen From jra at baylink.com Fri Jun 17 22:36:51 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 23:36:51 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <067C757A-61B6-4432-88B4-73DE48CAB83A@delong.com> Message-ID: <23505408.666.1308368211865.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > apple.com is a delegation from .com just as apple is a delegation from > . > > > apple. and www.apple. are *not* -- and the root operators may throw > > their hands up in the air if anyone asks them to have anything in > > their > > zone except glue -- rightly, I think; it's not a degree of > > complexity > > that's compatible with the required stability of the root zone. > > Sir, either you are very confused, or, I am. I am saying that TLDs > behave with the same delegation rules as SLDs, which I believe > to be correct. You are claiming that TLDs are in some way magical > and that the ability to delegate begins at SLDs. I think the fact that > there is data in the COM zone separate from the root indicates that > I am correct. I could be wrong--Cricket Liu I am not--but the point I'm trying to make is that the record "apple." does not *live* inside the zone server for the "apple" TLD; it lives in ".". The people who operate the "apple" zone can apply an A record to "www.apple"... Oh. Wait. I'm sorry: you're right. It's been so long since I climbed that far up the tree, I'd forgotten, the TLDs don't *live* in the root servers. So people operating a cTLD like "apple." would have to run their own analog of gtld-servers.net, to which the zone would be delegated, and such fanciness could happen there. Ok; so *this* bit of opposition was a red herring. :-) Cheers, -- jr '' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Fri Jun 17 22:39:58 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 17 Jun 2011 23:39:58 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <559C9BE3-9EF9-455B-AB6B-AC9A76E16553@delong.com> Message-ID: <23532008.670.1308368398612.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > MacDonald's would likely get title to .macdonalds under the new rules, > right? > > Well... Which MacDonald's? > > 1. The fast food chain > 2. O.C. MacDonald's Plumbing Supply > 3. MacDonald and Sons Paving Systems > 4. MacDonald and Madison Supply Company > 5. etc. > > All of them have legitimate non-conflicting trademarks on the name MacDonald's > (or at least could, I admit I made some of them up). I said when this mess > first started that mapping trademarks to DNS would only lead to dysfunction. > It did. Now the dysfunction is becoming all-encompassing. It will be > interesting to watch the worlds IP lawyers (IP as in Intellectual Property, > not Internet Protocol) > eat their young over these issues for the next several decades. Indeed. It's actually "McDonalds", of course, and the US trademark law system has a provision for "famous" marks. I don't recall what the rules are, but once they've decide your mark is "famous", then it no longer competes only in its own line-of-business category; *no one* can register a new mark in any category using your word. Coca-Cola, Sony, and I think Kodak, are the canonical examples of a famous mark. http://www.quizlaw.com/trademarks/what_is_a_famous_trademark.php Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From josmon at rigozsaurus.com Fri Jun 17 22:47:38 2011 From: josmon at rigozsaurus.com (John Osmon) Date: Fri, 17 Jun 2011 21:47:38 -0600 Subject: ICANN to allow commercial gTLDs In-Reply-To: <4DFBCAA7.6000800@paulgraydon.co.uk> References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> <4DFBCAA7.6000800@paulgraydon.co.uk> Message-ID: <20110618034738.GA6680@jeeves.rigozsaurus.com> On Fri, Jun 17, 2011 at 11:44:07AM -1000, Paul Graydon wrote: > [...] I don't mind new TLDs, but company ones are crazy > and going to lead to a confusing and messy internet. Maybe we could demote the commercial ones to live under a single TLD to make things simpler/neater... :-) From gaurab at lahai.com Fri Jun 17 22:52:56 2011 From: gaurab at lahai.com (Gaurab Raj Upadhaya) Date: Sat, 18 Jun 2011 04:52:56 +0100 Subject: good geographic for servers reaching the South East Asia market In-Reply-To: <58CB1AC4-BEFE-4FBC-9069-6F7B00807EEE@deman.com> References: <58CB1AC4-BEFE-4FBC-9069-6F7B00807EEE@deman.com> Message-ID: <4DFC2118.30304@lahai.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/17/11 4:22 AM, Michael DeMan wrote: > Hi Janne, > > Any thoughts about Malaysia? The outfit I am working for on this > right now already has manufacturing facilities there and it would be > easier for them to do it in-country. > > I would guess that probably everything from Kuala Lampur area is > trunked via Singapore anyway? Far from true, Allmost all subsea cables land in both countries. there are a few that only land in one. There is overland fiber connectivity as well. Though, choice of carriers available inside carrier hotels in Singapore is much higher. Ultimately, your choices will be determined by other factors (costs, ease of deployments), then based on connectivity. - -gaurab - -- http://www.gaurab.org.np/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk38IRgACgkQSo7fU26F3X0CqQCeJT/sgstTuDuBnXk16PP5GLZV w5IAn2iaWq/YcACeweLG/Ll2xL+Zpg3+ =D4xF -----END PGP SIGNATURE----- From georgeb at gmail.com Fri Jun 17 23:04:21 2011 From: georgeb at gmail.com (George B.) Date: Fri, 17 Jun 2011 21:04:21 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, Jun 17, 2011 at 2:04 PM, Jay Ashworth wrote: > Aw, Jeezus. > > No. ?Just, no. I think I will get .payme and make sure coke.payme, pepsi.payme, comcast.payme, etc. all get registered at the low-low price of $10/year. All I would need is 100,000 registrations to provide me with a million dollar a year income stream for the rest of my life. Wonder if the people who make DirtDevil vacuums will get .sucks and I wonder how much subdomains of that TLD will bring. Hey, this is a money fountain of unlimited potential. Basically it has the potential to be large scale extortion done with lots if micropayments. Chaos! From brunner at nic-naa.net Fri Jun 17 21:04:55 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Fri, 17 Jun 2011 22:04:55 -0400 Subject: ICANN to allow commercial gTLDs Message-ID: <201106180204.p5I24t6R033328@nic-naa.net> >> [...] I don't mind new TLDs, but company ones are crazy >> and going to lead to a confusing and messy internet. are either "confusing" or "messy" the best rationals for declining either or both of corporate names or trademarks? are these (corporate naming and trademark registration as generators) bounded generators of strings? what does unbounded change mean operationally? > Maybe we could demote the commercial ones to live under a single > TLD to make things simpler/neater... :-) well, back in wipo i or wipo ii time, there was the suggestion that a trademark tld would solve a bunch of problems. however, is the problem the absence of simplicity and/or neatness, or is dilution applied to a medium in which replication is policied differently than print the problem. see any of several presentations by lessig on the subject of basic applicability of property (intellectual) to new media, and if you're somewhat romantic (i am) rfc1591, on "ownership" of text labels. -e From drc at virtualized.org Fri Jun 17 23:09:53 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Jun 2011 18:09:53 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <6065C14D-00B5-4FC4-A157-39BCAC06AEC1@delong.com> References: <13002116.636.1308357431779.JavaMail.root@benjamin.baylink.com> <23892D49-AD8A-4B16-B2A9-49D356CEC3AD@delong.com> <6065C14D-00B5-4FC4-A157-39BCAC06AEC1@delong.com> Message-ID: <519D4091-A840-482B-B65C-BCCA0E01E63A@virtualized.org> On Jun 17, 2011, at 4:25 PM, Owen DeLong wrote: > On Jun 17, 2011, at 7:13 PM, David Conrad wrote: >> Why do you think there is an ASO? > To coordinate numberspace issues between the IANA and the RIRs. I believe the original intent was that the various SOs would provide their input on how policies impacted their particular areas. Sort of like why the various IETF areas meet at the same meeting. > Oh, there is tremendous inter-relation. However, making a mess and then punting it > to the ASO is an entirely different matter. You have an odd view of what a 'liaison' does. I was suggesting ASO AC members could provide information to the NANOG community since it would seem at least some participants in NANOG were unaware of ICANN's activities and were unpleasantly surprised. > It doesn't cost anything to participate in PPML. It doesn't cost anything (well, monetarily -- expense to sanity may be high, but that is the same as with PPML in my experience) to participate in ICANN meetings. Regards, -drc From johnl at iecc.com Fri Jun 17 23:10:33 2011 From: johnl at iecc.com (John Levine) Date: 18 Jun 2011 04:10:33 -0000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <559C9BE3-9EF9-455B-AB6B-AC9A76E16553@delong.com> Message-ID: <20110618041033.24188.qmail@joyce.lan> >Well... Which MacDonald's? ICANN has a 350 page draft applicant guidebook on their web site that explains the barococo application and evaluation process here: http://www.icann.org/en/topics/new-gtld-program.htm Please do NOT download it or read it, since actual knowledge is so much less fun than uninformed wankage on nanog. R's, John From johnl at iecc.com Fri Jun 17 23:13:29 2011 From: johnl at iecc.com (John Levine) Date: 18 Jun 2011 04:13:29 -0000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <201106180051.p5I0pJSo033034@nic-naa.net> Message-ID: <20110618041329.24307.qmail@joyce.lan> >so did anyone have a question or is my epistolary stylistic genius sufficient >as topic of general interest? Hi. How does ICANN seem to be reacting to the flaming arrow that the DOC shot in front of them? Also, the DOC letter refers to a European Commission letter from Tuesday, which I can't find on ICANN's web site or anywhere else. Anyone in Singapore know about it? R's, John From drc at virtualized.org Fri Jun 17 23:26:08 2011 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Jun 2011 18:26:08 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <29272713.660.1308364822544.JavaMail.root@benjamin.baylink.com> References: <29272713.660.1308364822544.JavaMail.root@benjamin.baylink.com> Message-ID: Jay, On Jun 17, 2011, at 4:40 PM, Jay Ashworth wrote: > and the root operators may throw > their hands up in the air if anyone asks them to have anything in their > zone except glue -- rightly, I think; it's not a degree of complexity > that's compatible with the required stability of the root zone. I believe the root server operators have stated (the equivalent of) that it is not their job to make editorial decisions on what the root zone contains. They distribute what the ICANN/NTIA/Verisign gestalt publishes. > Especially since the root zone actually lives in 14 different places. It lives in _far_ more places than that. > No, anything that requires the root zone to be fluid[1] is going to cause even > more fundamental engineering problems than I've been positing so far tonight. http://www.icann.org/en/topics/new-gtlds/summary-of-impact-root-zone-scaling-06oct10-en.pdf Folks of varying levels of technical, business, and political expertise have been working on the expansion of the root zone for more than a decade. I might suggest that instead of assuming people haven't thought of the issues you are raising, you might want to take the opposite approach and ask for pointers for the analyses. > [1]requiring updates in anything smaller than days. How often does the > root zone actually change; anyone got a pointer to stats on that? The root zone is updated two times a day. Relevant folks have stated this will not be changing. Regards, -drc From jra at baylink.com Fri Jun 17 23:29:52 2011 From: jra at baylink.com (Jay R Ashworth) Date: Sat, 18 Jun 2011 00:29:52 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <29272713.660.1308364822544.JavaMail.root@benjamin.baylink.com> Message-ID: <6e00fc6d-8c32-4a69-b825-7e20bce1d907@email.android.com> David Conrad wrote: >Jay, > >On Jun 17, 2011, at 4:40 PM, Jay Ashworth wrote: >> and the root operators may throw >> their hands up in the air if anyone asks them to have anything in >their >> zone except glue -- rightly, I think; it's not a degree of complexity >> that's compatible with the required stability of the root zone. > >I believe the root server operators have stated (the equivalent of) >that it is not their job to make editorial decisions on what the root >zone contains. They distribute what the ICANN/NTIA/Verisign gestalt >publishes. > >> Especially since the root zone actually lives in 14 different places. > >It lives in _far_ more places than that. > >> No, anything that requires the root zone to be fluid[1] is going to >cause even >> more fundamental engineering problems than I've been positing so far >tonight. > >http://www.icann.org/en/topics/new-gtlds/summary-of-impact-root-zone-scaling-06oct10-en.pdf > >Folks of varying levels of technical, business, and political expertise >have been working on the expansion of the root zone for more than a >decade. I might suggest that instead of assuming people haven't >thought of the issues you are raising, you might want to take the >opposite approach and ask for pointers for the analyses. > >> [1]requiring updates in anything smaller than days. How often does >the >> root zone actually change; anyone got a pointer to stats on that? > >The root zone is updated two times a day. Relevant folks have stated >this will not be changing. > >Regards, >-drc Note my reply to Owen. --jra -- Sent from my HTC Supersonic with K-9 Mail. Please excuse my brevity. From jsw at inconcepts.biz Sat Jun 18 00:05:14 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sat, 18 Jun 2011 01:05:14 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, Jun 18, 2011 at 12:04 AM, George B. wrote: > I think I will get .payme ?and make sure coke.payme, pepsi.payme, > comcast.payme, etc. all get registered at the low-low price of > $10/year. ?All I would need is 100,000 registrations to provide me > with a million dollar a year income stream for the rest of my life. I have read this thread, but certainly not any ICANN garbage. It seems to me that a TLD for a brand, like Coca-Cola, would not be used in the same way as GTLDs. Will George actually be allowed to carve up his own TLD and sell bits of it to anyone who is willing to click a checkbox on GoDaddy.com? Obviously there is not any technical limitation in place to prevent this, but will there be legal / "layer 9" limitations? I kinda figured additional GTLDs is not very useful given that probably every domain registrar drives customers to "protect their brand," avoid phishing attacks against their customers, etc. by buying not only example.com, but also net|org|biz|etc. I imagine that registrars may be really excited about this idea, because it represents additional fees/revenue to them. I can't understand why it is good for anyone else. Does McDonald's really want to print http://mcdonalds/ or www.mcdonalds instead of www.mcdonalds.com on their soft drink cups and TV ads? Is Owen so disconnected from reality that he thinks the chain with the golden arches is spelled "MacDonald's?" I don't particularly care about the intellectual property questions (in the context of NANOG) but if you really want to bang your head against that, I suggest reading about the current trademark status of "Standard Oil." In short, it remains a legally protected mark but has several distinct owners throughout the United States -- a result of the break-up. "Waffle House" is a little complex, too. Somehow the GTLD system continues to function. I imagine the relevant authorities are capable of figuring out who should be allowed to register which brand-TLD. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From bonomi at mail.r-bonomi.com Sat Jun 18 02:18:53 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 18 Jun 2011 02:18:53 -0500 (CDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <559C9BE3-9EF9-455B-AB6B-AC9A76E16553@delong.com> Message-ID: <201106180718.p5I7IrBe020792@mail.r-bonomi.com> > Subject: Re: ICANN to allow commercial gTLDs > From: Owen DeLong > > MacDonald's would likely get title to .macdonalds under the new rules, > right? > > Well... Which MacDonald's? > > 1. The fast food chain > 2. O.C. MacDonald's Plumbing Supply > 3. MacDonald and Sons Paving Systems > 4. MacDonald and Madison Supply Company > 5. etc. Easy to resolve (excuse the pun) _that_ one. The _senior_ claimant to that domain would be Clan MacDonald, of Scotland. Who gets 'apple'? Apple (the computer company), Apple (the record company)? How about the 'fruit of the month' club? Now, if you want a _hard_ problem, who gets to register 'YellowPages' ? <*EVIL* grin> From owen at delong.com Sat Jun 18 03:24:37 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 18 Jun 2011 01:24:37 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <23532008.670.1308368398612.JavaMail.root@benjamin.baylink.com> References: <23532008.670.1308368398612.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 17, 2011, at 8:39 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> MacDonald's would likely get title to .macdonalds under the new rules, >> right? >> >> Well... Which MacDonald's? >> >> 1. The fast food chain >> 2. O.C. MacDonald's Plumbing Supply >> 3. MacDonald and Sons Paving Systems >> 4. MacDonald and Madison Supply Company >> 5. etc. >> >> All of them have legitimate non-conflicting trademarks on the name MacDonald's >> (or at least could, I admit I made some of them up). I said when this mess >> first started that mapping trademarks to DNS would only lead to dysfunction. >> It did. Now the dysfunction is becoming all-encompassing. It will be >> interesting to watch the worlds IP lawyers (IP as in Intellectual Property, >> not Internet Protocol) >> eat their young over these issues for the next several decades. > > Indeed. > > It's actually "McDonalds", of course, and the US trademark law system has > a provision for "famous" marks. I don't recall what the rules are, but > once they've decide your mark is "famous", then it no longer competes only > in its own line-of-business category; *no one* can register a new mark in > any category using your word. > While that is true, there are several McDonalds registered in various spaces that actually predate even the existance of Mr. Crok's famous burger joints. > Coca-Cola, Sony, and I think Kodak, are the canonical examples of a > famous mark. > Let us not also forget the over-extension of that situation, as applied to Jell-O where there are now very bizarre rules about who can and can't refer to just any gelatine dessert as Jell-O. Owen From owen at delong.com Sat Jun 18 03:22:27 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 18 Jun 2011 01:22:27 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <23505408.666.1308368211865.JavaMail.root@benjamin.baylink.com> References: <23505408.666.1308368211865.JavaMail.root@benjamin.baylink.com> Message-ID: <8C7F9B57-2E82-4F80-BF77-60D05535B8E4@delong.com> On Jun 17, 2011, at 8:36 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> apple.com is a delegation from .com just as apple is a delegation from >> . >> >>> apple. and www.apple. are *not* -- and the root operators may throw >>> their hands up in the air if anyone asks them to have anything in >>> their >>> zone except glue -- rightly, I think; it's not a degree of >>> complexity >>> that's compatible with the required stability of the root zone. >> >> Sir, either you are very confused, or, I am. I am saying that TLDs >> behave with the same delegation rules as SLDs, which I believe >> to be correct. You are claiming that TLDs are in some way magical >> and that the ability to delegate begins at SLDs. I think the fact that >> there is data in the COM zone separate from the root indicates that >> I am correct. > > I could be wrong--Cricket Liu I am not--but the point I'm trying to make > is that the record "apple." does not *live* inside the zone server for > the "apple" TLD; it lives in ".". > You are, indeed, wrong. In . lives a pointer to apple. consisting of one or more NS records and possibly some A/AAAA glue for those nameservers if they are within apple. In the apple. zone file lives everything else about apple. including the SOA record for apple. Just as in COM lives one or more NS records for APPLE.COM and possibly some A/AAAA glue for NS that live within APPLE.COM. Inside the APPLE.COM zone file, OTOH, lives everything else about APPLE.COM including the SOA for APPLE.COM. > The people who operate the "apple" zone can apply an A record to "www.apple"... > > Oh. Wait. > > I'm sorry: you're right. It's been so long since I climbed that far > up the tree, I'd forgotten, the TLDs don't *live* in the root servers. > EXACTLY. > So people operating a cTLD like "apple." would have to run their > own analog of gtld-servers.net, to which the zone would be delegated, > and such fanciness could happen there. > EXACTLY. > Ok; so *this* bit of opposition was a red herring. :-) > YES. Have a nice day. Owen From owen at delong.com Sat Jun 18 03:25:08 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 18 Jun 2011 01:25:08 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110618034738.GA6680@jeeves.rigozsaurus.com> References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> <4DFBCAA7.6000800@paulgraydon.co.uk> <20110618034738.GA6680@jeeves.rigozsaurus.com> Message-ID: <986E7EA1-2D62-4E08-A1FD-EEAAF98F0451@delong.com> On Jun 17, 2011, at 8:47 PM, John Osmon wrote: > On Fri, Jun 17, 2011 at 11:44:07AM -1000, Paul Graydon wrote: >> [...] I don't mind new TLDs, but company ones are crazy >> and going to lead to a confusing and messy internet. > > Maybe we could demote the commercial ones to live under a single > TLD to make things simpler/neater... :-) I have an idea... Let's call it COM. Owen From owen at delong.com Sat Jun 18 03:43:00 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 18 Jun 2011 01:43:00 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <201106180718.p5I7IrBe020792@mail.r-bonomi.com> References: <201106180718.p5I7IrBe020792@mail.r-bonomi.com> Message-ID: On Jun 18, 2011, at 12:18 AM, Robert Bonomi wrote: > >> Subject: Re: ICANN to allow commercial gTLDs >> From: Owen DeLong >> >> MacDonald's would likely get title to .macdonalds under the new rules, >> right? >> >> Well... Which MacDonald's? >> >> 1. The fast food chain >> 2. O.C. MacDonald's Plumbing Supply >> 3. MacDonald and Sons Paving Systems >> 4. MacDonald and Madison Supply Company >> 5. etc. > > Easy to resolve (excuse the pun) _that_ one. > > The _senior_ claimant to that domain would be Clan MacDonald, of Scotland. > > Who gets 'apple'? Apple (the computer company), Apple (the record company)? > How about the 'fruit of the month' club? > > Now, if you want a _hard_ problem, who gets to register 'YellowPages' ? > <*EVIL* grin> > > > That's easy... Oracle as the successor to Sun Microsystems. :p Owen From owen at delong.com Sat Jun 18 03:41:49 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 18 Jun 2011 01:41:49 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> Message-ID: <7031EDEA-0484-4332-AC42-E0D44DD8FD7E@delong.com> On Jun 17, 2011, at 10:05 PM, Jeff Wheeler wrote: > On Sat, Jun 18, 2011 at 12:04 AM, George B. wrote: >> I think I will get .payme and make sure coke.payme, pepsi.payme, >> comcast.payme, etc. all get registered at the low-low price of >> $10/year. All I would need is 100,000 registrations to provide me >> with a million dollar a year income stream for the rest of my life. > > I have read this thread, but certainly not any ICANN garbage. It > seems to me that a TLD for a brand, like Coca-Cola, would not be used > in the same way as GTLDs. Will George actually be allowed to carve up > his own TLD and sell bits of it to anyone who is willing to click a > checkbox on GoDaddy.com? Obviously there is not any technical > limitation in place to prevent this, but will there be legal / "layer > 9" limitations? > Um, that'll be just GoDaddy. soon enough. > I kinda figured additional GTLDs is not very useful given that > probably every domain registrar drives customers to "protect their > brand," avoid phishing attacks against their customers, etc. by buying > not only example.com, but also net|org|biz|etc. I imagine that > registrars may be really excited about this idea, because it > represents additional fees/revenue to them. I can't understand why it > is good for anyone else. Does McDonald's really want to print > http://mcdonalds/ or www.mcdonalds instead of www.mcdonalds.com on > their soft drink cups and TV ads? > Ah, but at $185k/year/TLD to ICANN, Mr. Beckstrom has to be loving it. > Is Owen so disconnected from reality that he thinks the chain with the > golden arches is spelled "MacDonald's?" > No, just didn't want to get caught infringing. ;-) I did say that I made several of the examples up. > I don't particularly care about the intellectual property questions > (in the context of NANOG) but if you really want to bang your head > against that, I suggest reading about the current trademark status of > "Standard Oil." In short, it remains a legally protected mark but has > several distinct owners throughout the United States -- a result of > the break-up. "Waffle House" is a little complex, too. Somehow the > GTLD system continues to function. I imagine the relevant authorities > are capable of figuring out who should be allowed to register which > brand-TLD. > I find your faith most disturbing. Owen From marka at isc.org Sat Jun 18 03:47:25 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 18 Jun 2011 18:47:25 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sat, 18 Jun 2011 02:18:53 EST." <201106180718.p5I7IrBe020792@mail.r-bonomi.com> References: <201106180718.p5I7IrBe020792@mail.r-bonomi.com> Message-ID: <20110618084725.3E8F510E5622@drugs.dv.isc.org> In message <201106180718.p5I7IrBe020792 at mail.r-bonomi.com>, Robert Bonomi write s: > > > Subject: Re: ICANN to allow commercial gTLDs > > From: Owen DeLong > > > > MacDonald's would likely get title to .macdonalds under the new rules, > > right? > > > > Well... Which MacDonald's? > > > > 1. The fast food chain > > 2. O.C. MacDonald's Plumbing Supply > > 3. MacDonald and Sons Paving Systems > > 4. MacDonald and Madison Supply Company > > 5. etc. > > Easy to resolve (excuse the pun) _that_ one. > > The _senior_ claimant to that domain would be Clan MacDonald, of Scotland. > > Who gets 'apple'? Apple (the computer company), Apple (the record company)? > How about the 'fruit of the month' club? > > Now, if you want a _hard_ problem, who gets to register 'YellowPages' ? > <*EVIL* grin> YellowPages would work. It's used under licence. au.YellowPages uk.YellowPages As for single label hostnames, RFC 897 got rid of single label hostnames and they should not come back. They are a security issue, see RFC 1535. This has been pointed out in the past. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sat Jun 18 04:31:44 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 18 Jun 2011 19:31:44 +1000 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: Your message of "Fri, 17 Jun 2011 19:07:26 MST." References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> Message-ID: <20110618093144.46A6E10E6179@drugs.dv.isc.org> In message , Owen DeLong write s: > > On Jun 17, 2011, at 6:11 PM, Mark Andrews wrote: > > >=20 > > In message , = > Michael Dillon writes: > >>> The last v6day was an isoc effort, there can be a separate nanog = > effort or > >>> your own. > >>=20 > >> It does make a lot of sense for NANOG (perhaps jointly with RIPE and > >> other NOGs) to organize monthly IPv6 days with a theme or focus for > >> each month. If you have a focus, then you can recruit a lot of IPv6 > >> testers to try out certain things on IPv6 day and get a more thorough > >> test and more feedback > >>=20 > >> Skip July and August because it takes time to get this organized, and > >> then start the next one on September the 8th or thereabouts. > >>=20 > >> For instance, one month could focus on full IPv6 DNS support, but > >> maybe not right away. A nice easy start would be to deal with IPv6 > >> peering and weird paths that result from tunnels. That is the kind of > >> thing that would work good with a lot of testers participating and an > >> application that traces IPv4 and IPv6 paths and measures hop count, > >> latency, packet loss. > >>=20 > >> In conjunction with the monthly IPv6 day, NANOG should set up a blog > >> page or similar to publicly collect incident reports and solutions. > >=20 > > I really don't know why anyone is worried about advertising AAAA > > records for authoritative nameservers. It just works. Recursive > > nameservers have been dealing with authoritative nameservers having > > IPv6 addresses for well over a decade now. This includes dealing > > with them being unreachable. > >=20 > > DNS/UDP is not like HTTP/TCP. You don't have connect timeouts to > > worry about. Recursive nameservers have much shorter timeouts as > > they need to deal with IPv4 nameservers not being reachable. They > > also have to do all this re-trying within 3 or so seconds or else > > the stub clients will have timed out. > >=20 > Ah, but, with IPv6 records, you are much more likely to end up with > a TRUNC result and a TCP query than with IPv4. Not really. A AAAA record adds 28 octets (a A record takes 16). Unless you have a lot of name servers most referrals still fall within 512 octets additionally most answers also still fall withing 512 octets. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Sat Jun 18 04:30:22 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 18 Jun 2011 02:30:22 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110618084725.3E8F510E5622@drugs.dv.isc.org> References: <201106180718.p5I7IrBe020792@mail.r-bonomi.com> <20110618084725.3E8F510E5622@drugs.dv.isc.org> Message-ID: <163AC651-F1C2-4614-BCFA-40A991700E69@delong.com> On Jun 18, 2011, at 1:47 AM, Mark Andrews wrote: > > In message <201106180718.p5I7IrBe020792 at mail.r-bonomi.com>, Robert Bonomi write > s: >> >>> Subject: Re: ICANN to allow commercial gTLDs >>> From: Owen DeLong >>> >>> MacDonald's would likely get title to .macdonalds under the new rules, >>> right? >>> >>> Well... Which MacDonald's? >>> >>> 1. The fast food chain >>> 2. O.C. MacDonald's Plumbing Supply >>> 3. MacDonald and Sons Paving Systems >>> 4. MacDonald and Madison Supply Company >>> 5. etc. >> >> Easy to resolve (excuse the pun) _that_ one. >> >> The _senior_ claimant to that domain would be Clan MacDonald, of Scotland. >> >> Who gets 'apple'? Apple (the computer company), Apple (the record company)? >> How about the 'fruit of the month' club? >> >> Now, if you want a _hard_ problem, who gets to register 'YellowPages' ? >> <*EVIL* grin> > > YellowPages would work. It's used under licence. > > au.YellowPages > uk.YellowPages > > As for single label hostnames, RFC 897 got rid of single label > hostnames and they should not come back. They are a security issue, > see RFC 1535. > > This has been pointed out in the past. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org All true. However, since TLDs will now be run by anyone with $185k/year to get what they want... Owen From adrian.minta at gmail.com Sat Jun 18 04:54:51 2011 From: adrian.minta at gmail.com (Adrian Minta) Date: Sat, 18 Jun 2011 12:54:51 +0300 Subject: Business Ethernet Services In-Reply-To: References: Message-ID: <4DFC75EB.7050807@gmail.com> On 06/17/11 21:55, Elliot Finley wrote: > Anyone using a CPE that is reliable and costs<= $300 ? > > features needed: > > SFP for uplink, QnQ, basic layer 2 functionality. > > If you're using something with the above parameters and you like it, > please share. :) > > Thanks, > Elliot > Something like Zyxel MES-2110 ? From bonomi at mail.r-bonomi.com Sat Jun 18 07:15:45 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 18 Jun 2011 07:15:45 -0500 (CDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <201106181215.p5ICFjUI023541@mail.r-bonomi.com> > Subject: Re: ICANN to allow commercial gTLDs > From: Owen DeLong > Date: Sat, 18 Jun 2011 01:24:37 -0700 > [[.. sneck ..]] > > While that is true, there are several McDonalds registered in various > spaces that actually predate even the existance of Mr. Crok's famous > burger joints. Just for the recorcd, that's a crock. The man who made the burger chain a household word is Mr Ray _Kroc_. "Spelling counts." From eugen at imacandi.net Sat Jun 18 08:28:42 2011 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sat, 18 Jun 2011 16:28:42 +0300 Subject: Yup; the Internet is screwed up. In-Reply-To: <20110612194800.GB8003@hiwaay.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <4DF3E933.4080809@mompl.net> <20110612194800.GB8003@hiwaay.net> Message-ID: On Sun, Jun 12, 2011 at 22:48, Chris Adams wrote: > Once upon a time, Eugeniu Patrascu said: >> I need 100Mbs at home because I want to see a streamed movie NOW, not >> in a month because someone considers broadband a luxury :) >> Pretty simple usage scenario I might say. > > The top profile for Blu-Ray is 36 megabits per second, and that is > not used on most titles. ?Over-the-air HDTV is 19 megabits or less. > Cable HD channels are often only 12-15 megabits per second. ?OTA and > cable HD is typically MPEG2, and MPEG4 can reach similar quality in half > the bandwidth, which means TV quality HD can be 6-10 megabits per > second. Even though, my point stands. I don't want to wait forever for stuff to load just because a dialup should be enough for browsing :) From randy at psg.com Sat Jun 18 08:45:57 2011 From: randy at psg.com (Randy Bush) Date: Sat, 18 Jun 2011 06:45:57 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <27100748-F707-4B16-95C8-2895485FB6D1@virtualized.org> References: <22653040.608.1308347687356.JavaMail.root@benjamin.baylink.com> <27100748-F707-4B16-95C8-2895485FB6D1@virtualized.org> Message-ID: i am not learning anything here. well, except maybe that someone who normally has his head up his butt also had it in the sand. what's new? how about the operational technical effects, like data from modeling various resolvers' responses to a large root zone? randy From johnl at iecc.com Sat Jun 18 09:55:56 2011 From: johnl at iecc.com (John Levine) Date: 18 Jun 2011 14:55:56 -0000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <20110618145556.46650.qmail@joyce.lan> >I believe the root server operators have stated (the equivalent of) >that it is not their job to make editorial decisions on what the root >zone contains. They distribute what the ICANN/NTIA/Verisign gestalt >publishes. That has always been the case in the past. Given the level of public unhappiness that the US Dep't of Commerce has with ICANN's plan to add zillions of new TLDs, and noting that several of the root servers are run by agencies of the US government, who knows what will happen in the future. R's, John From mysidia at gmail.com Sat Jun 18 10:00:46 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 18 Jun 2011 10:00:46 -0500 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <20110618093144.46A6E10E6179@drugs.dv.isc.org> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> <20110618093144.46A6E10E6179@drugs.dv.isc.org> Message-ID: On Sat, Jun 18, 2011 at 4:31 AM, Mark Andrews wrote: > Not really. ?A AAAA record adds 28 octets (a A record takes 16). ?Unless > you have a lot of name servers most referrals still fall within 512 octets > additionally most answers also still fall withing 512 octets. I agree.. not that it should be assumed there is no v6 DNS issue. With IPv6, the main issue may be 'firewalls' and 'boxes in the middle' silently munging, eating, or destroying AAAA responses. DNSSEC and not AAAA is really the reason to have need for EDNS0 or TRUNC on validating resolvers. AAAA records should be fine for sane domains. consider a referral for example.com -> subdomain.example.com with 8 nameservers. mydomainname.example.com; and assume you get both AAAA and A additional responses. Total = 402 octets -- still safe; your domain name could be ~100 characters longer and it would still be fine. Header < 2 (id) + 2 (qr,opcode,aa,tc,rd,ra,z,rcode,qdcount) + 2 (ancount) + 2 (nscount) + 2 (arcount) = 10 octets Authority Section ns1.subdomain.example.com. IN NS ns1.subdomain.example.com. < 26name + 2 + 2 + 4 + 2 + 2(pointer) = 36 octets ns2.subdomain.example.com. IN NS ns2.subdomain.example.com. < 4 name + 2(pointer) + 2 + 2 + 4 + 2 +2(pointer) = 18 octets ns3.subdomain.example.com. IN NS ns3.subdomain.example.com. < 4 name + 2 + 2 + 2 + 4 + 2 + 2 = 18 octets ns4.subdomain.example.com. IN NS ns4.subdomain.example.com. < 18 octets ns5.subdomain.example.com. IN NS ns5.subdomain.example.com. < 18 octets ns6.subdomain.example.com. IN NS ns6.subdomain.example.com. < 18 octets ns7.subdomain.example.com. IN NS ns7.subdomain.example.com. < 18 octets ns8.subdomain.example.com. IN NS ns8.subdomain.example.com. < 18 octets Additional Section ns1.subdomain.example.com. IN AAAA 2001:DB8::0 < 2(pointer) +4TTL+2RDLENGTH+16RDATA = 24 octets ns2.subdomain.example.com. IN AAAA 2001:DB8::1 < 24 octets ns3.subdomain.example.com. IN AAAA 2001:DB8::2 < 24 octets ns4.subdomain.example.com. IN AAAA 2001:DB8::3 < 24 octets ns5.subdomain.example.com. IN AAAA 2001:DB8::4 < 24 octets ns6.subdomain.example.com. IN AAAA 2001:DB8::5 < 24 octets ns7.subdomain.example.com. IN AAAA 2001:DB8::6 < 24 octets ns8.subdomain.example.com. IN AAAA 2001:DB8::7 < 24 octets ns1.subdomain.example.com. IN A 192.0.0.0.1 < 2(pointer) +4TTL+2RDLENGTH+4RDATA = 12 octets ns2.subdomain.example.com. IN A 192.0.0.0.1 < 12 octets ns3subdomain.example.com. IN A 192.0.0.0.1 < 12 octets ns4.subdomain.example.com. IN A 192.0.0.0.1 < 12 octets Total = 402 octets -- still safe; your domain name could be ~100 characters longer and it would still be fine. -- -JH From mysidia at gmail.com Sat Jun 18 11:41:44 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 18 Jun 2011 11:41:44 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110618145556.46650.qmail@joyce.lan> References: <20110618145556.46650.qmail@joyce.lan> Message-ID: On Sat, Jun 18, 2011 at 9:55 AM, John Levine wrote: > That has always been the case in the past. ?Given the level of public > unhappiness that the US Dep't of Commerce has with ICANN's plan to add > zillions of new TLDs, and noting that several of the root servers are Speaking of some public unhappiness with new TLD plan... if you hadn't noticed, the DoC published a notice of inquiry regarding renewal of the ICANN contract expiring in September for the IANA functions.... http://www.ntia.doc.gov/frnotices/2011/FR_IANA_FurtherNOI_06102011.pdf If not pleased with ICANN's performance it might be worth reading the published DRAFT SOW for the renewal from the federal register and Investigate if the proposed terms seem to provide sufficient accountability/constraint. If not, it would be prudent to submit comments answering the questions listed in the inquiry :) Specifically, regarding "C.2.2.1.3.2 Responsibility and Respect for Stakeholders .... .... For delegation requests for new generic TLDS (gTLDs), the Contractor shall include documentation to demonstrate how the proposed string has received consensus support from relevant stakeholders and is supported by the global public interest.". > run by agencies of the US government, who knows what will happen in > the future. I'm not so sure volunteer root operators are in a position to editorialize and for that to have a positive effect. ICANN could go down the path of stating that this causes internet stability (due to operators publishing a partial root). That would then be sufficient justification to remove root server operators from the root zone, and use the proceeds of gTLD sales and gTLD renewal fees to hire (non-volunteer) operators, under contract requiring hired root operators to publish exactly an ICANN sanctified root. > R's, > John -- -JH From aftab.siddiqui at gmail.com Sat Jun 18 12:48:34 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Sat, 18 Jun 2011 22:48:34 +0500 Subject: Business Ethernet Services In-Reply-To: <4DFC75EB.7050807@gmail.com> References: <4DFC75EB.7050807@gmail.com> Message-ID: Try Maipu S3400 series, Chinese boxes and it is working really good for us fr couple of years. It would suits ur need n price range. On Saturday, June 18, 2011, Adrian Minta wrote: > On 06/17/11 21:55, Elliot Finley wrote: > > Anyone using a CPE that is reliable and costs<= $300 ? > > features needed: > > SFP for uplink, QnQ, basic layer 2 functionality. > > If you're using something with the above parameters and you like it, > please share. :) > > Thanks, > Elliot > > > > Something like Zyxel MES-2110 ? > > > > > -- Regards, Aftab A. Siddiqui From owen at delong.com Sat Jun 18 13:19:41 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 18 Jun 2011 11:19:41 -0700 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <20110618093144.46A6E10E6179@drugs.dv.isc.org> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> <20110618093144.46A6E10E6179@drugs.dv.isc.org> Message-ID: <4932DF54-FDD5-4903-BE45-281F7F346CCD@delong.com> >> > > Not really. A AAAA record adds 28 octets (a A record takes 16). Unless > you have a lot of name servers most referrals still fall within 512 octets > additionally most answers also still fall withing 512 octets. > 1. Most != All even in IPv4 (ran into this in a few hotels with some prominent MMORPG login sites) 2. 512/16 = 32, 512 / 28 = 18 (the 19th record will TRUNC). So, you get just over half the number of records to fit within the same space. I would say that my statement that you are much more likely to encounter TRUNC results and need a TCP query with IPv6 stands. It also matches my experience. Owen From owen at delong.com Sat Jun 18 13:35:57 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 18 Jun 2011 11:35:57 -0700 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> <20110618093144.46A6E10E6179@drugs.dv.isc.org> Message-ID: <43B2CE52-B07E-48E8-9BBE-772B979F4316@delong.com> On Jun 18, 2011, at 8:00 AM, Jimmy Hess wrote: > On Sat, Jun 18, 2011 at 4:31 AM, Mark Andrews wrote: >> Not really. A AAAA record adds 28 octets (a A record takes 16). Unless >> you have a lot of name servers most referrals still fall within 512 octets >> additionally most answers also still fall withing 512 octets. > > I agree.. not that it should be assumed there is no v6 DNS issue. > With IPv6, the main issue may > be 'firewalls' and 'boxes in the middle' silently munging, eating, > or destroying AAAA responses. > > DNSSEC and not AAAA is really the reason to have need for EDNS0 or TRUNC > on validating resolvers. AAAA records should be fine for sane domains. > > consider a referral for example.com -> subdomain.example.com with > 8 nameservers. > mydomainname.example.com; and assume you get both AAAA and A > additional responses. > > Total = 402 octets -- still safe; your domain name could be ~100 > characters longer and it would still be fine. > > Header < 2 (id) + 2 (qr,opcode,aa,tc,rd,ra,z,rcode,qdcount) + 2 > (ancount) + 2 (nscount) + 2 (arcount) > = 10 octets > Authority Section > ns1.subdomain.example.com. IN NS ns1.subdomain.example.com. < > 26name + 2 + 2 + 4 + 2 + 2(pointer) = 36 octets > ns2.subdomain.example.com. IN NS ns2.subdomain.example.com. < 4 > name + 2(pointer) + 2 + 2 + 4 + 2 +2(pointer) = 18 octets > ns3.subdomain.example.com. IN NS ns3.subdomain.example.com. < 4 > name + 2 + 2 + 2 + 4 + 2 + 2 = 18 octets > ns4.subdomain.example.com. IN NS ns4.subdomain.example.com. < 18 octets > ns5.subdomain.example.com. IN NS ns5.subdomain.example.com. < 18 octets > ns6.subdomain.example.com. IN NS ns6.subdomain.example.com. < 18 octets > ns7.subdomain.example.com. IN NS ns7.subdomain.example.com. < 18 octets > ns8.subdomain.example.com. IN NS ns8.subdomain.example.com. < 18 octets > > Additional Section > ns1.subdomain.example.com. IN AAAA 2001:DB8::0 < 2(pointer) > +4TTL+2RDLENGTH+16RDATA = 24 octets > ns2.subdomain.example.com. IN AAAA 2001:DB8::1 < 24 octets > ns3.subdomain.example.com. IN AAAA 2001:DB8::2 < 24 octets > ns4.subdomain.example.com. IN AAAA 2001:DB8::3 < 24 octets > ns5.subdomain.example.com. IN AAAA 2001:DB8::4 < 24 octets > ns6.subdomain.example.com. IN AAAA 2001:DB8::5 < 24 octets > ns7.subdomain.example.com. IN AAAA 2001:DB8::6 < 24 octets > ns8.subdomain.example.com. IN AAAA 2001:DB8::7 < 24 octets > ns1.subdomain.example.com. IN A 192.0.0.0.1 < 2(pointer) > +4TTL+2RDLENGTH+4RDATA = 12 octets > ns2.subdomain.example.com. IN A 192.0.0.0.1 < 12 octets > ns3subdomain.example.com. IN A 192.0.0.0.1 < 12 octets > ns4.subdomain.example.com. IN A 192.0.0.0.1 < 12 octets > > > Total = 402 octets -- still safe; your domain name could be ~100 > characters longer and it would still be fine. > This ignores the extra baggage that tends to come along in a DNS payload. Just the root: ; <<>> DiG 9.6.0-APPLE-P2 <<>> +trace -t any www.delong.com ;; global options: +cmd . 379756 IN NS e.root-servers.net. . 379756 IN NS i.root-servers.net. . 379756 IN NS l.root-servers.net. . 379756 IN NS f.root-servers.net. . 379756 IN NS k.root-servers.net. . 379756 IN NS b.root-servers.net. . 379756 IN NS j.root-servers.net. . 379756 IN NS d.root-servers.net. . 379756 IN NS c.root-servers.net. . 379756 IN NS g.root-servers.net. . 379756 IN NS m.root-servers.net. . 379756 IN NS h.root-servers.net. . 379756 IN NS a.root-servers.net. ;; Received 512 bytes from 192.159.10.2#53(192.159.10.2) in 7 ms Or the GTLD servers list: com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. ;; Received 495 bytes from 2001:500:3::42#53(l.root-servers.net) in 37 ms (not quite 512, but, close) Note, none of these came with glue. They ONLY included the name data. Had they come with glue, we would easily have been over 512 in both cases just for IPv4, let alone a v4/v6 combination. I know of at least one prominent MMORPG that has enough A records for their login servers that they triggered TRUNC DNS results which I discovered when they broke at some hotels I have stayed at. I've also encountered other sites. Owen From johnl at iecc.com Sat Jun 18 15:14:32 2011 From: johnl at iecc.com (John R. Levine) Date: 18 Jun 2011 16:14:32 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <20110618145556.46650.qmail@joyce.lan> Message-ID: >> run by agencies of the US government, who knows what will happen in >> the future. > > I'm not so sure volunteer root operators are in a position to editorialize > and for that to have a positive effect. ICANN could go down the > path of stating that this causes internet stability (due to operators > publishing a partial root). It is not my impression that the volunteer root operators have any great love for ICANN. They have carefully avoided making any agreements with ICANN that oblige them to do anything other than notify ICANN if they think something interesting is going on. If the USG operators said "sorry, the DOJ anti-trust rules don't allow us to serve a zone with .HONDA and .BACARDI", why would the the pressure be on them rather than on ICANN? Nobody outside the ICANN bubble cares about more TLDs. > That would then be sufficient justification to remove root server > operators from the root zone How do you propose to do that? The addresses of the roots are hard wired into the config of a million DNS caches around the world. If it came to a fight between ICANN and the root operators, it is hard to see how ICANN could win. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From nick at foobar.org Sat Jun 18 19:26:55 2011 From: nick at foobar.org (Nick Hilliard) Date: Sun, 19 Jun 2011 01:26:55 +0100 Subject: Cogent depeers ESnet Message-ID: <4DFD424F.6080300@foobar.org> Slightly old news, but it looks like Cogent depeered ESnet last week: > http://www.es.net/news-and-publications/esnet-news/2011/important-status-announcement-regarding-cogent-connectivity/ Current traceroutes indicate that ESnet is reaching Cogent via 6939_1299. In other news, automatically dropping interconnects at around the time of your HQ's close of business while your peering co-ordinator is on vacation seems to be the new gold standard. Nick From georgeb at gmail.com Sun Jun 19 01:44:28 2011 From: georgeb at gmail.com (George B.) Date: Sat, 18 Jun 2011 23:44:28 -0700 Subject: Cogent depeers ESnet In-Reply-To: <4DFD424F.6080300@foobar.org> References: <4DFD424F.6080300@foobar.org> Message-ID: On Sat, Jun 18, 2011 at 5:26 PM, Nick Hilliard wrote: > Slightly old news, but it looks like Cogent depeered ESnet last week: > >> >> http://www.es.net/news-and-publications/esnet-news/2011/important-status-announcement-regarding-cogent-connectivity/ > > Current traceroutes indicate that ESnet is reaching Cogent via 6939_1299. > > In other news, automatically dropping interconnects at around the time of > your HQ's close of business while your peering co-ordinator is on vacation > seems to be the new gold standard. > > Nick I suppose the moral of the story is: "never single-home to Cogent" From bonomi at mail.r-bonomi.com Sun Jun 19 03:15:09 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 19 Jun 2011 03:15:09 -0500 (CDT) Subject: Cogent depeers ESnet In-Reply-To: Message-ID: <201106190815.p5J8F9bN030469@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sun Jun 19 01:46:06 2011 > Date: Sat, 18 Jun 2011 23:44:28 -0700 > Subject: Re: Cogent depeers ESnet > From: "George B." > To: Nick Hilliard > Cc: "nanog at nanog.org" > > On Sat, Jun 18, 2011 at 5:26 PM, Nick Hilliard wrote: > > Slightly old news, but it looks like Cogent depeered ESnet last week: > > > >> > >> http://www.es.net/news-and-publications/esnet-news/2011/important-statu > >> s-announcement-regarding-cogent-connectivity/ > > > > Current traceroutes indicate that ESnet is reaching Cogent via > > 6939_1299. > > > > In other news, automatically dropping interconnects at around the time > > of your HQ's close of business while your peering co-ordinator is on > > vacation seems to be the new gold standard. > > > > Nick > > I suppose the moral of the story is: "never single-home to Cogent" Anybody got draft language for a SLA clause that requires routing 'at least one hop _past_ the provider's network edge' for every AS visible at major public peering points and/or LookingGlass sites? <*EVIL* grin> From vixie at isc.org Sun Jun 19 11:39:46 2011 From: vixie at isc.org (Paul Vixie) Date: Sun, 19 Jun 2011 16:39:46 +0000 Subject: ICANN to allow commercial gTLDs Message-ID: <93902.1308501586@nsa.vix.com> David Conrad writes: > I believe the root server operators have stated (the equivalent of) that > it is not their job to make editorial decisions on what the root zone > contains. They distribute what the ICANN/NTIA/Verisign gestalt > publishes. yes. for one example, see: http://www.icann.org/en/announcements/announcement-04jan08.htm other rootops who have spoken about this have said similar/compatible things. -- Paul Vixie KI6YSY From jra at baylink.com Sun Jun 19 11:51:50 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 19 Jun 2011 12:51:50 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <93902.1308501586@nsa.vix.com> Message-ID: <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Paul Vixie" > David Conrad writes: > > I believe the root server operators have stated (the equivalent of) that > > it is not their job to make editorial decisions on what the root zone > > contains. They distribute what the ICANN/NTIA/Verisign gestalt > > publishes. > > yes. for one example, see: > > http://www.icann.org/en/announcements/announcement-04jan08.htm > > other rootops who have spoken about this have said similar/compatible > things. Just to clarify, since I'm responsible for that particular red herring, I had at the time forgotten that the TLD zone don't actually *live* in the root -- I know; silly me, right? -- and that the root wouldn't be affected by the sort of things that previously-2LD now TLD operators might want to do with their monocomponent names... which as someone pointed out, a 3-digit RFC forbids for security reasons anyway. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From cjp at 0x1.net Sun Jun 19 12:52:16 2011 From: cjp at 0x1.net (Christopher Pilkington) Date: Sun, 19 Jun 2011 13:52:16 -0400 Subject: Cogent depeers ESnet In-Reply-To: <201106190815.p5J8F9bN030469@mail.r-bonomi.com> References: <201106190815.p5J8F9bN030469@mail.r-bonomi.com> Message-ID: <576539292915578717@unknownmsgid> On Jun 19, 2011, at 4:16 AM, Robert Bonomi wrote: > >> > Anybody got draft language for a SLA clause that requires routing 'at least > one hop _past_ the provider's network edge' for every AS visible at major > public peering points and/or LookingGlass sites? This is relevant to my interests. I'd love to sneak this into an RFP. -cjp From ikiris at gmail.com Sun Jun 19 13:05:25 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Sun, 19 Jun 2011 13:05:25 -0500 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> Message-ID: Now I'm tempted to be the guy that gets .mail On Fri, Jun 17, 2011 at 20:47, Jay Ashworth wrote: > ----- Original Message ----- > > From: "John Levine" > > > >The notion of a single-component FQDN would be quite a breakage for > > >the basic concept of using both FQDNs and Unqualified names. > > > > Well, you know, there's a guy whose email address has been n at ai for > > many years. People have varying amounts of success sending him mail. > > My Zimbra UI says it "might be invalid"; the default postfix config inside > it tries to send it to n at ai.baylink.com, and complains because the domain > won't resolve. > > If I'm reading 3.2.4 of 2822 properly (that notation is one I'm not > entirely familiar with, and should be), that really is a valid 2822 > address, as odd as it sounds. > > Clearly, it's semantics are unexpected, though. I guess I should go hang > a bug on it. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 > 1274 > > From randy at psg.com Sun Jun 19 13:16:32 2011 From: randy at psg.com (Randy Bush) Date: Sun, 19 Jun 2011 11:16:32 -0700 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> Message-ID: > Now I'm tempted to be the guy that gets .mail express that temptation in dollars, and well into two commas. randy From mysidia at gmail.com Sun Jun 19 13:43:24 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 19 Jun 2011 13:43:24 -0500 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <43B2CE52-B07E-48E8-9BBE-772B979F4316@delong.com> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> <20110618093144.46A6E10E6179@drugs.dv.isc.org> <43B2CE52-B07E-48E8-9BBE-772B979F4316@delong.com> Message-ID: On Sat, Jun 18, 2011 at 1:35 PM, Owen DeLong wrote: > This ignores the extra baggage that tends to come along in a DNS payload. > Just the root: ..... > Note, none of these came with glue. They ONLY included the name data. > Had they come with glue, we would easily have been over 512 in both > cases just for IPv4, let alone a v4/v6 combination. None of those come with glue, ....really? For the root zone, I currently see a fully populated NS response with a fair bit of glue that is 512 bytes total, and a majority of that 512 bytes response is the additional section. That is, with no glue, you would be looking at approximately 200 octets. In addition when I dig against 2001:dc3::35, the root server responds to my query IN with glue for all A through L .root-servers, and two pieces of AAAA glue without exceeding 492 message size. However, the root zone and gTLD zones are quite special, and a very significant exception to the norm for number of NS entries authoritative for a zone. Few domains have more than 3 NS. ;; MSG SIZE rcvd: 512 # dig +norecurse -t NS . @198.41.0.4 ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> +norecurse -t NS . @198.41.0.4 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46162 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS b.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS l.root-servers.net. ;; ADDITIONAL SECTION: b.root-servers.net. 3600000 IN A 192.228.79.201 e.root-servers.net. 3600000 IN A 192.203.230.10 k.root-servers.net. 3600000 IN A 193.0.14.129 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 m.root-servers.net. 3600000 IN A 202.12.27.33 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 f.root-servers.net. 3600000 IN A 192.5.5.241 f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f c.root-servers.net. 3600000 IN A 192.33.4.12 g.root-servers.net. 3600000 IN A 192.112.36.4 j.root-servers.net. 3600000 IN A 192.58.128.30 j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 h.root-servers.net. 3600000 IN A 128.63.2.53 h.root-servers.net. 3600000 IN AAAA 2001:500:1::803f:235 ;; Query time: 203 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Sun Jun 19 13:17:31 2011 ;; MSG SIZE rcvd: 512 # dig +norecurse -t NS . @2001:dc3::35 ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> +norecurse -t NS . @m.root-servers.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1931 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS c.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS a.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net. 3600000 IN A 198.41.0.4 b.root-servers.net. 3600000 IN A 192.228.79.201 c.root-servers.net. 3600000 IN A 192.33.4.12 d.root-servers.net. 3600000 IN A 128.8.10.90 e.root-servers.net. 3600000 IN A 192.203.230.10 f.root-servers.net. 3600000 IN A 192.5.5.241 g.root-servers.net. 3600000 IN A 192.112.36.4 h.root-servers.net. 3600000 IN A 128.63.2.53 i.root-servers.net. 3600000 IN A 192.36.148.17 j.root-servers.net. 3600000 IN A 192.58.128.30 k.root-servers.net. 3600000 IN A 193.0.14.129 l.root-servers.net. 3600000 IN A 199.7.83.42 m.root-servers.net. 3600000 IN A 202.12.27.33 a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30 d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d ;; Query time: 88 msec ;; SERVER: 2001:dc3::35#53(2001:dc3::35) ;; WHEN: Sun Jun 19 13:35:41 2011 ;; MSG SIZE rcvd: 492 -- -JH From cmadams at hiwaay.net Sun Jun 19 13:49:54 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 19 Jun 2011 13:49:54 -0500 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> Message-ID: <20110619184954.GA29788@hiwaay.net> Once upon a time, Randy Bush said: > > Now I'm tempted to be the guy that gets .mail > > express that temptation in dollars, and well into two commas. Imagine the "typo-squating" someone could do with .con. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From drc at virtualized.org Sun Jun 19 13:59:13 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 19 Jun 2011 08:59:13 -1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110619184954.GA29788@hiwaay.net> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <20110619184954.GA29788@hiwaay.net> Message-ID: On Jun 19, 2011, at 8:49 AM, Chris Adams wrote: > Once upon a time, Randy Bush said: >>> Now I'm tempted to be the guy that gets .mail >> express that temptation in dollars, and well into two commas. > Imagine the "typo-squating" someone could do with .con. See section 2.2.1.1 (and section 2.1.2) of http://www.icann.org/en/topics/new-gtlds/rfp-clean-30may11-en.pdf Regards, -drc From ghira at mistral.co.uk Sun Jun 19 14:03:15 2011 From: ghira at mistral.co.uk (Adam Atkinson) Date: Sun, 19 Jun 2011 20:03:15 +0100 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> Message-ID: <4DFE47F3.2040900@mistral.co.uk> It was a very long time ago, but I seem to recall being shown http://dk, the home page of Denmark, some time in the mid 90s. Must I be recalling incorrectly? From richard.barnes at gmail.com Sun Jun 19 14:27:18 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Sun, 19 Jun 2011 15:27:18 -0400 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110619184954.GA29788@hiwaay.net> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <20110619184954.GA29788@hiwaay.net> Message-ID: The same type that Colombia/NeuStar is doing with .co? On Sun, Jun 19, 2011 at 2:49 PM, Chris Adams wrote: > Once upon a time, Randy Bush said: >> > Now I'm tempted to be the guy that gets .mail >> >> express that temptation in dollars, and well into two commas. > > Imagine the "typo-squating" someone could do with .con. > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From Valdis.Kletnieks at vt.edu Sun Jun 19 16:47:10 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 19 Jun 2011 17:47:10 -0400 Subject: Cogent depeers ESnet In-Reply-To: Your message of "Sun, 19 Jun 2011 03:15:09 CDT." <201106190815.p5J8F9bN030469@mail.r-bonomi.com> References: <201106190815.p5J8F9bN030469@mail.r-bonomi.com> Message-ID: <114351.1308520030@turing-police.cc.vt.edu> On Sun, 19 Jun 2011 03:15:09 CDT, Robert Bonomi said: > Anybody got draft language for a SLA clause that requires routing 'at least > one hop _past_ the provider's network edge' for every AS visible at major > public peering points and/or LookingGlass sites? *every* ASN? Oh my. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joly at punkcast.com Sun Jun 19 17:08:39 2011 From: joly at punkcast.com (Joly MacFie) Date: Sun, 19 Jun 2011 18:08:39 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> Message-ID: The NTIA issued a new notice to ICANN on Tuesday emphasizing it's desire for "functional separation" of IANA http://www.ntia.doc.gov/frnotices/2011/FR_IANA_ FurtherNOI_06102011.pdf Larry Strickling spoke about it at the INET New York the same day http://bit.ly/inetnyarchive He also mentioned an extra hurdle- "in the global public interest" - for new gTLDs, surely inspired by .xxx j On Sun, Jun 19, 2011 at 12:51 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Paul Vixie" > > > David Conrad writes: > > > I believe the root server operators have stated (the equivalent of) > that > > > it is not their job to make editorial decisions on what the root zone > > > contains. They distribute what the ICANN/NTIA/Verisign gestalt > > > publishes. > > > > yes. for one example, see: > > > > http://www.icann.org/en/announcements/announcement-04jan08.htm > > > > other rootops who have spoken about this have said similar/compatible > > things. > > Just to clarify, since I'm responsible for that particular red herring, > I had at the time forgotten that the TLD zone don't actually *live* in > the root -- I know; silly me, right? -- and that the root wouldn't be > affected by the sort of things that previously-2LD now TLD operators > might want to do with their monocomponent names... > > which as someone pointed out, a 3-digit RFC forbids for security reasons > anyway. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 > 1274 > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From georgeb at gmail.com Sun Jun 19 17:48:32 2011 From: georgeb at gmail.com (George B.) Date: Sun, 19 Jun 2011 15:48:32 -0700 Subject: Cogent depeers ESnet In-Reply-To: <114351.1308520030@turing-police.cc.vt.edu> References: <201106190815.p5J8F9bN030469@mail.r-bonomi.com> <114351.1308520030@turing-police.cc.vt.edu> Message-ID: On Sun, Jun 19, 2011 at 2:47 PM, wrote: > On Sun, 19 Jun 2011 03:15:09 CDT, Robert Bonomi said: > >> Anybody got draft language for a SLA clause that requires routing 'at least >> one hop _past_ the provider's network edge' for every AS visible at major >> public peering points and/or LookingGlass sites? > > *every* ASN? Oh my. ;) > I would qualify that a bit to say "every ASN available at every peering point at which the provider appears". So if the provider appears at an Equinix peering point, there is no excuse for not providing connectivity to every other ASN also at that same peering point by some means. Cogent seems to want to play a game where they not only don't want to peer directly with a number of networks, they also don't want to use any transit to reach those with which it doesn't peer, forcing the other side to use transit to reach them. Interesting gamble but probably not providing the intended result. It just ends up selling transit to the competition as people multi-home instead of being single-homed to Cogent. Cogent probably is the single largest seller of competitors' services. From patrick at ianai.net Sun Jun 19 17:50:50 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 19 Jun 2011 18:50:50 -0400 Subject: SLA covering 3rd party assets, financial incentives In-Reply-To: <114351.1308520030@turing-police.cc.vt.edu> References: <201106190815.p5J8F9bN030469@mail.r-bonomi.com> <114351.1308520030@turing-police.cc.vt.edu> Message-ID: On Jun 19, 2011, at 5:47 PM, Valdis.Kletnieks at vt.edu wrote: > On Sun, 19 Jun 2011 03:15:09 CDT, Robert Bonomi said: > >> Anybody got draft language for a SLA clause that requires routing 'at least >> one hop _past_ the provider's network edge' for every AS visible at major >> public peering points and/or LookingGlass sites? > > *every* ASN? Oh my. ;) Many people are interested in things like end-to-end performance, or global connectivity. However, one must be careful how such an SLA is written. No network wants to guarantee performance or even simple connectivity to gear they do not own / control. (Well, almost no one. I know at least one company that does, but they don't sell "transit" per-se.) Put another way, how do you write this such that my competitor cannot cause me to go bankrupt with SLA credits? Some simple things spring to mind, such as: "Do substantially all prefixes appear in the table handed to BGP customers?" (Lawyers can fight over "substantially all". :) But is that really enough? Having a prefix in the table means nothing, if the path is over a cable modem in Sri Lanka. And the reverse, my prefixes appearing in other networks' tables, is under the control of my competitors. I'm not saying it is impossible. I'm saying be careful. Likely economic pressure is more productive, i.e. vote with your wallet. Unfortunately, on the Internet, we have a history of doing the opposite. When Sprint literally disconnected from some parts of the 'Net with ACL 112, people intentionally bought from Sprint to ensure they could reach the entire Internet. When InternetMCI couldn't connect to an exchange without packet loss to save its life, people intentionally bought from InternetMCI to avoid the congestion. Etc., etc. What did we think these networks would do when we literally paid them for their faults? Worse, if there is a network who will not peer, and a network who will, most people buy from the non-peering network. The result of this is more networks want to close down peering, fewer want to open it up. Seems counter-productive to me, and trivially easy to fix. For instance, make peering a requirement of transit purchases. Of course, there would be other requirements (still need to run a good network, 24/7 NOC, fair pricing, yadda, yadda), but it uses financial incentives to promote the activities we want, not the opposite. Perhaps it is time we stopped enabling - rewarding! - the very networks & behaviors most of want to change? -- TTFN, patrick From vixie at isc.org Sun Jun 19 18:36:28 2011 From: vixie at isc.org (Paul Vixie) Date: Sun, 19 Jun 2011 23:36:28 +0000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <4DFE47F3.2040900@mistral.co.uk> (Adam Atkinson's message of "Sun, 19 Jun 2011 20:03:15 +0100") References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> Message-ID: Adam Atkinson writes: > It was a very long time ago, but I seem to recall being shown http://dk, > the home page of Denmark, some time in the mid 90s. > > Must I be recalling incorrectly? no you need not must be. it would work as long as no dk.this or dk.that would be found first in a search list containing 'this' and 'that', where the default search list is normally the parent domain name of your own hostname (so for me on six.vix.com the search list would be vix.com and so as long as dk.vix.com did not exist then http://dk/ would reach "dk.") -- Paul Vixie KI6YSY From vixie at isc.org Sun Jun 19 18:44:59 2011 From: vixie at isc.org (Paul Vixie) Date: Sun, 19 Jun 2011 23:44:59 +0000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> (Jay Ashworth's message of "Sun, 19 Jun 2011 12:51:50 -0400 (EDT)") References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> Message-ID: <21633.1308527099@nsa.vix.com> Jay Ashworth writes: > ... and that the root wouldn't be affected by the sort of things that > previously-2LD now TLD operators might want to do with their > monocomponent names... someone asked me privately a related question which is, if there's a .SONY and someone's web browser looks up http://sony/ and a root name server gets a query for SONY./IN/AAAA then what will happen? the answer is happily that the result will be a delegation (no AAAA RR in the answer section even if the root name server knows one for some reason). the answer section will be empty, the authority section will have a SONY/IN/NS RRset in it, and the additional section will have the nec'y IN/AAAA and IN/A RRsets for those NSs. this is sometimes called "the BIND9 behaviour" in contrast to BIND8/BIND4 which would have answered the question if they knew the answer, even if they also knew that the qname had been delegated. BIND9 changed this, and NSD does it the same way. RFC 1034/1035 is pretty clear about this, so to be this should not be called "the BIND9 behaviour" but rather simply "correct". > which as someone pointed out, a 3-digit RFC forbids for security reasons > anyway. three digit? i was thinking of which was written as air cover for me when i added the "ndots:NNN" behaviour to BIND4's stub resolver. and, looking at firefox on my workstation just now: [58] 2011-06-19 23:27:49.906040 [#4 em1 0] \ [24.104.150.12].24003 [24.104.150.2].53 \ dns QUERY,NOERROR,57397,rd \ 1 sony.vix.com,IN,A 0 0 0 [58] 2011-06-19 23:27:49.909895 [#5 em1 0] \ [24.104.150.12].26356 [24.104.150.2].53 \ dns QUERY,NOERROR,57398,rd \ 1 sony.vix.com,IN,AAAA 0 0 0 [50] 2011-06-19 23:27:49.910489 [#6 em1 0] \ [24.104.150.12].23228 [24.104.150.2].53 \ dns QUERY,NOERROR,57399,rd \ 1 sony,IN,A 0 0 0 [50] 2011-06-19 23:27:49.930022 [#7 em1 0] \ [24.104.150.12].37238 [24.104.150.2].53 \ dns QUERY,NOERROR,57400,rd \ 1 sony,IN,AAAA 0 0 0 [58] 2011-06-19 23:27:49.931059 [#8 em1 0] \ [24.104.150.12].17401 [24.104.150.2].53 \ dns QUERY,NOERROR,33742,rd \ 1 www.sony.com,IN,A 0 0 0 [124] 2011-06-19 23:27:50.112451 [#9 em1 0] \ [24.104.150.2].53 [24.104.150.12].17401 \ dns QUERY,NOERROR,33742,qr|rd|ra \ 1 www.sony.com,IN,A \ 1 www.sony.com,IN,A,600,72.52.6.10 \ 2 sony.com,IN,NS,172800,pdns1.cscdns.net \ sony.com,IN,NS,172800,pdns2.cscdns.net 0 ...i see that the browser's stub is indeed looking at the search list first when there are no dots in the name. that's correct behaviour by the RFC and also anecdotally since if i had an internal web server here called sony.vix.com i would want my web browser to assume that that was the one i wanted when i typed "http://sony/". having it go outside my network and hit a TLD first would be a dangerous information leak. (this also shows DNS's lack of a formal presentation layer as clearly as anything ever could.) inevitably there will be folks who register .FOOBAR and advertise it as "http://foobar/" on a billboard and then get burned by all of the local "foobar.this.tld" and "foobar.that.tld" names that will get reached instead of their TLD. i say inevitable; i don't know a way to avoid it since there will be a lot of money and a lot of people involved. -- Paul Vixie KI6YSY From owen at delong.com Sun Jun 19 18:49:28 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 19 Jun 2011 16:49:28 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> References: <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> Message-ID: <8D5B1E35-2C26-4A0A-A530-DF721B1E39B2@delong.com> On Jun 19, 2011, at 9:51 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Paul Vixie" > >> David Conrad writes: >>> I believe the root server operators have stated (the equivalent of) that >>> it is not their job to make editorial decisions on what the root zone >>> contains. They distribute what the ICANN/NTIA/Verisign gestalt >>> publishes. >> >> yes. for one example, see: >> >> http://www.icann.org/en/announcements/announcement-04jan08.htm >> >> other rootops who have spoken about this have said similar/compatible >> things. > > Just to clarify, since I'm responsible for that particular red herring, > I had at the time forgotten that the TLD zone don't actually *live* in > the root -- I know; silly me, right? -- and that the root wouldn't be > affected by the sort of things that previously-2LD now TLD operators > might want to do with their monocomponent names... > > which as someone pointed out, a 3-digit RFC forbids for security reasons > anyway. > My point is that there is a relatively small group of root operators and I consider them generally clueful and likely to comply with RFCs other than through accidental violation. OTOH, I can easily see $COMPANY deciding that $RFC is not in their best interests and find the http://microsoft construct not at all unlikely. I realize that no responsible software vendor would ever deliberately do something insecure or contrary to a security-oriented RFC, but, history has shown that not all software vendors are responsible. Now imagine the number of corporate IT departments that can't even spell RFC, but, they run web servers and DNS servers... Yeah, under the coming circumstances, the expectation that said 3-digit RFC will remain anything more than a novel collection of bits on an FTP server somewhere is, well, optimistic at best. Owen From owen at delong.com Sun Jun 19 19:02:57 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 19 Jun 2011 17:02:57 -0700 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <20110619184954.GA29788@hiwaay.net> Message-ID: On Jun 19, 2011, at 11:59 AM, David Conrad wrote: > On Jun 19, 2011, at 8:49 AM, Chris Adams wrote: >> Once upon a time, Randy Bush said: >>>> Now I'm tempted to be the guy that gets .mail >>> express that temptation in dollars, and well into two commas. >> Imagine the "typo-squating" someone could do with .con. > > See section 2.2.1.1 (and section 2.1.2) of http://www.icann.org/en/topics/new-gtlds/rfp-clean-30may11-en.pdf > > Regards, > -drc > To save others some eye strain (apologies for the format when pasted from PDF): 2.1.2 History of cybersquatting ICANN will screen applicants against UDRP cases and legal databases as financially feasible for data that may indicate a pattern of cybersquatting behavior pursuant to the criteria listed in section 1.2.1. The applicant is required to make specific declarations regarding these activities in the application. Results returned during the screening process will be matched with the disclosures provided by the applicant and those instances will be followed up to resolve issues of discrepancies or potential false positives. If no hits are returned, the application will generally pass this portion of the background screening. and 2.2.1.1 String Similarity Review This review involves a preliminary comparison of each applied-for gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings. Note: In this Applicant Guidebook, ?similar? means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone. The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity. This similarity review will be conducted by an independent String Similarity Panel. 2.2.1.1.1 Reviews Performed The String Similarity Panel?s task is to identify visual string similarities that would create a probability of user confusion. The panel performs this task of assessing similarities that would lead to user confusion in four sets of circumstances, when comparing: ? Applied-for gTLD strings against existing TLDs and reserved names; ? Applied-for gTLD strings against other applied-for gTLD strings; ? Applied-for gTLD strings against strings requested as IDN ccTLDs; and ? Applied-for 2-character IDN gTLD strings against: o Every other single character. o Any other 2-character ASCII string (to protect possible future ccTLD delegations). Module 2 Evaluation ProceduresApplicant Guidebook (30 May 2011) 2-5 Module 2 Evaluation Procedures Similarity to Existing TLDs or Reserved Names ? This review involves cross-checking between each applied-for string and the lists of existing TLD strings and Reserved Names to determine whether two strings are so similar to one another that they create a probability of user confusion. In the simple case in which an applied-for gTLD string is identical to an existing TLD or reserved name, the online application system will not allow the application to be submitted. Testing for identical strings also takes into consideration the code point variants listed in any relevant IDN table. For example, protocols treat equivalent labels as alternative forms of the same label, just as ?foo? and ?Foo? are treated as alternative forms of the same label (RFC 3490). All TLDs currently in the root zone can be found at http://iana.org/domains/root/db/. IDN tables that have been submitted to ICANN are available at http://www.iana.org/domains/idn-tables/. Similarity to Other Applied-for gTLD Strings (String Contention Sets) ? All applied-for gTLD strings will be reviewed against one another to identify any similar strings. In performing this review, the String Similarity Panel will create contention sets that may be used in later stages of evaluation. A contention set contains at least two applied-for strings identical or similar to one another. Refer to Module 4, String Contention Procedures, for more information on contention sets and contention resolution. ICANN will notify applicants who are part of a contention set as soon as the String Similarity review is completed. (This provides a longer period for contending applicants to reach their own resolution before reaching the contention resolution stage.) These contention sets will also be published on ICANN?s website. Similarity to TLD strings requested as IDN ccTLDs -- Applied- for gTLD strings will also be reviewed for similarity to TLD strings requested in the IDN ccTLD Fast Track process (see http://www.icann.org/en/topics/idn/fast-track/). Should a conflict with a prospective fast-track IDN ccTLD be identified, ICANN will take the following approach to resolving the conflict. Applicant Guidebook (30 May 2011) 2-6 Module 2 Evaluation Procedures If one of the applications has completed its respective process before the other is lodged, that TLD will be delegated. A gTLD application that has successfully completed all relevant evaluation stages, including dispute resolution and string contention, if applicable, and is eligible for entry into a registry agreement will be considered complete, and therefore would not be disqualified by a newly-filed IDN ccTLD request. Similarly, an IDN ccTLD request that has completed evaluation (i.e., is validated) will be considered complete and therefore would not be disqualified by a newly-filed gTLD application. In the case where neither application has completed its respective process, where the gTLD application does not have the required approval from the relevant government or public authority, a validated request for an IDN ccTLD will prevail and the gTLD application will not be approved. The term ?validated? is defined in the IDN ccTLD Fast Track Process Implementation, which can be found at http://www.icann.org/en/topics/idn. In the case where a gTLD applicant has obtained the support or non-objection of the relevant government or public authority, but is eliminated due to contention with a string requested in the IDN ccTLD Fast Track process, a full refund of the evaluation fee is available to the applicant if the gTLD application was submitted prior to the publication of the ccTLD request. Review of 2-character IDN strings ? In addition to the above reviews, an applied-for gTLD string that is a 2- character IDN string is reviewed by the String Similarity Panel for visual similarity to: a) Any one-character label (in any script), and b) Any possible two-character ASCII combination. An applied-for gTLD string that is found to be too similar to a) or b) above will not pass this review. 2.2.1.1.2 Review Methodology The String Similarity Panel is informed in part by an algorithmic score for the visual similarity between each applied-for string and each of other existing and applied- for TLDs and reserved names. The score will provide one objective measure for consideration by the panel, as part of the process of identifying strings likely to result in user confusion. In general, applicants should expect that a higher visual similarity score suggests a higher probability Module 2 Evaluation Procedures that the application will not pass the String Similarity review. However, it should be noted that the score is only indicative and that the final determination of similarity is entirely up to the Panel?s judgment. The algorithm, user guidelines, and additional background information are available to applicants for testing and informational purposes.2 Applicants will have the ability to test their strings and obtain algorithmic results through the application system prior to submission of an application. The algorithm supports the common characters in Arabic, Chinese, Cyrillic, Devanagari, Greek, Japanese, Korean, and Latin scripts. It can also compare strings in different scripts to each other. The panel will also take into account variant characters, as defined in any relevant language table, in its determinations. For example, strings that are not visually similar but are determined to be variant TLD strings based on an IDN table would be placed in a contention set. Variant TLD strings that are listed as part of the application will also be subject to the string similarity analysis.3 The panel will examine all the algorithm data and perform its own review of similarities between strings and whether they rise to the level of string confusion. In cases of strings in scripts not yet supported by the algorithm, the panel?s assessment process is entirely manual. The panel will use a common standard to test for whether string confusion exists, as follows: Standard for String Confusion ? String confusion exists where a string so nearly resembles another visually that it is likely to deceive or cause confusion. For the likelihood of confusion to exist, it must be probable, not merely possible that confusion will arise in the mind of the average, reasonable Internet user. Mere association, in the sense that the string brings another string to mind, is insufficient to find a likelihood of confusion. 2.2.1.1.3 Outcomes of the String Similarity Review An application that fails the String Similarity review due to similarity to an existing TLD will not pass the Initial Evaluation, 2 See http://icann.sword-group.com/algorithm/ 3 In the case where an applicant has listed Declared Variants in its application (see subsection 1.3.3), the panel will perform an analysis of the listed strings to confirm that the strings are variants according to the applicant?s IDN table. This analysis may include comparison of applicant IDN tables with other existing tables for the same language or script, and forwarding any questions to the applicant. Applicant Guidebook (30 May 2011) 2-7 Module 2 Evaluation Procedures and no further reviews will be available. Where an application does not pass the String Similarity review, the applicant will be notified as soon as the review is completed. An application for a string that is found too similar to another applied-for gTLD string will be placed in a contention set. An application that passes the String Similarity review is still subject to objection by an existing TLD operator or by another gTLD applicant in the current application round. That process requires that a string confusion objection be filed by an objector having the standing to make such an objection. Such category of objection is not limited to visual similarity. Rather, confusion based on any type of similarity (including visual, aural, or similarity of meaning) may be claimed by an objector. Refer to Module 3, Dispute Resolution Procedures, for more information about the objection process. An applicant may file a formal objection against another gTLD application on string confusion grounds. Such an objection may, if successful, change the configuration of the preliminary contention sets in that the two applied-for gTLD strings will be considered in direct contention with one another (see Module 4, String Contention Procedures). The objection process will not result in removal of an application from a contention set. From marka at isc.org Sun Jun 19 19:08:45 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 10:08:45 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 23:36:28 GMT." References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> Message-ID: <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> In message , Paul Vixie writes: > Adam Atkinson writes: > > > It was a very long time ago, but I seem to recall being shown http://dk, > > the home page of Denmark, some time in the mid 90s. > > > > Must I be recalling incorrectly? > > no you need not must be. it would work as long as no dk.this or dk.that > would be found first in a search list containing 'this' and 'that', where > the default search list is normally the parent domain name of your own > hostname (so for me on six.vix.com the search list would be vix.com and > so as long as dk.vix.com did not exist then http://dk/ would reach "dk.") > -- > Paul Vixie > KI6YSY DK should NOT be doing this. DK is *not* a hierarchical host name and the address record should not exist, RFC 897. The Internet stopped using simple host names in the early '80s. In addition to that it is a security issue similar to that described in RFC 1535. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Sun Jun 19 19:06:17 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 19 Jun 2011 17:06:17 -0700 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <4DFE47F3.2040900@mistral.co.uk> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> Message-ID: Appears to now get you a redirect to https://www.dk-hostmaster.dk/ For those arguing that 512+ octet replies don't occur: baikal:owen (14) ~ % dig @a.nic.dk -t any dk. 2011/06/19 17:03:56 ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.6.0-APPLE-P2 <<>> @a.nic.dk -t any dk. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8417 ;; flags: qr aa rd; QUERY: 1, ANSWER: 19, AUTHORITY: 0, ADDITIONAL: 7 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;dk. IN ANY ;; ANSWER SECTION: dk. 86400 IN SOA b.nic.dk. tech.dk-hostmaster.dk. 1308524460 600 300 3024000 3600 dk. 86400 IN A 193.163.102.24 dk. 86400 IN RRSIG A 8 1 86400 20110623053818 20110616000559 42220 dk. vWYPal2lEoKjPUsBLjUibPISlij+zHcqJY7k0WP5C86SgHMERArxLD2r VqJwWlXlhDAmSRitX3aTyyZyI+lL1qSh4u1eNns0/9I/ysV+Hn7NbRgC A0Kwkspgc47MbPPPZOvlL37ZmbEN2jwCLckyESzaPpThF/sI5ZwGKr6N +mI= dk. 86400 IN RRSIG NS 8 1 86400 20110627054850 20110619180550 42220 dk. ckianMaLf8ajkiwk+jaPJyG98Ojv4ScDLB6HORiVXSesJEjLV/W2EF0Q CcOy3KeIws8xPCqKiovIESpwMJlP4Rwk+u9vO546/XdKekU5FdoeWhuw ebLoB29ahKcUvXo9s+uzHmUhbb8jEKDEgxyQIfjSLP+E6Op6+LAwKvOp dYw= dk. 86400 IN RRSIG SOA 8 1 86400 20110626220327 20110619220601 42220 dk. AQFNW7TNXsI4ZOAMzNYYYcDeMBO2mbmdmJt5fzKGrttoZDZmVopN9z7D cA9TIGiLERDxfk/lsuUO+QQAK6V4Gi9fawP/rThqTRv/HbI9+eTBDoTa 3RXEmHmnO+c769Hol7fy7ADkpOtFhb9xl4KLVV8sUDU/rL6wIM73kkl/ sGg= dk. 86400 IN RRSIG TXT 8 1 86400 20110626123535 20110619220601 42220 dk. tmrYWviDeeZmd5Jx1cd79IIjTYQL7do3TOomwqVEkCxwkfSR1H1H5r/x ZigoqqY9DApq3Lyyye95bSDRIaiOjKZksbgpj7Fd4AgxrD5SR1GUZTaz uVP+MAW3x6y0Z02YJmCAt6I0OcdaCAHInQHjnGJCiBSkNickbB1+aRu8 cYM= dk. 86400 IN RRSIG DNSKEY 8 1 86400 20110626014930 20110618154633 26887 dk. G67qd6YFu4ezyVYR5R2Jk7+Rb60bFt7siEaKKs2zZllCx5PFWLZtwrxR 4Rpp+FXtJk759XmaXQf0h33mG1nmJ2ReQNflVDnPddpl5YjbiLt2EHbc OuW3630mbNPVWN7G2HucxNZVzKqpApvfjYfo6cyv2DOk4uXNZCuQlPgM CsCizGgq8qtliY80zYFSsL9UEXlzRgQR7e57v7pOhsaZll0FfdUes2dB nfJtG97cFgOpfdct2YmcRFiowWTu4DMPCPZ5MZEGoqx1pwB0hTJ8KcJX gBhgm0n6riIYxZbbPe449tB+IprAQ+H9pdjOYPOZ74lznZjrcRW0IpnI Kb5DBQ== dk. 3600 IN RRSIG NSEC3PARAM 8 1 3600 20110624180533 20110618010606 42220 dk. bgMTmGKNs9M0VVoFIAiOpaAKvkzdV6PWSoCAf+VgFdOC7nJ3SgZG5nkz dubwoebOada+Si1f6kv/sWRUM9WTTY3gnfNFMdv51KLNOq9km2TLPjqG HKmTPTr5nVFSKLj53S5fmI8zfm9nye8fh7GN2WoxW0pdlrZUItCGjCw9 S8E= dk. 86400 IN NS a.nic.dk. dk. 86400 IN NS b.nic.dk. dk. 86400 IN NS c.nic.dk. dk. 86400 IN NS l.nic.dk. dk. 86400 IN NS p.nic.dk. dk. 86400 IN NS s.nic.dk. dk. 86400 IN TXT "DK zone update" "Epoch 1308524460" "localtime Mon Jun 20 01:01:00 2011" "gmtime Sun Jun 19 23:01:00 2011" dk. 86400 IN DNSKEY 256 3 8 AwEAAcRBGC1Fr12DjYvQQPNnOAzq/oDOibyuF61UzTRnmakZ7rV2xsDb WDl1Jp+Yt/BCqKxZ9M1TkrUFMDWynN7vzqJOKg8WLwIZmB6VvyEQvqv0 qu4B2Ss/ADeoYInVflc/iD6bINriRtWzvefOqrhbctCmQIKqT+BBRu0Q Y4y2twTn dk. 86400 IN DNSKEY 256 3 8 AwEAAd2Ny7OFu4XZ9M3NQQDMxdZwIq8WGfz5n0uAbAw8npuPsmHPtp0N xYpwIg1dUJSnf19RhlWUeu1M32w65oRW0pRxRvk8zdihEewW3wywEjRA 9Zp0eDT0X+xUPL3+xE4wWNl3qBZm1JW0hSqS9TAR05XbO5aQ9/W9o4h+ NJ4Q6Rsf dk. 86400 IN DNSKEY 257 3 8 AwEAAcX56/UAMzmxalCMl5KWD5ViYJIRhWI8upQy/KI7HL8rCkltQOY+ MGkdNIndl1m0IrqJ58pbFn3X6CSfXsbas0G0Pg5NyApomTtalw3E4CQH LeXc6aZF97PcE4w1tjucZAtgGmvPEJLPnkQJOrUoqklAUaKUyT4HXyr8 zPwsuT+S0sSJmpTrtQVbZwY0TXr7CrYRtpg/aFjNzRRSQC8RljQjRZi2 KammIx7PocVx8VXy6pzKEWDP4yOCmcJkh0oa3fP0QCIpSlrlPArKbLsA UN62ARflz04TrA0zskvRo4ah+C9Di9Il6KgkdAcUgdNX1FAvoo80GTqb 6rpZFsx7tn0= dk. 3600 IN NSEC3PARAM 1 0 17 96AB3C09C88F066B ;; ADDITIONAL SECTION: b.nic.dk. 86400 IN A 193.163.102.222 c.nic.dk. 86400 IN A 208.76.168.244 l.nic.dk. 86400 IN A 192.38.7.242 p.nic.dk. 86400 IN A 204.61.216.36 s.nic.dk. 86400 IN A 77.72.229.252 b.nic.dk. 86400 IN AAAA 2a01:630:0:80::53 s.nic.dk. 86400 IN AAAA 2a01:3f0:0:303::53 ;; Query time: 554 msec ;; SERVER: 212.88.78.122#53(212.88.78.122) ;; WHEN: Sun Jun 19 17:04:20 2011 ;; MSG SIZE rcvd: 2137 So... dk. does have an A record (in violation of said 3-digit RFC) and it points to 193.163.102.24... And that host responds with a redirect: baikal:owen (15) ~ % telnet 193.163.102.24 80 2011/06/19 17:04:20 Trying 193.163.102.24... Connected to www2.dk-hostmaster.dk. Escape character is '^]'. GET / HTTP/1.0 Host: dk HTTP/1.1 301 Moved Permanently Date: Mon, 20 Jun 2011 00:05:38 GMT Server: Apache Location: https://www.dk-hostmaster.dk/ Vary: Accept-Encoding Content-Length: 237 Connection: close Content-Type: text/html; charset=iso-8859-1 301 Moved Permanently

Moved Permanently

The document has moved here.

Connection closed by foreign host. On Jun 19, 2011, at 12:03 PM, Adam Atkinson wrote: > It was a very long time ago, but I seem to recall being shown http://dk, the home page of Denmark, some time in the mid 90s. > > Must I be recalling incorrectly? > From jra at baylink.com Sun Jun 19 19:18:04 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 19 Jun 2011 20:18:04 -0400 (EDT) Subject: The Internet Is An Engineering Construct (was: Re: ICANN to allow commercial gTLDs) In-Reply-To: <8D5B1E35-2C26-4A0A-A530-DF721B1E39B2@delong.com> Message-ID: <6149295.764.1308529084571.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Owen DeLong" > OTOH, I can easily see $COMPANY deciding that $RFC is not in their > best interests and find the http://microsoft construct not at all > unlikely. > > I realize that no responsible software vendor would ever deliberately > do something insecure or contrary to a security-oriented RFC, but, > history has shown that not all software vendors are responsible. > > Now imagine the number of corporate IT departments that can't > even spell RFC, but, they run web servers and DNS servers... > > Yeah, under the coming circumstances, the expectation that said 3-digit > RFC will remain anything more than a novel collection of bits on an > FTP server somewhere is, well, optimistic at best. And here is where it all comes off the rails. Done anyone here know *why* Interstate-grade highways are designed to the standards they are? Those standards have evolved markedly over the last 50 years or so, to the point were at today. And those things cost a megabuck a mile, or more. Why? Let's not always see the same hands. Of course: it's because if those engineers get things wrong: people die. Well, guess what, folks? That's true for us, now, too. I don't think it's even melodramatic to say that we have a pretty good handle on exactly what things are bad to do when furthering the design of the Internet at large, and that if we *do those things*... Really Bad Things will happen. I have said for nearly 30 years now that The Internet Is An Engineering Construct, and that should and must restrain us from doing stupid things to and with it, regardless of how much money they'll make someone. When you combine that with someone's famous observation that the Internet is man's only technological achievement where a single character typographical error in a server on the other side of the world that you don't even know exists can take your entire network down (which, these days, may mean "put your company out of business"), well, then... we would seem to be hooved not merely to roll our eyes and say "well, the suits will play, and they write the checks". That doesn't happen in the paved road business because (are you ready for this?) *the Government sets the standards*. I don't think I'm the first person to say -- even on NANOG -- that we'd better get our shit together before they start doing it for us... but we'd better get our shit together, before they start doing it for us. We now return you to Silly Sunday. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Sun Jun 19 19:19:52 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 19 Jun 2011 20:19:52 -0400 (EDT) Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <22497445.766.1308529192244.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Paul Vixie" > Adam Atkinson writes: > > It was a very long time ago, but I seem to recall being shown > > http://dk, the home page of Denmark, some time in the mid 90s. > > > > Must I be recalling incorrectly? > > no you need not must be. it would work as long as no dk.this or dk.that > would be found first in a search list containing 'this' and 'that', where > the default search list is normally the parent domain name of your own > hostname (so for me on six.vix.com the search list would be vix.com and > so as long as dk.vix.com did not exist then http://dk/ would reach "dk.") And in fact, it works right now; I clicked through to it from your email, and it's a redirect to their NIC. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From marka at isc.org Sun Jun 19 19:21:24 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 10:21:24 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 23:44:59 GMT." <21633.1308527099@nsa.vix.com> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> Message-ID: <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> In message <21633.1308527099 at nsa.vix.com>, Paul Vixie writes: > Jay Ashworth writes: > > > ... and that the root wouldn't be affected by the sort of things that > > previously-2LD now TLD operators might want to do with their > > monocomponent names... > > someone asked me privately a related question which is, if there's a .SONY > and someone's web browser looks up http://sony/ and a root name server gets > a query for SONY./IN/AAAA then what will happen? the answer is happily that > the result will be a delegation (no AAAA RR in the answer section even if > the root name server knows one for some reason). the answer section will be > empty, the authority section will have a SONY/IN/NS RRset in it, and the > additional section will have the nec'y IN/AAAA and IN/A RRsets for those NSs. > > this is sometimes called "the BIND9 behaviour" in contrast to BIND8/BIND4 > which would have answered the question if they knew the answer, even if they > also knew that the qname had been delegated. BIND9 changed this, and NSD > does it the same way. RFC 1034/1035 is pretty clear about this, so to be > this should not be called "the BIND9 behaviour" but rather simply "correct". > > > which as someone pointed out, a 3-digit RFC forbids for security reasons > > anyway. > > three digit? i was thinking of which > was written as air cover for me when i added the "ndots:NNN" behaviour to > BIND4's stub resolver. and, looking at firefox on my workstation just now: > > [58] 2011-06-19 23:27:49.906040 [#4 em1 0] \ > [24.104.150.12].24003 [24.104.150.2].53 \ > dns QUERY,NOERROR,57397,rd \ > 1 sony.vix.com,IN,A 0 0 0 > [58] 2011-06-19 23:27:49.909895 [#5 em1 0] \ > [24.104.150.12].26356 [24.104.150.2].53 \ > dns QUERY,NOERROR,57398,rd \ > 1 sony.vix.com,IN,AAAA 0 0 0 > [50] 2011-06-19 23:27:49.910489 [#6 em1 0] \ > [24.104.150.12].23228 [24.104.150.2].53 \ > dns QUERY,NOERROR,57399,rd \ > 1 sony,IN,A 0 0 0 > [50] 2011-06-19 23:27:49.930022 [#7 em1 0] \ > [24.104.150.12].37238 [24.104.150.2].53 \ > dns QUERY,NOERROR,57400,rd \ > 1 sony,IN,AAAA 0 0 0 > [58] 2011-06-19 23:27:49.931059 [#8 em1 0] \ > [24.104.150.12].17401 [24.104.150.2].53 \ > dns QUERY,NOERROR,33742,rd \ > 1 www.sony.com,IN,A 0 0 0 > [124] 2011-06-19 23:27:50.112451 [#9 em1 0] \ > [24.104.150.2].53 [24.104.150.12].17401 \ > dns QUERY,NOERROR,33742,qr|rd|ra \ > 1 www.sony.com,IN,A \ > 1 www.sony.com,IN,A,600,72.52.6.10 \ > 2 sony.com,IN,NS,172800,pdns1.cscdns.net \ > sony.com,IN,NS,172800,pdns2.cscdns.net 0 > > ...i see that the browser's stub is indeed looking at the search list first > when there are no dots in the name. that's correct behaviour by the RFC > and also anecdotally since if i had an internal web server here called > sony.vix.com i would want my web browser to assume that that was the one i > wanted when i typed "http://sony/". having it go outside my network and > hit a TLD first would be a dangerous information leak. (this also shows > DNS's lack of a formal presentation layer as clearly as anything ever > could.) > > inevitably there will be folks who register .FOOBAR and advertise it as > "http://foobar/" on a billboard and then get burned by all of the local > "foobar.this.tld" and "foobar.that.tld" names that will get reached > instead of their TLD. i say inevitable; i don't know a way to avoid it > since there will be a lot of money and a lot of people involved. Which just means we need to write yet another RFC saying that resolvers shouldn't lookup simple host names in the DNS. Simple host names should be qualified against a search list. Resolver can still lookup simple names against /etc/hosts which covers localhost. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Sun Jun 19 19:22:17 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 19 Jun 2011 20:22:17 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <21633.1308527099@nsa.vix.com> Message-ID: <8190112.768.1308529337430.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Paul Vixie" > inevitably there will be folks who register .FOOBAR and advertise it as > "http://foobar/" on a billboard and then get burned by all of the local > "foobar.this.tld" and "foobar.that.tld" names that will get reached > instead of their TLD. i say inevitable; i don't know a way to avoid it > since there will be a lot of money and a lot of people involved. I think it's probably worse than that, since a lot of the companies who might be foolish enough to try that *are companies that make stuff that's on your LAN*... and what are you going to name the *one* Apple server that's on your LAN in your internal DNS? Of course; you're gonna call it "apple". Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jbaino at gmail.com Sun Jun 19 19:30:58 2011 From: jbaino at gmail.com (Jeremy) Date: Sun, 19 Jun 2011 19:30:58 -0500 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> Message-ID: "DK" may not be hierarchical, but "DK." is. If you try to resolve "DK" on it's own, many (most? all?) DNS clients will attach the search string/domain name of the local system in order to make it a FQDN. The same happens when you try and resolve a non-existent domain. Such as alskdiufwfeiuwdr3948dx.com, in wireshark I see the initial request followed by alskdiufwfeiuwdr3948dx.com.gateway.2wire.net. However if I qualify it with the trailing dot, it stops after the first lookup. DK. is a valid FQDN and should be considered hierarchical due to the dot being the root and anything before that is a branch off of the root. see RFC1034 -Jeremy On Sun, Jun 19, 2011 at 7:08 PM, Mark Andrews wrote: > > In message , Paul Vixie writes: > > Adam Atkinson writes: > > > > > It was a very long time ago, but I seem to recall being shown > http://dk, > > > the home page of Denmark, some time in the mid 90s. > > > > > > Must I be recalling incorrectly? > > > > no you need not must be. it would work as long as no dk.this or dk.that > > would be found first in a search list containing 'this' and 'that', where > > the default search list is normally the parent domain name of your own > > hostname (so for me on six.vix.com the search list would be vix.com and > > so as long as dk.vix.com did not exist then http://dk/ would reach > "dk.") > > -- > > Paul Vixie > > KI6YSY > > DK should NOT be doing this. DK is *not* a hierarchical host name > and the address record should not exist, RFC 897. The Internet > stopped using simple host names in the early '80s. In addition to > that it is a security issue similar to that described in RFC 1535. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From johnl at iecc.com Sun Jun 19 19:41:57 2011 From: johnl at iecc.com (John Levine) Date: 20 Jun 2011 00:41:57 -0000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <20110620004157.15208.qmail@joyce.lan> A surprising number of TLDs have A records. Many are hosts with web servers, a few are hosts with misconfigured or unconfigured web servers (ph. and bi.), some don't respond. No TLD has an AAAA record, confirming the theory that nobody actually cares about IPv6. ac. 193.223.78.210 ai. 209.59.119.34 bi. 196.2.8.205 cm. 195.24.205.60 dk. 193.163.102.24 gg. 87.117.196.80 hk. 203.119.2.31 io. 193.223.78.212 je. 87.117.196.80 ph. 203.119.4.7 pn. 80.68.93.100 sh. 64.251.31.234 tk. 217.119.57.22 tm. 193.223.78.213 to. 216.74.32.107 uz. 91.212.89.8 ws. 63.101.245.10 xn--o3cw4h. 203.146.249.130 R's, John From marka at isc.org Sun Jun 19 19:44:58 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 10:44:58 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 17:06:17 MST." References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> Message-ID: <20110620004458.97BD810EAC7B@drugs.dv.isc.org> In message , Owen DeLong write s: > Appears to now get you a redirect to https://www.dk-hostmaster.dk/ > > For those arguing that 512+ octet replies don't occur: I don't think anyone argues that 512+ octet replies don't occur. They have occured for as long as the DNS has existed. Even RFC 1123 said you SHOULD handle them. Unfortunately there are SOHO router vendors (yes I'm talking about you Netgear) that have shipped products that don't even listen on DNS/TCP yet advertise themselves as recursive DNS servers and don't have fixed images that can be installed (yes the box is field upgradable and yes I have looked for updated images). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sun Jun 19 20:03:07 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 11:03:07 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 19:30:58 EST." References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> Message-ID: <20110620010307.46AD010EAF6A@drugs.dv.isc.org> In message , Jeremy writes: > > "DK" may not be hierarchical, but "DK." is. If you try to resolve "DK" on "DK." is NOT a hostname (RFC 952). It is NOT legal in a SMTP transaction. It is NOT legal in a HTTP header. > it's own, many (most? all?) DNS clients will attach the search string/domain > name of the local system in order to make it a FQDN. The same happens when > you try and resolve a non-existent domain. Such as > alskdiufwfeiuwdr3948dx.com, in wireshark I see the initial request followed > by alskdiufwfeiuwdr3948dx.com.gateway.2wire.net. However if I qualify it > with the trailing dot, it stops after the first lookup. DK. is a valid FQDN > and should be considered hierarchical due to the dot being the root and > anything before that is a branch off of the root. see RFC1034 You need to write 1000 lines of: RFC 1034 DOES NOT CHANGE WHAT IS A LEGAL HOSTNAME Go READ RFC 1034. "DK." it is NOT a valid heirachical hostname. Just because some random piece of software lets you get away with it does not make it a legal nor does it make it a good idea. Mark > -Jeremy > > On Sun, Jun 19, 2011 at 7:08 PM, Mark Andrews wrote: > > > > > In message , Paul Vixie writes: > > > Adam Atkinson writes: > > > > > > > It was a very long time ago, but I seem to recall being shown > > http://dk, > > > > the home page of Denmark, some time in the mid 90s. > > > > > > > > Must I be recalling incorrectly? > > > > > > no you need not must be. it would work as long as no dk.this or dk.that > > > would be found first in a search list containing 'this' and 'that', where > > > the default search list is normally the parent domain name of your own > > > hostname (so for me on six.vix.com the search list would be vix.com and > > > so as long as dk.vix.com did not exist then http://dk/ would reach > > "dk.") > > > -- > > > Paul Vixie > > > KI6YSY > > > > DK should NOT be doing this. DK is *not* a hierarchical host name > > and the address record should not exist, RFC 897. The Internet > > stopped using simple host names in the early '80s. In addition to > > that it is a security issue similar to that described in RFC 1535. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > --bcaec51f900961620b04a619d97b > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > "DK" may not be hierarchical, but "DK." is. If you try = > to resolve "DK" on it's own, many (most? all?) DNS clients wi= > ll attach the search string/domain name of the local system in order to mak= > e it a FQDN. The same happens when you try and resolve a non-existent domai= > n. Such as alskdiufwfeiuwdr39= > 48dx.com, in wireshark I see the initial request followed by =A0 ttp-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"> =3D"http://alskdiufwfeiuwdr3948dx.com.gateway.2wire.net">alskdiufwfeiuwdr39= > 48dx.com.gateway.2wire.net. However if I qualify it with the trailing d= > ot, it stops after the first lookup. DK. is a valid FQDN and should be cons= > idered hierarchical due to the dot being the root and anything before that = > is a branch off of the root. see RFC1034
>
-Jeremy

On Sun, Jun 19, 20= > 11 at 7:08 PM, Mark Andrews < sc.org">marka at isc.org> wrote:
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= > x;"> >

> In message <g339j59ywz.fsf= > @nsa.vix.com>, Paul Vixie writes:
> > Adam Atkinson <ghira at mistral= > .co.uk> writes:
> >
> > > It was a very long time ago, but I seem to recall being shown href=3D"http://dk" target=3D"_blank">http://dk,
> > > the home page of Denmark, some time in the mid 90s.
> > >
> > > Must I be recalling incorrectly?
> >
> > no you need not must be. =A0it would work as long as no dk.this or dk.= > that
> > would be found first in a search list containing 'this' and &#= > 39;that', where
> > the default search list is normally the parent domain name of your own= >
> > hostname (so for me on ">six.vix.com the search list would be t=3D"_blank">vix.com and
> > so as long as dk.vix.c= > om did not exist then http://d= > k/ would reach "dk.")
> > --
> > Paul Vixie
> > KI6YSY
>
>
DK should NOT be doing this. =A0DK is *not* a hierarchical host= > name
> and the address record should not exist, RFC 897. =A0The Internet
> stopped using simple host names in the early '80s. =A0In addition to > > that it is a security issue similar to that described in RFC 1535.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2= > 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka at isc.org">marka at isc.org
>
>

> > --bcaec51f900961620b04a619d97b-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From vixie at isc.org Sun Jun 19 20:24:30 2011 From: vixie at isc.org (Paul Vixie) Date: Mon, 20 Jun 2011 01:24:30 +0000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 19:30:58 EST." References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> Message-ID: <27712.1308533070@nsa.vix.com> > Date: Sun, 19 Jun 2011 19:30:58 -0500 > From: Jeremy > > "DK" may not be hierarchical, but "DK." is. If you try to resolve "DK" > on it's own, many (most? all?) DNS clients will attach the search > string/domain name of the local system in order to make it a FQDN. The > same happens when you try and resolve a non-existent domain. Such as > alskdiufwfeiuwdr3948dx.com, in wireshark I see the initial request > followed by alskdiufwfeiuwdr3948dx.com.gateway.2wire.net. However if I > qualify it with the trailing dot, it stops after the first lookup. > "DK." is a valid FQDN and should be considered hierarchical due to the > dot being the root and anything before that is a branch off of the > root. see RFC1034 i think he's seen RFC 1034 :-). anyway, i don't see the difference between http://sony/ and http://sony./ and if a technology person tried to explain to a marketing person that single-token TLD names *can* be used as long as there's a trailing dot, the result would hopefully be "that glazed look" of nonunderstanding but would far more likely be an interpretation of "oh, so it's OK after all, we'll use it that way, thanks!" furthermore, the internet has more in it than just the web, and i know that "foo at sony." will not have its RHS ("sony.") treated as a hierarchical name. i think we have to just discourage lookups of single-token names, universally. From jeff-kell at utc.edu Sun Jun 19 20:36:01 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 19 Jun 2011 21:36:01 -0400 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <27712.1308533070@nsa.vix.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> Message-ID: <4DFEA401.909@utc.edu> On 6/19/2011 9:24 PM, Paul Vixie wrote: > i think we have to just discourage lookups of single-token names, universally. Not to mention the folks of the Redmond persuasion with their additionally ambiguous \\hostname single names. (In the absence of a configured search domain, Windows won't even try DNS for a single name through it's own resolver libraries; although nslookup will). Jeff From jra at baylink.com Sun Jun 19 20:37:31 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 19 Jun 2011 21:37:31 -0400 (EDT) Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <27712.1308533070@nsa.vix.com> Message-ID: <18612702.774.1308533850991.JavaMail.root@benjamin.baylink.com> Vix: > i think he's seen RFC 1034 :-). anyway, i don't see the difference > between http://sony/ and http://sony./ The fact that the resolution of "sony." is deterministic, and that of "sony" is location dependent? > i think we have to just discourage lookups of single-token names, > universally. In order to do which, we have to discourage their *deployment*. And if by "universally" you mean "no Jay, you can't say 'telnet dns1' from your desktop machine to get to your inhouse nameserver, then I'm just gonna have to go ahead and disagree with ya' there, Vix. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From marka at isc.org Sun Jun 19 20:42:34 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 11:42:34 +1000 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: Your message of "Sun, 19 Jun 2011 13:43:24 EST." References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> <20110618093144.46A6E10E6179@drugs.dv.isc.org> <43B2CE52-B07E-48E8-9BBE-772B979F4316@delong.com> Message-ID: <20110620014234.113C910EB390@drugs.dv.isc.org> Adding AAAA records for existing nameservers will NOT cause TC to be set where it would not be set without AAAA records unless you do a "ANY" lookup of the nameserver where it MAY result in TC being set. All current implementations, including named, fail to set TC when adding glue records to a referral in contradiction on RFC 1034. This issue has been raised with the IETF dnsext wg. Fixing this would result in most COM/NET referrals, from the root, setting TC. Note: recent version of named will add glue which matches the question section is added to a referral in preference to other glue and if that glue rrset won't fit it then named will set TC to prevent the resolution process getting wedged. Usually only EDNS/512 + DO=1 queries result in a referral which fits the critera to set TC even then most such queries don't. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bonomi at mail.r-bonomi.com Sun Jun 19 20:43:43 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 19 Jun 2011 20:43:43 -0500 (CDT) Subject: Cogent depeers ESnet In-Reply-To: Message-ID: <201106200143.p5K1hhwX035537@mail.r-bonomi.com> > From georgeb at gmail.com Sun Jun 19 17:48:31 2011 > Date: Sun, 19 Jun 2011 15:48:32 -0700 > Subject: Re: Cogent depeers ESnet > From: "George B." > To: Valdis.Kletnieks at vt.edu > Cc: Robert Bonomi , nanog at nanog.org > > On Sun, Jun 19, 2011 at 2:47 PM, wrote: > > On Sun, 19 Jun 2011 03:15:09 CDT, Robert Bonomi said: > > > >> Anybody got draft language for a SLA clause that requires routing 'at > >> least one hop _past_ the provider's network edge' for every AS visible > >> at major public peering points and/or LookingGlass sites? > > > > *every* ASN? Oh my. ;) No, not an *unqualified* "every ASN". Merely every one that is 'publicly visible' at any 'signficiant' point on the network. <*GRIN*> > > I would qualify that a bit to say "every ASN available at every peering > point at which the provider appears". I wrote it the way I did, because I expressly did not want that loophole. If a provider claims they provide 'complete' Internet acess, the idea is to require _complete_ access. From drc at virtualized.org Sun Jun 19 21:04:09 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 19 Jun 2011 16:04:09 -1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <27712.1308533070@nsa.vix.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> Message-ID: <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote: > i think we have to just discourage lookups of single-token names, universally. How? Regards, -drc From vixie at isc.org Sun Jun 19 21:08:18 2011 From: vixie at isc.org (Paul Vixie) Date: Mon, 20 Jun 2011 02:08:18 +0000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 16:04:09 -1000." <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> Message-ID: <30657.1308535698@nsa.vix.com> > From: David Conrad > Date: Sun, 19 Jun 2011 16:04:09 -1000 > > On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote: > > > i think we have to just discourage lookups of single-token names, > > universally. > > How? that's a good question. marka mentioned writing an RFC, but i expect that ICANN could also have an impact on this by having applicants sign something that says "i know that my single-label top level domain name will not be directly usable the way normal domain names are and i intend to use it only to register subdomain names which will work normally." From mpalmer at hezmatt.org Sun Jun 19 21:19:50 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 20 Jun 2011 12:19:50 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <8190112.768.1308529337430.JavaMail.root@benjamin.baylink.com> References: <21633.1308527099@nsa.vix.com> <8190112.768.1308529337430.JavaMail.root@benjamin.baylink.com> Message-ID: <20110620021950.GF22897@hezmatt.org> On Sun, Jun 19, 2011 at 08:22:17PM -0400, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Paul Vixie" > > > inevitably there will be folks who register .FOOBAR and advertise it as > > "http://foobar/" on a billboard and then get burned by all of the local > > "foobar.this.tld" and "foobar.that.tld" names that will get reached > > instead of their TLD. i say inevitable; i don't know a way to avoid it > > since there will be a lot of money and a lot of people involved. > > I think it's probably worse than that, since a lot of the companies who might > be foolish enough to try that *are companies that make stuff that's on your > LAN*... and what are you going to name the *one* Apple server that's on your > LAN in your internal DNS? > > Of course; you're gonna call it "apple". And it only gets better from there... how many places have various "cutesy" naming schemes that might include one or more trademarks (or whatever) that someone might want as a TLD? A naming scheme involving fruit would cover your "apple" example, but I'd bet that someone, somewhere, names their servers after fast food restaurants or brands of shoe... and I'm confident in predicting that there are plenty of cartoon characters that some company or another will want to turn into a TLD. - Matt -- When all you have is a nailgun, every problem looks like a messiah. -- Iain Chalmers, ASR From scott at doc.net.au Sun Jun 19 21:21:27 2011 From: scott at doc.net.au (Scott Howard) Date: Sun, 19 Jun 2011 19:21:27 -0700 Subject: Fwd: ICANN 41 - now underway In-Reply-To: References: Message-ID: Guessing some people here might be interested in this, but it seems to have only been sent to APAC-based *NOGs... Scott ---------- Forwarded message ---------- From: Save Vocea Date: Sun, Jun 19, 2011 at 5:30 PM Subject: [AusNOG] ICANN 41 - now underway To: "ausnog at ausnog.net" Dear all, The ICANN 41 meeting is already underway in Singapore this week and fortunately this is closer to the Oceania regional time zones. The official welcoming ceremony and opening is starting at 9am Singapore time. The full meeting schedule is available at http://singapore41.icann.org/full-schedule where if you click on the session link takes you to remote participation links so one can participate/follow proceedings remotely. There?s also live twitter feeds referencing #ICANN and #ICANN41 Regards, Save Vocea ICANN rep Australasia/Pacific Islands _______________________________________________ AusNOG mailing list AusNOG at lists.ausnog.net http://lists.ausnog.net/mailman/listinfo/ausnog From mike at mtcc.com Sun Jun 19 21:22:46 2011 From: mike at mtcc.com (Michael Thomas) Date: Sun, 19 Jun 2011 19:22:46 -0700 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <30657.1308535698@nsa.vix.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> Message-ID: <4DFEAEF6.70407@mtcc.com> On 06/19/2011 07:08 PM, Paul Vixie wrote: >> From: David Conrad >> Date: Sun, 19 Jun 2011 16:04:09 -1000 >> >> On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote: >> >> >>> i think we have to just discourage lookups of single-token names, >>> universally. >>> >> How? >> > that's a good question. marka mentioned writing an RFC, but i expect > that ICANN could also have an impact on this by having applicants sign > something that says "i know that my single-label top level domain name > will not be directly usable the way normal domain names are and i intend > to use it only to register subdomain names which will work normally." > Isn't this problem self regulating? If sufficient things break with a single label, people will stop making themselves effectively unreachable, right? Mike From mpalmer at hezmatt.org Sun Jun 19 21:26:20 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 20 Jun 2011 12:26:20 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <30657.1308535698@nsa.vix.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> Message-ID: <20110620022620.GG22897@hezmatt.org> On Mon, Jun 20, 2011 at 02:08:18AM +0000, Paul Vixie wrote: > > From: David Conrad > > Date: Sun, 19 Jun 2011 16:04:09 -1000 > > > > On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote: > > > > > i think we have to just discourage lookups of single-token names, > > > universally. > > > > How? > > that's a good question. marka mentioned writing an RFC, but i expect > that ICANN could also have an impact on this by having applicants sign > something that says "i know that my single-label top level domain name > will not be directly usable the way normal domain names are and i intend > to use it only to register subdomain names which will work normally." Whilst we can dream that that will work, I don't think it'll actually last very long in the face of determined marketing department pressure; also, unless that agreement also says "I agree to pay the additional costs borne by any party on the Internet that result from my failure to adhere to this agreement", it's worthless. Are your customers going to call Sony when they put http://sony/ into their web browser and it doesn't work? Hell no. They're going to call your helpdesk, and it's going to tie up a non-trivial amount of engineer time either renaming things or reconfiguring the client machine to make that URL work as the user expects it to. - Matt -- It fsck's the volume or it gets the format again. -- Don Quixote, in the Monastery From drc at virtualized.org Sun Jun 19 21:26:25 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 19 Jun 2011 16:26:25 -1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <30657.1308535698@nsa.vix.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> Message-ID: <2055EEA1-9C80-47BF-9ADE-D86D14993698@virtualized.org> On Jun 19, 2011, at 4:08 PM, Paul Vixie wrote: > ICANN could also have an impact on this by having applicants sign something Well, yes, ICANN could have contracted parties (e.g., the new gTLDs) do this. A bit late to get it into the Applicant's Guidebook, but maybe something could be slipped in after the fact. Who is going to lead the contingent from NANOG to raise this in the GNSO? Of course, changing existing contracts tends to be challenging since the contracted parties have to agree to the changes and I wouldn't be surprised if they demanded ICANN give something up in exchange for agreeing to this new restriction. It'll probably take a while. ICANN can respectfully request ccTLD folks do the same, but whether or not the ccTLDs listen is a separate matter. If the ccTLD folks feel they gain benefit from having naked TLDs, they'll tell ICANN to take a hike. Not sure what will happen with the IDN ccTLDs since they appear to be sort of a combination of ccTLDs and contracted parties. You probably know all this, but things in the ICANN world probably don't work the way most folks think. Regards, -drc From vixie at isc.org Sun Jun 19 21:31:24 2011 From: vixie at isc.org (Paul Vixie) Date: Mon, 20 Jun 2011 02:31:24 +0000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 19:22:46 MST." <4DFEAEF6.70407@mtcc.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> Message-ID: <32105.1308537084@nsa.vix.com> > Date: Sun, 19 Jun 2011 19:22:46 -0700 > From: Michael Thomas > > > that's a good question. marka mentioned writing an RFC, but i expect > > that ICANN could also have an impact on this by having applicants sign > > something that says "i know that my single-label top level domain name > > will not be directly usable the way normal domain names are and i intend > > to use it only to register subdomain names which will work normally." > > Isn't this problem self regulating? If sufficient things break with a > single label, people will stop making themselves effectively unreachable, > right? alas, no. if someone adds something to the internet that doesn't work right but they ignore this and press onward until they have market share, then the final disposition will be based on market size not on first mover advantage. if you live in the san francisco bay area you probably know about the "sound walls" along the US101 corridor. the freeway was originally built a long way from where the houses were, but then a few generations of people built their houses closer and closer to the freeway. then their descendants or the folks who bought these houses third or fourth hand complained about the road noise and so we have sound walls. no harm exactly, and no foul, except, noone likes the result much. here's this quote again: "Distant hands in foreign lands are turning hidden wheels, causing things to come about which no one seems to feel. All invisible from where we stand, the connections come to pass and though too strange to comprehend, they affect us nonetheless, yes." James Taylor, _Migrations_ good stewardship and good governance means trying to avoid such outcomes. From marka at isc.org Sun Jun 19 22:00:09 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 13:00:09 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 19:22:46 MST." <4DFEAEF6.70407@mtcc.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> Message-ID: <20110620030009.726C010EBCC0@drugs.dv.isc.org> In message <4DFEAEF6.70407 at mtcc.com>, Michael Thomas writes: > Isn't this problem self regulating? If sufficient things break > with a single label, people will stop making themselves > effectively unreachable, right? The failure rate isn't going to be high enough for natural selection to take effect. Remember the protocols we use were designed to work back when there was only a single flat namespace. Simple hostnames will appear to work fine for 99.999% of people. It's just when you get namespace collisions that there will be problems. Unfortunately the nincompoops that decide to use tlds this way don't have to pay the costs of cleaning up the mess they cause. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gbonser at seven.com Sun Jun 19 22:08:05 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 19 Jun 2011 20:08:05 -0700 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620030009.726C010EBCC0@drugs.dv.isc.org> References: <20110618013328.18875.qmail@joyce.lan><1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com><4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org><27712.1308533070@nsa.vix.com><1641C545-C7B7-4827-843E-1C748342082D@virtualized.org><30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <20110620030009.726C010EBCC0@drugs.dv.isc.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0D633D5A@RWC-EX1.corp.seven.com> > > The failure rate isn't going to be high enough for natural selection > to take effect. Remember the protocols we use were designed to > work back when there was only a single flat namespace. Simple > hostnames will appear to work fine for 99.999% of people. It's > just when you get namespace collisions that there will be problems. I would guess that most of these are going to be purchased simply to prevent someone else from getting them and that most of them will never actually be placed into production. So it will basically just be a cash cow for ICANN while people pay their $185K/pop "application fee" to snap up a piece of real estate they don't want anyone else to have. From ghira at mistral.co.uk Sun Jun 19 22:33:45 2011 From: ghira at mistral.co.uk (Adam Atkinson) Date: Mon, 20 Jun 2011 04:33:45 +0100 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> Message-ID: <4DFEBF99.8020607@mistral.co.uk> Mark Andrews wrote: >>> It was a very long time ago, but I seem to recall being shown http://dk, >>> the home page of Denmark, some time in the mid 90s. >>> > DK should NOT be doing this. Oh, I'm not claiming it does it now. It certainly doesn't. I _think_ I was shown http://dk in about 1993 or 1994 as an example of something a bit silly. If my recollection is even correct, I would be curious to know at what point Denmark decided it no longer wanted whatever was on that page as the Denmark home page. And it's so long since I saw whatever I saw that I could very well be remembering incorrectly, as I said. From johnl at iecc.com Sun Jun 19 22:35:03 2011 From: johnl at iecc.com (John Levine) Date: 20 Jun 2011 03:35:03 -0000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <27712.1308533070@nsa.vix.com> Message-ID: <20110620033503.20835.qmail@joyce.lan> >i think he's seen RFC 1034 :-). anyway, i don't see the difference between >http://sony/ and http://sony./ Neither do any of the browsers I use, which resolve http://bi/ as well as http://dk./ just fine. Whatever problem unqualified TLD names might present to web browsers has been around for a long time and the world hasn't come to an end. The problems with zillions of single-registrant TLDs are more social and economic than technical. R's, John From ghira at mistral.co.uk Sun Jun 19 22:44:33 2011 From: ghira at mistral.co.uk (Adam Atkinson) Date: Mon, 20 Jun 2011 04:44:33 +0100 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <4DFEBF99.8020607@mistral.co.uk> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <4DFEBF99.8020607@mistral.co.uk> Message-ID: <4DFEC221.90902@mistral.co.uk> Adam Atkinson wrote: >>>> It was a very long time ago, but I seem to recall being shown >>>> http://dk, >>>> the home page of Denmark, some time in the mid 90s. >>>> >> DK should NOT be doing this. > > Oh, I'm not claiming it does it now. It certainly doesn't. I should have checked before I wrote that. The _last_ time I tried it it redirected to something else in Denmark but that was also years ago, just not as many as I think I remember being shown http://dk _Now_ I get rend up at http://www.dk.com/ if I don't put a dot on the end, and https://www.dk-hostmaster.dk/ if I do. From marka at isc.org Sun Jun 19 22:46:29 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 13:46:29 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 20:08:05 MST." <5A6D953473350C4B9995546AFE9939EE0D633D5A@RWC-EX1.corp.seven.com> References: <20110618013328.18875.qmail@joyce.lan><1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com><4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org><27712.1308533070@nsa.vix.com><1641C545-C7B7-4827-843E-1C748342082D@virtualized.org><30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <20110620030009.726C010EBCC0@drugs.dv.isc.org> <5A6D953473350C4B9995546AFE9939EE0D633D5A@RWC-EX1.corp.seven.com> Message-ID: <20110620034629.C304E10EBF12@drugs.dv.isc.org> In message <5A6D953473350C4B9995546AFE9939EE0D633D5A at RWC-EX1.corp.seven.com>, G eorge Bonser writes: > > The failure rate isn't going to be high enough for natural selection > > to take effect. Remember the protocols we use were designed to > > work back when there was only a single flat namespace. Simple > > hostnames will appear to work fine for 99.999% of people. It's > > just when you get namespace collisions that there will be problems. > > I would guess that most of these are going to be purchased simply to > prevent someone else from getting them I would agree with this part. > and that most of them will never > actually be placed into production. But not with this part. > So it will basically just be a cash > cow for ICANN while people pay their $185K/pop "application fee" to snap > up a piece of real estate they don't want anyone else to have. Adding gtlds and opening up the root to brands effectively requires TM holders to register/bid to protect their TM rights. Now $10 or so is not a lot for a TM.gtld and isn't worth the court costs but $185K/pop is a lot and sooner or later a TM holder will sue ICANN because they don't want to have to pay $185K to protect their TM and it will be interesting to see the results. It will be even more interesting if ICANN looses and has to roll back brand delegations it has made. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Sun Jun 19 22:47:14 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 19 Jun 2011 23:47:14 -0400 (EDT) Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620033503.20835.qmail@joyce.lan> Message-ID: <23626518.792.1308541634219.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Levine" > >i think he's seen RFC 1034 :-). anyway, i don't see the difference > >between http://sony/ and http://sony./ > > Neither do any of the browsers I use, which resolve http://bi/ as well > as http://dk./ just fine. Whatever problem unqualified TLD names > might present to web browsers has been around for a long time and the > world hasn't come to an end. C'mon, John; you've just been skimming the thread? The problem caused by making monocomponent name resolution non-deterministic has been covered in pretty decent detail, just today. We didn't say http://apple/ wouldn't work... we said it wouldn't work (as previously expected) *if someone already had an internal machine called "apple"*... at which point http://apple/ might resolve to a new and different thing which matched http://apple./ Saying "that's very unlikely to happen" only displays a fairly shallow knowledge of the *number* of different categories and shapes of large IP networks that exist in the world. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From drc at virtualized.org Sun Jun 19 23:01:39 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 19 Jun 2011 18:01:39 -1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620034629.C304E10EBF12@drugs.dv.isc.org> References: <20110618013328.18875.qmail@joyce.lan><1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com><4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org><27712.1308533070@nsa.vix.com><1641C545-C7B7-4827-843E-1C748342082D@virtualized.org><30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <20110620030009.726C010EBCC0@drugs.dv.isc.org> <5A6D953473350C4B9995546AFE9939EE0D633D5A@RWC-EX1.corp.seven.com> <20110620034629.C304E10EBF12@drugs.dv.isc.org> Message-ID: <1BC921A3-C4CD-4FFF-9AE5-49C1218D5191@virtualized.org> On Jun 19, 2011, at 5:46 PM, Mark Andrews wrote: >> I would guess that most of these are going to be purchased simply to >> prevent someone else from getting them > I would agree with this part. I suspect you underestimate the desires and power of marketing folks at larger organizations. > Adding gtlds and opening up the root to brands effectively requires > TM holders to register/bid to protect their TM rights. Not really. You might want to search on "trademark" in http://www.icann.org/en/topics/new-gtlds/rfp-clean-30may11-en.pdf. There has been a tremendous amount of traffic on that particular issue and that is reflected in the Applicant Guidebook. > It will be even > more interesting if ICANN looses and has to roll back brand delegations > it has made. Really, if you're going to opine on the disasters that will befall ICANN as a result of the new gTLD program, you might want to actually read what that program does and doesn't do. Really. Regards, -drc From marka at isc.org Sun Jun 19 23:20:48 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 14:20:48 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Mon, 20 Jun 2011 04:44:33 +0100." <4DFEC221.90902@mistral.co.uk> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <4DFEBF99.8020607@mistral.co.uk> <4DFEC221.90902@mistral.co.uk> Message-ID: <20110620042048.B293710EC078@drugs.dv.isc.org> In message <4DFEC221.90902 at mistral.co.uk>, Adam Atkinson writes: > Adam Atkinson wrote: > > >>>> It was a very long time ago, but I seem to recall being shown > >>>> http://dk, > >>>> the home page of Denmark, some time in the mid 90s. > >>>> > >> DK should NOT be doing this. > > > > Oh, I'm not claiming it does it now. It certainly doesn't. > > I should have checked before I wrote that. The _last_ time I tried it > it redirected to something else in Denmark but that was also years > ago, just not as many as I think I remember being shown http://dk > > _Now_ I get rend up at http://www.dk.com/ if I don't That's your browser "trying" to be helpful. If it is Firefox this can be turned off with about:config and browser.fixup.alternate.enabled to false. The default is true. > put a dot on the end, and https://www.dk-hostmaster.dk/ if I do. Safari, Mozilla and Google Chrome all fail to resolve "http://dk/" on my Mac but all resolve "http://dk./". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sun Jun 19 23:39:59 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 14:39:59 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 18:01:39 -1000." <1BC921A3-C4CD-4FFF-9AE5-49C1218D5191@virtualized.org> References: <20110618013328.18875.qmail@joyce.lan><1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com><4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org><27712.1308533070@nsa.vix.com><1641C545-C7B7-4827-843E-1C748342082D@virtualized.org><30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <20110620030009.726C010EBCC0@drugs.dv.isc.org> <5A6D953473350C4B9995546AFE9939EE0D633D5A@RWC-EX1.corp.seven.com> <20110620034629.C304E10EBF12@drugs.dv.isc.org> <1BC921A3-C4CD-4FFF-9AE5-49C1218D5191@virtualized.org> Message-ID: <20110620043959.32B0210ED1A3@drugs.dv.isc.org> In message <1BC921A3-C4CD-4FFF-9AE5-49C1218D5191 at virtualized.org>, David Conrad writes: > On Jun 19, 2011, at 5:46 PM, Mark Andrews wrote: > >> I would guess that most of these are going to be purchased simply to > >> prevent someone else from getting them > > I would agree with this part. > > I suspect you underestimate the desires and power of marketing folks at = > larger organizations. > > > Adding gtlds and opening up the root to brands effectively requires > > TM holders to register/bid to protect their TM rights. =20 > > Not really. You might want to search on "trademark" in = > http://www.icann.org/en/topics/new-gtlds/rfp-clean-30may11-en.pdf. = > There has been a tremendous amount of traffic on that particular issue = > and that is reflected in the Applicant Guidebook. > > > It will be even > > more interesting if ICANN looses and has to roll back brand = > delegations > > it has made. > > Really, if you're going to opine on the disasters that will befall ICANN = > as a result of the new gTLD program, you might want to actually read = > what that program does and doesn't do. Really. > > Regards, > -drc I'm curious how anyone that has not signed a agreement with ICANN can be bound to anything in any applicant guide book. Also rfp-clean-30may11-en.pdf basically deals with .. on a brief skimming not or is ICANN going to have a sunrise period for "."? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ghira at mistral.co.uk Sun Jun 19 23:41:57 2011 From: ghira at mistral.co.uk (Adam Atkinson) Date: Mon, 20 Jun 2011 05:41:57 +0100 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620042048.B293710EC078@drugs.dv.isc.org> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <4DFEBF99.8020607@mistral.co.uk> <4DFEC221.90902@mistral.co.uk> <20110620042048.B293710EC078@drugs.dv.isc.org> Message-ID: <4DFECF95.9090300@mistral.co.uk> Mark Andrews wrote: >> _Now_ I get rend up at http://www.dk.com/ if I don't > > That's your browser "trying" to be helpful. If it is Firefox this > can be turned off with about:config and browser.fixup.alternate.enabled > to false. The default is true. Ah, thanks. I imagined it was FF trying to be helpul but wandering around the settings thingy didn't produce anything that seemed relevant. From marka at isc.org Sun Jun 19 23:46:10 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 14:46:10 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "20 Jun 2011 03:35:03 GMT." <20110620033503.20835.qmail@joyce.lan> References: <20110620033503.20835.qmail@joyce.lan> Message-ID: <20110620044610.B5BEB10ED30F@drugs.dv.isc.org> In message <20110620033503.20835.qmail at joyce.lan>, "John Levine" writes: > >i think he's seen RFC 1034 :-). anyway, i don't see the difference between > >http://sony/ and http://sony./ > > Neither do any of the browsers I use, which resolve http://bi/ as well > as http://dk./ just fine. Whatever problem unqualified TLD names > might present to web browsers has been around for a long time and the > world hasn't come to an end. > > The problems with zillions of single-registrant TLDs are more > social and economic than technical. And your technical solution to ensure "http://apple/" always resolves to "apple." and doesn't break people using "http://apple/" to reach "http://apple.example.net/" is? Similarly for "mail user at apple". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gbonser at seven.com Sun Jun 19 23:49:26 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 19 Jun 2011 21:49:26 -0700 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620034629.C304E10EBF12@drugs.dv.isc.org> References: <20110618013328.18875.qmail@joyce.lan><1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com><4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org><27712.1308533070@nsa.vix.com><1641C545-C7B7-4827-843E-1C748342082D@virtualized.org><30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <20110620030009.726C010EBCC0@drugs.dv.isc.org> <5A6D953473350C4B9995546AFE9939EE0D633D5A@RWC-EX1.corp.seven.com> <20110620034629.C304E10EBF12@drugs.dv.isc.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0D633D61@RWC-EX1.corp.seven.com> > > > > I would guess that most of these are going to be purchased simply to > > prevent someone else from getting them > > I would agree with this part. > > > and that most of them will never > > actually be placed into production. > > But not with this part. Well, I said "most", some will likely be placed into use, but I am willing to wager that most of them will not be actively promoted. So mcdonalds. might be set up to point to the same thing as mcdonalds.com but I doubt http://McDonalds will actually be promoted because of the potential breakage. Image what happens in a shop that has a farm of servers named with a fast food theme and they have a mcdonalds.example.com, arbys.example.com, burgerking.example.com, etc. So a user in that domain trying to get to http://mcdonalds ends up going to mcdonalds.example.com A company deploying this would end up with a flood of complaints and the more "famous" the company is, the more likely they are to have problems. From drc at virtualized.org Sun Jun 19 23:50:27 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 19 Jun 2011 18:50:27 -1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620043959.32B0210ED1A3@drugs.dv.isc.org> References: <20110618013328.18875.qmail@joyce.lan><1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com><4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org><27712.1308533070@nsa.vix.com><1641C545-C7B7-4827-843E-1C748342082D@virtualized.org><30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <20110620030009.726C010EBCC0@drugs.dv.isc.org> <5A6D953473350C4B9995546AFE9939EE0D633D5A@RWC-EX1.corp.seven.com> <20110620034629.C304E10EBF12@drugs.dv.isc.org> <1BC921A3-C4CD-4FFF-9AE5-49C1218D5191@virtualized.org> <20110620043959.32B0210ED1A3@drugs.dv.isc.org> Message-ID: <83163718-FA5B-47BA-BA50-67701ABD5601@virtualized.org> On Jun 19, 2011, at 6:39 PM, Mark Andrews wrote: > I'm curious how anyone that has not signed a agreement with ICANN > can be bound to anything in any applicant guide book. In order to obtain a gTLD, you have to sign a contractual agreement with ICANN. > Also rfp-clean-30may11-en.pdf basically deals with .. You might want to re-read pretty much any part of that document (e.g., the title). Regards, -drc From scubacuda at gmail.com Sun Jun 19 23:56:22 2011 From: scubacuda at gmail.com (Rogelio) Date: Mon, 20 Jun 2011 01:56:22 -0300 Subject: Huawei equiv of Cisco 7201 router and Cisco ME 4924 switch? Message-ID: I am in Brazil and am having a heckuva time finding a Cisco 7201 router and Cisco ME 4924 switch. Anyone have any ideas on where I could buy these easily? And if not, any suggestions on Huawei equivalents? -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From johnl at iecc.com Sun Jun 19 23:57:41 2011 From: johnl at iecc.com (John R. Levine) Date: 20 Jun 2011 00:57:41 -0400 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620044610.B5BEB10ED30F@drugs.dv.isc.org> References: <20110620033503.20835.qmail@joyce.lan> <20110620044610.B5BEB10ED30F@drugs.dv.isc.org> Message-ID: > And your technical solution to ensure "http://apple/" always resolves > to "apple." and doesn't break people using "http://apple/" to reach > "http://apple.example.net/" is? Whatever people have been doing for the past decade to deal with http://dk/ and http://bi/. As I think I said in fairly easy to understand language, this is not a new problem. I am not thrilled about lots of new TLDs, but it is silly to claim that they present any new technical problems. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From brunner at nic-naa.net Sun Jun 19 21:59:14 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Sun, 19 Jun 2011 22:59:14 -0400 Subject: unqualified domains, was ICANN to allow commercial gTLDs Message-ID: <201106200259.p5K2xEdq056063@nic-naa.net> > Really, if you're going to opine on the disasters that will befall ICANN as a result of the new gTLD program, you might want to actually read what that program does and doesn't do. Really. you made my morning dave. thanks for the chuckle! From johnl at iecc.com Mon Jun 20 00:04:55 2011 From: johnl at iecc.com (John Levine) Date: 20 Jun 2011 05:04:55 -0000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620034629.C304E10EBF12@drugs.dv.isc.org> Message-ID: <20110620050455.23859.qmail@joyce.lan> >Adding gtlds and opening up the root to brands effectively requires >TM holders to register/bid to protect their TM rights. If you had read the applicant handbook, you would know that's not true. But I'm glad to see that people are taking my advice and continuing the traditional uninformed nanog wankage rather than reading the documentation and polluting the discussion with boring facts. R's, John From johnl at iecc.com Mon Jun 20 00:11:48 2011 From: johnl at iecc.com (John R. Levine) Date: 20 Jun 2011 01:11:48 -0400 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620050455.23859.qmail@joyce.lan> References: <20110620050455.23859.qmail@joyce.lan> Message-ID: By the way, the ICANN board just voted to approve the new gTLD program. Time to place bets on what the next move will be. My money is on lawsuits by US trademark lawyers. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From marka at isc.org Mon Jun 20 00:14:49 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 15:14:49 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 18:50:27 -1000." <83163718-FA5B-47BA-BA50-67701ABD5601@virtualized.org> References: <20110618013328.18875.qmail@joyce.lan><1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com><4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org><27712.1308533070@nsa.vix.com><1641C545-C7B7-4827-843E-1C748342082D@virtualized.org><30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <20110620030009.726C010EBCC0@drugs.dv.isc.org> <5A6D953473350C4B9995546AFE9939EE0D633D5A@RWC-EX1.corp.seven.com> <20110620034629.C304E10EBF12@drugs.dv.isc.org> <1BC921A3-C4CD-4FFF-9AE5-49C1218D5191@virtualized.org> <20110620043959.32B0210ED1A3@drugs.dv.isc.org> <83163718-FA5B-47BA-BA50-67701ABD5601@virtualized.org> Message-ID: <20110620051449.8B94710EDC64@drugs.dv.isc.org> In message <83163718-FA5B-47BA-BA50-67701ABD5601 at virtualized.org>, David Conrad writes: > On Jun 19, 2011, at 6:39 PM, Mark Andrews wrote: > > I'm curious how anyone that has not signed a agreement with ICANN > > can be bound to anything in any applicant guide book. =20 > > In order to obtain a gTLD, you have to sign a contractual agreement with = > ICANN. David, you are missing the point. The TM holder doesn't want the gtld, they just want to protect their trademark. The TM holder doesn't have a contract with ICANN. They do however have a legitimate right to the name and want to spend $0 keeping the name out of anybodys hands but theirs. $187K is not longer a amount to be sneezed at. Mark > > Also rfp-clean-30may11-en.pdf basically deals with .. > > You might want to re-read pretty much any part of that document (e.g., = > the title). > > Regards, > -drc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joly at punkcast.com Mon Jun 20 00:18:25 2011 From: joly at punkcast.com (Joly MacFie) Date: Mon, 20 Jun 2011 01:18:25 -0400 Subject: ICANN 41 - now underway In-Reply-To: References: Message-ID: I've reformatted the transcript of the discussion and vote on new gTLD's for easier readability. http://isoc-ny.org/icann41/06-20_singapore_gtld_vote.txt On Sun, Jun 19, 2011 at 10:21 PM, Scott Howard wrote: > Guessing some people here might be interested in this, but it seems to have > only been sent to APAC-based *NOGs... > > Scott > > ---------- Forwarded message ---------- > From: Save Vocea > Date: Sun, Jun 19, 2011 at 5:30 PM > Subject: [AusNOG] ICANN 41 - now underway > To: "ausnog at ausnog.net" > > > Dear all, > > The ICANN 41 meeting is already underway in Singapore this week and > fortunately this is closer to the Oceania regional time zones. > > The official welcoming ceremony and opening is starting at 9am Singapore > time. > > The full meeting schedule is available at > http://singapore41.icann.org/full-schedule where if you click on the > session > link takes you to remote participation links so one can participate/follow > proceedings remotely. > > There?s also live twitter feeds referencing #ICANN and #ICANN41 > > > Regards, > Save Vocea > ICANN rep Australasia/Pacific Islands > > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > http://lists.ausnog.net/mailman/listinfo/ausnog > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From drc at virtualized.org Mon Jun 20 00:20:57 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 19 Jun 2011 19:20:57 -1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620051449.8B94710EDC64@drugs.dv.isc.org> References: <20110618013328.18875.qmail@joyce.lan><1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com><4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org><27712.1308533070@nsa.vix.com><1641C545-C7B7-4827-843E-1C748342082D@virtualized.org><30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <20110620030009.726C010EBCC0@drugs.dv.isc.org> <5A6D953473350C4B9995546AFE9939EE0D633D5A@RWC-EX1.corp.seven.com> <20110620034629.C304E10EBF12@drugs.dv.isc.org> <1BC921A3-C4CD-4FFF-9AE5-49C1218D5191@virtualized.org> <20110620043959.32B0210ED1A3@drugs.dv.isc.org> <83163718-FA5B-47BA-BA50-67701ABD5601@virtualized.org> <20110620051449.8B94710EDC64@drugs.dv.isc.org> Message-ID: Mark, RTFDAG. Regards, -drc On Jun 19, 2011, at 7:14 PM, Mark Andrews wrote: >> In order to obtain a gTLD, you have to sign a contractual agreement with = >> ICANN. > > David, you are missing the point. The TM holder doesn't want the > gtld, they just want to protect their trademark. The TM holder > doesn't have a contract with ICANN. They do however have a legitimate > right to the name and want to spend $0 keeping the name out of > anybodys hands but theirs. $187K is not longer a amount to be > sneezed at. > > Mark > >>> Also rfp-clean-30may11-en.pdf basically deals with .. >> >> You might want to re-read pretty much any part of that document (e.g., = >> the title). >> >> Regards, >> -drc > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From marka at isc.org Mon Jun 20 00:25:54 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 15:25:54 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "20 Jun 2011 00:57:41 -0400." References: <20110620033503.20835.qmail@joyce.lan> <20110620044610.B5BEB10ED30F@drugs.dv.isc.org> Message-ID: <20110620052554.2DE3010EDDA8@drugs.dv.isc.org> In message , "John R. Levine" wr ites: > > And your technical solution to ensure "http://apple/" always resolves > > to "apple." and doesn't break people using "http://apple/" to reach > > "http://apple.example.net/" is? > > Whatever people have been doing for the past decade to deal with > http://dk/ and http://bi/. > > As I think I said in fairly easy to understand language, this is not a new > problem. I am not thrilled about lots of new TLDs, but it is silly to > claim that they present any new technical problems. There is a big difference between a handful of tld breaking the rules, by making simple hostnames resolve to addresses in the DNS, and thousands of companies wanting the rules re-written because they have purchased "." and want to be able to use "user at tm" reliably. Simple host names, as global identifiers, where phase out in the 1980's for good reasons. Those reasons are still relevant. Mark > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies > ", > Please consider the environment before reading this e-mail. http://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dougb at dougbarton.us Mon Jun 20 00:32:59 2011 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 19 Jun 2011 22:32:59 -0700 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <32105.1308537084@nsa.vix.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <32105.1308537084@nsa.vix.com> Message-ID: <4DFEDB8B.5080301@dougbarton.us> On 06/19/2011 19:31, Paul Vixie wrote: >> Date: Sun, 19 Jun 2011 19:22:46 -0700 >> From: Michael Thomas >> >>> that's a good question. marka mentioned writing an RFC, but i expect >>> that ICANN could also have an impact on this by having applicants sign >>> something that says "i know that my single-label top level domain name >>> will not be directly usable the way normal domain names are and i intend >>> to use it only to register subdomain names which will work normally." >> >> Isn't this problem self regulating? If sufficient things break with a >> single label, people will stop making themselves effectively unreachable, >> right? > > alas, no. if someone adds something to the internet that doesn't work right > but they ignore this and press onward until they have market share, then the > final disposition will be based on market size not on first mover advantage. I think you're going to see 2 primary use cases. Those who will do it anyway, either because they are ignorant of the possible downsides, or don't care. The other use case will be the highly risk-averse folks who won't unconditionally enable IPv6 on their web sites because it will cause problems for 1/2000 of their customers. If it will make $YOU (not nec. Paul or Michael) feel better, sure produce an RFC. Shout it from the housetops, whatever. You're not going to change anyone's mind. Meanwhile, David is right. Further pontificating on this topic without even reading the latest DAG is just useless nanog-chin-wagging. Completely aside from the fact that the assumption no one in the ICANN world has put any thought into this for the last 10+ years is sort of insulting. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From vixie at isc.org Mon Jun 20 00:47:24 2011 From: vixie at isc.org (Paul Vixie) Date: Mon, 20 Jun 2011 05:47:24 +0000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 22:32:59 MST." <4DFEDB8B.5080301@dougbarton.us> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <32105.1308537084@nsa.vix.com> <4DFEDB8B.5080301@dougbarton.us> Message-ID: <44655.1308548844@nsa.vix.com> > Date: Sun, 19 Jun 2011 22:32:59 -0700 > From: Doug Barton > > ... the highly risk-averse folks who won't unconditionally enable IPv6 > on their web sites because it will cause problems for 1/2000 of their > customers. let me just say that if i was making millions of dollars a day and i had the choice of reducing that by 1/2000th or not i would not choose to reduce it. as much as i love the free interchange of ideas i will point out that commerce is what's paid the internet's bills all these years. From dougb at dougbarton.us Mon Jun 20 00:57:34 2011 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 19 Jun 2011 22:57:34 -0700 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <44655.1308548844@nsa.vix.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <32105.1308537084@nsa.vix.com> <4DFEDB8B.5080301@dougbarton.us> <44655.1308548844@nsa.vix.com> Message-ID: <4DFEE14E.4070101@dougbarton.us> On 06/19/2011 22:47, Paul Vixie wrote: >> Date: Sun, 19 Jun 2011 22:32:59 -0700 >> From: Doug Barton >> >> ... the highly risk-averse folks who won't unconditionally enable IPv6 >> on their web sites because it will cause problems for 1/2000 of their >> customers. > > let me just say that if i was making millions of dollars a day and i had > the choice of reducing that by 1/2000th or not i would not choose to > reduce it. as much as i love the free interchange of ideas i will point > out that commerce is what's paid the internet's bills all these years. I wasn't using that as an example of them doing something wrong. I've spoken several places (including here on NANOG) in support of people doing what they need to do to meet their fiduciary responsibility to their stakeholders. My point was simply that there are 2 schools of thought on this issue, and both are so far out on the poles that meaningful changing of minds is next to impossible (and arguably, totally unnecessary). Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From mleber at he.net Mon Jun 20 01:38:02 2011 From: mleber at he.net (Mike Leber) Date: Sun, 19 Jun 2011 23:38:02 -0700 Subject: future revenue at risk vs near term cost ratio In-Reply-To: <44655.1308548844@nsa.vix.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <32105.1308537084@nsa.vix.com> <4DFEDB8B.5080301@dougbarton.us> <44655.1308548844@nsa.vix.com> Message-ID: <4DFEEACA.2070500@he.net> On 6/19/11 10:47 PM, Paul Vixie wrote: >> Date: Sun, 19 Jun 2011 22:32:59 -0700 >> From: Doug Barton >> >> ... the highly risk-averse folks who won't unconditionally enable IPv6 >> on their web sites because it will cause problems for 1/2000 of their >> customers. > let me just say that if i was making millions of dollars a day and i had > the choice of reducing that by 1/2000th or not i would not choose to > reduce it. as much as i love the free interchange of ideas i will point > out that commerce is what's paid the internet's bills all these years. Fortunately, 1/2000th was just the now proven false boogey man that people substituted as a placeholder for the unknown. Now that we've had World IPv6 Day, this has been clearly refuted. No, 1 out 2000 users did not get fatally broken due to deploying IPv6. That said, lets run with your revenue at risk theme... (well you did say you were severely concerned about that 1/2000th of your revenue!) What if the risk of you not enabling it was that at some later date you lose 1/10th of your revenue due to either competitive pressures or the inability to provide the next generation service customers want? (Or if you are a non profit, what if it meant that you can't service 10 percent of your user base in the way they want.) Assuming the company is a company that generates all of its revenue from the Internet, what if you were an investor with 1 billion invested in that company? What is the discounted future revenue at risk to near term cost ratio that you would tolerate due to not actively deploying IPv6? What would the lack of concrete progress in the form of real world deployment say about the company's prospects as a cutting edge technology company? (heh, time to diversify that portfolio?) (I know you actually are running IPv6, just posing these entertaining questions since you provided the opening.) Mike. ps. not expecting an answer since it's rhetorical and posed for fun. From dougb at dougbarton.us Mon Jun 20 02:00:23 2011 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 20 Jun 2011 00:00:23 -0700 Subject: future revenue at risk vs near term cost ratio In-Reply-To: <4DFEEACA.2070500@he.net> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <32105.1308537084@nsa.vix.com> <4DFEDB8B.5080301@dougbarton.us> <44655.1308548844@nsa.vix.com> <4DFEEACA.2070500@he.net> Message-ID: <4DFEF007.9080302@dougbarton.us> On 06/19/2011 23:38, Mike Leber wrote: > > > On 6/19/11 10:47 PM, Paul Vixie wrote: >>> Date: Sun, 19 Jun 2011 22:32:59 -0700 >>> From: Doug Barton >>> >>> ... the highly risk-averse folks who won't unconditionally enable IPv6 >>> on their web sites because it will cause problems for 1/2000 of their >>> customers. >> let me just say that if i was making millions of dollars a day and i had >> the choice of reducing that by 1/2000th or not i would not choose to >> reduce it. as much as i love the free interchange of ideas i will point >> out that commerce is what's paid the internet's bills all these years. > > Fortunately, 1/2000th was just the now proven false boogey man that > people substituted as a placeholder for the unknown. Actually the people using that number had hard facts to back it up, but that was all debated at length already, and I don't see any point going over it again. > What if the risk of you not enabling it was that at some later date you > lose 1/10th of your revenue due to either competitive pressures or the > inability to provide the next generation service customers want? (Or if > you are a non profit, what if it meant that you can't service 10 percent > of your user base in the way they want.) We've already been over this too: A) Users don't want "IPvanything," they want "the Internet." B) The date you propose is so far out in the future as to be not worth discussing at this point. My personal take on B is that long before we reach the tipping point you propose that the switch will have been flipped. I think W6D was a good step in the right direction, and I know that serious people are crunching the numbers from it and are overwhelmingly likely to make the right decisions going forward. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jaap at NLnetLabs.nl Mon Jun 20 02:39:59 2011 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Mon, 20 Jun 2011 09:39:59 +0200 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> Message-ID: <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> (Mark:) Which just means we need to write yet another RFC saying that resolvers shouldn't lookup simple host names in the DNS. Simple host names should be qualified against a search list. I don't see the problem. I'm happily running with a empty search list for the last 25 year or so. jaap From marka at isc.org Mon Jun 20 02:43:05 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 17:43:05 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Sun, 19 Jun 2011 22:32:59 MST." <4DFEDB8B.5080301@dougbarton.us> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <32105.1308537084@nsa.vix.com> <4DFEDB8B.5080301@dougbarton.us> Message-ID: <20110620074305.7645410EE739@drugs.dv.isc.org> In message <4DFEDB8B.5080301 at dougbarton.us>, Doug Barton writes: > On 06/19/2011 19:31, Paul Vixie wrote: > >> Date: Sun, 19 Jun 2011 19:22:46 -0700 > >> From: Michael Thomas > >> > >>> that's a good question. marka mentioned writing an RFC, but i expect > >>> that ICANN could also have an impact on this by having applicants sign > >>> something that says "i know that my single-label top level domain name > >>> will not be directly usable the way normal domain names are and i intend > >>> to use it only to register subdomain names which will work normally." > >> > >> Isn't this problem self regulating? If sufficient things break with a > >> single label, people will stop making themselves effectively unreachable, > >> right? > > > > alas, no. if someone adds something to the internet that doesn't work righ > t > > but they ignore this and press onward until they have market share, then th > e > > final disposition will be based on market size not on first mover advantage > . > > I think you're going to see 2 primary use cases. Those who will do it > anyway, either because they are ignorant of the possible downsides, or > don't care. The other use case will be the highly risk-averse folks who > won't unconditionally enable IPv6 on their web sites because it will > cause problems for 1/2000 of their customers. > > If it will make $YOU (not nec. Paul or Michael) feel better, sure > produce an RFC. Shout it from the housetops, whatever. You're not going > to change anyone's mind. > > Meanwhile, David is right. Further pontificating on this topic without > even reading the latest DAG is just useless nanog-chin-wagging. > Completely aside from the fact that the assumption no one in the ICANN > world has put any thought into this for the last 10+ years is sort of > insulting. > > > Doug > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ Where is the addition of address/mx records at the zone apex prohibited? B.T.W. Address and mx records are very common, just their *use* at the apex of a TLD is or should be uncommon. There is also no such thing as "in-bailiwick glue for the TLD???s DNS servers". The root zone contains glue for TLDs. No TLD zone contains glue for TLDs. The agreement explicitly outlaws the use of wildcard records. It would not have been hard to explicitly outlaw the addition of address and MX records at the zones apex. One can only think that the loose wording here was done to explictly allow address and MX records at the apex of a TLD. Mark 2.2.3.3 TLD Zone Contents ICANN receives a number of inquiries about use of various record types in a registry zone, as entities contemplate different business and technical models. Permissible zone contents for a TLD zone are: * Apex SOA record. * Apex NS records and in-bailiwick glue for the TLD???s DNS servers. * NS records and in-bailiwick glue for DNS servers of registered names in the TLD. * DS records for registered names in the TLD. * Records associated with signing the TLD zone (i.e., RRSIG, DNSKEY, NSEC, and NSEC3). An applicant wishing to place any other record types into its TLD zone should describe in detail its proposal in the registry services section of the application. This will be evaluated and could result in an extended evaluation to determine whether the service would create a risk of a meaningful adverse impact on security or stability of the DNS. Applicants should be aware that a service based on use of less-common DNS resource records in the TLD zone, even if approved in the registry services review, might not work as intended for all users due to lack of application support. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From warren at kumari.net Mon Jun 20 02:44:58 2011 From: warren at kumari.net (Warren Kumari) Date: Mon, 20 Jun 2011 02:44:58 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <13002116.636.1308357431779.JavaMail.root@benjamin.baylink.com> <23892D49-AD8A-4B16-B2A9-49D356CEC3AD@delong.com> Message-ID: On Jun 17, 2011, at 9:13 PM, David Conrad wrote: > On Jun 17, 2011, at 4:04 PM, Owen DeLong wrote: >> I really don't think that namespace issues are part of the role for the ASO AC. > > Why do you think there is an ASO? > >> This is clearly a problem for ICANN's disaster-ridden domain-name side, and not >> for the ASO/NRO side of things. > > Because there is clearly no inter-relation between domains and address and the > operation of the Internet. > >> Operationally, it's a horrible idea, but, >> most of us in layers 1-4 stopped paying much attention to the disasters happening >> at ICANN for DNS along time ago as we sort of came to believe that we didn't have >> enough money to bribe^h^h^h^h^hinfluence the right people in a sufficiently >> meaningful way to make our voices heard. > > Aren't you one of the folks who state that if you don't participate in PPML then > you have no reason to criticize ARIN policies? +1 -- If you haven't bothered to be involved, you have lost the right to kvetch? If enough operational folk had bothered to stay involved, ICANN would be more operational. Claiming that it is all driven by money is a cop out. Yes, it's very political, yes there are LOTS of lawyers and policy folk, yes the atmosphere is not fun, yes the registries and registrars are the big players (because they have bothered to play), but technical folk CAN and DO make a difference? Warren "serves on the SSAC" Kumari > > Regards, > -drc > > From marka at isc.org Mon Jun 20 03:25:00 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 18:25:00 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "Mon, 20 Jun 2011 09:39:59 +0200." <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> Message-ID: <20110620082501.0AC3210EEA33@drugs.dv.isc.org> In message <201106200739.p5K7dxHJ071146 at bartok.nlnetlabs.nl>, Jaap Akkerhuis wr ites: > > (Mark:) > Which just means we need to write yet another RFC saying that > resolvers shouldn't lookup simple host names in the DNS. Simple > host names should be qualified against a search list. > > I don't see the problem. I'm happily running with a empty search > list for the last 25 year or so. Which is your choice. Lots of others want search lists. I've seen requests for 20+ elements. > jaap > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tjc at ecs.soton.ac.uk Mon Jun 20 03:55:00 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 20 Jun 2011 09:55:00 +0100 Subject: future revenue at risk vs near term cost ratio In-Reply-To: <4DFEF007.9080302@dougbarton.us> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <32105.1308537084@nsa.vix.com> <4DFEDB8B.5080301@dougbarton.us> <44655.1308548844@nsa.vix.com> <4DFEEACA.2070500@he.net> <4DFEF007.9080302@dougbarton.us> <98B6AA34-3953-4A37-BFC2-CB8358AE6442@ecs.soton.ac.uk> Message-ID: On 20 Jun 2011, at 08:00, Doug Barton wrote: > On 06/19/2011 23:38, Mike Leber wrote: >> >> >> On 6/19/11 10:47 PM, Paul Vixie wrote: >>>> Date: Sun, 19 Jun 2011 22:32:59 -0700 >>>> From: Doug Barton >>>> >>>> ... the highly risk-averse folks who won't unconditionally enable IPv6 >>>> on their web sites because it will cause problems for 1/2000 of their >>>> customers. >>> let me just say that if i was making millions of dollars a day and i had >>> the choice of reducing that by 1/2000th or not i would not choose to >>> reduce it. as much as i love the free interchange of ideas i will point >>> out that commerce is what's paid the internet's bills all these years. >> >> Fortunately, 1/2000th was just the now proven false boogey man that >> people substituted as a placeholder for the unknown. > > Actually the people using that number had hard facts to back it up, but that was all debated at length already, and I don't see any point going over it again. Except that if there's new evidence showing the figure is lower, let's see it :) The measurements we have made show 0.07% over the past month or so, the figure being users who can access a site with an A record, but not one with an A and AAAA record. There are still corner case issues out there, but I suspect that that small percentage may well be down to users who don't update their OS or software. It would be very interesting to know the real causes. I would hope things like 3484-bis and happy eyeballs will help reduce these further. Tim From jaap at NLnetLabs.nl Mon Jun 20 04:51:48 2011 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Mon, 20 Jun 2011 11:51:48 +0200 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110620082501.0AC3210EEA33@drugs.dv.isc.org> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> <20110620082501.0AC3210EEA33@drugs.dv.isc.org> Message-ID: <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> Which is your choice. Lots of others want search lists. I've seen requests for 20+ elements. So they get what they ask for: Ambiguity in resolving the name space. jaap From marka at isc.org Mon Jun 20 05:14:53 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 20:14:53 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "Mon, 20 Jun 2011 11:51:48 +0200." <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> <20110620082501.0AC3210EEA33@drugs.dv.isc.org> <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> Message-ID: <20110620101453.6E4DB10EED57@drugs.dv.isc.org> In message <201106200951.p5K9pmsW051234 at bartok.nlnetlabs.nl>, Jaap Akkerhuis wr ites: > Which is your choice. Lots of others want search lists. I've seen > requests for 20+ elements. > > So they get what they ask for: Ambiguity in resolving the name space. > > jaap There is no ambiguity if tld operators don't unilaterally add address records causing simple hostnames to resolve. Simple hostnames as, global identifiers, were supposed to cease to work in 1984. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jaap at NLnetLabs.nl Mon Jun 20 05:34:35 2011 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Mon, 20 Jun 2011 12:34:35 +0200 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110620101453.6E4DB10EED57@drugs.dv.isc.org> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> <20110620082501.0AC3210EEA33@drugs.dv.isc.org> <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> <20110620101453.6E4DB10EED57@drugs.dv.isc.org> Message-ID: <201106201034.p5KAYZ2e008023@bartok.nlnetlabs.nl> Simple hostnames as, global identifiers, were supposed to cease to work in 1984. Can you point out where that is stated? jaap From marka at isc.org Mon Jun 20 05:43:41 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 20 Jun 2011 20:43:41 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "Mon, 20 Jun 2011 12:34:35 +0200." <201106201034.p5KAYZ2e008023@bartok.nlnetlabs.nl> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> <20110620082501.0AC3210EEA33@drugs.dv.isc.org> <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> <20110620101453.6E4DB10EED57@drugs.dv.isc.org> <201106201034.p5KAYZ2e008023@bartok.nlnetlabs.nl> Message-ID: <20110620104341.774DB10EF149@drugs.dv.isc.org> In message <201106201034.p5KAYZ2e008023 at bartok.nlnetlabs.nl>, Jaap Akkerhuis wr ites: > > > Simple hostnames as, global identifiers, were supposed to cease > to work in 1984. > > Can you point out where that is stated? > > jaap RFC 897. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From steverich.nanog at gmail.com Mon Jun 20 07:13:11 2011 From: steverich.nanog at gmail.com (Steve Richardson) Date: Mon, 20 Jun 2011 08:13:11 -0400 Subject: Address Assignment Question Message-ID: Hello NANOG, I work for a medium-sized ISP with our own ARIN assignments (several /18 and /19 netblocks) and I've got a question about a possibly dubious customer request. I know a lot of you have experience on a much grander scale than myself, so I'm looking for some good advice. We have a customer who, over the years, has amassed several small subnet assignments from us for their colo. They are an email marketer. They have requested these assignments in as many discontiguous netblocks as we can manage. They are now asking for more addresses (a /24s worth) in even more discontiguous blocks. What I'd like to know is whether there is a legitimate use for so many addresses in discontiguous networks besides spam? I am trying my best to give them the benefit of the doubt here, because they do work directly with Spamhaus to not be listed (I realize reasons on both sides why this could be) and searches on Google and spam newsgroups for their highest traffic email domains yield next to nothing, given the amount of email they say they send out. I strongly believe that their given justification for so many addresses is not a good one (many addresses on an MTA, off-chance one gets blocked, etc), especially now that IPv4 addresses are becoming more of a scarce resource. However, if they *are* legitimate, which certainly is possible, are discontiguous networks a common practice for even legit operators, as it's quite likely that even legit email marketers will end up being blocked because someone accidentally hit 'Spam' instead of 'Delete' in their AOL software? Thanks, steve Note: I hate spammers as much as anyone out there, but I *do* know that not everyone who sends out massive amounts of email is a spammer. While it's possible they don't deserve it, I'm trying to give my customer the benefit of the doubt. From bclark at spectraaccess.com Mon Jun 20 07:30:07 2011 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 20 Jun 2011 08:30:07 -0400 Subject: Address Assignment Question In-Reply-To: References: Message-ID: <4DFF3D4F.5010901@spectraaccess.com> On 06/20/2011 08:13 AM, Steve Richardson wrote: > What I'd like to know is whether there is a > legitimate use for so many addresses in discontiguous networks besides > spam? I am trying my best to give them the benefit of the doubt here, > because they do work directly with Spamhaus to not be listed (I realize > reasons on both sides why this could be) and searches on Google and spam > newsgroups for their highest traffic email domains yield next to nothing, > given the amount of email they say they send out. Well, not so sure I would worry about legit or not legit use...while ISP's are looked at being the police, legally law enforcement are the ones to pursue illegal use. But it sounds like you've done you're home work and they sound legit. Have them fill out an IP Justification form (as ARIN requires i) and go from there. I wouldn't worry about providing them the /24. Personally I would charge them for the /24 too, makes users think twice about the need for a block that large. Bret From jared at puck.nether.net Mon Jun 20 07:32:00 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 20 Jun 2011 08:32:00 -0400 Subject: Address Assignment Question In-Reply-To: <4DFF3D4F.5010901@spectraaccess.com> References: <4DFF3D4F.5010901@spectraaccess.com> Message-ID: <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> On Jun 20, 2011, at 8:30 AM, Bret Clark wrote: > Personally I would charge them for the /24 too, makes users think twice about the need for a block that large. I would also give them a /64 per lan (alt: broadcast domain) as well to allow them to start working with IPv6 for their email. - Jared From rs at seastrom.com Mon Jun 20 07:35:26 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 20 Jun 2011 08:35:26 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: (Randy Bush's message of "Sat, 18 Jun 2011 06:45:57 -0700") References: <22653040.608.1308347687356.JavaMail.root@benjamin.baylink.com> <27100748-F707-4B16-95C8-2895485FB6D1@virtualized.org> Message-ID: <86zklc7ka9.fsf@seastrom.com> Randy Bush writes: > what's new? how about the operational technical effects, like data from > modeling various resolvers' responses to a large root zone? I think the proper model is popular TLDs, perhaps the traditional gTLDs. As any (even former) decent sized TLD operator can tell you, both BIND and NSD are both quite functional for this, and there are also some proprietary authoritative nameservers out there that have excellet performance. Getting north of 100k queries/second answered authoritatively [*] from a single nameserver process on a single box (large zone, millions of records) is almost something one can do with an out of the box config. Things can get hairy with high update rates, so I'd encourage ICANN to dig in its heels about the 2x per day update rate, though even if they did it on demand, the $185k fee is probably sufficient to keep the number of delegations, and thus updates, down to a dull roar. An interesting question is what the load effects will be on the root. Inasmuch as the root operators (who can provide more detailed data themselves) send NXDOMAIN, REFUSED, or some SOL-semantically-similar response to 99%+ of the queries they get already, even a two order of magnitude lift on the number of legit queries will result in only a 2x lift in load on the roots. The operative question is "is two orders of magnitude a safe guess?". I don't have a good answer for that. The team over at ICANN has already likely thought this through in insane detail and I'm not saying anything new (to them anyway). Maybe they can speak to it. -r [*] to be pedantic, the AA flag is not set on the response to an NS query to a delegating nameserver. We'll call it authoritative anyway, since it is for the zone in which the delegation lives. :-P From fweimer at bfk.de Mon Jun 20 07:40:08 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 20 Jun 2011 12:40:08 +0000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <4DFE47F3.2040900@mistral.co.uk> (Adam Atkinson's message of "Sun, 19 Jun 2011 20:03:15 +0100") References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> Message-ID: <827h8gfzh3.fsf@mid.bfk.de> * Adam Atkinson: > It was a very long time ago, but I seem to recall being shown > http://dk, the home page of Denmark, some time in the mid 90s. > > Must I be recalling incorrectly? It must have been before 1996. Windows environments cannot resolve A/AAAA records for single-label domain names. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From rs at seastrom.com Mon Jun 20 07:41:51 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 20 Jun 2011 08:41:51 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110620021950.GF22897@hezmatt.org> (Matthew Palmer's message of "Mon, 20 Jun 2011 12:19:50 +1000") References: <21633.1308527099@nsa.vix.com> <8190112.768.1308529337430.JavaMail.root@benjamin.baylink.com> <20110620021950.GF22897@hezmatt.org> Message-ID: <86vcw07jzk.fsf@seastrom.com> Matthew Palmer writes: > And it only gets better from there... how many places have various "cutesy" > naming schemes that might include one or more trademarks (or whatever) that > someone might want as a TLD? As it happens, I have a set of routers that are named { craftsman, makita, dewalt, black-and-decker, jet } etc. A couple of notably small ones are named "dremel" and "proxxon". Likewise, our VM hosting machines are named after container shipping lines. Trademarks and candidates for dropping $185k on a TLD all. In my experience this sort of naming scheme is the rule rather than the exception. -r From steverich.nanog at gmail.com Mon Jun 20 07:44:04 2011 From: steverich.nanog at gmail.com (Steve Richardson) Date: Mon, 20 Jun 2011 08:44:04 -0400 Subject: Address Assignment Question In-Reply-To: <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> Message-ID: Hi, On Mon, Jun 20, 2011 at 8:32 AM, Jared Mauch wrote: > > On Jun 20, 2011, at 8:30 AM, Bret Clark wrote: > >> Personally I would charge them for the /24 too, makes users think twice about the need for a block that large. We do charge them for addresses already and cost doesn't come into play. We charge for assignments shorter than /28 to discourage IP hogs. > I would also give them a /64 per lan (alt: broadcast domain) as well to allow them to start working with IPv6 for their email. > > - Jared They have inquired about IPv6 already, but it's only gone so far as that. I would gladly give them a /64 and be done with it, but my concern is that they are going to want several /64 subnets for the same reason and I don't really *think* it's a legitimate reason. Bear in mind that "legitimate" in this context is referring to the justification itself, not their business model. Thanks, steve From jason at thebaughers.com Mon Jun 20 08:06:44 2011 From: jason at thebaughers.com (Jason Baugher) Date: Mon, 20 Jun 2011 08:06:44 -0500 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> Message-ID: <4DFF45E4.2050505@thebaughers.com> On 6/20/2011 7:44 AM, Steve Richardson wrote: > Hi, > > On Mon, Jun 20, 2011 at 8:32 AM, Jared Mauch wrote: >> On Jun 20, 2011, at 8:30 AM, Bret Clark wrote: >> >>> Personally I would charge them for the /24 too, makes users think twice about the need for a block that large. > We do charge them for addresses already and cost doesn't come into > play. We charge for assignments shorter than /28 to discourage IP > hogs. > >> I would also give them a /64 per lan (alt: broadcast domain) as well to allow them to start working with IPv6 for their email. >> >> - Jared > They have inquired about IPv6 already, but it's only gone so far as > that. I would gladly give them a /64 and be done with it, but my > concern is that they are going to want several /64 subnets for the > same reason and I don't really *think* it's a legitimate reason. Bear > in mind that "legitimate" in this context is referring to the > justification itself, not their business model. > > Thanks, > steve > Did everyone miss that the customer didn't request a /24, they requested a "/24s worth in even more dis-contiguous blocks". I can only think of one reason why a customer would specifically ask for that. They are concerned that they'll get blacklisted. They're hoping if they do, it will be a small block of many rather than one entire block. When customers make strange requests without giving a good explanation, I have to assume they're up to something. Jason From ops.lists at gmail.com Mon Jun 20 08:10:47 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 20 Jun 2011 18:40:47 +0530 Subject: Address Assignment Question In-Reply-To: References: Message-ID: That behavior is usually a warning sign of "snowshoe" bulk mailing, especially when coupled with randomly named domains / hostnames As for working directly with spamhaus .. did they specify how they do that? You might find http://www.spamhaus.org/news.lasso?article=641 worth reading On Mon, Jun 20, 2011 at 5:43 PM, Steve Richardson wrote: > > assignments from us for their colo. ?They are an email marketer. ?They have > requested these assignments in as many discontiguous netblocks as we can > manage. ?They are now asking for more addresses (a /24s worth) in even more > discontiguous blocks. ?What I'd like to know is whether there is a -- Suresh Ramasubramanian (ops.lists at gmail.com) From aftab.siddiqui at gmail.com Mon Jun 20 08:15:34 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Mon, 20 Jun 2011 18:15:34 +0500 Subject: Address Assignment Question In-Reply-To: <4DFF45E4.2050505@thebaughers.com> References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> Message-ID: Let them submit the IP justification form, I would like to read how spammers justify their IP usage and I would really like to see how RIR would take it. *Interetesting* Regards, Aftab A. Siddiqui On Mon, Jun 20, 2011 at 6:06 PM, Jason Baugher wrote: > On 6/20/2011 7:44 AM, Steve Richardson wrote: > >> Hi, >> >> On Mon, Jun 20, 2011 at 8:32 AM, Jared Mauch >> wrote: >> >>> On Jun 20, 2011, at 8:30 AM, Bret Clark wrote: >>> >>> Personally I would charge them for the /24 too, makes users think twice >>>> about the need for a block that large. >>>> >>> We do charge them for addresses already and cost doesn't come into >> play. We charge for assignments shorter than /28 to discourage IP >> hogs. >> >> I would also give them a /64 per lan (alt: broadcast domain) as well to >>> allow them to start working with IPv6 for their email. >>> >>> - Jared >>> >> They have inquired about IPv6 already, but it's only gone so far as >> that. I would gladly give them a /64 and be done with it, but my >> concern is that they are going to want several /64 subnets for the >> same reason and I don't really *think* it's a legitimate reason. Bear >> in mind that "legitimate" in this context is referring to the >> justification itself, not their business model. >> >> Thanks, >> steve >> >> Did everyone miss that the customer didn't request a /24, they requested > a "/24s worth in even more dis-contiguous blocks". I can only think of one > reason why a customer would specifically ask for that. They are concerned > that they'll get blacklisted. They're hoping if they do, it will be a small > block of many rather than one entire block. > > When customers make strange requests without giving a good explanation, I > have to assume they're up to something. > > Jason > > From bicknell at ufp.org Mon Jun 20 08:18:44 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 20 Jun 2011 06:18:44 -0700 Subject: Address Assignment Question In-Reply-To: <4DFF45E4.2050505@thebaughers.com> References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> Message-ID: <20110620131844.GA52390@ussenterprise.ufp.org> In a message written on Mon, Jun 20, 2011 at 08:06:44AM -0500, Jason Baugher wrote: > Did everyone miss that the customer didn't request a /24, they requested > a "/24s worth in even more dis-contiguous blocks". I can only think of > one reason why a customer would specifically ask for that. They are > concerned that they'll get blacklisted. They're hoping if they do, it > will be a small block of many rather than one entire block. +1 Almost every customer I've dealt with who requested such a thing eventually ended up having their contract terminated for spamming. Many of the RBL's chose to increase the size of their blocks to put more pressure on ISP's. So if you give them /29's in 10 different blocks they will block the /24 in each, then a /23 in each, and so on. Basically this becomes a quick way for you to get 100% of your address space blocked, and make the rest of your customers really unhappy. When the RBL's see you gave them a bunch of small blocks in different supernets they assume you are spammer friendly. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From aftab.siddiqui at gmail.com Mon Jun 20 08:20:42 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Mon, 20 Jun 2011 18:20:42 +0500 Subject: Address Assignment Question In-Reply-To: <4DFF3D4F.5010901@spectraaccess.com> References: <4DFF3D4F.5010901@spectraaccess.com> Message-ID: On Mon, Jun 20, 2011 at 5:30 PM, Bret Clark wrote: > On 06/20/2011 08:13 AM, Steve Richardson wrote: > >> What I'd like to know is whether there is a >> legitimate use for so many addresses in discontiguous networks besides >> spam? I am trying my best to give them the benefit of the doubt here, >> because they do work directly with Spamhaus to not be listed (I realize >> reasons on both sides why this could be) and searches on Google and spam >> newsgroups for their highest traffic email domains yield next to nothing, >> given the amount of email they say they send out. >> > Well, not so sure I would worry about legit or not legit use...while ISP's > are looked at being the police, legally law enforcement are the ones to > pursue illegal use. But it sounds like you've done you're home work and they > sound legit. Have them fill out an IP Justification form (as ARIN requires > i) and go from there. I wouldn't worry about providing them the /24. > Personally I would charge them for the /24 too, makes users think twice > about the need for a block that large. > Well its my responsbility (being an ISP) to know whether it is legit or not, because if it is legitimate than it will take My ASN to pollute the internet because I don't see if the customer has its own ASN. My reputation will be at stake because I failed to recognize the difference between policing or doing my business the right way.. Best Wishes, Aftab A. Siddiqui From steverich.nanog at gmail.com Mon Jun 20 08:26:30 2011 From: steverich.nanog at gmail.com (Steve Richardson) Date: Mon, 20 Jun 2011 09:26:30 -0400 Subject: Address Assignment Question In-Reply-To: <4DFF45E4.2050505@thebaughers.com> References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> Message-ID: Hi Jason, On Mon, Jun 20, 2011 at 9:06 AM, Jason Baugher wrote: > Did everyone miss that the customer didn't request a /24, they requested a > "/24s worth in even more dis-contiguous blocks". I can only think of one > reason why a customer would specifically ask for that. They are concerned > that they'll get blacklisted. They're hoping if they do, it will be a small > block of many rather than one entire block. > > When customers make strange requests without giving a good explanation, I > have to assume they're up to something. > > Jason They provided an explanation, describing how the IPs were going to be used. Yes, part of it does have to do with being blocked, which *definitely* concerns me. One thing they do say is that they need several IPs per block to assign to their MTAs to handle such a large amount of email (3 to 5 million per day). Being primarily focused on layers 1 through 4, I don't have an incredible amount of experience with high volume email server configuration, so I have no idea if they are feeding me a line of BS or not. My feeling is that (paraphrasing here) "we might get blocked occasionally" and "we need this many IPs on our MTAs because they can't handle the load" are *not* legitimate reasons for requesting so many addresses. Thanks, steve From john-nanog at johnpeach.com Mon Jun 20 08:33:41 2011 From: john-nanog at johnpeach.com (John Peach) Date: Mon, 20 Jun 2011 09:33:41 -0400 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> Message-ID: <20110620093341.61b50a76@jpeach-desktop.anbg.mssm.edu> On Mon, 20 Jun 2011 09:26:30 -0400 Steve Richardson wrote: > Hi Jason, > > On Mon, Jun 20, 2011 at 9:06 AM, Jason Baugher > wrote: > > Did everyone miss that the customer didn't request a /24, they > > requested a "/24s worth in even more dis-contiguous blocks". I can > > only think of one reason why a customer would specifically ask for > > that. They are concerned that they'll get blacklisted. They're > > hoping if they do, it will be a small block of many rather than one > > entire block. > > > > When customers make strange requests without giving a good > > explanation, I have to assume they're up to something. > > > > Jason > > They provided an explanation, describing how the IPs were going to be > used. Yes, part of it does have to do with being blocked, which > *definitely* concerns me. One thing they do say is that they need > several IPs per block to assign to their MTAs to handle such a large > amount of email (3 to 5 million per day). Being primarily focused on > layers 1 through 4, I don't have an incredible amount of experience > with high volume email server configuration, so I have no idea if they > are feeding me a line of BS or not. > > My feeling is that (paraphrasing here) "we might get blocked > occasionally" and "we need this many IPs on our MTAs because they > can't handle the load" are *not* legitimate reasons for requesting so > many addresses. If it helps you make your mind up, please give us the ranges you are going to give them and we'll pre-emptively block them..... From dot at dotat.at Mon Jun 20 08:38:19 2011 From: dot at dotat.at (Tony Finch) Date: Mon, 20 Jun 2011 14:38:19 +0100 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: <43B2CE52-B07E-48E8-9BBE-772B979F4316@delong.com> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> <20110618093144.46A6E10E6179@drugs.dv.isc.org> <43B2CE52-B07E-48E8-9BBE-772B979F4316@delong.com> Message-ID: <3DA28681-35CF-4A48-9840-AF5F8ED34957@dotat.at> On 18 Jun 2011, at 19:35, Owen DeLong wrote: > > Note, none of these came with glue. No, you used dig +trace which does not show the additional section. If they had not included glue then resolution would have failed. Tony. -- f.anthony.n.finch http://dotat.at/ From ghira at mistral.co.uk Mon Jun 20 08:48:12 2011 From: ghira at mistral.co.uk (Adam Atkinson) Date: Mon, 20 Jun 2011 14:48:12 +0100 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <827h8gfzh3.fsf@mid.bfk.de> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <827h8gfzh3.fsf@mid.bfk.de> Message-ID: <4DFF4F9C.2060106@mistral.co.uk> Florian Weimer wrote: >> It was a very long time ago, but I seem to recall being shown >> http://dk, the home page of Denmark, some time in the mid 90s. >> >> Must I be recalling incorrectly? > > It must have been before 1996. Windows environments cannot resolve > A/AAAA records for single-label domain names. This would have been May 1995 at the latest. And I don't recall the OS being used at the time. Some flavour of Unix, Windows or MacOS (or "System 7" or whatever it was called at the time) or possibly even an Amiga. From Valdis.Kletnieks at vt.edu Mon Jun 20 08:52:56 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 20 Jun 2011 09:52:56 -0400 Subject: Address Assignment Question In-Reply-To: Your message of "Mon, 20 Jun 2011 09:26:30 EDT." References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> Message-ID: <150620.1308577976@turing-police.cc.vt.edu> On Mon, 20 Jun 2011 09:26:30 EDT, Steve Richardson said: > *definitely* concerns me. One thing they do say is that they need > several IPs per block to assign to their MTAs to handle such a large > amount of email (3 to 5 million per day). Being primarily focused on > layers 1 through 4, I don't have an incredible amount of experience > with high volume email server configuration, so I have no idea if they > are feeding me a line of BS or not. It's BS. 5M a day is only about 60 per second, not at all a problem for a single IP address running properly configured SMTP software. For comparison, in the mid-90s, I was moving 1M RCPT TO's a day (and probably half that number of envelopes) on a Listserv host using Sendmail on an IBM RS6000-220 - a whole whopping 66MZ Power 604E processor and something like 64M of RAM (The same basic firepower as an old Apple 6600 Mac, if you remember them...) Doing 10M messages a day on a single box is *easy* these days - the hardest part is getting a disk subsystem that survives all the fsync() beating most MTAs like to dish out.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jlewis at lewis.org Mon Jun 20 09:10:10 2011 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 20 Jun 2011 10:10:10 -0400 (EDT) Subject: Address Assignment Question In-Reply-To: References: Message-ID: On Mon, 20 Jun 2011, Steve Richardson wrote: > We have a customer who, over the years, has amassed several small subnet > assignments from us for their colo. They are an email marketer. They have > requested these assignments in as many discontiguous netblocks as we can > manage. They are now asking for more addresses (a /24s worth) in even more > discontiguous blocks. What I'd like to know is whether there is a > legitimate use for so many addresses in discontiguous networks besides > spam? The most common uses for such IP assignments are SEO and snowshoe spamming. It may seem a crazy idea, but have you asked them why they need a bunch of subnets from as many different /24s as possible rather than just a /24? What was their justification for the /24 (regardless of contiguity)? > IPv4 addresses are becoming more of a scarce resource. However, if they > *are* legitimate, which certainly is possible, are discontiguous networks a > common practice for even legit operators, as it's quite likely that even > legit email marketers will end up being blocked because someone accidentally > hit 'Spam' instead of 'Delete' in their AOL software? No...and I'd say asking for that is a gamble which suggests they're not legit. A legit mailer should have no objection (or even prefer) to have all their IPs contiguous, so as not to be mixed up with and confused for another customer (one that might be a worse spammer than they are). ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jerome at ceriz.fr Mon Jun 20 09:15:08 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Mon, 20 Jun 2011 16:15:08 +0200 Subject: Graphical representation of a v6 address space usage Message-ID: Hi ! I'm trying to put together some statistical data about the allocation status of a (rather large) IPv6 LIR range. I'm used to representing v4 address space using Hilbert curves, but it's not really optimal for IPv6 as the allocated space is too sparse, and the unitary allocations way too small to label them on the graphical representation. So I'm looking for "graphical representation best practices", such as an anamorphic scaling algorithm to draw a more readable map while still pointing out the vast amount of free space remaining with a non proportionnal surface. Did anyone see such a tool ? Thanks ! -- J?r?me Nicolle From dmiller at tiggee.com Mon Jun 20 09:17:21 2011 From: dmiller at tiggee.com (David Miller) Date: Mon, 20 Jun 2011 10:17:21 -0400 Subject: Address Assignment Question In-Reply-To: <150620.1308577976@turing-police.cc.vt.edu> References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <150620.1308577976@turing-police.cc.vt.edu> Message-ID: <4DFF5671.9060902@tiggee.com> On 6/20/2011 9:52 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 20 Jun 2011 09:26:30 EDT, Steve Richardson said: > >> *definitely* concerns me. One thing they do say is that they need >> several IPs per block to assign to their MTAs to handle such a large >> amount of email (3 to 5 million per day). Being primarily focused on >> layers 1 through 4, I don't have an incredible amount of experience >> with high volume email server configuration, so I have no idea if they >> are feeding me a line of BS or not. > It's BS. 5M a day is only about 60 per second, not at all a problem for a > single IP address running properly configured SMTP software. > > For comparison, in the mid-90s, I was moving 1M RCPT TO's a day (and probably > half that number of envelopes) on a Listserv host using Sendmail on an IBM > RS6000-220 - a whole whopping 66MZ Power 604E processor and something like 64M > of RAM (The same basic firepower as an old Apple 6600 Mac, if you remember > them...) Doing 10M messages a day on a single box is *easy* these days - the > hardest part is getting a disk subsystem that survives all the fsync() beating > most MTAs like to dish out.... > Well... 10M messages per day on a single box today would be fine for hardware power, if most messages are accepted remotely on the first try, but not necessarily doable in the SMTP environment of today. Mail servers that send a lot of email have to hold a lot higher percentage of messages in queue for longer today due to greylisting and other deferrals - particularly from freemail sites. Your customer should only need X addresses per block for SMTP load sharing if they are going to have X number of physical servers. If they are not going to have that many physical servers, then multiple addresses in the same block per server provides no additional throughput and could only be for block avoidance. SMTP servers do most of their work managing mail queues - accepting new messages into queue, keeping track of messages in flight (those that failed and need to be retried), spoon feeding messages out to broken MTAs, etc... more IPs per box doesn't help this. Someone who expects to be "blocked occasionally" would only need two (or a few...) address blocks. Someone who expects to be "blocked all the time" would need *many* different discontiguous address blocks. Are you getting spam complaints for their current blocks at an unreasonable (to you) rate? Are they doing all the right things with SPF, DK/DKIM (not an invitation for a holy war on whether or not these are good or useful)? If I put my tin foil hat on for a moment, I might suspect that your email marketer may be feeling the pinch of the economic downturn and might be considering implementing less scrupulous practices than they have followed in the past. Even with my tin foil hat blocking out external voices... most internal voices agree that this sounds spammy. -DMM From marka at isc.org Mon Jun 20 09:38:45 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2011 00:38:45 +1000 Subject: So... is it time to do IPv6 day monthy yet? In-Reply-To: Your message of "Mon, 20 Jun 2011 14:38:19 +0100." <3DA28681-35CF-4A48-9840-AF5F8ED34957@dotat.at> References: <24415722.168.1307544055966.JavaMail.root@benjamin.baylink.com> <4DEF9047.5090404@nac.net> <6EFFEFBAC68377459A2E972105C759EC03B2560D@EXVBE005-2.exch005intermedia.net> <20110618011115.0C0A010E3EE2@drugs.dv.isc.org> <20110618093144.46A6E10E6179@drugs.dv.isc.org> <43B2CE52-B07E-48E8-9BBE-772B979F4316@delong.com> <3DA28681-35CF-4A48-9840-AF5F8ED34957@dotat.at> Message-ID: <20110620143845.43D3E10F03A4@drugs.dv.isc.org> In message <3DA28681-35CF-4A48-9840-AF5F8ED34957 at dotat.at>, Tony Finch writes: > On 18 Jun 2011, at 19:35, Owen DeLong wrote: > >=20 > > Note, none of these came with glue. > > No, you used dig +trace which does not show the additional section. If they h > = > ad not included glue then resolution would have failed.=20 And if you want to see the glue use "dig +trace +all" or "dig +trace +additional". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bill at herrin.us Mon Jun 20 09:41:38 2011 From: bill at herrin.us (William Herrin) Date: Mon, 20 Jun 2011 10:41:38 -0400 Subject: Address Assignment Question In-Reply-To: References: Message-ID: On Mon, Jun 20, 2011 at 8:13 AM, Steve Richardson wrote: > We have a customer who, over the years, has amassed several small subnet > assignments from us for their colo. ?They are an email marketer. ?They have > requested these assignments in as many discontiguous netblocks as we can > manage. ?They are now asking for more addresses (a /24s worth) in even more > discontiguous blocks. ?What I'd like to know is whether there is a > legitimate use for so many addresses in discontiguous networks besides > spam? Hi Steve, Best case scenario: they're using lists from their customers who claimed they followed proper practices when building the lists but didn't... because nobody who farms out bulk email builds a list via "confirmed opt in" as expected by best practices. When one of the lists gets filtered, they want the others to be protected. Worst case scenario they are deliberately spamming and trying to hide under the radar by spreading it out. > I am trying my best to give them the benefit of the doubt here, > because they do work directly with Spamhaus to not be listed (I realize > reasons on both sides why this could be) and searches on Google and spam > newsgroups for their highest traffic email domains yield next to nothing, > given the amount of email they say they send out. Try tools like http://www.mxtoolbox.com/blacklists.aspx and http://www.anti-abuse.org/multi-rbl-check/ and run through their existing address space. When you're skirting the gray zone, Spamhaus is generally the last one to list you. Find out what the other RBLs think. > However, if they > *are* legitimate, which certainly is possible, are discontiguous networks a > common practice for even legit operators, as it's quite likely that even > legit email marketers will end up being blocked because someone accidentally > hit 'Spam' instead of 'Delete' in their AOL software? If this was a brand new customer, I'd say hell no: they're obviously a spammer. Since they've been with you for years and haven't tripped the filters yet, I wouldn't be inclined to send them packing. As a contingency to receiving the spread-out assignments, however, I would ask them to sign a document to the effect that they only use email lists built with confirmed opt-in with a stiff and escalating dollar penalty clause should your abuse department receive convincing and voluminous complaints that they didn't. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jlewis at lewis.org Mon Jun 20 09:52:11 2011 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 20 Jun 2011 10:52:11 -0400 (EDT) Subject: Cogent depeers ESnet In-Reply-To: References: <4DFD424F.6080300@foobar.org> Message-ID: On Sat, 18 Jun 2011, George B. wrote: > I suppose the moral of the story is: "never single-home to Cogent" The moral is multihome. It gets real old hearing people whine that they're losing $XXX,XXX.XX per hour, minute, whatever, when their internet access fails...but they spend some tiny fraction (like 1% or a lot less) of that per month on a single internet connection. If your business depends on internet connectivity, and that much $ is at stake, you're stupid if you don't have some redundancy. Nothing works all the time forever. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jcdill.lists at gmail.com Mon Jun 20 10:01:24 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 20 Jun 2011 08:01:24 -0700 Subject: Address Assignment Question In-Reply-To: <20110620131844.GA52390@ussenterprise.ufp.org> References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> Message-ID: <4DFF60C4.2020603@gmail.com> On 20/06/11 6:18 AM, Leo Bicknell wrote: > > Almost every customer I've dealt with who requested such a thing > eventually ended up having their contract terminated for spamming. I would use this answer in reply to the customer, and ask them to (specifically) justify their request for the discontiguous blocks. > Many of the RBL's chose to increase the size of their blocks to put > more pressure on ISP's. So if you give them /29's in 10 different > blocks they will block the /24 in each, then a /23 in each, and so > on. Basically this becomes a quick way for you to get 100% of your > address space blocked, and make the rest of your customers really > unhappy. When the RBL's see you gave them a bunch of small blocks > in different supernets they assume you are spammer friendly. And mention all of this as well. If you don't have a special fee you charge when you have to deal with cleaning up or recovering contaminated IPs, include one with this next allocation. Theory: Since their current userbase is not currently creating a spam problem, they are doing one of two things: 1) They are going after a more risky new userbase (e.g. looking at providing services for more spammy customers). 2) They are *concerned* about the possibility of accidentally acquiring a more risky new userbase, and proactively designing their network to have the least collateral damage (to themselves) if such a customer should appear on their network. This would be prudent, good business even. Except for how it prepares for a business shift to #1. The big risk it that they are going to try to sell you on theory #2 when their real business plan is theory #1. I would charge a significant extra fee for discontiguous address space, enough that you can afford to carefully assign the rest of the block to non-web-non-mail-server uses, to not put other customers at risk. jc From mpalmer at hezmatt.org Mon Jun 20 10:03:26 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Tue, 21 Jun 2011 01:03:26 +1000 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> Message-ID: <20110620150326.GK22897@hezmatt.org> On Mon, Jun 20, 2011 at 09:26:30AM -0400, Steve Richardson wrote: > Hi Jason, > > On Mon, Jun 20, 2011 at 9:06 AM, Jason Baugher wrote: > > Did everyone miss that the customer didn't request a /24, they requested a > > "/24s worth in even more dis-contiguous blocks". I can only think of one > > reason why a customer would specifically ask for that. They are concerned > > that they'll get blacklisted. They're hoping if they do, it will be a small > > block of many rather than one entire block. > > > > When customers make strange requests without giving a good explanation, I > > have to assume they're up to something. > > > > Jason > > They provided an explanation, describing how the IPs were going to be > used. Yes, part of it does have to do with being blocked, which > *definitely* concerns me. One thing they do say is that they need > several IPs per block to assign to their MTAs to handle such a large > amount of email (3 to 5 million per day). Being primarily focused on > layers 1 through 4, I don't have an incredible amount of experience > with high volume email server configuration, so I have no idea if they > are feeding me a line of BS or not. I've worked at a company that did managed services (including the pipe and address range) of a "legitimate" bulk mailer[1], and the logic provided to you is "legit", as far as it goes -- that is to say, what they're saying is probably why they really want the space (whether it's a legitimate justification for the allocation of IP space as per current policies is a different matter). Basically, what your customer wants is to evade big e-mail providers' anti-spam measures. From their perspective, of course, I'm sure they think they're doing the "right thing", and the people they're delivering to really, really want this e-mail, and it's just the nasty e-mail provider getting in the way. As I understand it, a common technique at these big providers is to have reputation for IP addresses by spamminess, as an element of the overall determination of whether a particular e-mail is spam. If an address doesn't have a reputation (yet), then it's rate limited, to limit the damage that a new spammer can do before the e-mail provider gets feedback (from users) about whether the e-mail they're getting is spam or not. This reputation score (presumably) extends to the /24 (and probably, to a lesser extent, the WHOIS block, but I'm not as confident about that bit). What makes me think you're being scammed is that, for all the troubles we had with our customer, they never needed more address space once they'd gotten a good reputation for their initial allocation. Maybe my customer just didn't grow as much as yours did, so their spamcannon didn't need any more barrels. Still, I'm led to believe that once an IP address has good reputation, it should be effectively unlimited, so if they need more addresses it's because the current ones don't have real good rep... > My feeling is that (paraphrasing here) "we might get blocked > occasionally" and "we need this many IPs on our MTAs because they > can't handle the load" are *not* legitimate reasons for requesting so > many addresses. You are correct; as far as I know ARIN doesn't take those as valid justifications if you need to go back to them for more space, so you can't either. At this point they've admitted to you that they're shitting on your good name, and setting you up for headaches down the line (dealing with complaints from people who don't like their spam, having to clean up the IP addresses they discard when they're useless (or they leave). In techie utopia, you'd be able to sting them a fairly hefty surety to cover the costs associated with cleaning up their shit -- and then tell them that the IP addresses they've already got are enough, and if they need more capacity, they should clean up the addresses they've got. In reality, though, unless you've got management with a far more cavalier attitude to revenue than mine did, they won't do anything to piss off a customer who is, in their eyes, quite the cash cow. I'm mildly surprised that you got to evaluate their address request to the degree you have; I predict that any attempts to actually deny them more space (let alone extract additional compensation for their destruction of your resources) will be overridden by management. - Matt [1] I use scare quotes because as far as I'm concerned, if your business model is based on sending lots of e-mail, sooner or later you're going to be sending spam because that's what makes you the money. If you didn't personally collect the addresses, you're in for a world of hurt, and if you don't know that, you don't deserve to be in the business of bulk e-mail, and if you do know that, then at best you're a spammer-by-proxy. -- Q: Why do Marxists only drink herbal tea? A: Because proper tea is theft. -- Chris Suslowicz, in the Monastery From bicknell at ufp.org Mon Jun 20 10:07:27 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 20 Jun 2011 08:07:27 -0700 Subject: Address Assignment Question In-Reply-To: <4DFF60C4.2020603@gmail.com> References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> <4DFF60C4.2020603@gmail.com> Message-ID: <20110620150727.GA57111@ussenterprise.ufp.org> In a message written on Mon, Jun 20, 2011 at 08:01:24AM -0700, JC Dill wrote: > I would use this answer in reply to the customer, and ask them to > (specifically) justify their request for the discontiguous blocks. Or, just don't offer it. Make them fit in one block, giving them 3 months to renumber into a single, larger block if necessary. It sends a strong message you're willing to give them all the space they need, but won't help them evade RBL's. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jerome at ceriz.fr Mon Jun 20 10:26:20 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Mon, 20 Jun 2011 17:26:20 +0200 Subject: Address Assignment Question In-Reply-To: <20110620150727.GA57111@ussenterprise.ufp.org> References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> <4DFF60C4.2020603@gmail.com> <20110620150727.GA57111@ussenterprise.ufp.org> Message-ID: 2011/6/20 Leo Bicknell : > In a message written on Mon, Jun 20, 2011 at 08:01:24AM -0700, JC Dill wrote: >> I would use this answer in reply to the customer, and ask them to >> (specifically) justify their request for the discontiguous blocks. That's like asking them to state the obvious... > Or, just don't offer it. ?Make them fit in one block, giving them > 3 months to renumber into a single, larger block if necessary. Well, forcing a periodic renumbering whenever adress gets freed and there's a potential agregation is a good thing. It should be stated in service agreements, IMHO. > It sends a strong message you're willing to give them all the space > they need, but won't help them evade RBL's. Unless many contiguous blocks are assigned as different objects : a RBL must NOT presume of one end-user's inetnum unless it has been cathed doing nasty things AND didn't comply to abuse@ requests. But most RBL managers are shitheads anyway, so help them evade, that'll be one more proof of spamhaus &co. uselessness and negative impact on the Internet's best practices. -- J?r?me Nicolle From drc at virtualized.org Mon Jun 20 10:42:51 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 20 Jun 2011 05:42:51 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110620101453.6E4DB10EED57@drugs.dv.isc.org> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> <20110620082501.0AC3210EEA33@drugs.dv.isc.org> <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> <20110620101453.6E4DB10EED57@drugs.dv.isc.org> Message-ID: <77733847-FBF7-460A-AD30-08DC42DC3E96@virtualized.org> On Jun 20, 2011, at 12:14 AM, Mark Andrews wrote: >> So they get what they ask for: Ambiguity in resolving the name space. > There is no ambiguity if tld operators don't unilaterally add address > records causing simple hostnames to resolve. EDU.COM. Regards, -drc From joly at punkcast.com Mon Jun 20 11:17:04 2011 From: joly at punkcast.com (Joly MacFie) Date: Mon, 20 Jun 2011 12:17:04 -0400 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <2055EEA1-9C80-47BF-9ADE-D86D14993698@virtualized.org> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <2055EEA1-9C80-47BF-9ADE-D86D14993698@virtualized.org> Message-ID: Another avenue could be At-Large. The North American Regional At-Large Organization (NARALO) - uniquely amongst the RALO's - accepts individual members. http://naralo.org j On Sun, Jun 19, 2011 at 10:26 PM, David Conrad wrote: > > Well, yes, ICANN could have contracted parties (e.g., the new gTLDs) do > this. A bit late to get it into the Applicant's Guidebook, but maybe > something could be slipped in after the fact. Who is going to lead the > contingent from NANOG to raise this in the GNSO? > > Of course, changing existing contracts tends to be challenging since the > contracted parties have to agree to the changes and I wouldn't be surprised > if they demanded ICANN give something up in exchange for agreeing to this > new restriction. It'll probably take a while. > > ICANN can respectfully request ccTLD folks do the same, but whether or not > the ccTLDs listen is a separate matter. If the ccTLD folks feel they gain > benefit from having naked TLDs, they'll tell ICANN to take a hike. > > Not sure what will happen with the IDN ccTLDs since they appear to be sort > of a combination of ccTLDs and contracted parties. > > You probably know all this, but things in the ICANN world probably don't > work the way most folks think. > > Regards, > -drc > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From dot at dotat.at Mon Jun 20 11:22:42 2011 From: dot at dotat.at (Tony Finch) Date: Mon, 20 Jun 2011 17:22:42 +0100 Subject: ICANN to allow commercial gTLDs In-Reply-To: <8C7F9B57-2E82-4F80-BF77-60D05535B8E4@delong.com> References: <23505408.666.1308368211865.JavaMail.root@benjamin.baylink.com> <8C7F9B57-2E82-4F80-BF77-60D05535B8E4@delong.com> Message-ID: <66C867C8-ACE0-47E0-BD56-EEC5E9DDC4B3@dotat.at> On 18 Jun 2011, at 09:22, Owen DeLong wrote: > > In . lives a pointer to apple. consisting of one or more NS records and possibly some A/AAAA glue for those nameservers if they are within apple. Don't forget the DS records containing the hash of Apple's DNSSEC KSK. Tony. -- f.anthony.n.finch http://dotat.at/ From rps at maine.edu Mon Jun 20 11:36:26 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 20 Jun 2011 12:36:26 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> Message-ID: Technical issues aside (and there are many...) How long before we see marketing campaigns urging people to only trust ".band" and that ".com" et. al. are "less secure". With a $185,000 application fee this tends to really kill small businesses and conditions the public to favor ecommerce with the giants, not to mention a nice revenue boost for ICANN. Would love to hear the dirt on backroom conversations that led to this decision... Hopefully there will be enough public outcry to reverse it... but I'm not optimistic. On Fri, Jun 17, 2011 at 5:04 PM, Jay Ashworth wrote: > Aw, Jeezus. > > No. ?Just, no. > > ?http://tech.slashdot.org/story/11/06/17/202245/ > > Cjeers, > -- jra > -- > Jay R. Ashworth ? ? ? ? ? ? ? ? ?Baylink ? ? ? ? ? ? ? ? ? ? ? jra at baylink.com > Designer ? ? ? ? ? ? ? ? ? ? The Things I Think ? ? ? ? ? ? ? ? ? ? ? RFC 2100 > Ashworth & Associates ? ? http://baylink.pitas.com ? ? ? ? 2000 Land Rover DII > St Petersburg FL USA ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 727 647 1274 > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From cjp at 0x1.net Mon Jun 20 11:46:48 2011 From: cjp at 0x1.net (Christopher Pilkington) Date: Mon, 20 Jun 2011 12:46:48 -0400 Subject: Cogent depeers ESnet In-Reply-To: References: <4DFD424F.6080300@foobar.org> Message-ID: <-2211765233669277754@unknownmsgid> On Jun 20, 2011, at 10:53 AM, Jon Lewis wrote: > internet connectivity, and that much $ is at stake, you're stupid if you don't have some redundancy. Nothing works all the time forever. I can't consider Cogent even a redundant link, since I need two other upstreams to reach the Internet redundantly. -cjp From joly at punkcast.com Mon Jun 20 11:46:40 2011 From: joly at punkcast.com (Joly MacFie) Date: Mon, 20 Jun 2011 12:46:40 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> <60CD072E-8323-4CC0-A060-00A89990A0B2@virtualized.org> Message-ID: Two additional sticks for the fire: I haven't got around to reading the Jun 14 NTIA FNOI but in his talk at INET NY the same day Larry Strickling talked about a major review of the IANA functions contract, saying Based on the input of the global Internet community, we are proposing the > following changes in the IANA functions contract. First, we propose a > functional separation between DNS policy making wherever it occurs at ICANN > or elsewhere in the actual execution of tasks associated with the IANA > functions. > > Second, we propose enhanced transparency and accountability through the > development of documentation processes as well as performance standards and > metrics to establish service levels. > > Third, we propose that the contractor needs to include documentation that > demonstrates how proposed new top level domain strings have received > consensus support from relevant stakeholders and are supported by the > global > public interest. also, in the "whereas' section of the ICANN motion to approve the new gTLD program - there is language that would indicate that the Vertical Integration issue is far from settled. WHEREAS ICANN RECEIVED LETTERS FROM THE UNITED STATES DEPARTMENT OF > COMMERCE AND THE EUROPEAN COMMISSION ADDRESSING THE ISSUE OF > REGISTRY/REGISTRAR CROSS OWNERSHIP, AND THE BOARD CONSIDERED THE CONCERNS > EXPRESSED THEREIN. THE BOARD AGREES THAT THE POTENTIAL ABUSE OF SIGNIFICANT > MARKET POWER IS A SERIOUS CONCERN, AND DISCUSSIONS WITH COMPETITION > AUTHORITIES WILL CONTINUE. j -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From bonomi at mail.r-bonomi.com Mon Jun 20 12:04:40 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 20 Jun 2011 12:04:40 -0500 (CDT) Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620051449.8B94710EDC64@drugs.dv.isc.org> Message-ID: <201106201704.p5KH4eg9042045@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Mon Jun 20 00:15:32 2011 > To: David Conrad > From: Mark Andrews > Subject: Re: unqualified domains, was ICANN to allow commercial gTLDs > Date: Mon, 20 Jun 2011 15:14:49 +1000 > Cc: NANOG list > > > In message <83163718-FA5B-47BA-BA50-67701ABD5601 at virtualized.org>, David > Conrad > writes: > > On Jun 19, 2011, at 6:39 PM, Mark Andrews wrote: > > > I'm curious how anyone that has not signed a agreement with ICANN can > > > be bound to anything in any applicant guide book. =20 > > > > In order to obtain a gTLD, you have to sign a contractual agreement > > with = ICANN. > > David, you are missing the point. The TM holder doesn't want the gtld, > they just want to protect their trademark. The TM holder doesn't have a > contract with ICANN. They do however have a legitimate right to the name > and want to spend $0 keeping the name out of anybodys hands but theirs. > $187K is not longer a amount to be sneezed at. > > Mark > > > > Also rfp-clean-30may11-en.pdf basically deals with .. > > > > You might want to re-read pretty much any part of that document (e.g., > > = the title). > > > > Regards, > > -drc > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From georgeb at gmail.com Mon Jun 20 12:09:17 2011 From: georgeb at gmail.com (George B.) Date: Mon, 20 Jun 2011 10:09:17 -0700 Subject: Cogent depeers ESnet In-Reply-To: <-2211765233669277754@unknownmsgid> References: <4DFD424F.6080300@foobar.org> <-2211765233669277754@unknownmsgid> Message-ID: > >> internet connectivity, and that much $ is at stake, you're stupid if you don't have some redundancy. ?Nothing works all the time forever. > > I can't consider Cogent even a redundant link, since I need two other > upstreams to reach the Internet redundantly. > > -cjp > Well, they aren't someone you can take a default route from (either ipv4 or ipv6), that's for sure. So yeah, could use them if taking full routes. From sethm at rollernet.us Mon Jun 20 12:24:00 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 20 Jun 2011 10:24:00 -0700 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> Message-ID: <4DFF8230.6060105@rollernet.us> On 6/20/11 5:44 AM, Steve Richardson wrote: > > They have inquired about IPv6 already, but it's only gone so far as > that. I would gladly give them a /64 and be done with it, but my > concern is that they are going to want several /64 subnets for the > same reason and I don't really *think* it's a legitimate reason. Bear > in mind that "legitimate" in this context is referring to the > justification itself, not their business model. > Then just give them /64s randomly from under a single /48. ;) ~Seth From rps at maine.edu Mon Jun 20 12:28:46 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 20 Jun 2011 13:28:46 -0400 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110618013328.18875.qmail@joyce.lan> References: <20110618013328.18875.qmail@joyce.lan> Message-ID: Now that the cat is out of the bag, maybe we should look at trying to get people to make use of FQDN's more. I just added a rewrite to my person site to give it a try, and threw a quick note up about it: http://soucy.org./whydot.php So far, it looks like every browser correctly respects the use of a FQDN; though it looks like SSL is completely broken by it. The solution there is either to generate certificates with the correct FQDN CN, or to make browsers assume that every CN is a FQDN (better option IMHO). To be honest, I think we've all been a little lazy leaving off the last dot and are just annoyed now that it's going to cause a potential problem. On Fri, Jun 17, 2011 at 9:33 PM, John Levine wrote: >>The notion of a single-component FQDN ?would be quite a breakage for >>the basic concept of using both FQDNs and Unqualified names. > > Well, you know, there's a guy whose email address has been n at ai for > many years. ?People have varying amounts of success sending him mail. > > R's, > John > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From dot at dotat.at Mon Jun 20 12:28:40 2011 From: dot at dotat.at (Tony Finch) Date: Mon, 20 Jun 2011 18:28:40 +0100 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <27712.1308533070@nsa.vix.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> Message-ID: <868F401A-778F-48CC-821A-FC47474D1035@dotat.at> On 20 Jun 2011, at 02:24, Paul Vixie wrote: > > furthermore, the internet has more in it than just the web, and i know that > "foo at sony." will not have its RHS ("sony.") treated as a hierarchical name. Trailing dots are not permitted on mail domains. There has been an ongoing argument about the interaction between unqualified domains and TLDs in mail domains. RFC 2821 said single-label mail domains were syntax errors, but this was probably an editorial mistake and RFC 5321 permits them. It's probably safest to assume that a single-label mail domain is a local unqualified domain which will have its qualifying labels appended by the message submission server, and in other contexts all bets are off. Tony. -- f.anthony.n.finch http://dotat.at/ From jra at baylink.com Mon Jun 20 12:42:09 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 20 Jun 2011 13:42:09 -0400 (EDT) Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <868F401A-778F-48CC-821A-FC47474D1035@dotat.at> Message-ID: <32691592.860.1308591729763.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Tony Finch" > Trailing dots are not permitted on mail domains. I couldn't believe that, so I went and checked 5322. Tony's right: there is no way to write an email address which is deterministic, unless mail servers ignore the DNS search path. At least, that's what it sounds like to me. > There has been an ongoing argument about the interaction between > unqualified domains and TLDs in mail domains. RFC 2821 said > single-label mail domains were syntax errors, but this was probably an > editorial mistake and RFC 5321 permits them. It's probably safest to > assume that a single-label mail domain is a local unqualified domain > which will have its qualifying labels appended by the message > submission server, and in other contexts all bets are off. In fact what matters is what the processing rules and code of mail servers *do* with monocomponent RHSs. Do they try to apply the server's DNS search path to them? Or whatever's in their configs? Or do they just try to look them up in DNS, monocomponent. Cheers, -- jr 'Eric Allman, Wietse Venema, DJB; please pick up the courtesy phone' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From johnl at iecc.com Mon Jun 20 13:58:47 2011 From: johnl at iecc.com (John Levine) Date: 20 Jun 2011 18:58:47 -0000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <20110620185847.2204.qmail@joyce.lan> >How long before we see marketing campaigns urging people to only trust >".band" and that ".com" et. al. are "less secure". An interesting question. There was a group that was supposed to work on "high security TLDs". I suggested that to be usefully high security, the registry should make site visits to the registrants to verify their identity and processes, and charge accordingly, like $1000/yr or more. You could hear the sound of people reaching for their smelling salts. Shortly afterwards it was hijacked by marketers who came up with a laundry list of low value security features, nearly all of which any competent registry would do anyway, useful only as a gimmick to upsell registrants. Then they tried and failed to find someone competent yet cynical enough to administer the laundry list process, nobody was willing to do so, and the group collapsed. The motivation for HSTLD was fear that the banking industry might register their own .BANK with their own idea of high security, which might yet happen. R's, John From drc at virtualized.org Mon Jun 20 14:01:44 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 20 Jun 2011 09:01:44 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <86zklc7ka9.fsf@seastrom.com> References: <22653040.608.1308347687356.JavaMail.root@benjamin.baylink.com> <27100748-F707-4B16-95C8-2895485FB6D1@virtualized.org> <86zklc7ka9.fsf@seastrom.com> Message-ID: On Jun 20, 2011, at 2:35 AM, Robert E. Seastrom wrote: > Randy Bush writes: >> what's new? how about the operational technical effects, like data from >> modeling various resolvers' responses to a large root zone? Yep. That is an area that has been identified as needing additional study (see comments by kc, summarized in http://www.icann.org/en/topics/new-gtlds/summary-analysis-root-zone-scaling-impact-21feb11-en.pdf). > Things can get hairy with high update > rates, so I'd encourage ICANN to dig in its heels about the 2x per day > update rate I don't know anyone who is pushing to increase the update rate of the root zone. > An interesting question is what the load effects will be on the root. One of the studies relevant to this was done by DNS-OARC. See http://www.icann.org/en/topics/ssr/root-zone-augementation-analysis-17sep09-en.pdf. There was an intent to do some follow-on studies, but from ICANN's perspective the interesting scaling questions turned out to be related to the provisioning side, so focus moved away from impact on the root servers. Regards, -drc From gbonser at seven.com Mon Jun 20 14:04:17 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 20 Jun 2011 12:04:17 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0D633D76@RWC-EX1.corp.seven.com> > With a $185,000 application fee this tends to really kill small > businesses and conditions the public to favor ecommerce with the > giants, not to mention a nice revenue boost for ICANN. > > Would love to hear the dirt on backroom conversations that led to this > decision... > > Hopefully there will be enough public outcry to reverse it... but I'm > not optimistic. Looking at the array of other fees: Registry Services Review Fee - $50,000 Dispute Resolution Filing Fee - $1000 - $5000 per party per filing Community Priority Evaluation Fee - $10,000 It looks like this is a great opportunity for ICANN to staff up and boost salaries all around! I wish there were some other aspect of real estate where I could do something like this. Maybe my town could make a killing by deciding to name streets after famous brands for a low-low fee of only $185,000 plus annual fees ... per street. Maybe McDonalds and Burger King would bid up the price of the name of the main drag where they both have an outlet. Or maybe Sears would fight with Penney's over the name of the entrance road to the mall. Hmmm. The internet is pretty cool because "vital real estate" can be created out of thin air and it can apparently cost a fortune. From johnl at iecc.com Mon Jun 20 14:05:17 2011 From: johnl at iecc.com (John Levine) Date: 20 Jun 2011 19:05:17 -0000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110620104341.774DB10EF149@drugs.dv.isc.org> Message-ID: <20110620190517.2242.qmail@joyce.lan> >> Simple hostnames as, global identifiers, were supposed to cease >> to work in 1984. >> >> Can you point out where that is stated? >> >> jaap > >RFC 897. I see where it says that all of the hosts that existed in 1984 were supposed to change their names to something with at least two components, as part of the transition to the DNS. I think we can assume that process is now complete. I don't see where it says that new DNS names can't have a single component. A page and line reference would be helpful. R's, John From owen at delong.com Mon Jun 20 14:40:41 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Jun 2011 12:40:41 -0700 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <4DFEAEF6.70407@mtcc.com> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> Message-ID: <788DB34F-E943-4902-9644-EF82EDCBFD8C@delong.com> On Jun 19, 2011, at 7:22 PM, Michael Thomas wrote: > On 06/19/2011 07:08 PM, Paul Vixie wrote: >>> From: David Conrad >>> Date: Sun, 19 Jun 2011 16:04:09 -1000 >>> >>> On Jun 19, 2011, at 3:24 PM, Paul Vixie wrote: >>> >>> >>>> i think we have to just discourage lookups of single-token names, >>>> universally. >>>> >>> How? >>> >> that's a good question. marka mentioned writing an RFC, but i expect >> that ICANN could also have an impact on this by having applicants sign >> something that says "i know that my single-label top level domain name >> will not be directly usable the way normal domain names are and i intend >> to use it only to register subdomain names which will work normally." >> > > Isn't this problem self regulating? If sufficient things break > with a single label, people will stop making themselves > effectively unreachable, right? > > Mike I suspect that most of the entities in question will put both in to the DNS and the issues will persist. Owen From linux.yahoo at gmail.com Mon Jun 20 15:39:51 2011 From: linux.yahoo at gmail.com (Manu Chao) Date: Mon, 20 Jun 2011 22:39:51 +0200 Subject: VMware ESX LACP Support Message-ID: I would like to design VSS LACP based MECs with ESX hosts. Does VMware ESX support LACP? Do we need Nexus 1000 for ESX LACP support? R/ Manu From juicewvu at gmail.com Mon Jun 20 15:42:48 2011 From: juicewvu at gmail.com (Josh Smith) Date: Mon, 20 Jun 2011 16:42:48 -0400 Subject: VMware ESX LACP Support In-Reply-To: References: Message-ID: ESX does NOT support LACP out of the box. Not sure about the nexus 1kv. Thanks, Josh Smith KD8HRX email/jabber:? juicewvu at gmail.com phone:? 304.237.9369(c) On Mon, Jun 20, 2011 at 4:39 PM, Manu Chao wrote: > I would like to design VSS LACP based MECs with ESX hosts. > > Does VMware ESX support LACP? > > Do we need Nexus 1000 for ESX LACP support? > > R/ > Manu > From brunner at nic-naa.net Mon Jun 20 13:57:06 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Mon, 20 Jun 2011 14:57:06 -0400 Subject: ICANN to allow commercial gTLDs Message-ID: <201106201857.p5KIv65V060717@nic-naa.net> ray, > ... only trust ".band" and that ".com" et. al. are "less secure". "secure" is not a well-defined term. as the .com registry access model accepts credit card fraud risk, a hypothetical registry, say .giro, with wholesale registration at the same dollar price point but an access mechanism accepting less risk than credit card fraud would have less "insecure" registration events. as john levine pointed out, the hstld advisory group attempted to address a property of "zone file(s)." as a member of that advisory group i made public comments on the issues, technical and process, it encountered. > With a $185,000 application fee this tends to really kill small > businesses and conditions the public to favor ecommerce with the > giants, not to mention a nice revenue boost for ICANN. > > Would love to hear the dirt on backroom conversations that led to this > decision... a mainer has been invovled in policy development since, before there was an icann. a vermonter is on the current icann board. when looking for root causes, while the policy recommendation made by the policy development body did not restrict the implementation of the new gtld application process to a single event, staff adversity to law suit risk precluded distinguishing between types of applications based on policy -- say "high policy" applications like the original sponsored applications before "low policy" applications like the original standard applications -- and evaluating one type before the other. i suggest to you that institutional risk adversity (there exists a litigation history with the legacy monopoly operator) is the answer to questions of the form "wny one single, indivisible, wicked expensive, evaluation process for all?" > ... there will be enough public outcry to reverse it... but I'm > not optimistic. i would prefer "participation" over "outcry", and the act of "involvment" seems to be more on point than the mental state of being "optimistic", but milage always varies. on thursday there will be a text from the governmental, and the at large, advisory groups, on applicant support from developing economies. -e From dot at dotat.at Mon Jun 20 16:03:02 2011 From: dot at dotat.at (Tony Finch) Date: Mon, 20 Jun 2011 22:03:02 +0100 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620074305.7645410EE739@drugs.dv.isc.org> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <32105.1308537084@nsa.vix.com> <4DFEDB8B.5080301@dougbarton.us> <20110620074305.7645410EE739@drugs.dv.isc.org> Message-ID: <3DA313A7-911E-4439-9082-B50844338786@dotat.at> On 20 Jun 2011, at 08:43, Mark Andrews wrote: > > There is also no such thing as "in-bailiwick glue for the TLD?s DNS servers". The root zone contains glue for TLDs. No TLD zone contains glue for TLDs. "In-bailiwick" means that the nameservers for a zone are under the apex of that zone. So the uk TLD servers are in-bailiwick: they are all of the form nsX.nic.uk for various X. The com TLD servers are not in-bailiwick since they are all under gtld-servers.net; similarly the .aero servers are under .de, .ch, .info, .org. If a zone has in-bailiwick nameservers then it must have glue in the parent zone. It is possible for a TLD to have no glue of its own (like .com) if all of its nameservers are under other TLDs. It is possible for a TLD to have no glue at all if it shares no nameservers with any other TLD - so .com has glue (shared with .net) but the .aero nameservers are all under other TLDs and are different from those TLDs' servers, so it can work without glue. Tony. -- f.anthony.n.finch http://dotat.at/ From brunner at nic-naa.net Mon Jun 20 14:16:56 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Mon, 20 Jun 2011 15:16:56 -0400 Subject: unqualified domains, was ICANN to allow commercial gTLDs Message-ID: <201106201916.p5KJGuZE060820@nic-naa.net> > Another avenue could be At-Large. The North American Regional At-Large > Organization (NARALO) - uniquely amongst the RALO's - accepts individual > members. as the elected unaffiliated member representative (or "umr") i suppose i should point out that (a) yes, the structural feature of individual membership exists in the naralo, and (b) it is unique to this ralo, and (c) these members do elect an officer to the ralo leadership, in some cases by accliamation or apathy, depending upon point of view, and (d) redundently, i am that stuckee. points (c) and (d) are not terribly important to the issue of how any number of persons having no other "at large structure" (als) membership, say a local isoc chapter, may, if they choose, lobby for what they each, jointly or severally -- to express involvement as a liability -- think is in the public interest. i simply mention (c) and (d) for completeness. i do have a caveat to offer. when i switched from the contracted parties to the naralo mailing lists i found a "technical" working group and hoped right on over. i foud that its purpose was not to provide a venue for the technical evaluation of policy issues, such as the sanity of v6-uber-alles as a non-negotiable requirement for new registries located where there is no v6, but to educate others. at that point i hoped right out. i don't think "policy for dummies" is any more attractive than "tech for dumies" as process and competency models. > http://naralo.org as joly's comment implies, there's a link to click, and consequences in the form of works, not faith. -e From leigh.porter at ukbroadband.com Mon Jun 20 16:20:05 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 20 Jun 2011 21:20:05 +0000 Subject: VMware ESX LACP Support In-Reply-To: References: , Message-ID: <5C472E81-E14F-4CC5-8785-55BFCAC3080C@ukbroadband.com> Does not out of the box mean that there is an LACP 'fix' ? -- Leigh Porter On 20 Jun 2011, at 21:45, "Josh Smith" wrote: > ESX does NOT support LACP out of the box. Not sure about the nexus 1kv. > > > Thanks, > Josh Smith > KD8HRX > email/jabber: juicewvu at gmail.com > phone: 304.237.9369(c) > > > > > > On Mon, Jun 20, 2011 at 4:39 PM, Manu Chao wrote: >> I would like to design VSS LACP based MECs with ESX hosts. >> >> Does VMware ESX support LACP? >> >> Do we need Nexus 1000 for ESX LACP support? >> >> R/ >> Manu >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From marka at isc.org Mon Jun 20 16:19:24 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2011 07:19:24 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "Mon, 20 Jun 2011 05:42:51 -1000." <77733847-FBF7-460A-AD30-08DC42DC3E96@virtualized.org> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> <20110620082501.0AC3210EEA33@drugs.dv.isc.org> <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> <20110620101453.6E4DB10EED57@drugs.dv.isc.org> <77733847-FBF7-460A-AD30-08DC42DC3E96@virtualized.org> Message-ID: <20110620211924.8E30D10F0FCF@drugs.dv.isc.org> In message <77733847-FBF7-460A-AD30-08DC42DC3E96 at virtualized.org>, David Conrad writes: > On Jun 20, 2011, at 12:14 AM, Mark Andrews wrote: > >> So they get what they ask for: Ambiguity in resolving the name space. > > There is no ambiguity if tld operators don't unilaterally add address > > records causing simple hostnames to resolve. > > EDU.COM. See RFC 1535. Yes, a mistake was made implementing search lists. A RFC was issued to say don't do search lists this way. B.T.W. EDU.COM makes the point that TLD shouldn't make simple hostnames operational as doing so deliberately add ambiguity or do you want to issue a RFC that bans search lists? Mark > Regards, > -drc > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dot at dotat.at Mon Jun 20 16:24:16 2011 From: dot at dotat.at (Tony Finch) Date: Mon, 20 Jun 2011 22:24:16 +0100 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> <4DFF60C4.2020603@gmail.com> <20110620150727.GA57111@ussenterprise.ufp.org> Message-ID: On 20 Jun 2011, at 16:26, J?r?me Nicolle wrote: > > But most RBL managers are shitheads anyway, so help them evade, that'll be one more proof of spamhaus &co. uselessness and negative impact on the Internet's best practices. An organization that blocks 90% of spam with no false positives is incredibly useful. Tony. -- f.anthony.n.finch http://dotat.at/ From drc at virtualized.org Mon Jun 20 16:35:55 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 20 Jun 2011 11:35:55 -1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110620211924.8E30D10F0FCF@drugs.dv.isc.org> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> <20110620082501.0AC3210EEA33@drugs.dv.isc.org> <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> <20110620101453.6E4DB10EED57@drugs.dv.isc.org> <77733847-FBF7-460A-AD30-08DC42DC3E96@virtualized.org> <20110620211924.8E30D10F0FCF@drugs.dv.isc.org> Message-ID: On Jun 20, 2011, at 11:19 AM, Mark Andrews wrote: > do you want to issue a RFC that bans search lists? Personally, I think search lists are a mistake and don't use them. If you do use them, then you are accepting a certain amount of ambiguity. Naked TLDs will increase that ambiguity and would recommend against their use, however there is no Internet Police to enforce such things (ICANN certainly isn't since ccTLDs can do whatever they like). I have significant doubt that an RFC will magically solve this problem (for any value of "this"). Regards, -drc From dsparro at gmail.com Mon Jun 20 16:38:45 2011 From: dsparro at gmail.com (David Sparro) Date: Mon, 20 Jun 2011 17:38:45 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <20110618145556.46650.qmail@joyce.lan> Message-ID: <4DFFBDE5.3060606@gmail.com> On 6/18/2011 4:14 PM, John R. Levine wrote: > If the USG operators said "sorry, the DOJ anti-trust rules don't > allow us to serve a zone with .HONDA and .BACARDI", why would the > the pressure be on them rather than on ICANN? Nobody outside the > ICANN bubble cares about more TLDs. I think the most inclusive root zone will win. Nobody is going to complain to their ISP that the website http://civc.honda/ 'works.' On the other hand if http://farmville.facebook/ doesn't... > How do you propose to do that? The addresses of the roots are hard > wired into the config of a million DNS caches around the world. If > it came to a fight between ICANN and the root operators, it is hard > to see how ICANN could win. Yes, but that list will be replaced by the list found during the normal query resolution process. Therefore if one or two of the IP addresses get replaced on the ICANN list of roots, the outsiders will get marginalized. I think that you'd need quite a few root server operators to join you in your mutiny if you want to ensure victory. -- Dave From seth.mos at dds.nl Mon Jun 20 16:40:48 2011 From: seth.mos at dds.nl (Seth Mos) Date: Mon, 20 Jun 2011 23:40:48 +0200 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> <4DFF60C4.2020603@gmail.com> <20110620150727.GA57111@ussenterprise.ufp.org> Message-ID: Op 20 jun 2011, om 23:24 heeft Tony Finch het volgende geschreven: > On 20 Jun 2011, at 16:26, J?r?me Nicolle wrote: >> >> But most RBL managers are shitheads anyway, so help them evade, that'll be one more proof of spamhaus &co. uselessness and negative impact on the Internet's best practices. > > An organization that blocks 90% of spam with no false positives is incredibly useful. Using a greylisting system is equally effective without the black list part. My milter-greylist installation is aimed at allowing as much mail through as it can, instead of the other way around. Milter-greylist has a nice urlcheck feature and/or ldap verification for users. In my case it's a PHP script. If I can verify the IP to be inside a /22 of the MX records, www records or domain records that is sufficient to bypass the greylisting. The timers are also quite lenient. Just 15 minutes of wait is enough, of they are persistent if we've seen them before by domain. We get the email regardless and phone calls are rare, and I never run the risk of never getting the email. This has turned out to be a really effective way to allow normal email through without much delay. After just 2 days at work it's whitelisted over 75% of the active domains we do business with. We have about 17 domains and I know what the poster is asking, we've been emailing our customers before, subscribed customers none the less. We've had our share of blacklisting before. And we even sent the emails with unsubscribe links. But some of them will click the "report this as spam" link in their favourite mail agent as a means to unsubscribe. I mean, clicking a link is hard. The end result is that we end up on various block lists. It's a good thing that the email servers at large isps are often sensible enough to let the email through. Some of the smaller ones had rather odd draconian limits set. This makes the situation for all of us worse. Regards, Seth From marka at isc.org Mon Jun 20 16:45:41 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2011 07:45:41 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "20 Jun 2011 19:05:17 GMT." <20110620190517.2242.qmail@joyce.lan> References: <20110620190517.2242.qmail@joyce.lan> Message-ID: <20110620214541.3CEF510F118C@drugs.dv.isc.org> In message <20110620190517.2242.qmail at joyce.lan>, "John Levine" writes: > >> Simple hostnames as, global identifiers, were supposed to cease > >> to work in 1984. > >> > >> Can you point out where that is stated? > >> > >> jaap > > > >RFC 897. > > I see where it says that all of the hosts that existed in 1984 were > supposed to change their names to something with at least two > components, as part of the transition to the DNS. I think we can > assume that process is now complete. > > I don't see where it says that new DNS names can't have a single > component. A page and line reference would be helpful. Heirachical names have 2 or more labels or else they become simple names (one label). They are dis-joint sets. Then you hace RFC 1123 which explictly acknowledges the use of unqualified names. Simple names are indistingishable from unqualified names and unqualified names need to be qualified and the only syntaxically valid way to do that is to add a label. Although RFC-822 allows the local use of abbreviated domain names within a domain, the application of RFC-822 in Internet mail does not allow this. The intent is that an Internet host must not send an SMTP message header containing an abbreviated domain name in an address field. This allows the address fields of the header to be passed without alteration across the Internet, as required in Section 5.2.6. Then you have SUBMISSION, RFC 4409 section 4.2., Ensure All Domains Are Fully-Qualified. This allows simple names on input and says to qualify them. Or do you want more examples of where the use of simple names as global identifiers will cause things to break. Allowing or using address and MX records at the apex of a TLD is stupid, reckless behaviour. Configuring a TLD to behave as if it is a simple host names is stupid, reckless behaviour, i.e. be careful about which SRV records you add. Some are used with host names equivalents as suffixes and some arn't. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dmiller at tiggee.com Mon Jun 20 16:47:00 2011 From: dmiller at tiggee.com (David Miller) Date: Mon, 20 Jun 2011 17:47:00 -0400 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> <4DFF60C4.2020603@gmail.com> <20110620150727.GA57111@ussenterprise.ufp.org> Message-ID: <4DFFBFD4.50208@tiggee.com> On 6/20/2011 11:26 AM, J?r?me Nicolle wrote: > < SNIP /> > Unless many contiguous blocks are assigned as different objects : a > RBL must NOT presume of one end-user's inetnum unless it has been > cathed doing nasty things AND didn't comply to abuse@ requests. An RBL *can* do whatever an RBL wants to do. An RBL *can* block an entire allocation for whatever reason they chose including - a single spam message with no requests sent to abuse@ or any contact of any kind with the group allocated the space. The only "control" over an RBL is their desire to remain relevant by preserving an opinion of accuracy in the minds of end users. If end users believe that an RBL is no longer meeting their needs, then they will stop using that RBL. > But most RBL managers are shitheads anyway, so help them evade, > that'll be one more proof of spamhaus&co. uselessness and negative > impact on the Internet's best practices. > OK. I'll bite. What particular "internet best practices" are Spamhaus trampling on? -DMM From jerome at ceriz.fr Mon Jun 20 16:50:17 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Mon, 20 Jun 2011 23:50:17 +0200 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> <4DFF60C4.2020603@gmail.com> <20110620150727.GA57111@ussenterprise.ufp.org> Message-ID: 2011/6/20 Tony Finch : > An organization that blocks 90% of spam with no false positives is incredibly useful. Greylisting and reverse-DNS checks alone blocks 95-98% with no impact on mail sent from properly maintained mail servers. RBLs are only usefull for lazy mailadmins, and to save some network and CPU resources while avoiding greylisting and rDNS. But it implies you fully trust the RBL author, and some really ain't trustworthy. I'd rather loose some mails from poorly managed domains than rely on any external almighty authority, it looks to me like an incentive to consider SMTP administration seriously rather than using default settings from the package maintainer... -- J?r?me Nicolle From johnl at iecc.com Mon Jun 20 16:51:04 2011 From: johnl at iecc.com (John Levine) Date: 20 Jun 2011 21:51:04 -0000 Subject: Address Assignment Question In-Reply-To: Message-ID: <20110620215104.2575.qmail@joyce.lan> > My feeling is that (paraphrasing here) "we might get blocked > occasionally" and "we need this many IPs on our MTAs because they > can't handle the load" are *not* legitimate reasons for requesting > so many addresses. It is definitely not your job to help spammers evade blocking. If someone's blocking their mail, that's a message to stop sending it, not to try to sneak it in the back door. The valid scenarios for spreading out IPs are so rare (and generally involve guys with guns) that you can ignore them. Legitimate bulk senders want their IPs in a compact block so they can set up feedback loops from ISPs and stop sending mail that people don't want. As other people have noted, you can send vast amounts of mail from a small number of IPs, and anyone big enough to have a valid need for a lot of address space is also big enough that you have already heard of them. Friendly threat: around here, if we know that an ISP is hands out IP ranges for snowshoe spamming, we often block their entire address range preemptively to avoid the tedium of blocking it one little chunk at a time. R's, John From johnl at iecc.com Mon Jun 20 16:52:27 2011 From: johnl at iecc.com (John Levine) Date: 20 Jun 2011 21:52:27 -0000 Subject: Address Assignment Question In-Reply-To: Message-ID: <20110620215227.2594.qmail@joyce.lan> >They have inquired about IPv6 already, but it's only gone so far as >that. I would gladly give them a /64 and be done with it, but my >concern is that they are going to want several /64 subnets for the >same reason and I don't really *think* it's a legitimate reason. No legitimate mailer needs more than one /64 per physical network. Same reason. R's, John From johnl at iecc.com Mon Jun 20 16:55:10 2011 From: johnl at iecc.com (John Levine) Date: 20 Jun 2011 21:55:10 -0000 Subject: Address Assignment Question In-Reply-To: Message-ID: <20110620215510.2627.qmail@joyce.lan> > An organization that blocks 90% of spam with no false positives is >incredibly useful. >Using a greylisting system is equally effective without the black > list part. Hi. I'm the guy who wrote the CEAS paper on greylisting. Greylisting is useful, but anyone who thinks it's a substitute for DNSBLs has never run a large mail system. R's, John From jaap at NLnetLabs.nl Mon Jun 20 16:58:10 2011 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Mon, 20 Jun 2011 23:58:10 +0200 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110620211924.8E30D10F0FCF@drugs.dv.isc.org> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> <20110620082501.0AC3210EEA33@drugs.dv.isc.org> <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> <20110620101453.6E4DB10EED57@drugs.dv.isc.org> <77733847-FBF7-460A-AD30-08DC42DC3E96@virtualized.org> <20110620211924.8E30D10F0FCF@drugs.dv.isc.org> Message-ID: <201106202158.p5KLwAxW088140@bartok.nlnetlabs.nl> (Marka) See RFC 1535. Yes, a mistake was made implementing search lists. A RFC was issued to say don't do search lists this way. Which RFC? What way? It would be nice if you would say what you mean instead keep referring to things the reader has to guess. jaap From mysidia at gmail.com Mon Jun 20 17:01:27 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 20 Jun 2011 17:01:27 -0500 Subject: VMware ESX LACP Support In-Reply-To: References: Message-ID: On Mon, Jun 20, 2011 at 3:39 PM, Manu Chao wrote: > I would like to design VSS LACP based MECs with ESX hosts. > Does VMware ESX support LACP? No, ESX does not support the LACP protocol for control and negotiation of link aggregation. Should you want link aggregation, and the default load balancing operation of ESX does not meet requirements, it is possible to use a statically configured aggregation in non-negotiated ("on") state; or a third party solution. The standard way to load balance NICs in ESX, is to just plug in additional NICs to the same network, add the extra pNICs to the same vSwitch, and have all NICs in 'active' mode. The default operation is Load balancing based on Originating vSwitch port ID. That is, every time a new vNIC is connected to the vSwitch, it is assigned a port ID, which can be used to distribute outgoing traffic from the the vNICs among the pNICs, so individual VMs can be load balanced. > Do we need Nexus 1000 for ESX LACP support? The Nexus 1000v for ESX has LACP as a supported feature. The Nexus 1000v is one third party solution for VS link aggregation for Enterprise Plus ESX environments that use the VDS feature. VDS is a lot of complexity and expense to add, just to tick a "LACP Support" checkbox, however; if you don't also need its other features.... -- -JH From dholmes at mwdh2o.com Mon Jun 20 17:07:58 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 20 Jun 2011 15:07:58 -0700 Subject: VMware ESX LACP Support In-Reply-To: References: Message-ID: <922ACC42D498884AA02B3565688AF99531F58545FB@USEXMBS01.mwd.h2o> ESX does support link aggregation, if by that is meant more than one Ethernet switch-to-ESX bundle, acting as a single logical pipe, and with stacked TOR switch configurations the bundles Ethernet links can connect to different TOR switches for redundancy. Nexus 1000V is better for network visibility and management, though. -----Original Message----- From: Josh Smith [mailto:juicewvu at gmail.com] Sent: Monday, June 20, 2011 1:43 PM To: Manu Chao Cc: nanog at nanog.org Subject: Re: VMware ESX LACP Support ESX does NOT support LACP out of the box. Not sure about the nexus 1kv. Thanks, Josh Smith KD8HRX email/jabber: juicewvu at gmail.com phone: 304.237.9369(c) On Mon, Jun 20, 2011 at 4:39 PM, Manu Chao wrote: > I would like to design VSS LACP based MECs with ESX hosts. > > Does VMware ESX support LACP? > > Do we need Nexus 1000 for ESX LACP support? > > R/ > Manu > This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From seth.mos at dds.nl Mon Jun 20 17:08:34 2011 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 21 Jun 2011 00:08:34 +0200 Subject: Address Assignment Question In-Reply-To: <20110620215510.2627.qmail@joyce.lan> References: <20110620215510.2627.qmail@joyce.lan> Message-ID: <5DB6C4DB-C0EC-4B8F-9489-CECBC32E68B5@dds.nl> Op 20 jun 2011, om 23:55 heeft John Levine het volgende geschreven: >> An organization that blocks 90% of spam with no false positives is >> incredibly useful. > >> Using a greylisting system is equally effective without the black >> list part. > > Hi. I'm the guy who wrote the CEAS paper on greylisting. > > Greylisting is useful, but anyone who thinks it's a substitute for > DNSBLs has never run a large mail system. We use the black lists for scoring spam messages, but we never outright block messages. I was not implying that blacklists are not useful at all. I just see things in shades of grey over black and white. Of the 17 domains we have with roughly 250 users it does well enough. Regards, Seth From jerome at ceriz.fr Mon Jun 20 17:09:25 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 21 Jun 2011 00:09:25 +0200 Subject: Address Assignment Question In-Reply-To: <4DFFBFD4.50208@tiggee.com> References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> <4DFF60C4.2020603@gmail.com> <20110620150727.GA57111@ussenterprise.ufp.org> <4DFFBFD4.50208@tiggee.com> Message-ID: 2011/6/20 David Miller : > OK. ?I'll bite. ?What particular "internet best practices" are Spamhaus > trampling on? RBL's are often seen as an "easy solution" to a quite complex problem. Most mail administrators are relying on them so blindly that some may forget to evaluate an RBL's pertinence regarding their particular needs. Providing such an "easy" way to avoid learning how to provide your mail service definitely has a bad influence for the overall quality of mail services. That's a first negative impact : letting noobs think they can manage a mail server because "the magic RBLs seems to solve my major issue" without looking to further side-effects. Next in line, RBL managers don't even try to contact abuse@ or postmaster at . So mail admins can't use them as a way to improve their setups. Well, of course, it probably started with large corporation routing ther abuse at bigestrmailserviceonearth.com to /dev/null, but that's not the point : if you pretend to improve mail services, do it right : use abuse@ and postmaster@ before blacklisting (note : botnets sending from forged domains have to be considered differently of course, but the rDNS check often fits that part quite well). Last but not least, some RBLs are extorsion scams requiring one to pay to get it's inetnum removed from any blacklist. It might be just an incentive to help a non-profit charity cause, it still smells like a mafia-related scam to me. Let the RBLs' maintainers clean up their front doors before asking for any legitimacy. Right now, relying on them is either stupidity or lazyness. But if you can point me to any serious organisation providing a real value-added service maintained by real professionals, those who performs thorough checks _before_ putting a legitimaite mail server in a blacklist, then i'd enjoy benchmarking it on a test domain. Just let me doubt it'll be of any good regarding how efficients is a properly managed mail server with just a few tech tricks. -- J?r?me Nicolle 06 19 31 27 14 From jerome at ceriz.fr Mon Jun 20 17:16:22 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 21 Jun 2011 00:16:22 +0200 Subject: Address Assignment Question In-Reply-To: <20110620215510.2627.qmail@joyce.lan> References: <20110620215510.2627.qmail@joyce.lan> Message-ID: 2011/6/20 John Levine : > Hi. ?I'm the guy who wrote the CEAS paper on greylisting. URL ? > Greylisting is useful, but anyone who thinks it's a substitute for > DNSBLs has never run a large mail system. You're right, greylisting on a large system may not be efficient as it won't block everything and will eat-up quite a lot of system ressources. But it's a good start once basic protocol-checks have already eliminated the 80% amount of bullshit sent from botnets. My point is : combining server-side checks of different nature is often enough to avoid the use of RBLs and still provide a goode quality of service. It probably won't scale to comcast' or AOL' MXs but it's way better than relying on an external authority for your corporate or personnal mailserver. -- J?r?me Nicolle From jerome at ceriz.fr Mon Jun 20 17:18:57 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 21 Jun 2011 00:18:57 +0200 Subject: Address Assignment Question In-Reply-To: <5DB6C4DB-C0EC-4B8F-9489-CECBC32E68B5@dds.nl> References: <20110620215510.2627.qmail@joyce.lan> <5DB6C4DB-C0EC-4B8F-9489-CECBC32E68B5@dds.nl> Message-ID: Seth, 2011/6/21 Seth Mos : > We use the black lists for scoring spam messages, but we never outright block messages. I was not implying that blacklists are not useful at all. I just see things in shades of grey over black and white. Thanks for pointing this out : I was whining about amateurs using RBLs as a pre-processing hard filter. Using it with a scoring system isn't bad IMHO, depends on the weight you set to these rules. -- J?r?me Nicolle From johnl at iecc.com Mon Jun 20 17:20:18 2011 From: johnl at iecc.com (John R. Levine) Date: 20 Jun 2011 18:20:18 -0400 Subject: Address Assignment Question In-Reply-To: References: <20110620215510.2627.qmail@joyce.lan> Message-ID: >> Hi. ?I'm the guy who wrote the CEAS paper on greylisting. > > URL ? They don't have Google where you are, huh? http://www.ceas.cc/papers-2005/120.pdf > You're right, greylisting on a large system may not be efficient as it > won't block everything and will eat-up quite a lot of system > ressources. But it's a good start once basic protocol-checks have > already eliminated the 80% amount of bullshit sent from botnets. Most of us use DNSBLs like the CBL or Spamhaus XBL to catch the botnet mail. It's a lot easier to let them tune their protocol quirk checker than to do it myself. R's, John From dot at dotat.at Mon Jun 20 17:23:08 2011 From: dot at dotat.at (Tony Finch) Date: Mon, 20 Jun 2011 23:23:08 +0100 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> <4DFF60C4.2020603@gmail.com> <20110620150727.GA57111@ussenterprise.ufp.org> <4DFFBFD4.50208@tiggee.com> Message-ID: On 20 Jun 2011, at 23:09, J?r?me Nicolle wrote: > > But if you can point me to any serious organisation > providing a real value-added service maintained by real professionals, > those who performs thorough checks _before_ putting a legitimaite mail > server in a blacklist, then i'd enjoy benchmarking it on a test > domain. Spamhaus. And none of your complaints apply to them. Tony. -- f.anthony.n.finch http://dotat.at/ From jeroen at mompl.net Mon Jun 20 17:33:12 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 20 Jun 2011 15:33:12 -0700 Subject: ICANN to allow commercial gTLDs In-Reply-To: <4DFBCAA7.6000800@paulgraydon.co.uk> References: <16367643.606.1308345788311.JavaMail.root@benjamin.baylink.com> <4DFBCAA7.6000800@paulgraydon.co.uk> Message-ID: <4DFFCAA8.6070606@mompl.net> Paul Graydon wrote: > I've seen the stuff about adding a few extra TLDs, like XXX. I haven't > seen any references until now of them considering doing it on a > commercial basis. I don't mind new TLDs, but company ones are crazy > and going to lead to a confusing and messy internet. I don't know about you, but *I* really like to browse to http://google.google or https://yahoo.yahoo or http://microsoft.microsoft (or www.microsoft.microsoft, or www.com.microsoft, or...) instead of their .com equivalents. It makes perfect sense. Except I fear the extra characters transmitted may add to the global CO2 emmissions ;~C In addition, from TFA: ""We're advising people to buy their brands, park them and redirect visitors to their existing site, at the very least," says Hnarakis, whose more than 3,500 customers include Volvo, Lego and GlaxoSmithKline." I for one welcome the increased influx of money to registrars world wide and ICANN in particular. The more money goes to the "those who operate the c0re of the innernets" the more tools they have to improve it. Forward we go, never look back. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From johnl at iecc.com Mon Jun 20 17:36:18 2011 From: johnl at iecc.com (John Levine) Date: 20 Jun 2011 22:36:18 -0000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <20110620223618.2927.qmail@joyce.lan> >> do you want to issue a RFC that bans search lists? > >Personally, I think search lists are a mistake and don't use them. You're in good company. It's hard to find a modern mail system that allows abbreviated domain names in addresses. I just checked the mail at AOL, Yahoo, Gmail, and Hotmail, and the one at Tucows which is used by a lot of large corporate mail systems, and none of them will let you send a message to an address like foo at bar. Note that Yahoo and Hotmail each handle mail for many large ISPs. There's a lot of advice that made sense in 1989 which is irrelevant now. Programming around mail systems that rewrite partially qualified addresses is in that category. It may not be possible for people to send mail to addresses like n at ai, but that's a very different problem from it going to the wrong place. R's, John From bruns at 2mbit.com Mon Jun 20 17:55:20 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 20 Jun 2011 16:55:20 -0600 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> <4DFF60C4.2020603@gmail.com> <20110620150727.GA57111@ussenterprise.ufp.org> Message-ID: <4DFFCFD8.3030107@2mbit.com> On 6/20/11 9:26 AM, J?r?me Nicolle wrote: > But most RBL managers are shitheads anyway, so help them evade, > that'll be one more proof of spamhaus&co. uselessness and negative > impact on the Internet's best practices. I do believe in this one paragraph, we know who the real shithead is. Noted and filed away for future use. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From marka at isc.org Mon Jun 20 18:29:06 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2011 09:29:06 +1000 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: Your message of "Mon, 20 Jun 2011 22:03:02 +0100." <3DA313A7-911E-4439-9082-B50844338786@dotat.at> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <32105.1308537084@nsa.vix.com> <4DFEDB8B.5080301@dougbarton.us> <20110620074305.7645410EE739@drugs.dv.isc.org> <3DA313A7-911E-4439-9082-B50844338786@dotat.at> Message-ID: <20110620232906.36A3810F19E1@drugs.dv.isc.org> In message <3DA313A7-911E-4439-9082-B50844338786 at dotat.at>, Tony Finch writes: > On 20 Jun 2011, at 08:43, Mark Andrews wrote: > >=20 > > There is also no such thing as "in-bailiwick glue for the TLD=E2=80=99s DN= > S servers". The root zone contains glue for TLDs. No TLD zone contains glu= > e for TLDs. > > "In-bailiwick" means that the nameservers for a zone are under the apex of t= > hat zone. So the uk TLD servers are in-bailiwick: they are all of the form n= > sX.nic.uk for various X. The com TLD servers are not in-bailiwick since they= > are all under gtld-servers.net; similarly the .aero servers are under .de, . > = > ch, .info, .org. If a zone has in-bailiwick nameservers then it must have gl= > ue in the parent zone. It is possible for a TLD to have no glue of its own (= > like .com) if all of its nameservers are under other TLDs. It is possible fo= > r a TLD to have no glue at all if it shares no nameservers with any other TL= > D - so .com has glue (shared with .net) but the .aero nameservers are all un= > der other TLDs and are different from those TLDs' servers, so it can work wi= > thout glue. > > Tony. I will repeat my assertion. There is no such thing as glue records for the nameservers at the top of the zone within the zone itself be they in-baliwick or not. Glue records live in the parent zone and are there to avoid the catch 22 situation of needing the records to find the records. Now glue records which match the address records of the nameservers for the zone may still be needed but they are glue records for a delegated zone, not the zone's apex. One can add obsured address records for the zone's nameservers to the zone but they are not glue records and are not needed for operational purposes and will cause problems if loaded into old nameservers as they will incorrectly be returned as answers. Even some modern nameservers treat them incorrectly by returning them as additional data. All glue records are obsured records. Not all obsured records are glue records be they address records or otherwise. Obsured records can be of any type. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jmamodio at gmail.com Mon Jun 20 18:38:11 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 20 Jun 2011 18:38:11 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0D633D76@RWC-EX1.corp.seven.com> References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> <5A6D953473350C4B9995546AFE9939EE0D633D76@RWC-EX1.corp.seven.com> Message-ID: 185K is just the application few, the process includes some requirements to have a given amount of dough for operations in escrow, add what you need to pay attorneys, "experts" , lobbyists, and setup and staff a small corporation even if you plan to outsource part of the dayt-2-day operations to a back end operator, you can easy reach a $2M figure just to start playing on that level. And BTW, there is no guarantee you will get it, and that the NTIA will give green light to IANA to add it. And after the last pissing contest between the ICANN BoD and GAC, we still need to see how everything will play out. Yesterday's vote was just for the cameras, the program was approved long time ago, the staff just got the directive to start implementing, but there are still many holes in the process. All those part now the ICANN ecosystem are celebrating in fantastic parties while the developing world supposedly has to be happy because they reserved $2M (when the organization has at least a $70M/yr running budget) for assistance... The circus continues, Jon Postel watching from above the root zone ... My $185,000 - 184,998. Jorge From marka at isc.org Mon Jun 20 18:41:39 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2011 09:41:39 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "Mon, 20 Jun 2011 11:35:55 -1000." References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> <20110620082501.0AC3210EEA33@drugs.dv.isc.org> <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> <20110620101453.6E4DB10EED57@drugs.dv.isc.org> <77733847-FBF7-460A-AD30-08DC42DC3E96@virtualized.org> <20110620211924.8E30D10F0FCF@drugs.dv.isc.org> Message-ID: <20110620234139.6606C10F1AAD@drugs.dv.isc.org> In message , David Conrad writes: > On Jun 20, 2011, at 11:19 AM, Mark Andrews wrote: > > do you want to issue a RFC that bans search lists? > > Personally, I think search lists are a mistake and don't use them. If > you do use them, then you are accepting a certain amount of ambiguity. > Naked TLDs will increase that ambiguity and would recommend against > their use, however there is no Internet Police to enforce such things > (ICANN certainly isn't since ccTLDs can do whatever they like). I have > significant doubt that an RFC will magically solve this problem (for any > value of "this"). While there are no internet police, they are not supposed to exist and ICANN and the IAB can make statements to that effect. Similarly ICANN could direct Verisign to meet its RFC 1034 requirements by ensuring that regular checks of delegations be made to ensure they both sides of the zone cut are consistent and if not ensure that steps are take to make them constistent. ICANN and Verisign don't pick up the support cost caused by Verisign's and ultimately ICANN's failure to ensure these checks are done. The support costs falls to ISPs and nameserver vendors explaining that lookups are failing because the delegation in broken. Broken delegations that should have been caught and corrected by the regular checks. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Mon Jun 20 19:00:14 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2011 10:00:14 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "Mon, 20 Jun 2011 23:58:10 +0200." <201106202158.p5KLwAxW088140@bartok.nlnetlabs.nl> References: <93902.1308501586@nsa.vix.com> <26074296.726.1308502310904.JavaMail.root@benjamin.baylink.com> <21633.1308527099@nsa.vix.com> <20110620002124.2F4EB10EAB52@drugs.dv.isc.org> <201106200739.p5K7dxHJ071146@bartok.nlnetlabs.nl> <20110620082501.0AC3210EEA33@drugs.dv.isc.org> <201106200951.p5K9pmsW051234@bartok.nlnetlabs.nl> <20110620101453.6E4DB10EED57@drugs.dv.isc.org> <77733847-FBF7-460A-AD30-08DC42DC3E96@virtualized.org> <20110620211924.8E30D10F0FCF@drugs.dv.isc.org> <201106202158.p5KLwAxW088140@bartok.nlnetlabs.nl> Message-ID: <20110621000014.AAD6210F1B7B@drugs.dv.isc.org> In message <201106202158.p5KLwAxW088140 at bartok.nlnetlabs.nl>, Jaap Akkerhuis wr ites: > > (Marka) > See RFC 1535. Yes, a mistake was made implementing search lists. > A RFC was issued to say don't do search lists this way. > > Which RFC? What way? RFC 1535. A Security Problem and Proposed Correction With Widely Deployed DNS Software It had to do with how search lists are constructed and processed. A wildcard record for *.EDU.COM was added it broke communications from COM sites to EDU sites by creating a unexpected match. It is the unexpected match that is the problem not the wildcard though that made *lots* more unexpected matches. If you want the gory detail I can give them to you. It is the unexpected match that is the problem with simple hostnames as global identifiers. People expect global identifiers to work globally and simple hostnames can't in the presence of search lists as they produce unexpected matches. > It would be nice if you would say what you mean instead keep referring to > things the reader has to guess. > > jaap Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Mon Jun 20 19:09:12 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 21 Jun 2011 10:09:12 +1000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "20 Jun 2011 22:36:18 GMT." <20110620223618.2927.qmail@joyce.lan> References: <20110620223618.2927.qmail@joyce.lan> Message-ID: <20110621000912.1A43710F1C06@drugs.dv.isc.org> In message <20110620223618.2927.qmail at joyce.lan>, "John Levine" writes: > >> do you want to issue a RFC that bans search lists? > > > >Personally, I think search lists are a mistake and don't use them. > > You're in good company. It's hard to find a modern mail system that > allows abbreviated domain names in addresses. I just checked the mail > at AOL, Yahoo, Gmail, and Hotmail, and the one at Tucows which is used > by a lot of large corporate mail systems, and none of them will let > you send a message to an address like foo at bar. Note that Yahoo and > Hotmail each handle mail for many large ISPs. Abbreviated names make perfect sense within a company be they mail (submission), ssh or telnet or within the home. > There's a lot of advice that made sense in 1989 which is irrelevant > now. Programming around mail systems that rewrite partially qualified > addresses is in that category. It may not be possible for people to > send mail to addresses like n at ai, but that's a very different problem > from it going to the wrong place. > > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From brunner at nic-naa.net Mon Jun 20 17:21:24 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Mon, 20 Jun 2011 18:21:24 -0400 Subject: ICANN to allow commercial gTLDs Message-ID: <201106202221.p5KMLP8e061820@nic-naa.net> > 185K is just the application few, the process includes some > requirements to have a given amount of dough for operations in escrow, > add what you need to pay attorneys, "experts" > , lobbyists, and setup and staff a small corporation even if you plan > to outsource part of the dayt-2-day operations to a back end operator, > you can easy reach a $2M figure just to start playing on that level. correct that the $185k is just the application fee, and there is a schedule of additional fees which may be applicable, e.g., extended evaluation if the application fails some evaluation criteria, and objections should any party with standing pay a fee to file an objection, etc., the continuity cost is undefined and the subject of lengthy communication between primarily myself and icann staff on the tdg-legal mailing list, though a vendor also commented on an aspect of continuity there as well. opinions on what a dead registry has to do (necessary functions) while waiting to time out and go "poof" or find a new operator sought. clue, in units of business organizations, finance, human resources, leasing, (law) and consensus policy, existing and advocacy, and registry constituency issues (icann policy), and registry and registrar contractual (law) issues are useful. the if-outsource-then-2m back-of-an-bar-napkin figure may be beer dampened, as standard offers by platform operators offer revenue sharing (whether all are equally exploitive of applicants as eventual registry contract holders is a question of projection, expectation, and taste) terms, resulting in significantly lower initial cost-to-acquire outcomes. a data point is .cat, which started with two thousand euros as its total marketing budget, and what i personally consider reasonable commercial terms from one non-profit (platform operator) to another (registry contract holding foundation). another is .museum, which started on a desktop in a kitchen. comments critical of their post-initial investment outcome should, though rarely are, be informed by restrictions placed upon the respective access to registrants, a subject just commented upon recently by both the antitrust division of the department of justice, and the european commission. a counter-example of course is the public record of a 2000 round standard gtld applicant, which spent approximately $20m on its buildout, before down-sizing its head-count by approximately 100 in late 2001, and which ten years of operational art has obtained an approximately 4% market share of generic names. > Yesterday's vote was just for the cameras, the program was approved > long time ago, the staff just got the directive to start implementing, > but there are still many holes in the process. broadly true, though missing both the ongoing gac-board dynamic, and the senior leadership transition(s) as driving this particular date and place of announcement. > All those part now the ICANN ecosystem are celebrating in fantastic > parties while the developing world supposedly has to be happy because > they reserved $2M (when the organization has at least a $70M/yr > running budget) for assistance... this is still an area of active work, i was working on it ... yesterday and the day before, today, and tomorrow and the day after tomorrow ... there will be a gac+alac statement in about 24 hours from now on the subject of support for applicants meeting the qualifications contained in the mile stone 2 report of the joint application support working group. it is a matter of record that i contribute to the jas-wg, and that the alac formed a drafting team to work with the gac, and that i am one of the members of that drafting team. what i'd like to see is some "i can help" notes cluttering my inbox, or the list -- real soon now this is going to be blades or 1us in cages with 4 and 6 provisioning and cash and clue (see above). hell, the only reason i'm in singapore is that a high-status privacy-only issue advocacy guy quit and left a unit of travel support for re-allocation. i don't want to have to walk to senegal in three months time to finalize the forms of support available to applicants, and icann wasn't funding me, they were funding the guy who quit. -e From jmaslak at antelope.net Mon Jun 20 19:39:00 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Mon, 20 Jun 2011 18:39:00 -0600 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110620214541.3CEF510F118C@drugs.dv.isc.org> References: <20110620190517.2242.qmail@joyce.lan> <20110620214541.3CEF510F118C@drugs.dv.isc.org> Message-ID: <45FE4558-A38E-444E-AE52-6C140E3D8B2D@antelope.net> I wonder what sort of money .wpad would be worth... From jra at baylink.com Mon Jun 20 19:48:12 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 20 Jun 2011 20:48:12 -0400 (EDT) Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110621000912.1A43710F1C06@drugs.dv.isc.org> Message-ID: <24044893.900.1308617292433.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" > In message <20110620223618.2927.qmail at joyce.lan>, "John Levine" > writes: > > You're in good company. It's hard to find a modern mail system that > > allows abbreviated domain names in addresses. I just checked the > > mail at AOL, Yahoo, Gmail, and Hotmail, and the one at Tucows which is > > used by a lot of large corporate mail systems, and none of them will let > > you send a message to an address like foo at bar. Note that Yahoo and > > Hotmail each handle mail for many large ISPs. > > Abbreviated names make perfect sense within a company be they mail > (submission), ssh or telnet or within the home. And to take that rebuttal even further, I would suspect that username at division is a pretty common pattern in really large companies, in addition to colleges; I'm certain, for example, that USF has that pattern in its email addresses -- though whether it's mailers permit users to short cut addresses, I'm not sure. I'm sure we have some college email admins here, or on mailops; I'll ask over there and see. You would, clearly, have to be using the *internal* SMTP server, regardless of where you were sending from, in order to do that. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jerome at ceriz.fr Mon Jun 20 20:27:54 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 21 Jun 2011 03:27:54 +0200 Subject: Address Assignment Question In-Reply-To: References: <4DFF3D4F.5010901@spectraaccess.com> <71FE8C60-EB2E-4FE5-A8E0-8E602029F843@puck.nether.net> <4DFF45E4.2050505@thebaughers.com> <20110620131844.GA52390@ussenterprise.ufp.org> <4DFF60C4.2020603@gmail.com> <20110620150727.GA57111@ussenterprise.ufp.org> <4DFFBFD4.50208@tiggee.com> Message-ID: 2011/6/21 Tony Finch : > Spamhaus. And none of your complaints apply to them. Oh really ? So the blame is to throw at Google Docs administrators for beeing blacklisted (on the SBL, which should contain only "verified spam source", thus implying discussion with the service manager) ? And BTW, who is Spamhaus to claim any legitimacy about who can or can't register a domain ? (referal to the .at phishing campaign). Alright, those are probably exceptions, and _some_ lists may be usefull, but obviously noone can claim to have an efficient "zero false-positive" list. Blindly relying on those lists _will_ lead to false positives and are a comodity for mail server administrators that might lead to sloopy filtering and weaker control over their mail infrastructure. Also, such lists are _centralized_ systems that *might* (worst case scenario) be spotted for attacks. What would be your mail infrastructure load if you rely on a list that disapear overnight ? Yeah, right, anycasted DNS infrastructure, redundancy over 4 continents, that's fine for most of us ('til it fails). In my opinion, the use of RBLs as a first level filter for incoming mail, instead of greylisting, rDNS and strict protocol compliance (cluttered with some Exchange bug-compatibility perhaps), is less reliable, so it's against what I shall consider as a best practice. I hope that clarifies my point of view, and please excuse me for the previous insults, I just have a hard time reading "hey, my critical services are dependant of an external, centralized entity with no transparency and that's good for the Internet" without compulsive expressions including F. words. -- J?r?me Nicolle From smb at cs.columbia.edu Mon Jun 20 20:55:22 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 20 Jun 2011 21:55:22 -0400 Subject: Address Assignment Question In-Reply-To: <20110620215227.2594.qmail@joyce.lan> References: <20110620215227.2594.qmail@joyce.lan> Message-ID: On Jun 20, 2011, at 5:52 27PM, John Levine wrote: >> They have inquired about IPv6 already, but it's only gone so far as >> that. I would gladly give them a /64 and be done with it, but my >> concern is that they are going to want several /64 subnets for the >> same reason and I don't really *think* it's a legitimate reason. > > No legitimate mailer needs more than one /64 per physical network. > Same reason. > Note that the OP spoke of assigning them one /64, rather than one per physical net. I also note that ARIN, at least, suggests "/56 for small sites, those expected to need only a few subnets over the next 5 years", which would seem to include this site even without their justification. All they need -- or, I suspect, need to assert -- is to have multiple physical networks. They can claim a production net, a DMZ, a management net, a back-end net for their databases, a developer net, and no one would question an architecture like that.... --Steve Bellovin, https://www.cs.columbia.edu/~smb From johnl at iecc.com Mon Jun 20 21:22:45 2011 From: johnl at iecc.com (John R. Levine) Date: 20 Jun 2011 22:22:45 -0400 Subject: Address Assignment Question In-Reply-To: References: <20110620215227.2594.qmail@joyce.lan> Message-ID: > All they need -- or, I suspect, need to assert -- is to have > multiple physical networks. They can claim a production net, a DMZ, > a management net, a back-end net for their databases, a developer > net, and no one would question an architecture like that.... My impression is that this is about a client whose stuff is all hosted in a single data center. R's, John From smb at cs.columbia.edu Mon Jun 20 21:32:31 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 20 Jun 2011 22:32:31 -0400 Subject: Address Assignment Question In-Reply-To: References: <20110620215227.2594.qmail@joyce.lan> Message-ID: <40BD8E3E-B46B-43BA-913B-C0EDC7E72647@cs.columbia.edu> On Jun 20, 2011, at 10:22 45PM, John R. Levine wrote: >> All they need -- or, I suspect, need to assert -- is to have >> multiple physical networks. They can claim a production net, a DMZ, >> a management net, a back-end net for their databases, a developer >> net, and no one would question an architecture like that.... > > My impression is that this is about a client whose stuff is all hosted in a single data center. > Then take out the developer net (or make it a VPN) but the rest remains. --Steve Bellovin, https://www.cs.columbia.edu/~smb From joly at punkcast.com Tue Jun 21 00:23:55 2011 From: joly at punkcast.com (Joly MacFie) Date: Tue, 21 Jun 2011 01:23:55 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: <201106202221.p5KMLP8e061820@nic-naa.net> References: <201106202221.p5KMLP8e061820@nic-naa.net> Message-ID: And you are to be complimented on your diligence in this respect, Eric. On Mon, Jun 20, 2011 at 6:21 PM, wrote: > > this is still an area of active work, i was working on it ... yesterday > and the day before, today, and tomorrow and the day after tomorrow ... > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From dot at dotat.at Tue Jun 21 05:14:30 2011 From: dot at dotat.at (Tony Finch) Date: Tue, 21 Jun 2011 11:14:30 +0100 Subject: unqualified domains, was ICANN to allow commercial gTLDs In-Reply-To: <20110620232906.36A3810F19E1@drugs.dv.isc.org> References: <20110618013328.18875.qmail@joyce.lan> <1905522.656.1308361667262.JavaMail.root@benjamin.baylink.com> <4DFE47F3.2040900@mistral.co.uk> <20110620000845.F01AE10EAA6B@drugs.dv.isc.org> <27712.1308533070@nsa.vix.com> <1641C545-C7B7-4827-843E-1C748342082D@virtualized.org> <30657.1308535698@nsa.vix.com> <4DFEAEF6.70407@mtcc.com> <32105.1308537084@nsa.vix.com> <4DFEDB8B.5080301@dougbarton.us> <20110620074305.7645410EE739@drugs.dv.isc.org> <3DA313A7-911E-4439-9082-B50844338786@dotat.at> <20110620232906.36A3810F19E1@drugs.dv.isc.org> Message-ID: <734770AF-335A-467D-8448-EF7308A6FED6@dotat.at> On 21 Jun 2011, at 00:29, Mark Andrews wrote: > > I will repeat my assertion. There is no such thing as glue records > for the nameservers at the top of the zone within the zone itself > be they in-baliwick or not. Glue records live in the parent zone > and are there to avoid the catch 22 situation of needing the records > to find the records. I understand "in-bailiwick" to be a property of the name of a nameserver, independent of whether you are looking at the glue or authoritative NS RRs - it is not the same as "in-zone". In-bailiwick nameservers must have glue. But you said ''There is also no such thing as 'in-bailiwick glue for the TLD's DNS servers'.'' I think you are arguing about the meaning and location of glue, whereas I am arguing about the meaning of "in-bailiwick". Tony. -- f.anthony.n.finch http://dotat.at/ From steverich.nanog at gmail.com Tue Jun 21 06:16:41 2011 From: steverich.nanog at gmail.com (Steve Richardson) Date: Tue, 21 Jun 2011 07:16:41 -0400 Subject: Address Assignment Question In-Reply-To: <20110620215227.2594.qmail@joyce.lan> References: <20110620215227.2594.qmail@joyce.lan> Message-ID: Meant to send this to the list. On Mon, Jun 20, 2011 at 5:52 PM, John Levine wrote: >>They have inquired about IPv6 already, but it's only gone so far as >>that. ?I would gladly give them a /64 and be done with it, but my >>concern is that they are going to want several /64 subnets for the >>same reason and I don't really *think* it's a legitimate reason. > > No legitimate mailer needs more than one /64 per physical network. > Same reason. > > R's, > John > This is my feeling exactly. The unfortunate part is, they seem to be close with another customer of ours with whom we've had a very good professional and non-shady working relationship for a number of years. My feeling is that they simply do not fully know what they are doing. I believe that they think they are doing things in a technically clever way, but in reality, it just makes them look incredibly shady. As I said, they've been a customer for about 7 years now and for the amount of email that they send, the complaints are at a bare minimum. I've seen much worse much quicker when a customer's box becomes an open spam relay. That said, the decision has been made to not provide them the addresses. In addition, we are going to force them to renumber into a much smaller block of contiguous IPs. I am of the firm belief of many others on here that for customers whose business deals primarily in email, there is no legitimate reason to have multiple discontiguous blocks. We've dished out assignments like this before, but I've only seen it requested by companies that do *legal* security vulnerability scans. Thanks, steve From rps at maine.edu Tue Jun 21 08:17:31 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 21 Jun 2011 09:17:31 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: <201106201857.p5KIv65V060717@nic-naa.net> References: <201106201857.p5KIv65V060717@nic-naa.net> Message-ID: I was talking about public perception and the ability to change it through marketing; not any actual security. It's like the difference between ".com" and ".biz", "people" don't understand when something isn't a ".com" and don't trust it. When I say "people" I'm talking about the average non-technical consumer. That is all. I do think that this breaks more than it's worth, and while it will mean a short-term revenue boost, it doesn't seem very scaleable nor in the long-term interest of DNS on the whole. It sounds like we're beginning the process of migrating to AOL keywords; I wonder if AOL has a patent on it... On Mon, Jun 20, 2011 at 2:57 PM, wrote: > ray, > >> ... only trust ".band" and that ".com" et. al. are "less secure". > > "secure" is not a well-defined term. > > as the .com registry access model accepts credit card fraud risk, > a hypothetical registry, say .giro, with wholesale registration at > the same dollar price point but an access mechanism accepting less > risk than credit card fraud would have less "insecure" registration > events. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From Valdis.Kletnieks at vt.edu Tue Jun 21 09:56:55 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 21 Jun 2011 10:56:55 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: Your message of "Mon, 20 Jun 2011 18:39:00 MDT." <45FE4558-A38E-444E-AE52-6C140E3D8B2D@antelope.net> References: <20110620190517.2242.qmail@joyce.lan> <20110620214541.3CEF510F118C@drugs.dv.isc.org> <45FE4558-A38E-444E-AE52-6C140E3D8B2D@antelope.net> Message-ID: <14185.1308668215@turing-police.cc.vt.edu> On Mon, 20 Jun 2011 18:39:00 MDT, Joel Maslak said: > I wonder what sort of money .wpad would be worth... I was thinking .gbmh myself... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kyle.creyts at gmail.com Tue Jun 21 11:52:00 2011 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Tue, 21 Jun 2011 12:52:00 -0400 Subject: ICANN to allow commercial gTLDs In-Reply-To: <14185.1308668215@turing-police.cc.vt.edu> References: <20110620190517.2242.qmail@joyce.lan> <20110620214541.3CEF510F118C@drugs.dv.isc.org> <45FE4558-A38E-444E-AE52-6C140E3D8B2D@antelope.net> <14185.1308668215@turing-police.cc.vt.edu> Message-ID: Or .inc? On Jun 21, 2011 10:57 AM, wrote: > On Mon, 20 Jun 2011 18:39:00 MDT, Joel Maslak said: >> I wonder what sort of money .wpad would be worth... > > I was thinking .gbmh myself... > From tmagill at providecommerce.com Tue Jun 21 15:03:55 2011 From: tmagill at providecommerce.com (Thomas Magill) Date: Tue, 21 Jun 2011 20:03:55 +0000 Subject: VMware ESX LACP Support In-Reply-To: References: Message-ID: I have to agree with this. Port-channels add no value with the way ESX load-balances. In fact, we had a few issues arise because of them and converted everything to native ESX LB. -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Monday, June 20, 2011 3:01 PM To: Manu Chao Cc: nanog at nanog.org Subject: Re: VMware ESX LACP Support On Mon, Jun 20, 2011 at 3:39 PM, Manu Chao wrote: > I would like to design VSS LACP based MECs with ESX hosts. > Does VMware ESX support LACP? No, ESX does not support the LACP protocol for control and negotiation of link aggregation. Should you want link aggregation, and the default load balancing operation of ESX does not meet requirements, it is possible to use a statically configured aggregation in non-negotiated ("on") state; or a third party solution. The standard way to load balance NICs in ESX, is to just plug in additional NICs to the same network, add the extra pNICs to the same vSwitch, and have all NICs in 'active' mode. The default operation is Load balancing based on Originating vSwitch port ID. That is, every time a new vNIC is connected to the vSwitch, it is assigned a port ID, which can be used to distribute outgoing traffic from the the vNICs among the pNICs, so individual VMs can be load balanced. > Do we need Nexus 1000 for ESX LACP support? The Nexus 1000v for ESX has LACP as a supported feature. The Nexus 1000v is one third party solution for VS link aggregation for Enterprise Plus ESX environments that use the VDS feature. VDS is a lot of complexity and expense to add, just to tick a "LACP Support" checkbox, however; if you don't also need its other features.... -- -JH From jmamodio at gmail.com Tue Jun 21 17:57:54 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 21 Jun 2011 17:57:54 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: References: <201106201857.p5KIv65V060717@nic-naa.net> Message-ID: On Tue, Jun 21, 2011 at 8:17 AM, Ray Soucy wrote: > I was talking about public perception and the ability to change it > through marketing; not any actual security. > > It's like the difference between ".com" and ".biz", "people" don't > understand when something isn't a ".com" and don't trust it. ?When I > say "people" I'm talking about the average non-technical consumer. Not even a .CO after all the fuss and misinformation campaign promoting it as the new "dotCOM" charging 3X the price of a .com, they barely reached 1M registrations (many as you can imagine from the same companies that hold the names in .com) when Verisign surpassed the 95M and getting closer for the 100M celebration (without taking in account the ~14M in .net). PS. Eric you are doing a great job !! I admire your patience and persistence. And forget about .INC, it is the airport code for Yinchuan, China. -J From brunner at nic-naa.net Tue Jun 21 16:27:27 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Tue, 21 Jun 2011 17:27:27 -0400 Subject: ICANN to allow commercial gTLDs Message-ID: <201106212127.p5LLRRBp070142@nic-naa.net> > I was talking about public perception and the ability to change it > through marketing; not any actual security. > > It's like the difference between ".com" and ".biz", "people" don't > understand when something isn't a ".com" and don't trust it. When I > say "people" I'm talking about the average non-technical consumer. > > That is all. it isn't likely that we could arrive at a useful definition of some subjective view held by others, so a discussion of "security" as a belief held by others is a waste of list and subscribers. there are broad claims: o zone file security requires registrant data correctness, a claim advanced by the set of actors advancing "WHOIS" policy at icann and elsewhere, o zone file security requires digital signature and little else, a claim implicit in the broad advocacy of dnssec and no other requirement relating to zone files, o zone file security requires registry applicant vetting and little else, a claim implicit in the broad advocacy for vetting and no other requirement relating to zone files, o zone file security requires registry security, and that would be me, channeling for roland on availability as an architecture consequence, followed by the other two legs of the cannonical CIA triad, for distributed systems. pick one or write your own and run with it. the folks at nominet did something useful and generous during the life in hell of the hstld ag, they attempted to cost compliance to the baroque set of requirements the aba/bits salted the mine with before there was an agenda, and the whois fanatics added. they came up with a six figure sum, which if applied to all registries, would put a nice "gold standard" logo on .com, and kill off (the whois fanatics wanted it mandatory on all new registries) all of the registries with less than that amount in wasteful excess annual income. -e From christopher.morrow at gmail.com Tue Jun 21 20:10:38 2011 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 21 Jun 2011 21:10:38 -0400 Subject: coresite in reston? Message-ID: apparently had a bad day? fbi raid? (happy to lend a hand if folk who aren't local need assistance getting things put back together... wkumari used to run a list at: newhere.com ) -chris From cb.list6 at gmail.com Tue Jun 21 20:21:41 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 21 Jun 2011 18:21:41 -0700 Subject: Cogent depeers ESnet Message-ID: On Jun 20, 2011 9:47 AM, "Christopher Pilkington" wrote: > > On Jun 20, 2011, at 10:53 AM, Jon Lewis wrote: > > > internet connectivity, and that much $ is at stake, you're stupid if you don't have some redundancy. Nothing works all the time forever. > > I can't consider Cogent even a redundant link, since I need two other > upstreams to reach the Internet redundantly. > This is the same case I face with level3 today. I have about 5 upstream isp's and level3 is the only one that does not have a "full ipv6 table" and therefore sites where level3 is one of the 2 upstreams are not redundant. I have calls into my account team, the response they gave me was laughable. .... something about how only 0.3% of the internet uses ipv6. Escalating .... if you can, it might be an opportune time for other level3 customers consider an escalation. Their lack of a full table contributes to the aaaa breakage / risk. This is not acceptable. Buying from cogent is its own reward, level3 should not be a service risk in itself. Cb > -cjp > From rdobbins at arbor.net Tue Jun 21 23:10:25 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 22 Jun 2011 04:10:25 +0000 Subject: Consequences of BGP Peering with Private Addresses In-Reply-To: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> References: <4522CE80-08B1-4310-B86F-9CAEA09DCB0E@cs.fiu.edu> Message-ID: <5F2589D3-C229-4B2B-B038-CCD8843F7A77@arbor.net> On Jun 15, 2011, at 12:47 PM, James Grace wrote: > Are there any horrific consequences to picking up this practice? ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From jnegro at billtrust.com Wed Jun 22 08:32:07 2011 From: jnegro at billtrust.com (Jeffrey Negro) Date: Wed, 22 Jun 2011 09:32:07 -0400 Subject: Any experience with Fonality Enterprise VoIP Solution? Message-ID: Sorry for the slightly off-topic question, but I'm hitting a brick wall of marketing, SEO planted, fake reviews. If anyone has any real experience with them, good, bad or bland, I'd would greatly appreciate your input off-list. Jeffrey From jeroen at mompl.net Wed Jun 22 14:30:55 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 22 Jun 2011 12:30:55 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <201106111344.p5BDiDTq046205@aurora.sol.net> References: <201106111344.p5BDiDTq046205@aurora.sol.net> Message-ID: <4E0242EF.8000600@mompl.net> Joe Greco wrote: > that things are changing. The number of TV's in a household are going > up. Some can now stream directly to the TV. I have numerous devices How can it go up even more? I thought every bedroom and living room has one by now, in the average family house. In my experience families have fared pretty well getting these TV signals through more traditional means. > that stream Internet radio audio, something that would have seemed > completely frivolous 15 years ago, but today my AV receiver comes with There has been in place for many decades multiple perfectly viable alternatives of getting TV or radio signals into your house. Using your good old antenna, satellite, cable... Considering these alternatives I'd say the idea of the internet replacing old existing infrastructures shouldn't be the top priority. Now if you mean added functionality or special ways of doing things that delivering content over the internet can provide I can see a point. Be that as it may, I don't think current methods and techniques in use will scale well to fully replace antennas, satellite and cable to provide tv and radio signals. (remembering for example the recent discussion about multicast) -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From jeroen at mompl.net Wed Jun 22 14:48:25 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 22 Jun 2011 12:48:25 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <5AB5CD2F-2839-4C8F-93BA-E8249E2B8C1B@cs.columbia.edu> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <5AB5CD2F-2839-4C8F-93BA-E8249E2B8C1B@cs.columbia.edu> Message-ID: <4E024709.2060102@mompl.net> Steven Bellovin wrote: > When I was in grad school, the director of the computer center (remember > those) felt that there was no need for 1200 bps modems -- 300 bps was > fine, since no one could read the scrolling output any faster than that > anyway. > > Right now, I'm running an rsync job to back up my laptop's hard drive to my > office. I hope it finishes before I leave today for Denver. I understand the sentiment, but the comparison is flawed in my opinion. The speeds back then were barely any faster than you could type, I know all too well the horrors of 1200/75 baud connectivity. Luckily nowadays now it's about getting your dvd torrent downloaded in 2 minutes, vs. 20 minutes, or 2 hours. Or your whole disk backed up before your flight leaves. You're now able to back it up online to begin with. The thing here is that I talk about *necessity*. Once connectivity has reached a certain speed threshold having increased speed generally starts leaning towards *would be nice* instead of *must*. And so far the examples people gave are almost all more in the realm of luxury problems than problems that hinder your life in fundamental ways. If you have a 100 mbps broadband connection and your toddlers are slowing down your video conference call with your boss by watching the newest Dexter (hah!). Then your *need* can be easily satisfied by telling your toddlers to cut the crap for a while. Sure it'd be nice if your toddlers could watch Dexter kill another victim whilst you were having a smooth video conference talk with your boss, but it's not necessary. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From lstewart at superb.net Wed Jun 22 14:56:30 2011 From: lstewart at superb.net (Landon Stewart) Date: Wed, 22 Jun 2011 12:56:30 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <4E024709.2060102@mompl.net> References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com> <70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net> <20110610134746.GA11923@hiwaay.net> <06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net> <4DF33692.6000300@mompl.net> <5AB5CD2F-2839-4C8F-93BA-E8249E2B8C1B@cs.columbia.edu> <4E024709.2060102@mompl.net> Message-ID: On Wed, Jun 22, 2011 at 12:48 PM, Jeroen van Aart wrote: > If you have a 100 mbps broadband connection and your toddlers are slowing > down your video conference call with your boss by watching the newest Dexter > (hah!). Then your *need* can be easily satisfied by telling your toddlers to > cut the crap for a while. Sure it'd be nice if your toddlers could watch > Dexter kill another victim whilst you were having a smooth video conference > talk with your boss, but it's not necessary. > +1 best comment I've read all day :-D -- Landon Stewart SuperbHosting.Net by Superb Internet Corp. Toll Free (US/Canada): 888-354-6128 x 4199 Direct: 206-438-5879 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From mksmith at adhost.com Wed Jun 22 15:19:13 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 22 Jun 2011 20:19:13 +0000 Subject: Yup; the Internet is screwed up. In-Reply-To: <4E024709.2060102@mompl.net> Message-ID: On 6/22/11 12:48 PM, "Jeroen van Aart" wrote: >Steven Bellovin wrote: >> When I was in grad school, the director of the computer center (remember >> those) felt that there was no need for 1200 bps modems -- 300 bps was >> fine, since no one could read the scrolling output any faster than that >> anyway. >> >> Right now, I'm running an rsync job to back up my laptop's hard drive >>to my >> office. I hope it finishes before I leave today for Denver. > >I understand the sentiment, but the comparison is flawed in my opinion. >The speeds back then were barely any faster than you could type, I know >all too well the horrors of 1200/75 baud connectivity. > >Luckily nowadays now it's about getting your dvd torrent downloaded in 2 >minutes, vs. 20 minutes, or 2 hours. Or your whole disk backed up before >your flight leaves. You're now able to back it up online to begin with. > >The thing here is that I talk about *necessity*. Once connectivity has >reached a certain speed threshold having increased speed generally >starts leaning towards *would be nice* instead of *must*. > >And so far the examples people gave are almost all more in the realm of >luxury problems than problems that hinder your life in fundamental ways. > >If you have a 100 mbps broadband connection and your toddlers are >slowing down your video conference call with your boss by watching the >newest Dexter (hah!). Then your *need* can be easily satisfied by >telling your toddlers to cut the crap for a while. Sure it'd be nice if >your toddlers could watch Dexter kill another victim whilst you were >having a smooth video conference talk with your boss, but it's not >necessary. > >Greetings, >Jeroen To paraphrase Randy Bush - I hope all my competitors work on their version of what their customers "need" versus what they "want". Why on earth would you not want to give them what they want? Why does "need" have anything to do with it, particularly when "need" is impossible to quantify? Mike From tvhawaii at shaka.com Wed Jun 22 15:45:38 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Wed, 22 Jun 2011 10:45:38 -1000 Subject: Yup; the Internet is screwed up. References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com><70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net><20110610134746.GA11923@hiwaay.net><06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net><4DF33692.6000300@mompl.net><5AB5CD2F-2839-4C8F-93BA-E8249E2B8C1B@cs.columbia.edu><4E024709.2060102@mompl.net> Message-ID: Landon Stewart wrote: > On Wed, Jun 22, 2011 at 12:48 PM, Jeroen van Aart wrote: > >> If you have a 100 mbps broadband connection and your toddlers are slowing >> down your video conference call with your boss by watching the newest Dexter >> (hah!). Then your *need* can be easily satisfied by telling your toddlers to >> cut the crap for a while. Sure it'd be nice if your toddlers could watch >> Dexter kill another victim whilst you were having a smooth video conference >> talk with your boss, but it's not necessary. >> > > +1 best comment I've read all day :-D I just *have* to say, "me too"...and as Jeroen says, some things work fine just the way they are. I waited 30+ years to be able to see the puck in a Hockey game via OTA Broadcast HDTV, and now Genachowski wants to use that spectrum so I can watch the game on a 3x3 in. screen. From bhmccie at gmail.com Wed Jun 22 15:51:51 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 22 Jun 2011 15:51:51 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <9557095.22.1307666608541.JavaMail.root@benjamin.baylink.com><70F1B41B-DF16-4A78-821B-8A7FBC3B3003@puck.nether.net><20110610134746.GA11923@hiwaay.net><06D2AA6D-FCDF-4C2A-9902-1C3A66A14C46@puck.nether.net><4DF33692.6000300@mompl.net><5AB5CD2F-2839-4C8F-93BA-E8249E2B8C1B@cs.columbia.edu><4E024709.2060102@mompl.net> Message-ID: <4E0255E7.9060405@gmail.com> If you have a 100mbps video connection and you can't handle a video conference in parallel with Dexter you may have bigger issues. :) -Hammer- On 06/22/2011 03:45 PM, Michael Painter wrote: > Landon Stewart wrote: >> On Wed, Jun 22, 2011 at 12:48 PM, Jeroen van Aart >> wrote: >> >>> If you have a 100 mbps broadband connection and your toddlers are >>> slowing >>> down your video conference call with your boss by watching the >>> newest Dexter >>> (hah!). Then your *need* can be easily satisfied by telling your >>> toddlers to >>> cut the crap for a while. Sure it'd be nice if your toddlers could >>> watch >>> Dexter kill another victim whilst you were having a smooth video >>> conference >>> talk with your boss, but it's not necessary. >>> >> >> +1 best comment I've read all day :-D > > I just *have* to say, "me too"...and as Jeroen says, some things work > fine just the way they are. > I waited 30+ years to be able to see the puck in a Hockey game via OTA > Broadcast HDTV, and now Genachowski wants to use that spectrum so I > can watch the game on a 3x3 in. screen. > From Erik.Amundson at oati.net Wed Jun 22 15:52:17 2011 From: Erik.Amundson at oati.net (Erik Amundson) Date: Wed, 22 Jun 2011 15:52:17 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <4E024709.2060102@mompl.net> Message-ID: <635D17EE85D35A49B8F278998E6C340459473A6B9D@EXVS.dev.oati.local> I agree, the whole use of the terms 'need' and 'want' in this conversation are ridiculous. It's the Internet. The entire thing isn't a 'need'. It's not like life support or something that will cause loss of life if it isn't there. The only thing to even discuss here is 'want'. Yes, consumers 'want' super-fast Internet, faster than any of us can comprehend right now. 1Tbps to the house, for everyone, for cheap! - Erik -----Original Message----- From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] Sent: Wednesday, June 22, 2011 3:19 PM To: Jeroen van Aart; NANOG list Subject: Re: Yup; the Internet is screwed up. On 6/22/11 12:48 PM, "Jeroen van Aart" wrote: >Steven Bellovin wrote: >> When I was in grad school, the director of the computer center >> (remember >> those) felt that there was no need for 1200 bps modems -- 300 bps was >> fine, since no one could read the scrolling output any faster than >> that anyway. >> >> Right now, I'm running an rsync job to back up my laptop's hard drive >>to my office. I hope it finishes before I leave today for Denver. > >I understand the sentiment, but the comparison is flawed in my opinion. >The speeds back then were barely any faster than you could type, I know >all too well the horrors of 1200/75 baud connectivity. > >Luckily nowadays now it's about getting your dvd torrent downloaded in >2 minutes, vs. 20 minutes, or 2 hours. Or your whole disk backed up >before your flight leaves. You're now able to back it up online to begin with. > >The thing here is that I talk about *necessity*. Once connectivity has >reached a certain speed threshold having increased speed generally >starts leaning towards *would be nice* instead of *must*. > >And so far the examples people gave are almost all more in the realm of >luxury problems than problems that hinder your life in fundamental ways. > >If you have a 100 mbps broadband connection and your toddlers are >slowing down your video conference call with your boss by watching the >newest Dexter (hah!). Then your *need* can be easily satisfied by >telling your toddlers to cut the crap for a while. Sure it'd be nice if >your toddlers could watch Dexter kill another victim whilst you were >having a smooth video conference talk with your boss, but it's not >necessary. > >Greetings, >Jeroen To paraphrase Randy Bush - I hope all my competitors work on their version of what their customers "need" versus what they "want". Why on earth would you not want to give them what they want? Why does "need" have anything to do with it, particularly when "need" is impossible to quantify? Mike From jgreco at ns.sol.net Wed Jun 22 15:55:05 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 22 Jun 2011 15:55:05 -0500 (CDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <4E0242EF.8000600@mompl.net> Message-ID: <201106222055.p5MKt59g044783@aurora.sol.net> > Joe Greco wrote: > > that things are changing. The number of TV's in a household are going > > up. Some can now stream directly to the TV. I have numerous devices > > How can it go up even more? I thought every bedroom and living room has > one by now, in the average family house. That's not universally true. It is, however, becoming more true as the cost of the devices drops and the form factor becomes more convenient. At one time, families could only afford the money and space for a single TV; they were large, expensive console affairs. Now I can have a TV on the wall in my office which does multiple duty as an additional screen for less-resolution-intensive computer uses, customer presentation purposes, and oh yes it can act as a highly competent TV capable of over the air, cable, or Internet stuff too. It's feasible to stick a TV on most any wall, without losing floorspace. And last I checked, TV's of a respectable size were only a few hundred bucks. > In my experience families have > fared pretty well getting these TV signals through more traditional means. People said similar things in the Days Before Cable. And then before the Days Before Satellite TV. While it's true, it's only *so* true. There's a ton of stuff, for example, that's available on Netflix streaming that hasn't been aired on commercial TV (at least that I've seen) in a very long time. Those of us who are TiVo fans are used to being able to have meaningful selections of shows available to watch at our convenience. This, however, is a process that involves being aware of the shows that are interesting and going to be broadcast, or hoping that the TiVo will "guess" as to what we like, which is only so likely. By way of comparison, Netflix streaming - while limited in show selection - offers the convenience of TiVo-style "on demand" viewing without being limited to the 980 hours our TiVo is capable of storing. There are many thousands of hours of TV instantly available, and the way it seems to be to me, it is only likely to go up. > > that stream Internet radio audio, something that would have seemed > > completely frivolous 15 years ago, but today my AV receiver comes with > > There has been in place for many decades multiple perfectly viable > alternatives of getting TV or radio signals into your house. Using your > good old antenna, satellite, cable... Considering these alternatives I'd > say the idea of the internet replacing old existing infrastructures > shouldn't be the top priority. Shouldn't be? Maybe. But these things happen. > Now if you mean added functionality or special ways of doing things that > delivering content over the internet can provide I can see a point. > > Be that as it may, I don't think current methods and techniques in use > will scale well to fully replace antennas, satellite and cable to > provide tv and radio signals. I remember when the same was being said of VoIP back when 33.6 modems were the majority consumer access device. Even now, VoIP isn't that prevalent, but it is becoming moreso. It's a slow process, but the convenience is there. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From Valdis.Kletnieks at vt.edu Wed Jun 22 16:08:32 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 22 Jun 2011 17:08:32 -0400 Subject: Yup; the Internet is screwed up. In-Reply-To: Your message of "Wed, 22 Jun 2011 15:52:17 CDT." <635D17EE85D35A49B8F278998E6C340459473A6B9D@EXVS.dev.oati.local> References: <4E024709.2060102@mompl.net> <635D17EE85D35A49B8F278998E6C340459473A6B9D@EXVS.dev.oati.local> Message-ID: <31611.1308776912@turing-police.cc.vt.edu> On Wed, 22 Jun 2011 15:52:17 CDT, Erik Amundson said: > I agree, the whole use of the terms 'need' and 'want' in this conversation > are ridiculous. It's the Internet. The entire thing isn't a 'need'. It's > not like life support or something that will cause loss of life if it isn't > there. If you're using e-mail and other communication technology to organize a regime change as is currently ongoing in the Middle East, the lack of it *can* cause loss of life if somebody literally doesn't get the memo. (Don't start in on the whole "it shouldn't be used for life-critical applications" unless you (a) are currently *in* one of the affected countries and (b) have a better *viable*, *deployable* suggestion for the populace. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Wed Jun 22 16:07:21 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 22 Jun 2011 14:07:21 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <4E0242EF.8000600@mompl.net> References: <201106111344.p5BDiDTq046205@aurora.sol.net> <4E0242EF.8000600@mompl.net> Message-ID: <151F0730-9105-4043-85FA-625D7CE583AB@delong.com> On Jun 22, 2011, at 12:30 PM, Jeroen van Aart wrote: > Joe Greco wrote: >> that things are changing. The number of TV's in a household are going >> up. Some can now stream directly to the TV. I have numerous devices > > How can it go up even more? I thought every bedroom and living room has one by now, in the average family house. In my experience families have fared pretty well getting these TV signals through more traditional means. > >> that stream Internet radio audio, something that would have seemed >> completely frivolous 15 years ago, but today my AV receiver comes with > > There has been in place for many decades multiple perfectly viable alternatives of getting TV or radio signals into your house. Using your good old antenna, satellite, cable... Considering these alternatives I'd say the idea of the internet replacing old existing infrastructures shouldn't be the top priority. > > Now if you mean added functionality or special ways of doing things that delivering content over the internet can provide I can see a point. > > Be that as it may, I don't think current methods and techniques in use will scale well to fully replace antennas, satellite and cable to provide tv and radio signals. > > (remembering for example the recent discussion about multicast) > They won't, but, that's not what consumers think about when they decide where to get their content. Consumers look at convenience, cost, and availability. In some cases, quality also enters the picture. If you don't believe that consumer content acquisition is shifting away from traditional methods towards internet-oriented mechanisms rapidly, you haven't been paying attention to the bandwidth growth at Netflix as just one example. Hulu, Youtube, and even the various networks own web-based episode streaming services are all additional examples that cannot be ignored. We're going to have to either find a way to convince consumers to change direction, or, we're going to have to develop new methods and techniques that will scale to fully replace antennas, satellite, and cable because that's what consumers are starting to do. Owen From joelja at bogus.com Wed Jun 22 16:19:56 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 22 Jun 2011 14:19:56 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <635D17EE85D35A49B8F278998E6C340459473A6B9D@EXVS.dev.oati.local> References: <4E024709.2060102@mompl.net> <635D17EE85D35A49B8F278998E6C340459473A6B9D@EXVS.dev.oati.local> Message-ID: life safety systems run over the internet and pstn all the time if you want to talk about need. Replace need with business requirement, and you're most of the way there... This discussion was going on this list 10-15 years ago and the numbers being squabled over were three orders of magnitude lower then they are today. In 2021 I don't think gig-e to the curb, or what it's applications might be will be particularly controversial. joel On Jun 22, 2011, at 1:52 PM, Erik Amundson wrote: > I agree, the whole use of the terms 'need' and 'want' in this conversation are ridiculous. It's the Internet. The entire thing isn't a 'need'. It's not like life support or something that will cause loss of life if it isn't there. The only thing to even discuss here is 'want'. Yes, consumers 'want' super-fast Internet, faster than any of us can comprehend right now. 1Tbps to the house, for everyone, for cheap! > > - Erik From nathan at atlasnetworks.us Wed Jun 22 16:33:56 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 22 Jun 2011 21:33:56 +0000 Subject: Yup; the Internet is screwed up. In-Reply-To: <635D17EE85D35A49B8F278998E6C340459473A6B9D@EXVS.dev.oati.local> References: <4E024709.2060102@mompl.net> <635D17EE85D35A49B8F278998E6C340459473A6B9D@EXVS.dev.oati.local> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B4AC02F@ex-mb-1.corp.atlasnetworks.us> > I agree, the whole use of the terms 'need' and 'want' in this conversation are > ridiculous. It's the Internet. The entire thing isn't a 'need'. It's not like life > support or something that will cause loss of life if it isn't there. The only thing > to even discuss here is 'want'. Yes, consumers 'want' super-fast Internet, > faster than any of us can comprehend right now. 1Tbps to the house, for > everyone, for cheap! Wait, the internet isn't a need? Is this 1991? Of course it's a need, as surely as heat or electricity are needs. Without even trying, I can think of a dozen life-safety systems that rely solely on the internet for their functionality. Nathan From jgreco at ns.sol.net Wed Jun 22 17:07:53 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 22 Jun 2011 17:07:53 -0500 (CDT) Subject: Yup; the Internet is screwed up. In-Reply-To: <151F0730-9105-4043-85FA-625D7CE583AB@delong.com> Message-ID: <201106222207.p5MM7rFb045569@aurora.sol.net> > > Be that as it may, I don't think current methods and techniques in use = > will scale well to fully replace antennas, satellite and cable to = > provide tv and radio signals. > >=20 > > (remembering for example the recent discussion about multicast) > >=20 > They won't, but, that's not what consumers think about when they decide = > where to get their content. > > Consumers look at convenience, cost, and availability. In some cases, = > quality also enters the picture. > > If you don't believe that consumer content acquisition is shifting away = > from traditional methods towards internet-oriented mechanisms rapidly, = > you haven't been paying attention to the bandwidth growth at Netflix as = > just one example. Hulu, Youtube, and even the various networks own = > web-based episode streaming services are all additional examples that = > cannot be ignored. > > We're going to have to either find a way to convince consumers to change = > direction, or, we're going to have to develop new methods and techniques = > that will scale to fully replace antennas, satellite, and cable because = > that's what consumers are starting to do. I've been arguing that we're going to see this for years now and even so it comes up and catches me a bit unaware at times. I can think of two trivial examples. I used to like doing long-haul driving on the weekends because it'd give me a chance to listen to "Car Talk" and a few other things that I found amusing ways to keep myself from being totally bored. With the advent of podcasts, I got away from that... it became possible to download them and stick them on an iPod so I could listen to my convenience. But wait... it gets worse... now I can run an app on a phone that actually downloads the podcast over the cellular internet and plays it to me on demand, so I don't even need to plan ahead and download prior to leaving the house or office. From a network operator's perspective, this is worst-case behaviour because it's using a scarce resource (cell bw) for something that I could have done on normal Internet in advance, but from a convenience point of view, I get to ditch having to worry about iTunes and syncing and all that - I just ask for the content when I actually want it. It works. I feel moderately justified in saying that I pay for the privilege, given what the carrier charges for cell data. It's so *convenient.* I also picked up an Aluratek AIRMM01 clock radio a while back because I wanted to be able to have a radio that played a specific kind of music in a specific room, without much advertising. While I had originally planned to load up a USB thumb drive with some CD's worth of content I already had, upon plugging the thing in and playing with it a bit, it fairly easily hooked up to our wifi, and had a really massive list of available stations, including some of the type I was looking for, and which I've yet to hear any advertising on. From a network operator's perspective, it'd be much better for me to load up a USB flash with some content and let it play that, but from a user's perspective, it's actually more convenient to just let it stream audio over the Internet. Both of these represent use cases where the outcomes were not what I had originally envisioned, and are causing more load on bits of the Internet than what's ideally required. Your average person cares a whole lot less about what's crossing their Internet connection than they care about whether or not "this works" than I do. I continue to be amazed at the quality of Netflix video coming across the wire. Our local cable company just recently upped their old 7M/512K normal tier to 10M/1M, and is now offering much higher speed tiers as well, which isn't going to be discouraging to anyone wanting to do this sort of thing. I guess the most telling bit of all this was when I found myself needing an ethernet switch behind the TV, AND WAS ABLE TO FILL ALL THE PORTS, for Internet-capable TV set Internet-capable Blu-Ray player Networkable TiVo AppleTV Video Game Console Networked AV Receiver UPS and an uplink of course. 8 ports. Geez. That keeps striking me as such a paradigm shift. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From bret at getjive.com Wed Jun 22 17:27:26 2011 From: bret at getjive.com (Bret Palsson) Date: Wed, 22 Jun 2011 16:27:26 -0600 Subject: BGP Design question. Message-ID: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Here is my current setup in ASCII art. (Please view in a fixed width font.) Below the art I'll write out the setup. +--------+ +--------+ | Peer A | | Peer A | <-Many carriers. Using 1 carrier +---+----+ +----+---+ for this scenario. |eBGP | eBGP | | +---+----+iBGP+----+---+ | Router +----+ Router | <-Netiron CERs Routers. +-+------+ +------+-+ |A `.P A.' |P <-A/P indicates Active/Passive | `. .' | link. | :: | +-+------+' `+------+-+ |Act. FW | |Pas. FW | <-Firewalls Active/Passive. +--------+ +--------+ To keep this scenario simple, I'm multihoming to one carrier. I have two Netiron CERs. Each have a eBGP connection to the same peer. The CERs have an iBGP connection to each other. That works all fine and dandy. Feel free to comment, however if you think there is a better way to do this. Here comes the tricky part. I have two firewalls in an Active/Passive setup. When one fails the other is configured exactly the same and picks up where the other left off. (Yes, all the sessions etc. are actively mirrored between the devices) I am using OSPFv2 between the CERs and the Firewalls. Failover works just fine, however when I fail an OSPF link that has the active default route, ingress traffic still routes fine and dandy, but egress traffic doesn't. Both Netiron's OSPF are setup to advertise they are the default route. What I'm wondering is, if OSPF is the right solution for this. How do others solve this problem? Thanks, Bret Note: Since lately ipv6 has been a hot topic, I'll state that after we get the BGP all figured out and working properly, ipv6 is our next project. :) From branto at networking-architecture.com Wed Jun 22 17:33:57 2011 From: branto at networking-architecture.com (Brant I. Stevens) Date: Wed, 22 Jun 2011 17:33:57 -0500 Subject: BGP Design question. In-Reply-To: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: On 6/22/11 6:27 PM, "Bret Palsson" wrote: >Here is my current setup in ASCII art. (Please view in a fixed width >font.) Below the art I'll write out the setup. > > > +--------+ +--------+ > | Peer A | | Peer A | <-Many carriers. Using 1 carrier > +---+----+ +----+---+ for this scenario. > |eBGP | eBGP > | | > +---+----+iBGP+----+---+ > | Router +----+ Router | <-Netiron CERs Routers. > +-+------+ +------+-+ > |A `.P A.' |P <-A/P indicates Active/Passive > | `. .' | link. > | :: | > +-+------+' `+------+-+ > |Act. FW | |Pas. FW | <-Firewalls Active/Passive. > +--------+ +--------+ > > >To keep this scenario simple, I'm multihoming to one carrier. >I have two Netiron CERs. Each have a eBGP connection to the same peer. >The CERs have an iBGP connection to each other. >That works all fine and dandy. Feel free to comment, however if you think >there is a better way to do this. > >Here comes the tricky part. I have two firewalls in an Active/Passive >setup. When one fails the other is configured exactly the same >and picks up where the other left off. (Yes, all the sessions etc. are >actively mirrored between the devices) > >I am using OSPFv2 between the CERs and the Firewalls. Failover works just >fine, however when I fail an OSPF link that has the active default route, >ingress traffic still routes fine and dandy, but egress traffic doesn't. >Both Netiron's OSPF are setup to advertise they are the default route. > >What I'm wondering is, if OSPF is the right solution for this. How do >others solve this problem? You could also do an eBGP session through the firewall between the outside routers and routers on the inside firewall, passing only the default route to the inside routers. > > >Thanks, > >Bret > > >Note: Since lately ipv6 has been a hot topic, I'll state that after we >get the BGP all figured out and working properly, ipv6 is our next >project. :) > > From owen at delong.com Wed Jun 22 17:44:01 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 22 Jun 2011 15:44:01 -0700 Subject: BGP Design question. In-Reply-To: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: <030821C3-B4FF-415D-A4BF-1FC9B900E092@delong.com> I would suggest running VRRP on the routers towards the firewalls and only use OSPF to advertise the ingress routes. Statically route default to the VRRP group. Implemented as follows: [RA]------[switch]-----[switch]------[RB] | | [AFW] [PFW] Make sense? AFW/PFW advertise OSPF for the interior routes so that RA/RB know how to reach them, but, RA/RB don't have to advertise anything and AFW/PFW have static default routes to a VRRP group address shared between RA/RB. If you want to make OSPF work, then, try making sure you have default-information originate always on both RA and RB. Owen On Jun 22, 2011, at 3:27 PM, Bret Palsson wrote: > Here is my current setup in ASCII art. (Please view in a fixed width font.) Below the art I'll write out the setup. > > > +--------+ +--------+ > | Peer A | | Peer A | <-Many carriers. Using 1 carrier > +---+----+ +----+---+ for this scenario. > |eBGP | eBGP > | | > +---+----+iBGP+----+---+ > | Router +----+ Router | <-Netiron CERs Routers. > +-+------+ +------+-+ > |A `.P A.' |P <-A/P indicates Active/Passive > | `. .' | link. > | :: | > +-+------+' `+------+-+ > |Act. FW | |Pas. FW | <-Firewalls Active/Passive. > +--------+ +--------+ > > > To keep this scenario simple, I'm multihoming to one carrier. > I have two Netiron CERs. Each have a eBGP connection to the same peer. > The CERs have an iBGP connection to each other. > That works all fine and dandy. Feel free to comment, however if you think there is a better way to do this. > > Here comes the tricky part. I have two firewalls in an Active/Passive setup. When one fails the other is configured exactly the same > and picks up where the other left off. (Yes, all the sessions etc. are actively mirrored between the devices) > > I am using OSPFv2 between the CERs and the Firewalls. Failover works just fine, however when I fail an OSPF link that has the active default route, ingress traffic still routes fine and dandy, but egress traffic doesn't. Both Netiron's OSPF are setup to advertise they are the default route. > > What I'm wondering is, if OSPF is the right solution for this. How do others solve this problem? > > > Thanks, > > Bret > > > Note: Since lately ipv6 has been a hot topic, I'll state that after we get the BGP all figured out and working properly, ipv6 is our next project. :) > From randy at psg.com Wed Jun 22 18:01:07 2011 From: randy at psg.com (Randy Bush) Date: Thu, 23 Jun 2011 08:01:07 +0900 Subject: Yup; the Internet is screwed up. In-Reply-To: References: <4E024709.2060102@mompl.net> <635D17EE85D35A49B8F278998E6C340459473A6B9D@EXVS.dev.oati.local> Message-ID: > This discussion was going on this list 10-15 years ago and the numbers > being squabled over were three orders of magnitude lower then they are > today. and will be discussed again when the numbers are orders of magnitude greater than they are now. i think we should keep a pointer to this thread and to the "we don't need" folk so we can replay it for them then. randy, who lives in a country which has real 2000-speed broadband to the home (and i use it) From randy at psg.com Wed Jun 22 18:02:59 2011 From: randy at psg.com (Randy Bush) Date: Thu, 23 Jun 2011 08:02:59 +0900 Subject: BGP Design question. In-Reply-To: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: vrrp? From jeroen at mompl.net Wed Jun 22 18:06:45 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 22 Jun 2011 16:06:45 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <151F0730-9105-4043-85FA-625D7CE583AB@delong.com> References: <201106111344.p5BDiDTq046205@aurora.sol.net> <4E0242EF.8000600@mompl.net> <151F0730-9105-4043-85FA-625D7CE583AB@delong.com> Message-ID: <4E027585.5040601@mompl.net> Owen DeLong wrote: > If you don't believe that consumer content acquisition is shifting away from traditional methods towards internet-oriented mechanisms rapidly, you haven't been paying attention to the bandwidth growth at Netflix as just one example. Hulu, Youtube, and even the various networks own web-based episode streaming services are all additional examples that cannot be ignored. For the record I do believe that. > We're going to have to either find a way to convince consumers to change direction, or, we're going to have to develop new methods and techniques that will scale to fully replace antennas, satellite, and cable because that's what consumers are starting to do. I hope for the latter. It just pains me to think how to do this with existing techniques in use. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From young at jsyoung.net Wed Jun 22 18:06:58 2011 From: young at jsyoung.net (Jeffrey S. Young) Date: Thu, 23 Jun 2011 09:06:58 +1000 Subject: Yup; the Internet is screwed up. In-Reply-To: <201106222207.p5MM7rFb045569@aurora.sol.net> References: <201106222207.p5MM7rFb045569@aurora.sol.net> Message-ID: <916B3B5F-94BB-4A8F-9975-64746C1AA5BC@jsyoung.net> On 23/06/2011, at 8:07 AM, Joe Greco wrote: >>> Be that as it may, I don't think current methods and techniques in use = >> will scale well to fully replace antennas, satellite and cable to = >> provide tv and radio signals. >>> =20 >>> (remembering for example the recent discussion about multicast) >>> =20 >> They won't, but, that's not what consumers think about when they decide = >> where to get their content. >> >> Consumers look at convenience, cost, and availability. In some cases, = >> quality also enters the picture. It's interesting in an "Innovator's Dilemma" sort of way. Consumers are moving from time-based consumption to time-shifted consumption. As (we) technologists finds ways to bring the market what it wants in a cost-effective manner the old methods to deliver content are eclipsed. If we can scale to deliver the majority of content from the big hard drive in the sky the market for cable and television's linear programming signals goes away. It's hard for me to think that radio will be eclipsed (but with LTE and iCloud, perhaps even that is possible). As the methods to deliver content change so will the paradigms and the descriptive language. How many kids know what an LP is? How many of their kids will understand what a "time-slot" is? How many will lose their favorite program because it was "cancelled" by the "network" -- will programs vie for real eyeballs rather than places in a "fall lineup"? Will "blanket ads" be replaced by the household's "Google Profile" and what was a Neilsen rating anyway? Our jobs are going to depend on finding ways to scale infrastructure for the convenience of others. I don't think the Internet is "screwed up" it's just reached the point of inflection after which it will scale based on convenience. Broadcast and multicast are much more efficient ways of video delivery than unicast IP, but then the PSTN was a perfectly good system, who needs cellular or VoIP? jy From if at xip.at Wed Jun 22 18:07:54 2011 From: if at xip.at (Ingo Flaschberger) Date: Thu, 23 Jun 2011 01:07:54 +0200 (CEST) Subject: BGP Design question. In-Reply-To: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: Hi Bret, > To keep this scenario simple, I'm multihoming to one carrier. > I have two Netiron CERs. Each have a eBGP connection to the same peer. > The CERs have an iBGP connection to each other. > That works all fine and dandy. Feel free to comment, however if you think there is a better way to do this. > > Here comes the tricky part. I have two firewalls in an Active/Passive setup. When one fails the other is configured exactly the same > and picks up where the other left off. (Yes, all the sessions etc. are actively mirrored between the devices) > > I am using OSPFv2 between the CERs and the Firewalls. Failover works > just fine, however when I fail an OSPF link that has the active default > route, ingress traffic still routes fine and dandy, but egress traffic > doesn't. Both Netiron's OSPF are setup to advertise they are the default > route. Linux firewall? disabled rp-filter? > What I'm wondering is, if OSPF is the right solution for this. How do others solve this problem? I do something similar with freebsd; you always make shure the backbone area 0.0.0.0 does not break into 2 parts, perhaps use an extra link between the 2 firewalls just because of this. Kind regards, Ingo Flaschberger From bhmccie at gmail.com Wed Jun 22 18:11:13 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 22 Jun 2011 18:11:13 -0500 Subject: BGP Design question. In-Reply-To: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: <4E027691.6020305@gmail.com> Another option would be to insert switches between your routers and FWs. OSPF from the routers to the switches (yes, switches running L3 OSPF) and then HSRP/VRRP/etc. to the FWs. This way routing changes don't affect the FWs. The FWs simply have a default route to the HSRP/VRRP/etc. VIP. Then the primary switch routes to the routers which then route out to their EBGP peers. Only caveat is to make sure you are only redistributing the 0/0 into OSPF. Not the full route table. -Hammer- On 06/22/2011 05:27 PM, Bret Palsson wrote: > Here is my current setup in ASCII art. (Please view in a fixed width font.) Below the art I'll write out the setup. > > > +--------+ +--------+ > | Peer A | | Peer A |<-Many carriers. Using 1 carrier > +---+----+ +----+---+ for this scenario. > |eBGP | eBGP > | | > +---+----+iBGP+----+---+ > | Router +----+ Router |<-Netiron CERs Routers. > +-+------+ +------+-+ > |A `.P A.' |P<-A/P indicates Active/Passive > | `. .' | link. > | :: | > +-+------+' `+------+-+ > |Act. FW | |Pas. FW |<-Firewalls Active/Passive. > +--------+ +--------+ > > > To keep this scenario simple, I'm multihoming to one carrier. > I have two Netiron CERs. Each have a eBGP connection to the same peer. > The CERs have an iBGP connection to each other. > That works all fine and dandy. Feel free to comment, however if you think there is a better way to do this. > > Here comes the tricky part. I have two firewalls in an Active/Passive setup. When one fails the other is configured exactly the same > and picks up where the other left off. (Yes, all the sessions etc. are actively mirrored between the devices) > > I am using OSPFv2 between the CERs and the Firewalls. Failover works just fine, however when I fail an OSPF link that has the active default route, ingress traffic still routes fine and dandy, but egress traffic doesn't. Both Netiron's OSPF are setup to advertise they are the default route. > > What I'm wondering is, if OSPF is the right solution for this. How do others solve this problem? > > > Thanks, > > Bret > > > Note: Since lately ipv6 has been a hot topic, I'll state that after we get the BGP all figured out and working properly, ipv6 is our next project. :) > > > From joelja at bogus.com Wed Jun 22 18:19:16 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 22 Jun 2011 16:19:16 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <4E027585.5040601@mompl.net> References: <201106111344.p5BDiDTq046205@aurora.sol.net> <4E0242EF.8000600@mompl.net> <151F0730-9105-4043-85FA-625D7CE583AB@delong.com> <4E027585.5040601@mompl.net> Message-ID: On Jun 22, 2011, at 4:06 PM, Jeroen van Aart wrote: > Owen DeLong wrote: >> We're going to have to either find a way to convince consumers to change direction, or, we're going to have to develop new methods and techniques that will scale to fully replace antennas, satellite, and cable because that's what consumers are starting to do. > > I hope for the latter. It just pains me to think how to do this with existing techniques in use. Not only will it happen but it will cost less per byte delivered than the other distribution methods and enable applications that aren't simply broadcast one to many. Geoff had a presentation a couple of years ago that projected the cost per byte that was necessary to make the growth projection pan out economically out a decade or two to the right if I recall, we get to build that. From wcooper02 at gmail.com Wed Jun 22 18:22:23 2011 From: wcooper02 at gmail.com (William Cooper) Date: Wed, 22 Jun 2011 19:22:23 -0400 Subject: BGP Design question. In-Reply-To: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: Couple of questions for clarification (inline): On Wed, Jun 22, 2011 at 6:27 PM, Bret Palsson wrote: > Here is my current setup in ASCII art. (Please view in a fixed width font.) Below the art I'll write out the setup. > > > ? ? +--------+ ? ?+--------+ > ? ? | Peer A | ? ?| Peer A | ?<-Many carriers. Using 1 carrier > ? ? +---+----+ ? ?+----+---+ ? ?for this scenario. > ? ? ? ? |eBGP ? ? ? ? ?| eBGP > ? ? ? ? | ? ? ? ? ? ? ?| > ? ? +---+----+iBGP+----+---+ > ? ? | Router +----+ Router | ?<-Netiron CERs Routers. > ? ? +-+------+ ? ?+------+-+ > ? ? ? |A ? `.P ? ?A.' ? ?|P ? <-A/P indicates Active/Passive > ? ? ? | ? ? ?`. ?.' ? ? ?| ? ? ?link. > ? ? ? | ? ? ? ?:: ? ? ? ?| > ? ? +-+------+' ?`+------+-+ > ? ? |Act. FW | ? ?|Pas. FW | ?<-Firewalls Active/Passive. > ? ? +--------+ ? ?+--------+ (Tony) What's behind this point? > > > To keep this scenario simple, I'm multihoming to one carrier. > I have two Netiron CERs. Each have a eBGP connection to the same peer. > The CERs have an iBGP connection to each other. > That works all fine and dandy. Feel free to comment, however if you think there is a better way to do this. > > Here comes the tricky part. I have two firewalls in an Active/Passive setup. When one fails the other is configured exactly the same > and picks up where the other left off. (Yes, all the sessions etc. are actively mirrored between the devices) > > I am using OSPFv2 between the CERs and the Firewalls. Failover works just fine, however when I fail an OSPF link that has the active default route, ingress traffic still routes fine and dandy, but egress traffic doesn't. Both Netiron's OSPF are setup to advertise they are the default route. > (Tony) (Apologies for the seemingly dumb question) but by egress, do you mean from behind the FW towards your carrier? > What I'm wondering is, if OSPF is the right solution for this. How do others solve this problem? > > > Thanks, > > Bret > > > Note: Since lately ipv6 has been a hot topic, I'll state that after we get the BGP all figured out and working properly, ipv6 is our next project. :) > > > From paul4004 at gmail.com Wed Jun 22 18:33:35 2011 From: paul4004 at gmail.com (PC) Date: Wed, 22 Jun 2011 17:33:35 -0600 Subject: BGP Design question. In-Reply-To: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: Who makes the firewall? To make this work and be "hitless", your firewall vendor must support stateful replication of routing protocol data (including OSPF). For example, Cisco didn't support this in their ASA product until version 8.4 of code. Otherwise, a failover requires OSPF to re-converge -- and quite frankly, will likely cause some state of confusion on the upstream OSPF peers, loss of adjacency, and a loss of routing until this occurs. It's like someone just swapped a router with the same IP to the upstream device -- assuming your active/standby vendor's implementation only presents itself as one device. However, once this is succesful your current failover topology should work fine -- even if it takes some time to failover. In my opinion though, unless the firewall is serving as "transit" to downstream routers or other layer 3 elements, and you need to run OSPF to it (And through it) as a result, it's often just easier to static default route out from the firewall(s) and redistribute a static route on the upstream routers for the subnets behind the firewalls. It also helps ensure symmetrical traffic flows, which is important for stateful firewalls and can become moderatly confusing when your firewalls start having many interfaces. On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson wrote: > Here is my current setup in ASCII art. (Please view in a fixed width font.) > Below the art I'll write out the setup. > > > +--------+ +--------+ > | Peer A | | Peer A | <-Many carriers. Using 1 carrier > +---+----+ +----+---+ for this scenario. > |eBGP | eBGP > | | > +---+----+iBGP+----+---+ > | Router +----+ Router | <-Netiron CERs Routers. > +-+------+ +------+-+ > |A `.P A.' |P <-A/P indicates Active/Passive > | `. .' | link. > | :: | > +-+------+' `+------+-+ > |Act. FW | |Pas. FW | <-Firewalls Active/Passive. > +--------+ +--------+ > > > To keep this scenario simple, I'm multihoming to one carrier. > I have two Netiron CERs. Each have a eBGP connection to the same peer. > The CERs have an iBGP connection to each other. > That works all fine and dandy. Feel free to comment, however if you think > there is a better way to do this. > > Here comes the tricky part. I have two firewalls in an Active/Passive > setup. When one fails the other is configured exactly the same > and picks up where the other left off. (Yes, all the sessions etc. are > actively mirrored between the devices) > > I am using OSPFv2 between the CERs and the Firewalls. Failover works just > fine, however when I fail an OSPF link that has the active default route, > ingress traffic still routes fine and dandy, but egress traffic doesn't. > Both Netiron's OSPF are setup to advertise they are the default route. > > What I'm wondering is, if OSPF is the right solution for this. How do > others solve this problem? > > > Thanks, > > Bret > > > Note: Since lately ipv6 has been a hot topic, I'll state that after we get > the BGP all figured out and working properly, ipv6 is our next project. :) > > > From bhmccie at gmail.com Wed Jun 22 18:37:21 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 22 Jun 2011 18:37:21 -0500 Subject: BGP Design question. In-Reply-To: References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: <4E027CB1.9070007@gmail.com> Do people really run routing protocols with their public address space on their FWs? I'm not saying right or wrong. Just curious. Seems like the last thing I would want to do would be to have my FW participate in a routing protocol unless is was absolutely necessary. Better to static the FW with a default route? I'd love to hear arguments for or against.... -Hammer- On 06/22/2011 06:33 PM, PC wrote: > Who makes the firewall? > > To make this work and be "hitless", your firewall vendor must support > stateful replication of routing protocol data (including OSPF). For > example, Cisco didn't support this in their ASA product until version 8.4 of > code. > > Otherwise, a failover requires OSPF to re-converge -- and quite frankly, > will likely cause some state of confusion on the upstream OSPF peers, loss > of adjacency, and a loss of routing until this occurs. It's like someone > just swapped a router with the same IP to the upstream device -- assuming > your active/standby vendor's implementation only presents itself as one > device. > > However, once this is succesful your current failover topology should work > fine -- even if it takes some time to failover. > > In my opinion though, unless the firewall is serving as "transit" to > downstream routers or other layer 3 elements, and you need to run OSPF to it > (And through it) as a result, it's often just easier to static default route > out from the firewall(s) and redistribute a static route on the upstream > routers for the subnets behind the firewalls. It also helps ensure > symmetrical traffic flows, which is important for stateful firewalls and can > become moderatly confusing when your firewalls start having many interfaces. > > > > > On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson wrote: > > >> Here is my current setup in ASCII art. (Please view in a fixed width font.) >> Below the art I'll write out the setup. >> >> >> +--------+ +--------+ >> | Peer A | | Peer A |<-Many carriers. Using 1 carrier >> +---+----+ +----+---+ for this scenario. >> |eBGP | eBGP >> | | >> +---+----+iBGP+----+---+ >> | Router +----+ Router |<-Netiron CERs Routers. >> +-+------+ +------+-+ >> |A `.P A.' |P<-A/P indicates Active/Passive >> | `. .' | link. >> | :: | >> +-+------+' `+------+-+ >> |Act. FW | |Pas. FW |<-Firewalls Active/Passive. >> +--------+ +--------+ >> >> >> To keep this scenario simple, I'm multihoming to one carrier. >> I have two Netiron CERs. Each have a eBGP connection to the same peer. >> The CERs have an iBGP connection to each other. >> That works all fine and dandy. Feel free to comment, however if you think >> there is a better way to do this. >> >> Here comes the tricky part. I have two firewalls in an Active/Passive >> setup. When one fails the other is configured exactly the same >> and picks up where the other left off. (Yes, all the sessions etc. are >> actively mirrored between the devices) >> >> I am using OSPFv2 between the CERs and the Firewalls. Failover works just >> fine, however when I fail an OSPF link that has the active default route, >> ingress traffic still routes fine and dandy, but egress traffic doesn't. >> Both Netiron's OSPF are setup to advertise they are the default route. >> >> What I'm wondering is, if OSPF is the right solution for this. How do >> others solve this problem? >> >> >> Thanks, >> >> Bret >> >> >> Note: Since lately ipv6 has been a hot topic, I'll state that after we get >> the BGP all figured out and working properly, ipv6 is our next project. :) >> >> >> >> From bill at herrin.us Wed Jun 22 18:42:31 2011 From: bill at herrin.us (William Herrin) Date: Wed, 22 Jun 2011 19:42:31 -0400 Subject: BGP Design question. In-Reply-To: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: On Wed, Jun 22, 2011 at 6:27 PM, Bret Palsson wrote: > I am using OSPFv2 between the CERs and the Firewalls. >Failover works just fine, however when I fail an OSPF link >that has the active default route, ingress traffic still routes >fine and dandy, but egress traffic doesn't. Both Netiron's >OSPF are setup to advertise they are the default route. Hi Bret, I have a setup that is almost identical except there is a pair of simple switches between the routers and firewalls interconnecting all into a LAN and I'm working with Cisco 2811's instead of Netiron CERs. Can you expand on the interface addressing and what the firewalls see via OSPF during your failure scenario? > What I'm wondering is, if OSPF is the right solution for >this. How do others solve this problem? My failover firewall also connects to the switches (inside and out) and turns down ports which connect to the primary firewall. During a failure, the primary can't be depended on to completely take itself out of line. If it was in a working state that could be depended on, it wouldn't have failed. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bret at getjive.com Wed Jun 22 20:04:16 2011 From: bret at getjive.com (Bret Palsson) Date: Wed, 22 Jun 2011 19:04:16 -0600 Subject: BGP Design question. In-Reply-To: References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: On Wed, Jun 22, 2011 at 5:22 PM, William Cooper wrote: > Couple of questions for clarification (inline): > > On Wed, Jun 22, 2011 at 6:27 PM, Bret Palsson wrote: > > Here is my current setup in ASCII art. (Please view in a fixed width > font.) Below the art I'll write out the setup. > > > > > > +--------+ +--------+ > > | Peer A | | Peer A | <-Many carriers. Using 1 carrier > > +---+----+ +----+---+ for this scenario. > > |eBGP | eBGP > > | | > > +---+----+iBGP+----+---+ > > | Router +----+ Router | <-Netiron CERs Routers. > > +-+------+ +------+-+ > > |A `.P A.' |P <-A/P indicates Active/Passive > > | `. .' | link. > > | :: | > > +-+------+' `+------+-+ > > |Act. FW | |Pas. FW | <-Firewalls Active/Passive. > > +--------+ +--------+ > > (Tony) What's behind this point? > We have a few gigs of voice (RTP) traffic at any given time of the day. We want/need hitless failover. Currently we provide this, but we use our providers BGP mix. We will be peering with many carriers directly now and are changing our topology to do so. Before we had a HSRP L3 hand-off to two switches in the same vlan. On our juniper SSGs we bonded ports and we use the NSRP for all the RTOs. Which provided hitless fail-over. > > > > > > > To keep this scenario simple, I'm multihoming to one carrier. > > I have two Netiron CERs. Each have a eBGP connection to the same peer. > > The CERs have an iBGP connection to each other. > > That works all fine and dandy. Feel free to comment, however if you think > there is a better way to do this. > > > > Here comes the tricky part. I have two firewalls in an Active/Passive > setup. When one fails the other is configured exactly the same > > and picks up where the other left off. (Yes, all the sessions etc. are > actively mirrored between the devices) > > > > I am using OSPFv2 between the CERs and the Firewalls. Failover works just > fine, however when I fail an OSPF link that has the active default route, > ingress traffic still routes fine and dandy, but egress traffic doesn't. > Both Netiron's OSPF are setup to advertise they are the default route. > > > > (Tony) (Apologies for the seemingly dumb question) but by egress, do > you mean from behind the FW towards your carrier? > Yes. > > > What I'm wondering is, if OSPF is the right solution for this. How do > others solve this problem? > > > > > > Thanks, > > > > Bret > > > > > > Note: Since lately ipv6 has been a hot topic, I'll state that after we > get the BGP all figured out and working properly, ipv6 is our next project. > :) > > > > > > > From bret at getjive.com Wed Jun 22 20:07:06 2011 From: bret at getjive.com (Bret Palsson) Date: Wed, 22 Jun 2011 19:07:06 -0600 Subject: BGP Design question. In-Reply-To: References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: On Wed, Jun 22, 2011 at 5:33 PM, PC wrote: > Who makes the firewall? > > Juniper SSG. We use NSRP and replicate all the RTOs. We have hitless on the Firewalls, have for years. We're now peering with our own carriers vs. using our datacenter's mix. A static route from the junipers to the VIP (VRRP) is probably the way to go. I think. To make this work and be "hitless", your firewall vendor must support > stateful replication of routing protocol data (including OSPF). For > example, Cisco didn't support this in their ASA product until version 8.4 of > code. > > Otherwise, a failover requires OSPF to re-converge -- and quite frankly, > will likely cause some state of confusion on the upstream OSPF peers, loss > of adjacency, and a loss of routing until this occurs. It's like someone > just swapped a router with the same IP to the upstream device -- assuming > your active/standby vendor's implementation only presents itself as one > device. > > However, once this is succesful your current failover topology should work > fine -- even if it takes some time to failover. > > In my opinion though, unless the firewall is serving as "transit" to > downstream routers or other layer 3 elements, and you need to run OSPF to it > (And through it) as a result, it's often just easier to static default route > out from the firewall(s) and redistribute a static route on the upstream > routers for the subnets behind the firewalls. It also helps ensure > symmetrical traffic flows, which is important for stateful firewalls and can > become moderatly confusing when your firewalls start having many interfaces. > > > > > On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson wrote: > >> Here is my current setup in ASCII art. (Please view in a fixed width >> font.) Below the art I'll write out the setup. >> >> >> +--------+ +--------+ >> | Peer A | | Peer A | <-Many carriers. Using 1 carrier >> +---+----+ +----+---+ for this scenario. >> |eBGP | eBGP >> | | >> +---+----+iBGP+----+---+ >> | Router +----+ Router | <-Netiron CERs Routers. >> +-+------+ +------+-+ >> |A `.P A.' |P <-A/P indicates Active/Passive >> | `. .' | link. >> | :: | >> +-+------+' `+------+-+ >> |Act. FW | |Pas. FW | <-Firewalls Active/Passive. >> +--------+ +--------+ >> >> >> To keep this scenario simple, I'm multihoming to one carrier. >> I have two Netiron CERs. Each have a eBGP connection to the same peer. >> The CERs have an iBGP connection to each other. >> That works all fine and dandy. Feel free to comment, however if you think >> there is a better way to do this. >> >> Here comes the tricky part. I have two firewalls in an Active/Passive >> setup. When one fails the other is configured exactly the same >> and picks up where the other left off. (Yes, all the sessions etc. are >> actively mirrored between the devices) >> >> I am using OSPFv2 between the CERs and the Firewalls. Failover works just >> fine, however when I fail an OSPF link that has the active default route, >> ingress traffic still routes fine and dandy, but egress traffic doesn't. >> Both Netiron's OSPF are setup to advertise they are the default route. >> >> What I'm wondering is, if OSPF is the right solution for this. How do >> others solve this problem? >> >> >> Thanks, >> >> Bret >> >> >> Note: Since lately ipv6 has been a hot topic, I'll state that after we get >> the BGP all figured out and working properly, ipv6 is our next project. :) >> >> >> > From nanog.20110127 at jason.roysdon.net Wed Jun 22 22:42:30 2011 From: nanog.20110127 at jason.roysdon.net (Jason Roysdon) Date: Wed, 22 Jun 2011 20:42:30 -0700 Subject: BGP Design question. In-Reply-To: References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: <4E02B626.80908@jason.roysdon.net> I second the static routes, specially from a simplicity standpoint. Add in a pair of layer two switches to simplify further: +--------+ +--------+ | Peer A | | Peer A | <-Many carriers. Using 1 carrier +---+----+ +----+---+ for this scenario. |eBGP | eBGP | | +---+----+iBGP+----+---+ | Router + + Router | <- Routers. Not directly connected +-+------+ +------+-+ | | +-+------+ +------+-+ |L2Switch|----|L2Switch| <- Layer 2 switches, can be stacked +--------+ +--------+ | | +-+------+ +------+-+ |Act. FW |----|Pas. FW | <-Firewalls Active/Passive. +--------+ +--------+ You can lose all of the left leg, or all of the right leg, and still be up. If you want to complicate things, you can add crossing links between it all, but again, beyond BGP and VRRP, this is a very simple design you can easily troubleshoot at 3AM. It's also much easier to document the troubleshooting steps (so you can go on vacation and someone else can solve without calling you) and test upgrades. You can nearly evenly split the traffic by having a VRRP VIP on each edge router, with the other router backing up the first. The firewalls can have two static routes, one to each VIP, and this will roughly load-balance the traffic out on a packet basis. As you peer with the same ISP, this will work just fine. If they have an outage, your edge routers will learn, and even if the circuit drops it'll know, and basically the VIP will just redirect traffic to the other router. Now all your firewalls have to do is maintain stateful session information, not OSPF. If you had two different ISPs (especially if they are not roughly evenly connected), then not having intelligence of the BGP paths in your firewalls can cause an extra hop when it hits router with the longer path, which will redirect it to the router with the shorter path. Speaking from a Cisco/HSRP point of view, you could be more intelligent (re:more complicated, and complication means harder troubleshooting and more documentation needed) during problem periods by having the VIP move routers automatically based on the WAN link dropping and/or a route beyond it being lost (others can comment to if VRRP supports this). This would save one hop to the "broken" router when the BGP path or WAN is down. Jason Roysdon On 06/22/2011 06:07 PM, Bret Palsson wrote: > On Wed, Jun 22, 2011 at 5:33 PM, PC wrote: > >> Who makes the firewall? >> >> > Juniper SSG. We use NSRP and replicate all the RTOs. We have hitless on the > Firewalls, have for years. We're now peering with our own carriers vs. using > our datacenter's mix. > > A static route from the junipers to the VIP (VRRP) is probably the way to > go. I think. > > To make this work and be "hitless", your firewall vendor must support >> stateful replication of routing protocol data (including OSPF). For >> example, Cisco didn't support this in their ASA product until version 8.4 of >> code. >> >> Otherwise, a failover requires OSPF to re-converge -- and quite frankly, >> will likely cause some state of confusion on the upstream OSPF peers, loss >> of adjacency, and a loss of routing until this occurs. It's like someone >> just swapped a router with the same IP to the upstream device -- assuming >> your active/standby vendor's implementation only presents itself as one >> device. >> >> However, once this is succesful your current failover topology should work >> fine -- even if it takes some time to failover. >> >> In my opinion though, unless the firewall is serving as "transit" to >> downstream routers or other layer 3 elements, and you need to run OSPF to it >> (And through it) as a result, it's often just easier to static default route >> out from the firewall(s) and redistribute a static route on the upstream >> routers for the subnets behind the firewalls. It also helps ensure >> symmetrical traffic flows, which is important for stateful firewalls and can >> become moderatly confusing when your firewalls start having many interfaces. >> >> >> >> >> On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson wrote: >> >>> Here is my current setup in ASCII art. (Please view in a fixed width >>> font.) Below the art I'll write out the setup. >>> >>> >>> +--------+ +--------+ >>> | Peer A | | Peer A | <-Many carriers. Using 1 carrier >>> +---+----+ +----+---+ for this scenario. >>> |eBGP | eBGP >>> | | >>> +---+----+iBGP+----+---+ >>> | Router +----+ Router | <-Netiron CERs Routers. >>> +-+------+ +------+-+ >>> |A `.P A.' |P <-A/P indicates Active/Passive >>> | `. .' | link. >>> | :: | >>> +-+------+' `+------+-+ >>> |Act. FW | |Pas. FW | <-Firewalls Active/Passive. >>> +--------+ +--------+ >>> >>> >>> To keep this scenario simple, I'm multihoming to one carrier. >>> I have two Netiron CERs. Each have a eBGP connection to the same peer. >>> The CERs have an iBGP connection to each other. >>> That works all fine and dandy. Feel free to comment, however if you think >>> there is a better way to do this. >>> >>> Here comes the tricky part. I have two firewalls in an Active/Passive >>> setup. When one fails the other is configured exactly the same >>> and picks up where the other left off. (Yes, all the sessions etc. are >>> actively mirrored between the devices) >>> >>> I am using OSPFv2 between the CERs and the Firewalls. Failover works just >>> fine, however when I fail an OSPF link that has the active default route, >>> ingress traffic still routes fine and dandy, but egress traffic doesn't. >>> Both Netiron's OSPF are setup to advertise they are the default route. >>> >>> What I'm wondering is, if OSPF is the right solution for this. How do >>> others solve this problem? >>> >>> >>> Thanks, >>> >>> Bret >>> >>> >>> Note: Since lately ipv6 has been a hot topic, I'll state that after we get >>> the BGP all figured out and working properly, ipv6 is our next project. :) >>> >>> >>> >> > From paul4004 at gmail.com Wed Jun 22 23:04:05 2011 From: paul4004 at gmail.com (PC) Date: Wed, 22 Jun 2011 22:04:05 -0600 Subject: BGP Design question. In-Reply-To: References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: A quick google search says you should be ok with screenos 6.0 or later for the routing protocol replication. I'm looking at your diagram again though. You will want a switch in the middle of your Firewalls and routers, as the firewalls are in an active/standby mode and do not independently run OSPF. And in this case, throw them all on one vlan, and let them peer with each other (2x1). This could actually be your problem. None the less, I agree, why involve it in OSPF and make it complex if there's no real need to? I think your static route idea is the best way to do, given the FW supports presenting itself as a "single" entity. On Wed, Jun 22, 2011 at 7:07 PM, Bret Palsson wrote: > > > On Wed, Jun 22, 2011 at 5:33 PM, PC wrote: > >> Who makes the firewall? >> >> > Juniper SSG. We use NSRP and replicate all the RTOs. We have hitless on the > Firewalls, have for years. We're now peering with our own carriers vs. using > our datacenter's mix. > > A static route from the junipers to the VIP (VRRP) is probably the way to > go. I think. > > To make this work and be "hitless", your firewall vendor must support >> stateful replication of routing protocol data (including OSPF). For >> example, Cisco didn't support this in their ASA product until version 8.4 of >> code. >> >> Otherwise, a failover requires OSPF to re-converge -- and quite frankly, >> will likely cause some state of confusion on the upstream OSPF peers, loss >> of adjacency, and a loss of routing until this occurs. It's like someone >> just swapped a router with the same IP to the upstream device -- assuming >> your active/standby vendor's implementation only presents itself as one >> device. >> >> However, once this is succesful your current failover topology should work >> fine -- even if it takes some time to failover. >> >> In my opinion though, unless the firewall is serving as "transit" to >> downstream routers or other layer 3 elements, and you need to run OSPF to it >> (And through it) as a result, it's often just easier to static default route >> out from the firewall(s) and redistribute a static route on the upstream >> routers for the subnets behind the firewalls. It also helps ensure >> symmetrical traffic flows, which is important for stateful firewalls and can >> become moderatly confusing when your firewalls start having many interfaces. >> >> >> >> >> On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson wrote: >> >>> Here is my current setup in ASCII art. (Please view in a fixed width >>> font.) Below the art I'll write out the setup. >>> >>> >>> +--------+ +--------+ >>> | Peer A | | Peer A | <-Many carriers. Using 1 carrier >>> +---+----+ +----+---+ for this scenario. >>> |eBGP | eBGP >>> | | >>> +---+----+iBGP+----+---+ >>> | Router +----+ Router | <-Netiron CERs Routers. >>> +-+------+ +------+-+ >>> |A `.P A.' |P <-A/P indicates Active/Passive >>> | `. .' | link. >>> | :: | >>> +-+------+' `+------+-+ >>> |Act. FW | |Pas. FW | <-Firewalls Active/Passive. >>> +--------+ +--------+ >>> >>> >>> To keep this scenario simple, I'm multihoming to one carrier. >>> I have two Netiron CERs. Each have a eBGP connection to the same peer. >>> The CERs have an iBGP connection to each other. >>> That works all fine and dandy. Feel free to comment, however if you think >>> there is a better way to do this. >>> >>> Here comes the tricky part. I have two firewalls in an Active/Passive >>> setup. When one fails the other is configured exactly the same >>> and picks up where the other left off. (Yes, all the sessions etc. are >>> actively mirrored between the devices) >>> >>> I am using OSPFv2 between the CERs and the Firewalls. Failover works just >>> fine, however when I fail an OSPF link that has the active default route, >>> ingress traffic still routes fine and dandy, but egress traffic doesn't. >>> Both Netiron's OSPF are setup to advertise they are the default route. >>> >>> What I'm wondering is, if OSPF is the right solution for this. How do >>> others solve this problem? >>> >>> >>> Thanks, >>> >>> Bret >>> >>> >>> Note: Since lately ipv6 has been a hot topic, I'll state that after we >>> get the BGP all figured out and working properly, ipv6 is our next project. >>> :) >>> >>> >>> >> > From hank at efes.iucc.ac.il Thu Jun 23 01:02:31 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 23 Jun 2011 09:02:31 +0300 Subject: BGP Design question. In-Reply-To: <4E02B626.80908@jason.roysdon.net> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: <5.1.0.14.2.20110623085011.036d3c08@efes.iucc.ac.il> At 20:42 22/06/2011 -0700, Jason Roysdon wrote: Let me be a bit of a heretic here. How often does your router fail? Or your firewall? In the 25 years I have gone into customers I have found when they did a cross setup as proposed below by Bret and Jason, only one person truly knew the complete setup and if something broke only he was able to fix it. There is never complete printed documentation: routing design, IPs on all interfaces, subnetting schematic, etc. And if there was at one point, after 2 years it was outdated and never updated and only the *1* guy knew the changes in his head. In that kind of situation, when something stopped working they always had to call in the "guru" to fix it. On the other hand, a simple design of only *one* path (pick either left or right side of each of the ASCII arts), made it possible that even junior network engineers as well as technicians called in on emergency with 4 hours notice, were able to fix the situation much more quickly than the "cross" design. And the MTBF on a single path solution, IMHO, is around 3-4 years. And if you need redundancy, keep a spare box on a shelf, completely loaded with the latest config so that it can be hot-swapped in within 15 minutes of failure. This 1-path design is not for everyone. The vendors always recommend the "cross" design since they sell 2x the amount of boxes but I have found that life works fine with just a 1-path design as well. -Hank >I second the static routes, specially from a simplicity standpoint. Add >in a pair of layer two switches to simplify further: > > > +--------+ +--------+ > | Peer A | | Peer A | <-Many carriers. Using 1 carrier > +---+----+ +----+---+ for this scenario. > |eBGP | eBGP > | | > +---+----+iBGP+----+---+ > | Router + + Router | <- Routers. Not directly connected > +-+------+ +------+-+ > | | > +-+------+ +------+-+ > |L2Switch|----|L2Switch| <- Layer 2 switches, can be stacked > +--------+ +--------+ > | | > +-+------+ +------+-+ > |Act. FW |----|Pas. FW | <-Firewalls Active/Passive. > +--------+ +--------+ > >You can lose all of the left leg, or all of the right leg, and still be >up. If you want to complicate things, you can add crossing links >between it all, but again, beyond BGP and VRRP, this is a very simple >design you can easily troubleshoot at 3AM. It's also much easier to >document the troubleshooting steps (so you can go on vacation and >someone else can solve without calling you) and test upgrades. > >You can nearly evenly split the traffic by having a VRRP VIP on each >edge router, with the other router backing up the first. The firewalls >can have two static routes, one to each VIP, and this will roughly >load-balance the traffic out on a packet basis. As you peer with the >same ISP, this will work just fine. If they have an outage, your edge >routers will learn, and even if the circuit drops it'll know, and >basically the VIP will just redirect traffic to the other router. > >Now all your firewalls have to do is maintain stateful session >information, not OSPF. > >If you had two different ISPs (especially if they are not roughly evenly >connected), then not having intelligence of the BGP paths in your >firewalls can cause an extra hop when it hits router with the longer >path, which will redirect it to the router with the shorter path. > >Speaking from a Cisco/HSRP point of view, you could be more intelligent >(re:more complicated, and complication means harder troubleshooting and >more documentation needed) during problem periods by having the VIP move >routers automatically based on the WAN link dropping and/or a route >beyond it being lost (others can comment to if VRRP supports this). >This would save one hop to the "broken" router when the BGP path or WAN >is down. > >Jason Roysdon > >On 06/22/2011 06:07 PM, Bret Palsson wrote: > > On Wed, Jun 22, 2011 at 5:33 PM, PC wrote: > > > >> Who makes the firewall? > >> > >> > > Juniper SSG. We use NSRP and replicate all the RTOs. We have hitless on the > > Firewalls, have for years. We're now peering with our own carriers vs. > using > > our datacenter's mix. > > > > A static route from the junipers to the VIP (VRRP) is probably the way to > > go. I think. > > > > To make this work and be "hitless", your firewall vendor must support > >> stateful replication of routing protocol data (including OSPF). For > >> example, Cisco didn't support this in their ASA product until version > 8.4 of > >> code. > >> > >> Otherwise, a failover requires OSPF to re-converge -- and quite frankly, > >> will likely cause some state of confusion on the upstream OSPF peers, loss > >> of adjacency, and a loss of routing until this occurs. It's like someone > >> just swapped a router with the same IP to the upstream device -- assuming > >> your active/standby vendor's implementation only presents itself as one > >> device. > >> > >> However, once this is succesful your current failover topology should work > >> fine -- even if it takes some time to failover. > >> > >> In my opinion though, unless the firewall is serving as "transit" to > >> downstream routers or other layer 3 elements, and you need to run OSPF > to it > >> (And through it) as a result, it's often just easier to static default > route > >> out from the firewall(s) and redistribute a static route on the upstream > >> routers for the subnets behind the firewalls. It also helps ensure > >> symmetrical traffic flows, which is important for stateful firewalls > and can > >> become moderatly confusing when your firewalls start having many > interfaces. > >> > >> > >> > >> > >> On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson wrote: > >> > >>> Here is my current setup in ASCII art. (Please view in a fixed width > >>> font.) Below the art I'll write out the setup. > >>> > >>> > >>> +--------+ +--------+ > >>> | Peer A | | Peer A | <-Many carriers. Using 1 carrier > >>> +---+----+ +----+---+ for this scenario. > >>> |eBGP | eBGP > >>> | | > >>> +---+----+iBGP+----+---+ > >>> | Router +----+ Router | <-Netiron CERs Routers. > >>> +-+------+ +------+-+ > >>> |A `.P A.' |P <-A/P indicates Active/Passive > >>> | `. .' | link. > >>> | :: | > >>> +-+------+' `+------+-+ > >>> |Act. FW | |Pas. FW | <-Firewalls Active/Passive. > >>> +--------+ +--------+ > >>> > >>> > >>> To keep this scenario simple, I'm multihoming to one carrier. > >>> I have two Netiron CERs. Each have a eBGP connection to the same peer. > >>> The CERs have an iBGP connection to each other. > >>> That works all fine and dandy. Feel free to comment, however if you think > >>> there is a better way to do this. > >>> > >>> Here comes the tricky part. I have two firewalls in an Active/Passive > >>> setup. When one fails the other is configured exactly the same > >>> and picks up where the other left off. (Yes, all the sessions etc. are > >>> actively mirrored between the devices) > >>> > >>> I am using OSPFv2 between the CERs and the Firewalls. Failover works just > >>> fine, however when I fail an OSPF link that has the active default route, > >>> ingress traffic still routes fine and dandy, but egress traffic doesn't. > >>> Both Netiron's OSPF are setup to advertise they are the default route. > >>> > >>> What I'm wondering is, if OSPF is the right solution for this. How do > >>> others solve this problem? > >>> > >>> > >>> Thanks, > >>> > >>> Bret > >>> > >>> > >>> Note: Since lately ipv6 has been a hot topic, I'll state that after > we get > >>> the BGP all figured out and working properly, ipv6 is our next > project. :) > >>> > >>> > >>> > >> > > From jmamodio at gmail.com Thu Jun 23 01:03:49 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 23 Jun 2011 01:03:49 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0D633D76@RWC-EX1.corp.seven.com> References: <30895183.604.1308344665298.JavaMail.root@benjamin.baylink.com> <5A6D953473350C4B9995546AFE9939EE0D633D76@RWC-EX1.corp.seven.com> Message-ID: Well I just asked the question during the "Getting Ready" panel at the ICANN 41 meeting. Q: How much on top of the $185K is required for a new gTLD Answers: It is hard to say, too many variables, biz plan dependencies, if the string will be contended it can go to a more complex/costly process, but the estimate just for the application could be 2X or 3X the application fee. Another panelist also made reference at the biz plan but stated that you may need to have available 3X the figure of your annual operating budget. Cheers Jorge From bret at getjive.com Thu Jun 23 01:07:00 2011 From: bret at getjive.com (Bret Palsson) Date: Thu, 23 Jun 2011 00:07:00 -0600 Subject: BGP Design question. In-Reply-To: <5.1.0.14.2.20110623085011.036d3c08@efes.iucc.ac.il> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> <5.1.0.14.2.20110623085011.036d3c08@efes.iucc.ac.il> Message-ID: That's fine if you are running a website. When it comes to telecommunications, a 15 minute outage is pretty huge. Especially with certain types of customers: emergency services for example. -Bret On Jun 23, 2011, at 12:02 AM, Hank Nussbacher wrote: > At 20:42 22/06/2011 -0700, Jason Roysdon wrote: > > Let me be a bit of a heretic here. How often does your router fail? Or your firewall? In the 25 years I have gone into customers I have found when they did a cross setup as proposed below by Bret and Jason, only one person truly knew the complete setup and if something broke only he was able to fix it. There is never complete printed documentation: routing design, IPs on all interfaces, subnetting schematic, etc. And if there was at one point, after 2 years it was outdated and never updated and only the *1* guy knew the changes in his head. > > In that kind of situation, when something stopped working they always had to call in the "guru" to fix it. On the other hand, a simple design of only *one* path (pick either left or right side of each of the ASCII arts), made it possible that even junior network engineers as well as technicians called in on emergency with 4 hours notice, were able to fix the situation much more quickly than the "cross" design. And the MTBF on a single path solution, IMHO, is around 3-4 years. And if you need redundancy, keep a spare box on a shelf, completely loaded with the latest config so that it can be hot-swapped in within 15 minutes of failure. > > This 1-path design is not for everyone. The vendors always recommend the "cross" design since they sell 2x the amount of boxes but I have found that life works fine with just a 1-path design as well. > > -Hank > > >> I second the static routes, specially from a simplicity standpoint. Add >> in a pair of layer two switches to simplify further: >> >> >> +--------+ +--------+ >> | Peer A | | Peer A | <-Many carriers. Using 1 carrier >> +---+----+ +----+---+ for this scenario. >> |eBGP | eBGP >> | | >> +---+----+iBGP+----+---+ >> | Router + + Router | <- Routers. Not directly connected >> +-+------+ +------+-+ >> | | >> +-+------+ +------+-+ >> |L2Switch|----|L2Switch| <- Layer 2 switches, can be stacked >> +--------+ +--------+ >> | | >> +-+------+ +------+-+ >> |Act. FW |----|Pas. FW | <-Firewalls Active/Passive. >> +--------+ +--------+ >> >> You can lose all of the left leg, or all of the right leg, and still be >> up. If you want to complicate things, you can add crossing links >> between it all, but again, beyond BGP and VRRP, this is a very simple >> design you can easily troubleshoot at 3AM. It's also much easier to >> document the troubleshooting steps (so you can go on vacation and >> someone else can solve without calling you) and test upgrades. >> >> You can nearly evenly split the traffic by having a VRRP VIP on each >> edge router, with the other router backing up the first. The firewalls >> can have two static routes, one to each VIP, and this will roughly >> load-balance the traffic out on a packet basis. As you peer with the >> same ISP, this will work just fine. If they have an outage, your edge >> routers will learn, and even if the circuit drops it'll know, and >> basically the VIP will just redirect traffic to the other router. >> >> Now all your firewalls have to do is maintain stateful session >> information, not OSPF. >> >> If you had two different ISPs (especially if they are not roughly evenly >> connected), then not having intelligence of the BGP paths in your >> firewalls can cause an extra hop when it hits router with the longer >> path, which will redirect it to the router with the shorter path. >> >> Speaking from a Cisco/HSRP point of view, you could be more intelligent >> (re:more complicated, and complication means harder troubleshooting and >> more documentation needed) during problem periods by having the VIP move >> routers automatically based on the WAN link dropping and/or a route >> beyond it being lost (others can comment to if VRRP supports this). >> This would save one hop to the "broken" router when the BGP path or WAN >> is down. >> >> Jason Roysdon >> >> On 06/22/2011 06:07 PM, Bret Palsson wrote: >> > On Wed, Jun 22, 2011 at 5:33 PM, PC wrote: >> > >> >> Who makes the firewall? >> >> >> >> >> > Juniper SSG. We use NSRP and replicate all the RTOs. We have hitless on the >> > Firewalls, have for years. We're now peering with our own carriers vs. using >> > our datacenter's mix. >> > >> > A static route from the junipers to the VIP (VRRP) is probably the way to >> > go. I think. >> > >> > To make this work and be "hitless", your firewall vendor must support >> >> stateful replication of routing protocol data (including OSPF). For >> >> example, Cisco didn't support this in their ASA product until version 8.4 of >> >> code. >> >> >> >> Otherwise, a failover requires OSPF to re-converge -- and quite frankly, >> >> will likely cause some state of confusion on the upstream OSPF peers, loss >> >> of adjacency, and a loss of routing until this occurs. It's like someone >> >> just swapped a router with the same IP to the upstream device -- assuming >> >> your active/standby vendor's implementation only presents itself as one >> >> device. >> >> >> >> However, once this is succesful your current failover topology should work >> >> fine -- even if it takes some time to failover. >> >> >> >> In my opinion though, unless the firewall is serving as "transit" to >> >> downstream routers or other layer 3 elements, and you need to run OSPF to it >> >> (And through it) as a result, it's often just easier to static default route >> >> out from the firewall(s) and redistribute a static route on the upstream >> >> routers for the subnets behind the firewalls. It also helps ensure >> >> symmetrical traffic flows, which is important for stateful firewalls and can >> >> become moderatly confusing when your firewalls start having many interfaces. >> >> >> >> >> >> >> >> >> >> On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson wrote: >> >> >> >>> Here is my current setup in ASCII art. (Please view in a fixed width >> >>> font.) Below the art I'll write out the setup. >> >>> >> >>> >> >>> +--------+ +--------+ >> >>> | Peer A | | Peer A | <-Many carriers. Using 1 carrier >> >>> +---+----+ +----+---+ for this scenario. >> >>> |eBGP | eBGP >> >>> | | >> >>> +---+----+iBGP+----+---+ >> >>> | Router +----+ Router | <-Netiron CERs Routers. >> >>> +-+------+ +------+-+ >> >>> |A `.P A.' |P <-A/P indicates Active/Passive >> >>> | `. .' | link. >> >>> | :: | >> >>> +-+------+' `+------+-+ >> >>> |Act. FW | |Pas. FW | <-Firewalls Active/Passive. >> >>> +--------+ +--------+ >> >>> >> >>> >> >>> To keep this scenario simple, I'm multihoming to one carrier. >> >>> I have two Netiron CERs. Each have a eBGP connection to the same peer. >> >>> The CERs have an iBGP connection to each other. >> >>> That works all fine and dandy. Feel free to comment, however if you think >> >>> there is a better way to do this. >> >>> >> >>> Here comes the tricky part. I have two firewalls in an Active/Passive >> >>> setup. When one fails the other is configured exactly the same >> >>> and picks up where the other left off. (Yes, all the sessions etc. are >> >>> actively mirrored between the devices) >> >>> >> >>> I am using OSPFv2 between the CERs and the Firewalls. Failover works just >> >>> fine, however when I fail an OSPF link that has the active default route, >> >>> ingress traffic still routes fine and dandy, but egress traffic doesn't. >> >>> Both Netiron's OSPF are setup to advertise they are the default route. >> >>> >> >>> What I'm wondering is, if OSPF is the right solution for this. How do >> >>> others solve this problem? >> >>> >> >>> >> >>> Thanks, >> >>> >> >>> Bret >> >>> >> >>> >> >>> Note: Since lately ipv6 has been a hot topic, I'll state that after we get >> >>> the BGP all figured out and working properly, ipv6 is our next project. :) >> >>> >> >>> >> >>> >> >> >> > > From brunner at nic-naa.net Thu Jun 23 00:28:51 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Thu, 23 Jun 2011 01:28:51 -0400 Subject: ICANN to allow commercial gTLDs Message-ID: <201106230528.p5N5SqkD086715@nic-naa.net> > Well I just asked the question during the "Getting Ready" panel at the > ICANN 41 meeting. keep in mind that the venues for asking precise questions for the purpose of obtaining accurate answers of record are tdg-legal, or the saturday gnso gtld hours ("the kurt show"). > Q: How much on top of the $185K is required for a new gTLD zero, in applicatin fee, more, where the applicant seeks extended evaluation, more, where a party with standing pays an objection fee and the applicant choses to contest the objection ("loser pays" model), ... (multiple objections are possible, though they may be consolidated). there are service level agreements that have cost consequences. there is a continuity instrument requirement, which creates a funding requirement, and upon the event triggering "continuity", a cost to the applicant. the current number is three years of operating cost, which is the likely source of your panelist's unreflected response, but the actual functional requirements for continuity are not yet defined, and therefore not fixed costs, and there are means to reduce these substantially. how fully informed an answer did you really want at an intro event staffed by commercial service or application services providers? -e From jmamodio at gmail.com Thu Jun 23 03:20:53 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 23 Jun 2011 03:20:53 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: <201106230528.p5N5SqkD086715@nic-naa.net> References: <201106230528.p5N5SqkD086715@nic-naa.net> Message-ID: > keep in mind that the venues for asking precise questions for the > purpose of obtaining accurate answers of record are tdg-legal, or > the saturday gnso gtld hours ("the kurt show"). "Kurt Show" that's a good one. I was not expecting any elaborated response, just see if anybody on that panel had a number in mind. It is not an easy question to answer, and I'm not referring about the cost of the application per se, there is some level of misinformation (fed by some media outlets) that with the new gTLD program if you want a .COM you pay $8.99 (or whatever is the offer of the day), do you want your own .BRAND you pay $185K, which as you know is not exactly right. Then the actual question, besides the application fee, is how much dough you need to play on the gTLD game, and I'm not talking about community oriented, etc. Lets say I want to apply for .WINE with commercial purposes, then what is a ballpark figure for the funds/investment required ? My guess, it is way way above the $185K Regards Jorge From brunner at nic-naa.net Thu Jun 23 01:49:57 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Thu, 23 Jun 2011 02:49:57 -0400 Subject: ICANN to allow commercial gTLDs Message-ID: <201106230649.p5N6nvUo087150@nic-naa.net> > Lets say I want to apply for .WINE with commercial purposes, then what > is a ballpark figure for the funds/investment required ? > > My guess, it is way way above the $185K assuming no defect in the application, necessitiating a second bite at the apple, at cost (extended eval), and no objections by parties with standing, all of which are nuisance costs in this scenario, the controlling cost is "none of the above". it is not the $185k fee. it is not any of, singally or in their aggregate, the scheduled fees for extended eval or objections. it is not the pick-your-poison capital investment in sites, boxen, staff. it is not the pick-your-other-poison marketing investment in campaigns and registrars and pricing programs. it is not the three-times-annual-unstated-continuity cost of a security instrument. it is not the recurring $25k fee. it is the one-dollar-more-than-amount of any other applicant in the contention set which contains "WINE", which might be some other business organization intending to acquire "WINE" for their purposes. applications not subject to allocation under the community comparative evaluation (and i've not looked up the current name of this) 14 of 16 rule, nor to allocation under the informed consent of the relevant public administration, are subjet to allocation, where there is contention, defined by two or more applications in the same contention set, by auction. so for your purposes, nothing matters except the depth of your last competitor's pocket, where she/he reaches lint, you've still got a piece of silver. of course, being ruined by winning an auction is known in the literature, as are bizorg mechanisms for recapitalizations. -e From jean.clery at beehive.fr Thu Jun 23 05:43:51 2011 From: jean.clery at beehive.fr (Jean Clery) Date: Thu, 23 Jun 2011 12:43:51 +0200 Subject: Routing Provider SFR in france Message-ID: <331C413427FF654FBBADD7D6AAFA44FD54447C25A8@srvmail01.beehive.loc> Afternoon, Many routing problems into the network of French Internet operator "LDCOM SFR" http://bgpupdates.potaroo.net/instability/plot-table.png see June 22 on graph. Regards, __________________________ Jean CLERY Technical Dep. GSM : +33 628 553 540 Support : +33 491 100 441 [cid:image001.jpg at 01CC31A3.3468DEA0] [cid:image002.jpg at 01CC31A3.3468DEA0] -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 28503 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 31656 bytes Desc: image002.jpg URL: From bhmccie at gmail.com Thu Jun 23 07:44:33 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 23 Jun 2011 07:44:33 -0500 Subject: BGP Design question. In-Reply-To: References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> <5.1.0.14.2.20110623085011.036d3c08@efes.iucc.ac.il> Message-ID: <4E033531.5050604@gmail.com> Agreed. At an enterprise level, there is no need to risk extended downtime to save a buck or two. Redundant hardware is always a good way to keep Murphy out of the equation. And as far as hardware failures go, it's not that common. Nowadays it's the bugs in overly complicated code on your gear that get you first. I miss IOS 11.3..... -Hammer- On 06/23/2011 01:07 AM, Bret Palsson wrote: > That's fine if you are running a website. When it comes to telecommunications, a 15 minute outage is pretty huge. Especially with certain types of customers: emergency services for example. > > -Bret > > On Jun 23, 2011, at 12:02 AM, Hank Nussbacher wrote: > > >> At 20:42 22/06/2011 -0700, Jason Roysdon wrote: >> >> Let me be a bit of a heretic here. How often does your router fail? Or your firewall? In the 25 years I have gone into customers I have found when they did a cross setup as proposed below by Bret and Jason, only one person truly knew the complete setup and if something broke only he was able to fix it. There is never complete printed documentation: routing design, IPs on all interfaces, subnetting schematic, etc. And if there was at one point, after 2 years it was outdated and never updated and only the *1* guy knew the changes in his head. >> >> In that kind of situation, when something stopped working they always had to call in the "guru" to fix it. On the other hand, a simple design of only *one* path (pick either left or right side of each of the ASCII arts), made it possible that even junior network engineers as well as technicians called in on emergency with 4 hours notice, were able to fix the situation much more quickly than the "cross" design. And the MTBF on a single path solution, IMHO, is around 3-4 years. And if you need redundancy, keep a spare box on a shelf, completely loaded with the latest config so that it can be hot-swapped in within 15 minutes of failure. >> >> This 1-path design is not for everyone. The vendors always recommend the "cross" design since they sell 2x the amount of boxes but I have found that life works fine with just a 1-path design as well. >> >> -Hank >> >> >> >>> I second the static routes, specially from a simplicity standpoint. Add >>> in a pair of layer two switches to simplify further: >>> >>> >>> +--------+ +--------+ >>> | Peer A | | Peer A |<-Many carriers. Using 1 carrier >>> +---+----+ +----+---+ for this scenario. >>> |eBGP | eBGP >>> | | >>> +---+----+iBGP+----+---+ >>> | Router + + Router |<- Routers. Not directly connected >>> +-+------+ +------+-+ >>> | | >>> +-+------+ +------+-+ >>> |L2Switch|----|L2Switch|<- Layer 2 switches, can be stacked >>> +--------+ +--------+ >>> | | >>> +-+------+ +------+-+ >>> |Act. FW |----|Pas. FW |<-Firewalls Active/Passive. >>> +--------+ +--------+ >>> >>> You can lose all of the left leg, or all of the right leg, and still be >>> up. If you want to complicate things, you can add crossing links >>> between it all, but again, beyond BGP and VRRP, this is a very simple >>> design you can easily troubleshoot at 3AM. It's also much easier to >>> document the troubleshooting steps (so you can go on vacation and >>> someone else can solve without calling you) and test upgrades. >>> >>> You can nearly evenly split the traffic by having a VRRP VIP on each >>> edge router, with the other router backing up the first. The firewalls >>> can have two static routes, one to each VIP, and this will roughly >>> load-balance the traffic out on a packet basis. As you peer with the >>> same ISP, this will work just fine. If they have an outage, your edge >>> routers will learn, and even if the circuit drops it'll know, and >>> basically the VIP will just redirect traffic to the other router. >>> >>> Now all your firewalls have to do is maintain stateful session >>> information, not OSPF. >>> >>> If you had two different ISPs (especially if they are not roughly evenly >>> connected), then not having intelligence of the BGP paths in your >>> firewalls can cause an extra hop when it hits router with the longer >>> path, which will redirect it to the router with the shorter path. >>> >>> Speaking from a Cisco/HSRP point of view, you could be more intelligent >>> (re:more complicated, and complication means harder troubleshooting and >>> more documentation needed) during problem periods by having the VIP move >>> routers automatically based on the WAN link dropping and/or a route >>> beyond it being lost (others can comment to if VRRP supports this). >>> This would save one hop to the "broken" router when the BGP path or WAN >>> is down. >>> >>> Jason Roysdon >>> >>> On 06/22/2011 06:07 PM, Bret Palsson wrote: >>> >>>> On Wed, Jun 22, 2011 at 5:33 PM, PC wrote: >>>> >>>> >>>>> Who makes the firewall? >>>>> >>>>> >>>>> >>>> Juniper SSG. We use NSRP and replicate all the RTOs. We have hitless on the >>>> Firewalls, have for years. We're now peering with our own carriers vs. using >>>> our datacenter's mix. >>>> >>>> A static route from the junipers to the VIP (VRRP) is probably the way to >>>> go. I think. >>>> >>>> To make this work and be "hitless", your firewall vendor must support >>>> >>>>> stateful replication of routing protocol data (including OSPF). For >>>>> example, Cisco didn't support this in their ASA product until version 8.4 of >>>>> code. >>>>> >>>>> Otherwise, a failover requires OSPF to re-converge -- and quite frankly, >>>>> will likely cause some state of confusion on the upstream OSPF peers, loss >>>>> of adjacency, and a loss of routing until this occurs. It's like someone >>>>> just swapped a router with the same IP to the upstream device -- assuming >>>>> your active/standby vendor's implementation only presents itself as one >>>>> device. >>>>> >>>>> However, once this is succesful your current failover topology should work >>>>> fine -- even if it takes some time to failover. >>>>> >>>>> In my opinion though, unless the firewall is serving as "transit" to >>>>> downstream routers or other layer 3 elements, and you need to run OSPF to it >>>>> (And through it) as a result, it's often just easier to static default route >>>>> out from the firewall(s) and redistribute a static route on the upstream >>>>> routers for the subnets behind the firewalls. It also helps ensure >>>>> symmetrical traffic flows, which is important for stateful firewalls and can >>>>> become moderatly confusing when your firewalls start having many interfaces. >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson wrote: >>>>> >>>>> >>>>>> Here is my current setup in ASCII art. (Please view in a fixed width >>>>>> font.) Below the art I'll write out the setup. >>>>>> >>>>>> >>>>>> +--------+ +--------+ >>>>>> | Peer A | | Peer A |<-Many carriers. Using 1 carrier >>>>>> +---+----+ +----+---+ for this scenario. >>>>>> |eBGP | eBGP >>>>>> | | >>>>>> +---+----+iBGP+----+---+ >>>>>> | Router +----+ Router |<-Netiron CERs Routers. >>>>>> +-+------+ +------+-+ >>>>>> |A `.P A.' |P<-A/P indicates Active/Passive >>>>>> | `. .' | link. >>>>>> | :: | >>>>>> +-+------+' `+------+-+ >>>>>> |Act. FW | |Pas. FW |<-Firewalls Active/Passive. >>>>>> +--------+ +--------+ >>>>>> >>>>>> >>>>>> To keep this scenario simple, I'm multihoming to one carrier. >>>>>> I have two Netiron CERs. Each have a eBGP connection to the same peer. >>>>>> The CERs have an iBGP connection to each other. >>>>>> That works all fine and dandy. Feel free to comment, however if you think >>>>>> there is a better way to do this. >>>>>> >>>>>> Here comes the tricky part. I have two firewalls in an Active/Passive >>>>>> setup. When one fails the other is configured exactly the same >>>>>> and picks up where the other left off. (Yes, all the sessions etc. are >>>>>> actively mirrored between the devices) >>>>>> >>>>>> I am using OSPFv2 between the CERs and the Firewalls. Failover works just >>>>>> fine, however when I fail an OSPF link that has the active default route, >>>>>> ingress traffic still routes fine and dandy, but egress traffic doesn't. >>>>>> Both Netiron's OSPF are setup to advertise they are the default route. >>>>>> >>>>>> What I'm wondering is, if OSPF is the right solution for this. How do >>>>>> others solve this problem? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Bret >>>>>> >>>>>> >>>>>> Note: Since lately ipv6 has been a hot topic, I'll state that after we get >>>>>> the BGP all figured out and working properly, ipv6 is our next project. :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >> > > From eesslinger at fpu-tn.com Thu Jun 23 08:07:40 2011 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Thu, 23 Jun 2011 08:07:40 -0500 Subject: ping me please... Message-ID: I have just turned up and migrated to a new circuit. I'm getting a few reports from one customer that some of his users are unable to reach his system. If I could get people on the list to ping 65.5.48.2, and if it fails, to do a traceroute and email it to me offlist? I'd appreciate it. Thanks. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From Neil.Robst at ioko.com Thu Jun 23 08:15:09 2011 From: Neil.Robst at ioko.com (Neil Robst) Date: Thu, 23 Jun 2011 14:15:09 +0100 Subject: ping me please... In-Reply-To: References: Message-ID: <7A57DCAA71129142A6EF9C0074D38A8F33E2FC480F@INTCL1EX01.uk.ioko365.com> Works from here (AS30914) Regards, Neil > -----Original Message----- > From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] > Sent: 23 June 2011 14:08 > To: 'nanog at nanog.org' > Subject: ping me please... > > I have just turned up and migrated to a new circuit. I'm getting a few reports > from one customer that some of his users are unable to reach his system. > If I could get people on the list to ping 65.5.48.2, and if it fails, to do a > traceroute and email it to me offlist? I'd appreciate it. > Thanks. > __________________________ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities http://www.fpu- > tn.com/ > (931)433-1522 ext 165 > > This message may contain confidential and/or proprietary information and is > intended for the person/entity to whom it was originally addressed. Any use > by others is strictly prohibited. This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. ioko365 Limited does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. From zeusdadog at gmail.com Thu Jun 23 08:20:46 2011 From: zeusdadog at gmail.com (Jay Nakamura) Date: Thu, 23 Jun 2011 09:20:46 -0400 Subject: ping me please... In-Reply-To: References: Message-ID: You may want to take a look at traceroute.org and use the many sites listed there. On Thu, Jun 23, 2011 at 9:07 AM, Eric J Esslinger wrote: > I have just turned up and migrated to a new circuit. I'm getting a few reports from one customer that some of his users are unable to reach his system. > If I could get people on the list to ping 65.5.48.2, and if it fails, to do a traceroute and email it to me offlist? I'd appreciate it. > Thanks. > __________________________ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ > (931)433-1522 ext 165 > > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. > > From ristic.sasa at gmail.com Thu Jun 23 08:20:36 2011 From: ristic.sasa at gmail.com (Sasa Ristic) Date: Thu, 23 Jun 2011 15:20:36 +0200 Subject: ping me please... In-Reply-To: <7A57DCAA71129142A6EF9C0074D38A8F33E2FC480F@INTCL1EX01.uk.ioko365.com> References: <7A57DCAA71129142A6EF9C0074D38A8F33E2FC480F@INTCL1EX01.uk.ioko365.com> Message-ID: works from AS15982 [admin at router] > ping 65.5.48.2 65.5.48.2 64 byte ping: ttl=245 time=141 ms 65.5.48.2 64 byte ping: ttl=245 time=141 ms 65.5.48.2 64 byte ping: ttl=245 time=141 ms 65.5.48.2 64 byte ping: ttl=245 time=141 ms 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 141/141.0/141 ms On Thu, Jun 23, 2011 at 15:15, Neil Robst wrote: > Works from here (AS30914) > > Regards, > Neil > >> -----Original Message----- >> From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] >> Sent: 23 June 2011 14:08 >> To: 'nanog at nanog.org' >> Subject: ping me please... >> >> I have just turned up and migrated to a new circuit. I'm getting a few reports >> from one customer that some of his users are unable to reach his system. >> If I could get people on the list to ping 65.5.48.2, and if it fails, to do a >> traceroute and email it to me offlist? I'd appreciate it. >> Thanks. >> __________________________ >> Eric Esslinger >> Information Services Manager - Fayetteville Public Utilities http://www.fpu- >> tn.com/ >> (931)433-1522 ext 165 >> >> This message may contain confidential and/or proprietary information and is >> intended for the person/entity to whom it was originally addressed. Any use >> by others is strictly prohibited. > > > This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. > > Internet communications are not guaranteed to be secure or virus-free. ioko365 Limited does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. > > -- ricky From jlewis at lewis.org Thu Jun 23 08:21:26 2011 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 23 Jun 2011 09:21:26 -0400 (EDT) Subject: ping me please... In-Reply-To: References: Message-ID: On Thu, 23 Jun 2011, Eric J Esslinger wrote: > I have just turned up and migrated to a new circuit. I'm getting a few reports from one customer that some of his users are unable to reach his system. > If I could get people on the list to ping 65.5.48.2, and if it fails, to do a traceroute and email it to me offlist? I'd appreciate it. > Thanks. You can trace to it yourself from all over the world...unfortunately, the vast majority of these are going to use UDP packets, which you appear to be blocking at the destination. http://lmgtfy.com/?q=traceroute.org ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From eesslinger at fpu-tn.com Thu Jun 23 08:30:03 2011 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Thu, 23 Jun 2011 08:30:03 -0500 Subject: ping me please... Think I've got enough data, thanks In-Reply-To: Message-ID: > -----Original Message----- > From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] > Sent: Thursday, June 23, 2011 8:08 AM > To: 'nanog at nanog.org' > Subject: ping me please... > > > I have just turned up and migrated to a new circuit. I'm > getting a few reports from one customer that some of his > users are unable to reach his system. If I could get people > on the list to ping 65.5.48.2, and if it fails, to do a > traceroute and email it to me offlist? I'd appreciate it. > Thanks. I think I've got enough data. If there's a problem it's specific to a few users of that one customer and I need them to give me more information to isolate it. None of my looking glass tests (I was aware of traceroute.org and used ~50 of the sites before coming to the list. I also saw no problems). Thank you for the help. Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: Eric J Esslinger.vcf Type: text/x-vcard Size: 498 bytes Desc: Eric J Esslinger.vcf URL: From Valdis.Kletnieks at vt.edu Thu Jun 23 08:59:00 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 23 Jun 2011 09:59:00 -0400 Subject: BGP Design question. In-Reply-To: Your message of "Thu, 23 Jun 2011 07:44:33 CDT." <4E033531.5050604@gmail.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> <5.1.0.14.2.20110623085011.036d3c08@efes.iucc.ac.il> <4E033531.5050604@gmail.com> Message-ID: <41968.1308837540@turing-police.cc.vt.edu> On Thu, 23 Jun 2011 07:44:33 CDT, -Hammer- said: > Agreed. At an enterprise level, there is no need to risk extended > downtime to save a buck or two. Redundant hardware is always a good way > to keep Murphy out of the equation. And as far as hardware failures go, > it's not that common. Nowadays it's the bugs in overly complicated code > on your gear that get you first. I miss IOS 11.3..... So what you're saying is we're more likely to take an outage due to tripping over a bug, so we should go for the simplest non-crossover config to minimize the chances of hitting a bug. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From baconzombie at gmail.com Thu Jun 23 09:01:38 2011 From: baconzombie at gmail.com (Bacon Zombie) Date: Thu, 23 Jun 2011 15:01:38 +0100 Subject: ping me please... In-Reply-To: References: Message-ID: Reachable from Ireland using Eircom AS5466. Host is up (0.029s latency). Not shown: 64531 filtered ports, 1002 closed ports PORT STATE SERVICE VERSION 443/tcp open ssl/http Cisco ASA firewall http config (Cisco AWARE 2.0) |_http-methods: No Allow or Public header in OPTIONS response (status code 302) | http-title: SSL VPN Service |_Requested resource was http://65.5.48.2/+CSCOE+/logon.html 10000/tcp open tcpwrapped Network Distance: 4 hops TRACEROUTE (using port 995/tcp) HOP RTT ADDRESS 1 0.00 ms 10.xxx.xxx.xxx 2 16.00 ms 192.xxx.xxx.xxx 3 16.00 ms xxx.xxx.xxx.xxx 4 16.00 ms 65.5.48.2 On 23 June 2011 14:07, Eric J Esslinger wrote: > I have just turned up and migrated to a new circuit. I'm getting a few reports from one customer that some of his users are unable to reach his system. > If I could get people on the list to ping 65.5.48.2, and if it fails, to do a traceroute and email it to me offlist? I'd appreciate it. > Thanks. > __________________________ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ > (931)433-1522 ext 165 > > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. > > -- BaconZombie LOAD "*",8,1 From jean.clery at beehive.fr Thu Jun 23 09:02:22 2011 From: jean.clery at beehive.fr (Jean Clery) Date: Thu, 23 Jun 2011 16:02:22 +0200 Subject: ping me please... In-Reply-To: References: Message-ID: <331C413427FF654FBBADD7D6AAFA44FD54447C25C3@srvmail01.beehive.loc> Hi, >From France provider "Orange" echo request reply ok with 700ms Regards, __________________________ Jean CLERY Technical Dep. GSM : +33 628 553 540 Support : +33 491 100 441 -----Message d'origine----- De?: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] Envoy??: jeudi 23 juin 2011 15:08 ??: 'nanog at nanog.org' Objet?: ping me please... I have just turned up and migrated to a new circuit. I'm getting a few reports from one customer that some of his users are unable to reach his system. If I could get people on the list to ping 65.5.48.2, and if it fails, to do a traceroute and email it to me offlist? I'd appreciate it. Thanks. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From bhmccie at gmail.com Thu Jun 23 10:44:41 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 23 Jun 2011 10:44:41 -0500 Subject: BGP Design question. In-Reply-To: <41968.1308837540@turing-police.cc.vt.edu> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> <5.1.0.14.2.20110623085011.036d3c08@efes.iucc.ac.il> <4E033531.5050604@gmail.com> <41968.1308837540@turing-police.cc.vt.edu> Message-ID: <4E035F69.9090908@gmail.com> HaHa! I agree with keeping it simple. I keep my routers simple. I keep my switches simple. Sometimes it's not as easy on a Layer 7 FW or a load balancer. So plan accordingly. :) -Hammer- On 06/23/2011 08:59 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 23 Jun 2011 07:44:33 CDT, -Hammer- said: > >> Agreed. At an enterprise level, there is no need to risk extended >> downtime to save a buck or two. Redundant hardware is always a good way >> to keep Murphy out of the equation. And as far as hardware failures go, >> it's not that common. Nowadays it's the bugs in overly complicated code >> on your gear that get you first. I miss IOS 11.3..... >> > So what you're saying is we're more likely to take an outage due to tripping > over a bug, so we should go for the simplest non-crossover config to minimize > the chances of hitting a bug. ;) > From dmm at 1-4-5.net Thu Jun 23 11:22:53 2011 From: dmm at 1-4-5.net (David Meyer) Date: Thu, 23 Jun 2011 09:22:53 -0700 Subject: [NANOG-announce] NANOG 53 Call For Presentations available! Message-ID: Folks, The Call for Presentations for NANOG 53 is up on http://nanog.org/meetings/nanog53/callforpresent.php Looking forward to your submissions and seeing you all in Philadelphia. Dave (for the NANOG PC) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From gbonser at seven.com Thu Jun 23 12:04:41 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 23 Jun 2011 10:04:41 -0700 Subject: BGP Design question. In-Reply-To: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0D633E21@RWC-EX1.corp.seven.com> > I am using OSPFv2 between the CERs and the Firewalls. Failover works > just fine, however when I fail an OSPF link that has the active default > route, ingress traffic still routes fine and dandy, but egress traffic > doesn't. Both Netiron's OSPF are setup to advertise they are the > default route. > > What I'm wondering is, if OSPF is the right solution for this. How do > others solve this problem? > > > Thanks, > > Bret Man, I would have a lot of questions. The CER's are a layer2/3 switch. What is the topology and how are you "failing" the link? Are the links to the firewalls on a vlan with the interfaces being a ve on the CERs or are the interfaces to the firewalls "route-only"? Is that vlan trunked across on the link between the two switches? How are you failing it over? There are lots of "failover" things you could be doing (turning off the left router, turning off the left firewall, disabling the primary port from the left router to the left firewall). When you say it doesn't work are you saying that it doesn't work if you disable the port from the left router to the left firewall or are you saying it doesn't work with the right firewall takes over from the left or what. There are so many subtle configuration possibilities with these units that just given a wiring diagram without also seeing the config makes it hard to help. I am guessing that the connections to the firewalls are not MCT cluster trunks because you can't run layer3 routing protocols with MCT (yet) on the CERs. Is it link failover or device failover that isn't working? From johnl at iecc.com Thu Jun 23 12:10:06 2011 From: johnl at iecc.com (John Levine) Date: 23 Jun 2011 17:10:06 -0000 Subject: ICANN to allow commercial gTLDs In-Reply-To: Message-ID: <20110623171006.47716.qmail@joyce.lan> >Lets say I want to apply for .WINE with commercial purposes, then what >is a ballpark figure for the funds/investment required ? I wouldn't try it with less than a million bucks in hand. Beyond the ICANN application nonsense, you'd also want to budget something for running and promoting it for however long it takes to verify that it was a silly idea and then go bust. R's, John From sethm at rollernet.us Thu Jun 23 13:52:04 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 23 Jun 2011 11:52:04 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <201106222207.p5MM7rFb045569@aurora.sol.net> References: <201106222207.p5MM7rFb045569@aurora.sol.net> Message-ID: <4E038B54.8010901@rollernet.us> On 6/22/11 3:07 PM, Joe Greco wrote: > Your average person cares a whole lot less about what's crossing their > Internet connection than they care about whether or not "this works" > than I do. > > I continue to be amazed at the quality of Netflix video coming across > the wire. Our local cable company just recently upped their old 7M/512K > normal tier to 10M/1M, and is now offering much higher speed tiers as > well, which isn't going to be discouraging to anyone wanting to do this > sort of thing. What still dismays me is the pitiful low upstream speeds that are still common. Not because most people want to run servers or host content at home (they don't), but because they want to share content with friends and the user experience can be greatly enhanced with symmetric speeds. Sharing those HD videos or 1,000 pictures during party weekend is less painful if it takes 10 minutes to upload rather than 10 hours. Also, things like GoToMyPC and "back to my Mac" are end user experience things that are best served by not using horribly low upstream speeds. I can understand that a decade ago most people were still sharing content offline, but dare I say now sharing online is becoming more common than offline. > I guess the most telling bit of all this was when I found myself needing > an ethernet switch behind the TV, AND WAS ABLE TO FILL ALL THE PORTS, for > > Internet-capable TV set > Internet-capable Blu-Ray player > Networkable TiVo > AppleTV > Video Game Console > Networked AV Receiver > UPS > and an uplink of course. 8 ports. Geez. > > That keeps striking me as such a paradigm shift. > I was talking to one of my friends about when we wired his house a while back. When he moved in we wired the crap out of it - we put Ethernet ports in the kitchen, behind the sofa, everywhere. The one place we didn't put anything though was behind the entertainment center. We put it lots of coax and wiring for surround sound, but at the time it never occurred to us to put Ethernet there. Of course, now there has to be without question. ~Seth From owen at delong.com Thu Jun 23 14:15:03 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Jun 2011 12:15:03 -0700 Subject: BGP Design question. In-Reply-To: <4E033531.5050604@gmail.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> <5.1.0.14.2.20110623085011.036d3c08@efes.iucc.ac.il> <4E033531.5050604@gmail.com> Message-ID: <561C0511-7936-4475-AD3A-016D98DC92ED@delong.com> Except in those (becoming less rare than hardware failure) instances where the software controlling the failover process is the actual cause of the outage. Owen On Jun 23, 2011, at 5:44 AM, -Hammer- wrote: > Agreed. At an enterprise level, there is no need to risk extended downtime to save a buck or two. Redundant hardware is always a good way to keep Murphy out of the equation. And as far as hardware failures go, it's not that common. Nowadays it's the bugs in overly complicated code on your gear that get you first. I miss IOS 11.3..... > > -Hammer- > > > > On 06/23/2011 01:07 AM, Bret Palsson wrote: >> That's fine if you are running a website. When it comes to telecommunications, a 15 minute outage is pretty huge. Especially with certain types of customers: emergency services for example. >> >> -Bret >> >> On Jun 23, 2011, at 12:02 AM, Hank Nussbacher wrote: >> >> >>> At 20:42 22/06/2011 -0700, Jason Roysdon wrote: >>> >>> Let me be a bit of a heretic here. How often does your router fail? Or your firewall? In the 25 years I have gone into customers I have found when they did a cross setup as proposed below by Bret and Jason, only one person truly knew the complete setup and if something broke only he was able to fix it. There is never complete printed documentation: routing design, IPs on all interfaces, subnetting schematic, etc. And if there was at one point, after 2 years it was outdated and never updated and only the *1* guy knew the changes in his head. >>> >>> In that kind of situation, when something stopped working they always had to call in the "guru" to fix it. On the other hand, a simple design of only *one* path (pick either left or right side of each of the ASCII arts), made it possible that even junior network engineers as well as technicians called in on emergency with 4 hours notice, were able to fix the situation much more quickly than the "cross" design. And the MTBF on a single path solution, IMHO, is around 3-4 years. And if you need redundancy, keep a spare box on a shelf, completely loaded with the latest config so that it can be hot-swapped in within 15 minutes of failure. >>> >>> This 1-path design is not for everyone. The vendors always recommend the "cross" design since they sell 2x the amount of boxes but I have found that life works fine with just a 1-path design as well. >>> >>> -Hank >>> >>> >>> >>>> I second the static routes, specially from a simplicity standpoint. Add >>>> in a pair of layer two switches to simplify further: >>>> >>>> >>>> +--------+ +--------+ >>>> | Peer A | | Peer A |<-Many carriers. Using 1 carrier >>>> +---+----+ +----+---+ for this scenario. >>>> |eBGP | eBGP >>>> | | >>>> +---+----+iBGP+----+---+ >>>> | Router + + Router |<- Routers. Not directly connected >>>> +-+------+ +------+-+ >>>> | | >>>> +-+------+ +------+-+ >>>> |L2Switch|----|L2Switch|<- Layer 2 switches, can be stacked >>>> +--------+ +--------+ >>>> | | >>>> +-+------+ +------+-+ >>>> |Act. FW |----|Pas. FW |<-Firewalls Active/Passive. >>>> +--------+ +--------+ >>>> >>>> You can lose all of the left leg, or all of the right leg, and still be >>>> up. If you want to complicate things, you can add crossing links >>>> between it all, but again, beyond BGP and VRRP, this is a very simple >>>> design you can easily troubleshoot at 3AM. It's also much easier to >>>> document the troubleshooting steps (so you can go on vacation and >>>> someone else can solve without calling you) and test upgrades. >>>> >>>> You can nearly evenly split the traffic by having a VRRP VIP on each >>>> edge router, with the other router backing up the first. The firewalls >>>> can have two static routes, one to each VIP, and this will roughly >>>> load-balance the traffic out on a packet basis. As you peer with the >>>> same ISP, this will work just fine. If they have an outage, your edge >>>> routers will learn, and even if the circuit drops it'll know, and >>>> basically the VIP will just redirect traffic to the other router. >>>> >>>> Now all your firewalls have to do is maintain stateful session >>>> information, not OSPF. >>>> >>>> If you had two different ISPs (especially if they are not roughly evenly >>>> connected), then not having intelligence of the BGP paths in your >>>> firewalls can cause an extra hop when it hits router with the longer >>>> path, which will redirect it to the router with the shorter path. >>>> >>>> Speaking from a Cisco/HSRP point of view, you could be more intelligent >>>> (re:more complicated, and complication means harder troubleshooting and >>>> more documentation needed) during problem periods by having the VIP move >>>> routers automatically based on the WAN link dropping and/or a route >>>> beyond it being lost (others can comment to if VRRP supports this). >>>> This would save one hop to the "broken" router when the BGP path or WAN >>>> is down. >>>> >>>> Jason Roysdon >>>> >>>> On 06/22/2011 06:07 PM, Bret Palsson wrote: >>>> >>>>> On Wed, Jun 22, 2011 at 5:33 PM, PC wrote: >>>>> >>>>> >>>>>> Who makes the firewall? >>>>>> >>>>>> >>>>>> >>>>> Juniper SSG. We use NSRP and replicate all the RTOs. We have hitless on the >>>>> Firewalls, have for years. We're now peering with our own carriers vs. using >>>>> our datacenter's mix. >>>>> >>>>> A static route from the junipers to the VIP (VRRP) is probably the way to >>>>> go. I think. >>>>> >>>>> To make this work and be "hitless", your firewall vendor must support >>>>> >>>>>> stateful replication of routing protocol data (including OSPF). For >>>>>> example, Cisco didn't support this in their ASA product until version 8.4 of >>>>>> code. >>>>>> >>>>>> Otherwise, a failover requires OSPF to re-converge -- and quite frankly, >>>>>> will likely cause some state of confusion on the upstream OSPF peers, loss >>>>>> of adjacency, and a loss of routing until this occurs. It's like someone >>>>>> just swapped a router with the same IP to the upstream device -- assuming >>>>>> your active/standby vendor's implementation only presents itself as one >>>>>> device. >>>>>> >>>>>> However, once this is succesful your current failover topology should work >>>>>> fine -- even if it takes some time to failover. >>>>>> >>>>>> In my opinion though, unless the firewall is serving as "transit" to >>>>>> downstream routers or other layer 3 elements, and you need to run OSPF to it >>>>>> (And through it) as a result, it's often just easier to static default route >>>>>> out from the firewall(s) and redistribute a static route on the upstream >>>>>> routers for the subnets behind the firewalls. It also helps ensure >>>>>> symmetrical traffic flows, which is important for stateful firewalls and can >>>>>> become moderatly confusing when your firewalls start having many interfaces. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson wrote: >>>>>> >>>>>> >>>>>>> Here is my current setup in ASCII art. (Please view in a fixed width >>>>>>> font.) Below the art I'll write out the setup. >>>>>>> >>>>>>> >>>>>>> +--------+ +--------+ >>>>>>> | Peer A | | Peer A |<-Many carriers. Using 1 carrier >>>>>>> +---+----+ +----+---+ for this scenario. >>>>>>> |eBGP | eBGP >>>>>>> | | >>>>>>> +---+----+iBGP+----+---+ >>>>>>> | Router +----+ Router |<-Netiron CERs Routers. >>>>>>> +-+------+ +------+-+ >>>>>>> |A `.P A.' |P<-A/P indicates Active/Passive >>>>>>> | `. .' | link. >>>>>>> | :: | >>>>>>> +-+------+' `+------+-+ >>>>>>> |Act. FW | |Pas. FW |<-Firewalls Active/Passive. >>>>>>> +--------+ +--------+ >>>>>>> >>>>>>> >>>>>>> To keep this scenario simple, I'm multihoming to one carrier. >>>>>>> I have two Netiron CERs. Each have a eBGP connection to the same peer. >>>>>>> The CERs have an iBGP connection to each other. >>>>>>> That works all fine and dandy. Feel free to comment, however if you think >>>>>>> there is a better way to do this. >>>>>>> >>>>>>> Here comes the tricky part. I have two firewalls in an Active/Passive >>>>>>> setup. When one fails the other is configured exactly the same >>>>>>> and picks up where the other left off. (Yes, all the sessions etc. are >>>>>>> actively mirrored between the devices) >>>>>>> >>>>>>> I am using OSPFv2 between the CERs and the Firewalls. Failover works just >>>>>>> fine, however when I fail an OSPF link that has the active default route, >>>>>>> ingress traffic still routes fine and dandy, but egress traffic doesn't. >>>>>>> Both Netiron's OSPF are setup to advertise they are the default route. >>>>>>> >>>>>>> What I'm wondering is, if OSPF is the right solution for this. How do >>>>>>> others solve this problem? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Bret >>>>>>> >>>>>>> >>>>>>> Note: Since lately ipv6 has been a hot topic, I'll state that after we get >>>>>>> the BGP all figured out and working properly, ipv6 is our next project. :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> >> From bhmccie at gmail.com Thu Jun 23 14:19:43 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 23 Jun 2011 14:19:43 -0500 Subject: BGP Design question. In-Reply-To: <561C0511-7936-4475-AD3A-016D98DC92ED@delong.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> <5.1.0.14.2.20110623085011.036d3c08@efes.iucc.ac.il> <4E033531.5050604@gmail.com> <561C0511-7936-4475-AD3A-016D98DC92ED@delong.com> Message-ID: <4E0391CF.5070202@gmail.com> True True. I've seen that before as well. Actually I've seen it more with various vendors implementations of VRRP than I have with Cisco HSRP or Juniper NSRP. But it seems to me more or less that most issues we deal with these days are software related bugs as opposed to hardware related issues. Maybe that's why I get a quarterly bug scrub from Cisco on my gear as opposed to a quarterly hardware analysis. :) To each their own.... -Hammer- On 06/23/2011 02:15 PM, Owen DeLong wrote: > Except in those (becoming less rare than hardware failure) instances where the software controlling the failover process is the actual cause of the outage. > > Owen > > On Jun 23, 2011, at 5:44 AM, -Hammer- wrote: > > >> Agreed. At an enterprise level, there is no need to risk extended downtime to save a buck or two. Redundant hardware is always a good way to keep Murphy out of the equation. And as far as hardware failures go, it's not that common. Nowadays it's the bugs in overly complicated code on your gear that get you first. I miss IOS 11.3..... >> >> -Hammer- >> >> >> >> On 06/23/2011 01:07 AM, Bret Palsson wrote: >> >>> That's fine if you are running a website. When it comes to telecommunications, a 15 minute outage is pretty huge. Especially with certain types of customers: emergency services for example. >>> >>> -Bret >>> >>> On Jun 23, 2011, at 12:02 AM, Hank Nussbacher wrote: >>> >>> >>> >>>> At 20:42 22/06/2011 -0700, Jason Roysdon wrote: >>>> >>>> Let me be a bit of a heretic here. How often does your router fail? Or your firewall? In the 25 years I have gone into customers I have found when they did a cross setup as proposed below by Bret and Jason, only one person truly knew the complete setup and if something broke only he was able to fix it. There is never complete printed documentation: routing design, IPs on all interfaces, subnetting schematic, etc. And if there was at one point, after 2 years it was outdated and never updated and only the *1* guy knew the changes in his head. >>>> >>>> In that kind of situation, when something stopped working they always had to call in the "guru" to fix it. On the other hand, a simple design of only *one* path (pick either left or right side of each of the ASCII arts), made it possible that even junior network engineers as well as technicians called in on emergency with 4 hours notice, were able to fix the situation much more quickly than the "cross" design. And the MTBF on a single path solution, IMHO, is around 3-4 years. And if you need redundancy, keep a spare box on a shelf, completely loaded with the latest config so that it can be hot-swapped in within 15 minutes of failure. >>>> >>>> This 1-path design is not for everyone. The vendors always recommend the "cross" design since they sell 2x the amount of boxes but I have found that life works fine with just a 1-path design as well. >>>> >>>> -Hank >>>> >>>> >>>> >>>> >>>>> I second the static routes, specially from a simplicity standpoint. Add >>>>> in a pair of layer two switches to simplify further: >>>>> >>>>> >>>>> +--------+ +--------+ >>>>> | Peer A | | Peer A |<-Many carriers. Using 1 carrier >>>>> +---+----+ +----+---+ for this scenario. >>>>> |eBGP | eBGP >>>>> | | >>>>> +---+----+iBGP+----+---+ >>>>> | Router + + Router |<- Routers. Not directly connected >>>>> +-+------+ +------+-+ >>>>> | | >>>>> +-+------+ +------+-+ >>>>> |L2Switch|----|L2Switch|<- Layer 2 switches, can be stacked >>>>> +--------+ +--------+ >>>>> | | >>>>> +-+------+ +------+-+ >>>>> |Act. FW |----|Pas. FW |<-Firewalls Active/Passive. >>>>> +--------+ +--------+ >>>>> >>>>> You can lose all of the left leg, or all of the right leg, and still be >>>>> up. If you want to complicate things, you can add crossing links >>>>> between it all, but again, beyond BGP and VRRP, this is a very simple >>>>> design you can easily troubleshoot at 3AM. It's also much easier to >>>>> document the troubleshooting steps (so you can go on vacation and >>>>> someone else can solve without calling you) and test upgrades. >>>>> >>>>> You can nearly evenly split the traffic by having a VRRP VIP on each >>>>> edge router, with the other router backing up the first. The firewalls >>>>> can have two static routes, one to each VIP, and this will roughly >>>>> load-balance the traffic out on a packet basis. As you peer with the >>>>> same ISP, this will work just fine. If they have an outage, your edge >>>>> routers will learn, and even if the circuit drops it'll know, and >>>>> basically the VIP will just redirect traffic to the other router. >>>>> >>>>> Now all your firewalls have to do is maintain stateful session >>>>> information, not OSPF. >>>>> >>>>> If you had two different ISPs (especially if they are not roughly evenly >>>>> connected), then not having intelligence of the BGP paths in your >>>>> firewalls can cause an extra hop when it hits router with the longer >>>>> path, which will redirect it to the router with the shorter path. >>>>> >>>>> Speaking from a Cisco/HSRP point of view, you could be more intelligent >>>>> (re:more complicated, and complication means harder troubleshooting and >>>>> more documentation needed) during problem periods by having the VIP move >>>>> routers automatically based on the WAN link dropping and/or a route >>>>> beyond it being lost (others can comment to if VRRP supports this). >>>>> This would save one hop to the "broken" router when the BGP path or WAN >>>>> is down. >>>>> >>>>> Jason Roysdon >>>>> >>>>> On 06/22/2011 06:07 PM, Bret Palsson wrote: >>>>> >>>>> >>>>>> On Wed, Jun 22, 2011 at 5:33 PM, PC wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Who makes the firewall? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Juniper SSG. We use NSRP and replicate all the RTOs. We have hitless on the >>>>>> Firewalls, have for years. We're now peering with our own carriers vs. using >>>>>> our datacenter's mix. >>>>>> >>>>>> A static route from the junipers to the VIP (VRRP) is probably the way to >>>>>> go. I think. >>>>>> >>>>>> To make this work and be "hitless", your firewall vendor must support >>>>>> >>>>>> >>>>>>> stateful replication of routing protocol data (including OSPF). For >>>>>>> example, Cisco didn't support this in their ASA product until version 8.4 of >>>>>>> code. >>>>>>> >>>>>>> Otherwise, a failover requires OSPF to re-converge -- and quite frankly, >>>>>>> will likely cause some state of confusion on the upstream OSPF peers, loss >>>>>>> of adjacency, and a loss of routing until this occurs. It's like someone >>>>>>> just swapped a router with the same IP to the upstream device -- assuming >>>>>>> your active/standby vendor's implementation only presents itself as one >>>>>>> device. >>>>>>> >>>>>>> However, once this is succesful your current failover topology should work >>>>>>> fine -- even if it takes some time to failover. >>>>>>> >>>>>>> In my opinion though, unless the firewall is serving as "transit" to >>>>>>> downstream routers or other layer 3 elements, and you need to run OSPF to it >>>>>>> (And through it) as a result, it's often just easier to static default route >>>>>>> out from the firewall(s) and redistribute a static route on the upstream >>>>>>> routers for the subnets behind the firewalls. It also helps ensure >>>>>>> symmetrical traffic flows, which is important for stateful firewalls and can >>>>>>> become moderatly confusing when your firewalls start having many interfaces. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Here is my current setup in ASCII art. (Please view in a fixed width >>>>>>>> font.) Below the art I'll write out the setup. >>>>>>>> >>>>>>>> >>>>>>>> +--------+ +--------+ >>>>>>>> | Peer A | | Peer A |<-Many carriers. Using 1 carrier >>>>>>>> +---+----+ +----+---+ for this scenario. >>>>>>>> |eBGP | eBGP >>>>>>>> | | >>>>>>>> +---+----+iBGP+----+---+ >>>>>>>> | Router +----+ Router |<-Netiron CERs Routers. >>>>>>>> +-+------+ +------+-+ >>>>>>>> |A `.P A.' |P<-A/P indicates Active/Passive >>>>>>>> | `. .' | link. >>>>>>>> | :: | >>>>>>>> +-+------+' `+------+-+ >>>>>>>> |Act. FW | |Pas. FW |<-Firewalls Active/Passive. >>>>>>>> +--------+ +--------+ >>>>>>>> >>>>>>>> >>>>>>>> To keep this scenario simple, I'm multihoming to one carrier. >>>>>>>> I have two Netiron CERs. Each have a eBGP connection to the same peer. >>>>>>>> The CERs have an iBGP connection to each other. >>>>>>>> That works all fine and dandy. Feel free to comment, however if you think >>>>>>>> there is a better way to do this. >>>>>>>> >>>>>>>> Here comes the tricky part. I have two firewalls in an Active/Passive >>>>>>>> setup. When one fails the other is configured exactly the same >>>>>>>> and picks up where the other left off. (Yes, all the sessions etc. are >>>>>>>> actively mirrored between the devices) >>>>>>>> >>>>>>>> I am using OSPFv2 between the CERs and the Firewalls. Failover works just >>>>>>>> fine, however when I fail an OSPF link that has the active default route, >>>>>>>> ingress traffic still routes fine and dandy, but egress traffic doesn't. >>>>>>>> Both Netiron's OSPF are setup to advertise they are the default route. >>>>>>>> >>>>>>>> What I'm wondering is, if OSPF is the right solution for this. How do >>>>>>>> others solve this problem? >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Bret >>>>>>>> >>>>>>>> >>>>>>>> Note: Since lately ipv6 has been a hot topic, I'll state that after we get >>>>>>>> the BGP all figured out and working properly, ipv6 is our next project. :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >>> >>> > From owen at delong.com Thu Jun 23 14:21:03 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Jun 2011 12:21:03 -0700 Subject: BGP Design question. In-Reply-To: <41968.1308837540@turing-police.cc.vt.edu> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> <5.1.0.14.2.20110623085011.036d3c08@efes.iucc.ac.il> <4E033531.5050604@gmail.com> <41968.1308837540@turing-police.cc.vt.edu> Message-ID: <76E5FD12-85CE-4A5C-8332-6C02FEB9354B@delong.com> On Jun 23, 2011, at 6:59 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 23 Jun 2011 07:44:33 CDT, -Hammer- said: >> Agreed. At an enterprise level, there is no need to risk extended >> downtime to save a buck or two. Redundant hardware is always a good way >> to keep Murphy out of the equation. And as far as hardware failures go, >> it's not that common. Nowadays it's the bugs in overly complicated code >> on your gear that get you first. I miss IOS 11.3..... > > So what you're saying is we're more likely to take an outage due to tripping > over a bug, so we should go for the simplest non-crossover config to minimize > the chances of hitting a bug. ;) It's certainly worthy of consideration. Owen From jeroen at mompl.net Thu Jun 23 16:03:00 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 23 Jun 2011 14:03:00 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <201106112340.p5BNeku0051520@aurora.sol.net> References: <201106112340.p5BNeku0051520@aurora.sol.net> Message-ID: <4E03AA04.6070100@mompl.net> Joe Greco wrote: >> toddlers around and drive to and from work. An SUV in almost all cases >> is added luxury. > > My SUV carries seven passengers and allows me to haul gear including > conduit, lumber, ladders, etc. It's actively dangerous to do some of > these things in a sedan. Hence I said "in almost all cases". Although I admit the car analogy is pretty much flawed by its very nature, and over used. I shouldn't have done it. Greetings, Jeroen -- Earthquake Magnitude: 1.8 Date: Thursday, June 23, 2011 20:16:35 UTC Location: Southern Alaska Latitude: 60.0763; Longitude: -141.1119 Depth: 0.30 km From jeroen at mompl.net Thu Jun 23 17:10:38 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 23 Jun 2011 15:10:38 -0700 Subject: IPv6 words Message-ID: <4E03B9DE.5020205@mompl.net> I am sure it has come up a number of times, but with IPv6 you can make up fancy addresses that are (almost) complete words or phrases. Making it almost as easy to remember as the resolved name. It'd be nice in a weird geek sort of way (but totally impractical) to be able to request IPv6 blocks that have some sort of fancy name of your choice. 2001:db8:dead:beef:: dead:beef:: dead::beef As seen on http://en.wikipedia.org/wiki/Magic_number_%28programming%29 "DEADBEEF Famously used on IBM systems such as the RS/6000, also used in the original Mac OS operating systems, OPENSTEP Enterprise, and the Commodore Amiga. On Sun Microsystems' Solaris, marks freed kernel memory (KMEM_FREE_PATTERN)" Bonus points if your organisation's name only contains HEX characters. Greetings, Jeroen -- Earthquake Magnitude: 1.1 Date: Thursday, June 23, 2011 21:27:56 UTC Location: Southern California Latitude: 33.6613; Longitude: -116.7003 Depth: 17.10 km From paul at paulgraydon.co.uk Thu Jun 23 17:16:28 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 23 Jun 2011 12:16:28 -1000 Subject: IPv6 words In-Reply-To: <4E03B9DE.5020205@mompl.net> References: <4E03B9DE.5020205@mompl.net> Message-ID: <4E03BB3C.1080404@paulgraydon.co.uk> On 06/23/2011 12:10 PM, Jeroen van Aart wrote: > I am sure it has come up a number of times, but with IPv6 you can make > up fancy addresses that are (almost) complete words or phrases. Making > it almost as easy to remember as the resolved name. > > It'd be nice in a weird geek sort of way (but totally impractical) to > be able to request IPv6 blocks that have some sort of fancy name of > your choice. > > 2001:db8:dead:beef:: > dead:beef:: > dead::beef > > As seen on http://en.wikipedia.org/wiki/Magic_number_%28programming%29 > "DEADBEEF Famously used on IBM systems such as the RS/6000, also > used in the original Mac OS operating systems, OPENSTEP Enterprise, > and the Commodore Amiga. On Sun Microsystems' Solaris, marks freed > kernel memory (KMEM_FREE_PATTERN)" > > Bonus points if your organisation's name only contains HEX characters. > > Greetings, > Jeroen > Not quite dead beef, but spotted this when testing connectivity using a site from one of the rackspace guys: ipv6.icanhazip.com. 7200 IN AAAA 2001:470:1f10:d57:feed:beef:cafe:d00d Paul From wmaton at ryouko.imsb.nrc.ca Thu Jun 23 17:19:08 2011 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Thu, 23 Jun 2011 18:19:08 -0400 (EDT) Subject: IPv6 words In-Reply-To: <4E03B9DE.5020205@mompl.net> References: <4E03B9DE.5020205@mompl.net> Message-ID: (Warning: This email contains scenes of flashbacks) On Thu, 23 Jun 2011, Jeroen van Aart wrote: > I am sure it has come up a number of times, but with IPv6 you can make up > fancy addresses that are (almost) complete words or phrases. Making it almost > as easy to remember as the resolved name. > > It'd be nice in a weird geek sort of way (but totally impractical) to be able > to request IPv6 blocks that have some sort of fancy name of your choice. > > 2001:db8:dead:beef:: > dead:beef:: > dead::beef 3fff:BAD:: Seriously though, I remember playing little games like this numbering Novell IPX network segments back in the 1990's. After IP came on the network I think I was accussed of polluting pristine IPX nets....then... I'll stop now. ;-) wfms From pete at altadena.net Thu Jun 23 17:23:44 2011 From: pete at altadena.net (Pete Carah) Date: Thu, 23 Jun 2011 18:23:44 -0400 Subject: IPv6 words In-Reply-To: <4E03BB3C.1080404@paulgraydon.co.uk> References: <4E03B9DE.5020205@mompl.net> <4E03BB3C.1080404@paulgraydon.co.uk> Message-ID: <4E03BCF0.3020108@altadena.net> On 06/23/2011 06:16 PM, Paul Graydon wrote: > On 06/23/2011 12:10 PM, Jeroen van Aart wrote: >> I am sure it has come up a number of times, but with IPv6 you can >> make up fancy addresses that are (almost) complete words or phrases. >> Making it almost as easy to remember as the resolved name. >> >> It'd be nice in a weird geek sort of way (but totally impractical) to >> be able to request IPv6 blocks that have some sort of fancy name of >> your choice. >> >> 2001:db8:dead:beef:: >> dead:beef:: >> dead::beef >> >> As seen on http://en.wikipedia.org/wiki/Magic_number_%28programming%29 >> "DEADBEEF Famously used on IBM systems such as the RS/6000, also >> used in the original Mac OS operating systems, OPENSTEP Enterprise, >> and the Commodore Amiga. On Sun Microsystems' Solaris, marks freed >> kernel memory (KMEM_FREE_PATTERN)" >> >> Bonus points if your organisation's name only contains HEX characters. >> >> Greetings, >> Jeroen >> > Not quite dead beef, but spotted this when testing connectivity using > a site from one of the rackspace guys: > > ipv6.icanhazip.com. 7200 IN AAAA > 2001:470:1f10:d57:feed:beef:cafe:d00d like c15c:0d06:f00d seen on ipv6 day (tail end of cisco's website v6 address) (among several others with lots of deadbeef's and cafe's) -- Pete From fred at cisco.com Thu Jun 23 17:41:41 2011 From: fred at cisco.com (Fred Baker) Date: Thu, 23 Jun 2011 15:41:41 -0700 Subject: IPv6 words In-Reply-To: <4E03BCF0.3020108@altadena.net> References: <4E03B9DE.5020205@mompl.net> <4E03BB3C.1080404@paulgraydon.co.uk> <4E03BCF0.3020108@altadena.net> Message-ID: <2A9B7C13-BEBD-44AD-962B-BA1D2728F087@cisco.com> On Jun 23, 2011, at 3:23 PM, Pete Carah wrote: > On 06/23/2011 06:16 PM, Paul Graydon wrote: >> On 06/23/2011 12:10 PM, Jeroen van Aart wrote: >>> I am sure it has come up a number of times, but with IPv6 you can >>> make up fancy addresses that are (almost) complete words or phrases. >>> Making it almost as easy to remember as the resolved name. >>> >>> It'd be nice in a weird geek sort of way (but totally impractical) to >>> be able to request IPv6 blocks that have some sort of fancy name of >>> your choice. >>> >>> 2001:db8:dead:beef:: >>> dead:beef:: >>> dead::beef >>> >>> As seen on http://en.wikipedia.org/wiki/Magic_number_%28programming%29 >>> "DEADBEEF Famously used on IBM systems such as the RS/6000, also >>> used in the original Mac OS operating systems, OPENSTEP Enterprise, >>> and the Commodore Amiga. On Sun Microsystems' Solaris, marks freed >>> kernel memory (KMEM_FREE_PATTERN)" >>> >>> Bonus points if your organisation's name only contains HEX characters. >>> >>> Greetings, >>> Jeroen >>> >> Not quite dead beef, but spotted this when testing connectivity using >> a site from one of the rackspace guys: >> >> ipv6.icanhazip.com. 7200 IN AAAA >> 2001:470:1f10:d57:feed:beef:cafe:d00d > > like c15c:0d06:f00d seen on ipv6 day (tail end of cisco's website v6 > address) (among several others with lots of deadbeef's and cafe's) and face:b00c, dead:babe, I think there are actually quite a few of these. http://en.wikipedia.org/wiki/Hexspeak From bill at herrin.us Thu Jun 23 17:52:15 2011 From: bill at herrin.us (William Herrin) Date: Thu, 23 Jun 2011 18:52:15 -0400 Subject: IPv6 words In-Reply-To: <4E03B9DE.5020205@mompl.net> References: <4E03B9DE.5020205@mompl.net> Message-ID: On Thu, Jun 23, 2011 at 6:10 PM, Jeroen van Aart wrote: > I am sure it has come up a number of times, but with IPv6 you can make up > fancy addresses that are (almost) complete words or phrases. Making it > almost as easy to remember as the resolved name. > > It'd be nice in a weird geek sort of way (but totally impractical) to be > able to request IPv6 blocks that have some sort of fancy name of your > choice. 4-character or shorter hex words, for your reference: aced ace5 ac1d add5 a1de a1d5 baa5 babe ba5e ba55 bead bed5 beef b1a5 b1de b0de b00b b055 ca5e cede c0da c0de c0ed c01f da15 dead deaf deed d1ce d1ed d1e5 d15c d155 d0d0 d0ff d05e ea5e face fade fed5 feed fee5 f1b5 f1ef f1fe f00d 1ced 1dea 1de5 0b0e 0dd5 5afe 5a1d 5a55 5cab 5cad 5eed 51de 50da 50fa ace add ad0 ad5 a1d a55 bad bed bee b1b b1d b0a b0b b00 cab cad c0b c0d dab dad d1d d1e d0c d0e d05 ebb fad fed fee f1b f1e f0b f0e 1ce 0af 0dd 0de 0ff 5ad 5ea 5ee 51c 515 50b ad a5 be d0 1f 15 0f 50 a 1 -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmamodio at gmail.com Thu Jun 23 18:29:31 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 23 Jun 2011 18:29:31 -0500 Subject: ICANN to allow commercial gTLDs In-Reply-To: <20110623171006.47716.qmail@joyce.lan> References: <20110623171006.47716.qmail@joyce.lan> Message-ID: On Thu, Jun 23, 2011 at 12:10 PM, John Levine wrote: >>Lets say I want to apply for .WINE with commercial purposes, then what >>is a ballpark figure for the funds/investment required ? > > I wouldn't try it with less than a million bucks in hand. ?Beyond the > ICANN application nonsense, you'd also want to budget something for > running and promoting it for however long it takes to verify that it > was a silly idea and then go bust. My perception is that if you don't have access to ~$2M for that kind of gTLD don't even waste your time. (Does the $185K include the given gTLD cocktail party at the seasonal ICANN meeting ?) Cheers Jorge From jeroen at mompl.net Thu Jun 23 18:55:55 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 23 Jun 2011 16:55:55 -0700 Subject: IPv6 words In-Reply-To: References: <4E03B9DE.5020205@mompl.net> Message-ID: <4E03D28B.5090104@mompl.net> William Herrin wrote: > On Thu, Jun 23, 2011 at 6:10 PM, Jeroen van Aart wrote: >> able to request IPv6 blocks that have some sort of fancy name of your >> choice. > > 4-character or shorter hex words, for your reference: > > aced > ace5 > ac1d :-D Thanks. I wonder about 2001:db8 The person who made it up must like the movie "2001: a space odyssey" and Aston Martin. Even though I don't think they ever made a db8, but they made or make db2, db4, db5, db6, db7 and db9 amongst others. Greetings, Jeroen -- Earthquake Magnitude: 1.6 Date: Thursday, June 23, 2011 23:15:02 UTC Location: Southern California Latitude: 33.7095; Longitude: -116.2785 Depth: 28.30 km From surfer at mauigateway.com Thu Jun 23 18:59:42 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 23 Jun 2011 16:59:42 -0700 Subject: IPv6 words Message-ID: <20110623165942.A117A866@resin07.mta.everyone.net> 2607:f9a0::f0c:0ff >;-) scott From brunner at nic-naa.net Thu Jun 23 17:13:18 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Thu, 23 Jun 2011 18:13:18 -0400 Subject: ICANN to allow commercial gTLDs Message-ID: <201106232213.p5NMDIxb091976@nic-naa.net> > My perception is that if you don't have access to ~$2M for that kind > of gTLD don't even waste your time. you may want to consult with a practitioner in the jurisdiction of your choice who does business organization and investor equity structures, as the cost to acquire a right to contract for a delegation in the iana root for a string likely to be in a contention set is unbounded. your ~$2m may be a total loss of $185k plus the time value of capital and a "slot" in the 201x evaluation cohort (nomianlly 500 units of evaluation, subject to some grouping if exceeded, for which there are art issues), or it may be a significant over-capitalization with excessive loss of initial investor equity paying for mezzanine or later capital which may be deferred and acquired at lower equity costs after the right to contract has been secured. pat answers are easy. your milage may vary if pat answers are best answers. > (Does the $185K include the given gTLD cocktail party at the seasonal > ICANN meeting ?) this is really a auction avoidance and/or investment invitation cost, and again, ymmv. does gmo improve the likely outome of its campaign to obtain "shop" by holding high cost socials? i don't know. for all i know a bid for .shop will be made by an entity capable of outbidding gmo, or gmo plus its line of auction risk capital and credit, and acquire both "shop" and the value of gmo's pre-auction marketing investment. there's a reason many people use "shoe" as an example of a generic. disclosure only increases risk and cost, except where a rule exist that pre-empts the allocation by auction rule. full disclosure: i spent last fall writing a memo making the case for the affirmative support or non-opposition requirement for iso3166 state capitals to be expanded to all city and geographic names where public administration(s) exists, on secondary meaning (trademark), contrary to the position of the board last fall, adding the public interest by secondary meaning (marks) to the gac's (sovereign) claim. the issue was vigorously discussed at the cartagena meeting, and i think(*) the final applicant's guidebook has the affirmative support or non-opposition requirement for the names of urban areas and other administered regional identifiers. where booze-pub adds value, by all means, spend $$ on booze-pub. where it does not, consider alternatives. -e (*) i've actualy been too busy doing policy work related to applicant support to catch the kurt show in its primary (saturday gnsoc) showing, or any of its reduced calorie repeats during the week, and i've not even opened the .pdf. all that can wait until next week, so for all i know my dagv1/v2/v3/v4/v5 data needs a refresh run over the redline, later. From sethm at rollernet.us Thu Jun 23 19:47:18 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 23 Jun 2011 17:47:18 -0700 Subject: Yup; the Internet is screwed up. In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B4AC02F@ex-mb-1.corp.atlasnetworks.us> References: <4E024709.2060102@mompl.net> <635D17EE85D35A49B8F278998E6C340459473A6B9D@EXVS.dev.oati.local> <8C26A4FDAE599041A13EB499117D3C286B4AC02F@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4E03DE96.9040201@rollernet.us> On 6/22/2011 14:33, Nathan Eisenberg wrote: >> I agree, the whole use of the terms 'need' and 'want' in this conversation are >> ridiculous. It's the Internet. The entire thing isn't a 'need'. It's not like life >> support or something that will cause loss of life if it isn't there. The only thing >> to even discuss here is 'want'. Yes, consumers 'want' super-fast Internet, >> faster than any of us can comprehend right now. 1Tbps to the house, for >> everyone, for cheap! > > Wait, the internet isn't a need? Is this 1991? Of course it's a need, as surely as heat or electricity are needs. > > Without even trying, I can think of a dozen life-safety systems that rely solely on the internet for their functionality. > Life safety aside, enough common stuff is moving online (whether it's paying bills, schoolwork, or preparing forms for the DMV ahead of time), and it's slowly becoming a disadvantage to not have the internet. ~Seth From ben at bencarleton.com Thu Jun 23 19:48:03 2011 From: ben at bencarleton.com (Ben Carleton) Date: Thu, 23 Jun 2011 20:48:03 -0400 (EDT) Subject: IPv6 words In-Reply-To: <20110623165942.A117A866@resin07.mta.everyone.net> References: <20110623165942.A117A866@resin07.mta.everyone.net> Message-ID: <1308876483.00853962@apps.rackspace.com> That one would be good for a firewall/IDS setup... "Oh rats, our attack was stopped by a firewall at... HEY!" :-D bc -----Original Message----- From: "Scott Weeks" Sent: Thursday, June 23, 2011 7:59pm To: nanog at nanog.org Subject: Re: IPv6 words 2607:f9a0::f0c:0ff >;-) scott From mikea at mikea.ath.cx Thu Jun 23 20:17:34 2011 From: mikea at mikea.ath.cx (mikea) Date: Thu, 23 Jun 2011 20:17:34 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <4E03DE96.9040201@rollernet.us> References: <4E024709.2060102@mompl.net> <635D17EE85D35A49B8F278998E6C340459473A6B9D@EXVS.dev.oati.local> <8C26A4FDAE599041A13EB499117D3C286B4AC02F@ex-mb-1.corp.atlasnetworks.us> <4E03DE96.9040201@rollernet.us> Message-ID: <20110624011734.GE66976@mikea.ath.cx> On Thu, Jun 23, 2011 at 05:47:18PM -0700, Seth Mattinen wrote: > On 6/22/2011 14:33, Nathan Eisenberg wrote: > >> I agree, the whole use of the terms 'need' and 'want' in this conversation are > >> ridiculous. It's the Internet. The entire thing isn't a 'need'. It's not like life > >> support or something that will cause loss of life if it isn't there. The only thing > >> to even discuss here is 'want'. Yes, consumers 'want' super-fast Internet, > >> faster than any of us can comprehend right now. 1Tbps to the house, for > >> everyone, for cheap! > > > > Wait, the internet isn't a need? Is this 1991? Of course it's a need, as surely as heat or electricity are needs. > > > > Without even trying, I can think of a dozen life-safety systems that rely solely on the internet for their functionality. > > > > Life safety aside, enough common stuff is moving online (whether it's > paying bills, schoolwork, or preparing forms for the DMV ahead of time), > and it's slowly becoming a disadvantage to not have the internet. A friend is having to job-hunt. It pretty much _requires_ Net access. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From daniel.unam.ipv6 at gmail.com Thu Jun 23 21:10:50 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Thu, 23 Jun 2011 21:10:50 -0500 Subject: ping me please... In-Reply-To: References: Message-ID: <4E03F22A.2040809@gmail.com> Pinging behind my natted ISP conection (AS22566), seems to work: $ ping 65.5.48.2 PING 65.5.48.2 (65.5.48.2) 56(84) bytes of data. 64 bytes from 65.5.48.2: icmp_seq=1 ttl=240 time=72.5 ms 64 bytes from 65.5.48.2: icmp_seq=2 ttl=240 time=72.9 ms 64 bytes from 65.5.48.2: icmp_seq=3 ttl=240 time=73.4 ms 64 bytes from 65.5.48.2: icmp_seq=4 ttl=240 time=73.4 ms ^C --- 65.5.48.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 72.528/73.076/73.455/0.428 ms But when tracing that IP a lot of hops doesn't respond: $ traceroute 65.5.48.2 traceroute to 65.5.48.2 (65.5.48.2), 30 hops max, 60 byte packets 1 10.206.0.3 (10.206.0.3) 7.266 ms 7.459 ms 7.674 ms 2 10.12.1.2 (10.12.1.2) 11.622 ms 11.818 ms 12.283 ms 3 10.10.1.154 (10.10.1.154) 12.508 ms 13.473 ms 16.941 ms 4 63.221.133.1 (63.221.133.1) 16.978 ms 17.111 ms 17.327 ms 5 so-4-1-0.gar1.Houston1.Level3.net (4.59.122.13) 52.272 ms 55.217 ms 55.437 ms 6 ae-3-16.bar1.Houston1.Level3.net (4.69.140.205) 51.994 ms 39.478 ms 39.523 ms 7 ae-13-13.ebr1.Dallas1.Level3.net (4.69.137.138) 48.342 ms 48.558 ms 48.606 ms 8 ae-61-61.csw1.Dallas1.Level3.net (4.69.151.125) 49.114 ms ae-71-71.csw2.Dallas1.Level3.net (4.69.151.137) 49.169 ms ae-61-61.csw1.Dallas1.Level3.net (4.69.151.125) 49.251 ms 9 ae-4-90.edge10.Dallas1.Level3.net (4.69.145.210) 50.239 ms 53.285 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 53.336 ms 10 ATT (4.68.62.230) 53.556 ms 54.032 ms 55.245 ms 11 cr1.dlstx.ip.att.net (12.122.212.10) 74.479 ms 74.929 ms 77.851 ms 12 cr2.hs1tx.ip.att.net (12.122.28.158) 62.983 ms 63.210 ms 62.959 ms 13 cr1.hs1tx.ip.att.net (12.122.5.189) 63.661 ms 64.389 ms 64.858 ms 14 cr1.nwrla.ip.att.net (12.122.1.142) 67.812 ms 68.243 ms 68.455 ms 15 gar3.brhal.ip.att.net (12.122.100.85) 68.652 ms 68.881 ms 69.105 ms 16 12.248.15.46 (12.248.15.46) 79.204 ms 82.829 ms 82.894 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * > ------------------------------ > > Message: 2 > Date: Thu, 23 Jun 2011 08:07:40 -0500 > From: Eric J Esslinger > Subject: ping me please... > To: "'nanog at nanog.org'" > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > I have just turned up and migrated to a new circuit. I'm getting a few reports from one customer that some of his users are unable to reach his system. > If I could get people on the list to ping 65.5.48.2, and if it fails, to do a traceroute and email it to me offlist? I'd appreciate it. > Thanks. > __________________________ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ > (931)433-1522 ext 165 > > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. > -- Daniel Espejel Perez From Erik.Amundson at oati.net Thu Jun 23 21:27:32 2011 From: Erik.Amundson at oati.net (Erik Amundson) Date: Thu, 23 Jun 2011 21:27:32 -0500 Subject: Yup; the Internet is screwed up. In-Reply-To: <4E038B54.8010901@rollernet.us> References: <201106222207.p5MM7rFb045569@aurora.sol.net> <4E038B54.8010901@rollernet.us> Message-ID: <635D17EE85D35A49B8F278998E6C340459473A6DDF@EXVS.dev.oati.local> My big concern with pitiful low speed upstream speed is the whole 'cloud' movement. Every one will have all of their 'data' in the 'cloud' sooner than we all think, and that involves uploading it from their PC to the 'cloud'. For instance, I use a 'cloud' drive to backup bunches of data (150+GB of data). However, doing the initial backup really is no fun, even though I have a 10Mbps connection at home, the upload is more like 1.5Mbps. 150GB over 1.5Mbps is no fun, and most 'non-technical' folks would have given up a long time ago trying to backup that data... The 'cloud' is going to create a strong 'want' (some may choose to call it a 'need') for higher speed brodband, and symmetrical speeds. - Erik -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Thursday, June 23, 2011 1:52 PM To: nanog at nanog.org Subject: Re: Yup; the Internet is screwed up. On 6/22/11 3:07 PM, Joe Greco wrote: > Your average person cares a whole lot less about what's crossing their > Internet connection than they care about whether or not "this works" > than I do. > > I continue to be amazed at the quality of Netflix video coming across > the wire. Our local cable company just recently upped their old 7M/512K > normal tier to 10M/1M, and is now offering much higher speed tiers as > well, which isn't going to be discouraging to anyone wanting to do this > sort of thing. What still dismays me is the pitiful low upstream speeds that are still common. Not because most people want to run servers or host content at home (they don't), but because they want to share content with friends and the user experience can be greatly enhanced with symmetric speeds. Sharing those HD videos or 1,000 pictures during party weekend is less painful if it takes 10 minutes to upload rather than 10 hours. Also, things like GoToMyPC and "back to my Mac" are end user experience things that are best served by not using horribly low upstream speeds. I can understand that a decade ago most people were still sharing content offline, but dare I say now sharing online is becoming more common than offline. > I guess the most telling bit of all this was when I found myself needing > an ethernet switch behind the TV, AND WAS ABLE TO FILL ALL THE PORTS, for > > Internet-capable TV set > Internet-capable Blu-Ray player > Networkable TiVo > AppleTV > Video Game Console > Networked AV Receiver > UPS > and an uplink of course. 8 ports. Geez. > > That keeps striking me as such a paradigm shift. > I was talking to one of my friends about when we wired his house a while back. When he moved in we wired the crap out of it - we put Ethernet ports in the kitchen, behind the sofa, everywhere. The one place we didn't put anything though was behind the entertainment center. We put it lots of coax and wiring for surround sound, but at the time it never occurred to us to put Ethernet there. Of course, now there has to be without question. ~Seth From nanog.20110127 at jason.roysdon.net Fri Jun 24 00:36:09 2011 From: nanog.20110127 at jason.roysdon.net (Jason Roysdon) Date: Thu, 23 Jun 2011 22:36:09 -0700 Subject: BGP Design question. In-Reply-To: <4E033531.5050604@gmail.com> References: <3A9F8592-5F60-42B9-AC3F-8A6EFDB7E294@getjive.com> <5.1.0.14.2.20110623085011.036d3c08@efes.iucc.ac.il> <4E033531.5050604@gmail.com> Message-ID: <4E042249.7010006@jason.roysdon.net> The config I propose is really not complicated beyond BGP and HSRP/VRRP. It doesn't take a CCIE for this, and the documentation isn't that hard to set up and maintain. It's just a procedural thing that any config change automatically requires a document review/update. You should have as-builds documenting all changes before it ever is made in production. If you can't manage that, you've got bigger problems. Second, if you're support bench isn't deep enough, this is why you have support contracts with people who do know how to maintain things. If it's that important, get the support lined up ahead of time with guaranteed response times and make sure everyone knows the method to contact them, and test it (monthly, quarterly, whatever makes you comfortable). I agree that code/bugs are the biggest problems. However, you cannot just ignore updates when they affect your specific implementations, which means you will have to patch sometimes. I review each update that is released for the major.minor versions we are on and determine if the security or other bugs affect us enough to outweigh the risk of some unknown bug affecting us. It seems to be running about 50% right now (about half the time we skip an update). With redundancy in place, you can take down one of the node during your slowest times, upgrade, and then watch for whatever time you feel is sufficient (couple of days, week, two weeks), and then upgrade the other mate. Further, if you really care about downtime, you'll have an identical setup in test and be vetting all changes and updates before hand. No change or command would ever be issued on a production device that you didn't vet on the test gear. Granted, this may not catch the corner cases, but if you can simulate and stress the gear the same as the production gear, you'll catch most of the problems. When the 9s count, you do the math and do it right. On 06/23/2011 05:44 AM, -Hammer- wrote: > Agreed. At an enterprise level, there is no need to risk extended > downtime to save a buck or two. Redundant hardware is always a good way > to keep Murphy out of the equation. And as far as hardware failures go, > it's not that common. Nowadays it's the bugs in overly complicated code > on your gear that get you first. I miss IOS 11.3..... > > -Hammer- > > > > On 06/23/2011 01:07 AM, Bret Palsson wrote: >> That's fine if you are running a website. When it comes to >> telecommunications, a 15 minute outage is pretty huge. Especially with >> certain types of customers: emergency services for example. >> >> -Bret >> >> On Jun 23, 2011, at 12:02 AM, Hank Nussbacher wrote: >> >> >>> At 20:42 22/06/2011 -0700, Jason Roysdon wrote: >>> >>> Let me be a bit of a heretic here. How often does your router fail? >>> Or your firewall? In the 25 years I have gone into customers I have >>> found when they did a cross setup as proposed below by Bret and >>> Jason, only one person truly knew the complete setup and if something >>> broke only he was able to fix it. There is never complete printed >>> documentation: routing design, IPs on all interfaces, subnetting >>> schematic, etc. And if there was at one point, after 2 years it was >>> outdated and never updated and only the *1* guy knew the changes in >>> his head. >>> >>> In that kind of situation, when something stopped working they always >>> had to call in the "guru" to fix it. On the other hand, a simple >>> design of only *one* path (pick either left or right side of each of >>> the ASCII arts), made it possible that even junior network engineers >>> as well as technicians called in on emergency with 4 hours notice, >>> were able to fix the situation much more quickly than the "cross" >>> design. And the MTBF on a single path solution, IMHO, is around 3-4 >>> years. And if you need redundancy, keep a spare box on a shelf, >>> completely loaded with the latest config so that it can be >>> hot-swapped in within 15 minutes of failure. >>> >>> This 1-path design is not for everyone. The vendors always recommend >>> the "cross" design since they sell 2x the amount of boxes but I have >>> found that life works fine with just a 1-path design as well. >>> >>> -Hank >>> >>> >>> >>>> I second the static routes, specially from a simplicity standpoint. >>>> Add >>>> in a pair of layer two switches to simplify further: >>>> >>>> >>>> +--------+ +--------+ >>>> | Peer A | | Peer A |<-Many carriers. Using 1 carrier >>>> +---+----+ +----+---+ for this scenario. >>>> |eBGP | eBGP >>>> | | >>>> +---+----+iBGP+----+---+ >>>> | Router + + Router |<- Routers. Not directly connected >>>> +-+------+ +------+-+ >>>> | | >>>> +-+------+ +------+-+ >>>> |L2Switch|----|L2Switch|<- Layer 2 switches, can be stacked >>>> +--------+ +--------+ >>>> | | >>>> +-+------+ +------+-+ >>>> |Act. FW |----|Pas. FW |<-Firewalls Active/Passive. >>>> +--------+ +--------+ >>>> >>>> You can lose all of the left leg, or all of the right leg, and still be >>>> up. If you want to complicate things, you can add crossing links >>>> between it all, but again, beyond BGP and VRRP, this is a very simple >>>> design you can easily troubleshoot at 3AM. It's also much easier to >>>> document the troubleshooting steps (so you can go on vacation and >>>> someone else can solve without calling you) and test upgrades. >>>> >>>> You can nearly evenly split the traffic by having a VRRP VIP on each >>>> edge router, with the other router backing up the first. The firewalls >>>> can have two static routes, one to each VIP, and this will roughly >>>> load-balance the traffic out on a packet basis. As you peer with the >>>> same ISP, this will work just fine. If they have an outage, your edge >>>> routers will learn, and even if the circuit drops it'll know, and >>>> basically the VIP will just redirect traffic to the other router. >>>> >>>> Now all your firewalls have to do is maintain stateful session >>>> information, not OSPF. >>>> >>>> If you had two different ISPs (especially if they are not roughly >>>> evenly >>>> connected), then not having intelligence of the BGP paths in your >>>> firewalls can cause an extra hop when it hits router with the longer >>>> path, which will redirect it to the router with the shorter path. >>>> >>>> Speaking from a Cisco/HSRP point of view, you could be more intelligent >>>> (re:more complicated, and complication means harder troubleshooting and >>>> more documentation needed) during problem periods by having the VIP >>>> move >>>> routers automatically based on the WAN link dropping and/or a route >>>> beyond it being lost (others can comment to if VRRP supports this). >>>> This would save one hop to the "broken" router when the BGP path or WAN >>>> is down. >>>> >>>> Jason Roysdon >>>> >>>> On 06/22/2011 06:07 PM, Bret Palsson wrote: >>>> >>>>> On Wed, Jun 22, 2011 at 5:33 PM, PC wrote: >>>>> >>>>> >>>>>> Who makes the firewall? >>>>>> >>>>>> >>>>>> >>>>> Juniper SSG. We use NSRP and replicate all the RTOs. We have >>>>> hitless on the >>>>> Firewalls, have for years. We're now peering with our own carriers >>>>> vs. using >>>>> our datacenter's mix. >>>>> >>>>> A static route from the junipers to the VIP (VRRP) is probably the >>>>> way to >>>>> go. I think. >>>>> >>>>> To make this work and be "hitless", your firewall vendor must support >>>>> >>>>>> stateful replication of routing protocol data (including OSPF). For >>>>>> example, Cisco didn't support this in their ASA product until >>>>>> version 8.4 of >>>>>> code. >>>>>> >>>>>> Otherwise, a failover requires OSPF to re-converge -- and quite >>>>>> frankly, >>>>>> will likely cause some state of confusion on the upstream OSPF >>>>>> peers, loss >>>>>> of adjacency, and a loss of routing until this occurs. It's like >>>>>> someone >>>>>> just swapped a router with the same IP to the upstream device -- >>>>>> assuming >>>>>> your active/standby vendor's implementation only presents itself >>>>>> as one >>>>>> device. >>>>>> >>>>>> However, once this is succesful your current failover topology >>>>>> should work >>>>>> fine -- even if it takes some time to failover. >>>>>> >>>>>> In my opinion though, unless the firewall is serving as "transit" to >>>>>> downstream routers or other layer 3 elements, and you need to run >>>>>> OSPF to it >>>>>> (And through it) as a result, it's often just easier to static >>>>>> default route >>>>>> out from the firewall(s) and redistribute a static route on the >>>>>> upstream >>>>>> routers for the subnets behind the firewalls. It also helps ensure >>>>>> symmetrical traffic flows, which is important for stateful >>>>>> firewalls and can >>>>>> become moderatly confusing when your firewalls start having many >>>>>> interfaces. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Here is my current setup in ASCII art. (Please view in a fixed width >>>>>>> font.) Below the art I'll write out the setup. >>>>>>> >>>>>>> >>>>>>> +--------+ +--------+ >>>>>>> | Peer A | | Peer A |<-Many carriers. Using 1 carrier >>>>>>> +---+----+ +----+---+ for this scenario. >>>>>>> |eBGP | eBGP >>>>>>> | | >>>>>>> +---+----+iBGP+----+---+ >>>>>>> | Router +----+ Router |<-Netiron CERs Routers. >>>>>>> +-+------+ +------+-+ >>>>>>> |A `.P A.' |P<-A/P indicates Active/Passive >>>>>>> | `. .' | link. >>>>>>> | :: | >>>>>>> +-+------+' `+------+-+ >>>>>>> |Act. FW | |Pas. FW |<-Firewalls Active/Passive. >>>>>>> +--------+ +--------+ >>>>>>> >>>>>>> >>>>>>> To keep this scenario simple, I'm multihoming to one carrier. >>>>>>> I have two Netiron CERs. Each have a eBGP connection to the same >>>>>>> peer. >>>>>>> The CERs have an iBGP connection to each other. >>>>>>> That works all fine and dandy. Feel free to comment, however if >>>>>>> you think >>>>>>> there is a better way to do this. >>>>>>> >>>>>>> Here comes the tricky part. I have two firewalls in an >>>>>>> Active/Passive >>>>>>> setup. When one fails the other is configured exactly the same >>>>>>> and picks up where the other left off. (Yes, all the sessions >>>>>>> etc. are >>>>>>> actively mirrored between the devices) >>>>>>> >>>>>>> I am using OSPFv2 between the CERs and the Firewalls. Failover >>>>>>> works just >>>>>>> fine, however when I fail an OSPF link that has the active >>>>>>> default route, >>>>>>> ingress traffic still routes fine and dandy, but egress traffic >>>>>>> doesn't. >>>>>>> Both Netiron's OSPF are setup to advertise they are the default >>>>>>> route. >>>>>>> >>>>>>> What I'm wondering is, if OSPF is the right solution for this. >>>>>>> How do >>>>>>> others solve this problem? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Bret >>>>>>> >>>>>>> >>>>>>> Note: Since lately ipv6 has been a hot topic, I'll state that >>>>>>> after we get >>>>>>> the BGP all figured out and working properly, ipv6 is our next >>>>>>> project. :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> >> > From ryan.finnesey at HarrierInvestments.com Fri Jun 24 03:31:17 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Fri, 24 Jun 2011 01:31:17 -0700 Subject: SMB Internet market? Message-ID: <6EFFEFBAC68377459A2E972105C759EC03C1A9C0@EXVBE005-2.exch005intermedia.net> Can anyone recommend a good resource of metrics on the SMB Internet market? I am trying to find out which ISPs have the most market share and if they are using DSL, DS1, or Cable for access. Cheers Ryan From rol at witbe.net Fri Jun 24 04:10:45 2011 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Fri, 24 Jun 2011 11:10:45 +0200 Subject: IPv6 words In-Reply-To: <1308876483.00853962@apps.rackspace.com> References: <20110623165942.A117A866@resin07.mta.everyone.net> <1308876483.00853962@apps.rackspace.com> Message-ID: <20110624111045.6cc9f3a6@tux.DEF.witbe.net> On Thu, 23 Jun 2011 20:48:03 -0400 (EDT) "Ben Carleton" wrote: > That one would be good for a firewall/IDS setup... "Oh rats, our attack > was stopped by a firewall at... HEY!" :-D ::b19:b00b:babe:101 ? :) Sure, that would be funny ! Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bzeeb-lists at lists.zabbadoz.net Fri Jun 24 04:10:53 2011 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri, 24 Jun 2011 09:10:53 +0000 Subject: IPv6 words In-Reply-To: <4E03B9DE.5020205@mompl.net> References: <4E03B9DE.5020205@mompl.net> Message-ID: On Jun 23, 2011, at 10:10 PM, Jeroen van Aart wrote: > I am sure it has come up a number of times, but with IPv6 you can make up fancy addresses that are (almost) complete words or phrases. Making it almost as easy to remember as the resolved name. > > It'd be nice in a weird geek sort of way (but totally impractical) to be able to request IPv6 blocks that have some sort of fancy name of your choice. > > 2001:db8:dead:beef:: > dead:beef:: > dead::beef For IPv6 I consider it "address spam". My content filter will give you some extra tiny score if your MX uses such an address. If you want to do it, make sure you do understand the restrictions that apply to IPv6 addresses, like U/G bits, etc. Too many people unfortunately just think it's cool in a weird geeky sense and violate RFCs with them. I was very close to write an article about that after W6D... /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From bonomi at mail.r-bonomi.com Fri Jun 24 06:07:06 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 24 Jun 2011 06:07:06 -0500 (CDT) Subject: Yup; the Internet is screwed up. [ getting _way_ off-topic ] In-Reply-To: <4E03AA04.6070100@mompl.net> Message-ID: <201106241107.p5OB76rU073565@mail.r-bonomi.com> > Date: Thu, 23 Jun 2011 14:03:00 -0700 > To: NANOG list > Subject: Re: Yup; the Internet is screwed up. > [[ attibutions lost ]] > >> toddlers around and drive to and from work. An SUV in almost all cases > >> is added luxury. > > > > My SUV carries seven passengers and allows me to haul gear including > > conduit, lumber, ladders, etc. It's actively dangerous to do some of > > these things in a sedan. I'll just point out that that "depends on the sedan". I had a sedan[1] where I could carry three full sections of commercial scaffolding _inside_ the car. Six 5'x5' uprights, six 2'x10' platform sections, and all the cross-braces. 10' sections of conduit, or plumbing pipe were a 'nothing'. I could put half-sheets (4'x4') of plywood _flat_ on the floor of the trunk, and close the trunk lid. I had about 1500 lbs of actual cargo capacity, but I "wasn't legal" with over about half-a-ton on board. -- [1] A Cadillac Fleetwood on the 'long commercial' chassis, with a crica 8L engine, it routinely delivered 27+ mpg on the highway, with the A/C on, when lightly loaded. From jimmy.kyriannis at nyu.edu Fri Jun 24 07:10:20 2011 From: jimmy.kyriannis at nyu.edu (Jimmy Kyriannis) Date: Fri, 24 Jun 2011 08:10:20 -0400 Subject: Broken Teredo relay AS1101? In-Reply-To: <4DEECABE.6080902@kl.net> References: <4DEECABE.6080902@kl.net> Message-ID: <008101cc3267$b06151d0$1123f570$@kyriannis@nyu.edu> I'm still seeing this behavior, which is causing a good amount of Teredo-based connectivity to fail. The relay appears to be miredo.surfnet.nl - any chance someone on the list is from SURFNet and could take a look? -----Original Message----- From: Kevin Loch [mailto:kloch at kl.net] Sent: Tuesday, June 07, 2011 9:05 PM To: nanog list Subject: Broken Teredo relay AS1101? This path for 2001::/32 leads to a broken teredo relay: 3257 1103 1101 http://ip6.me was using this path and not working from my client. When I routing to prefer 6939's relays it started working. - Kevin From raymond at prolocation.net Fri Jun 24 07:13:32 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Fri, 24 Jun 2011 14:13:32 +0200 (CEST) Subject: Broken Teredo relay AS1101? In-Reply-To: <008101cc3267$b06151d0$1123f570$@kyriannis@nyu.edu> References: <4DEECABE.6080902@kl.net> <008101cc3267$b06151d0$1123f570$@kyriannis@nyu.edu> Message-ID: Hello Jimmy, > I'm still seeing this behavior, which is causing a good amount of > Teredo-based connectivity to fail. The relay appears to be > miredo.surfnet.nl - any chance someone on the list is from SURFNet and > could take a look? If you can send me offlist some traces i can check for you. > This path for 2001::/32 leads to a broken teredo relay: > > 3257 1103 1101 > > http://ip6.me was using this path and not working from my client. When I > routing to prefer 6939's relays it started working. We see ~ 180 mbps running over the relay so i doubt its a generic thing. Bye, Raymond. From mwalter at 3z.net Fri Jun 24 08:28:47 2011 From: mwalter at 3z.net (Mike Walter) Date: Fri, 24 Jun 2011 13:28:47 +0000 Subject: IPv6 words In-Reply-To: <4E03B9DE.5020205@mompl.net> References: <4E03B9DE.5020205@mompl.net> Message-ID: We decided to go the TEXT to HEX conversion route and our main website IPv6 Address ends in 337a:2e6e:6574 -Mike -----Original Message----- From: Jeroen van Aart [mailto:jeroen at mompl.net] Sent: Thursday, June 23, 2011 6:11 PM To: NANOG list Subject: IPv6 words I am sure it has come up a number of times, but with IPv6 you can make up fancy addresses that are (almost) complete words or phrases. Making it almost as easy to remember as the resolved name. It'd be nice in a weird geek sort of way (but totally impractical) to be able to request IPv6 blocks that have some sort of fancy name of your choice. 2001:db8:dead:beef:: dead:beef:: dead::beef As seen on http://en.wikipedia.org/wiki/Magic_number_%28programming%29 "DEADBEEF Famously used on IBM systems such as the RS/6000, also used in the original Mac OS operating systems, OPENSTEP Enterprise, and the Commodore Amiga. On Sun Microsystems' Solaris, marks freed kernel memory (KMEM_FREE_PATTERN)" Bonus points if your organisation's name only contains HEX characters. Greetings, Jeroen -- Earthquake Magnitude: 1.1 Date: Thursday, June 23, 2011 21:27:56 UTC Location: Southern California Latitude: 33.6613; Longitude: -116.7003 Depth: 17.10 km From bicknell at ufp.org Fri Jun 24 08:50:24 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 24 Jun 2011 06:50:24 -0700 Subject: IPv6 words In-Reply-To: References: <4E03B9DE.5020205@mompl.net> Message-ID: <20110624135024.GB85069@ussenterprise.ufp.org> In a message written on Fri, Jun 24, 2011 at 09:10:53AM +0000, Bjoern A. Zeeb wrote: > If you want to do it, make sure you do understand the restrictions that apply to IPv6 addresses, like U/G bits, etc. Too many people unfortunately just think it's cool in a weird geeky sense and violate RFCs with them. I was very close to write an article about that after W6D... Perhaps I missed something in an RFC somewhere, but I believe those bits only have meaning locally on an Ethernet LAN. They have no meaning when used on non-Ethernet networks, for instance POS or on a Loopback. If someone wanted to use them for a /128 virtual for their web site for instance that would be ok. Or, turning that around, if you assume an IPv6 address is part of a /64 on an Ethernet network, you have made a false assumption. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From joelja at bogus.com Fri Jun 24 10:16:38 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 24 Jun 2011 08:16:38 -0700 Subject: IPv6 words In-Reply-To: <20110624135024.GB85069@ussenterprise.ufp.org> References: <4E03B9DE.5020205@mompl.net> <20110624135024.GB85069@ussenterprise.ufp.org> Message-ID: <5C24E8A1-F906-428B-B54D-CAC26756B4DE@bogus.com> On Jun 24, 2011, at 6:50 AM, Leo Bicknell wrote: > In a message written on Fri, Jun 24, 2011 at 09:10:53AM +0000, Bjoern A. Zeeb wrote: >> If you want to do it, make sure you do understand the restrictions that apply to IPv6 addresses, like U/G bits, etc. Too many people unfortunately just think it's cool in a weird geeky sense and violate RFCs with them. I was very close to write an article about that after W6D... > > Perhaps I missed something in an RFC somewhere, but I believe those > bits only have meaning locally on an Ethernet LAN. They have no > meaning when used on non-Ethernet networks, for instance POS or on > a Loopback. If someone wanted to use them for a /128 virtual for > their web site for instance that would be ok. > > Or, turning that around, if you assume an IPv6 address is part of a /64 > on an Ethernet network, you have made a false assumption. A load-balancer attached to it's first hop router via a /126 may well advertise the virtual ip's it's serving (and treat them) as /128s. the assumption that links are /64s falls down a lot (even on ethernet) when most of them are point-to-point. > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From raymond at prolocation.net Fri Jun 24 11:13:32 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Fri, 24 Jun 2011 18:13:32 +0200 (CEST) Subject: Broken Teredo relay AS1101? In-Reply-To: References: <4DEECABE.6080902@kl.net> <008101cc3267$b06151d0$1123f570$@kyriannis@nyu.edu> Message-ID: Hi! >> I'm still seeing this behavior, which is causing a good amount of >> Teredo-based connectivity to fail. The relay appears to be >> miredo.surfnet.nl - any chance someone on the list is from SURFNet and >> could take a look? > If you can send me offlist some traces i can check for you. >> This path for 2001::/32 leads to a broken teredo relay: >> >> 3257 1103 1101 >> >> http://ip6.me was using this path and not working from my client. When I >> routing to prefer 6939's relays it started working. > We see ~ 180 mbps running over the relay so i doubt its a generic thing. This has been resolved. Thanks, Raymond. From cscora at apnic.net Fri Jun 24 14:05:08 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Jun 2011 05:05:08 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201106241905.p5OJ58tY031454@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 25 Jun, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 361681 Prefixes after maximum aggregation: 164222 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 178750 Total ASes present in the Internet Routing Table: 37989 Prefixes per ASN: 9.52 Origin-only ASes present in the Internet Routing Table: 31644 Origin ASes announcing only one prefix: 15205 Transit ASes present in the Internet Routing Table: 5162 Transit-only ASes present in the Internet Routing Table: 136 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 849 Unregistered ASNs in the Routing Table: 461 Number of 32-bit ASNs allocated by the RIRs: 1493 Number of 32-bit ASNs visible in the Routing Table: 1183 Prefixes from 32-bit ASNs in the Routing Table: 2711 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 137 Number of addresses announced to Internet: 2493130048 Equivalent to 148 /8s, 154 /16s and 37 /24s Percentage of available address space announced: 67.3 Percentage of allocated address space announced: 67.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.0 Total number of prefixes smaller than registry allocations: 150698 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 89840 Total APNIC prefixes after maximum aggregation: 30209 APNIC Deaggregation factor: 2.97 Prefixes being announced from the APNIC address blocks: 86590 Unique aggregates announced from the APNIC address blocks: 36226 APNIC Region origin ASes present in the Internet Routing Table: 4497 APNIC Prefixes per ASN: 19.26 APNIC Region origin ASes announcing only one prefix: 1249 APNIC Region transit ASes present in the Internet Routing Table: 712 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 52 Number of APNIC addresses announced to Internet: 622748704 Equivalent to 37 /8s, 30 /16s and 100 /24s Percentage of available APNIC address space announced: 79.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 141304 Total ARIN prefixes after maximum aggregation: 72518 ARIN Deaggregation factor: 1.95 Prefixes being announced from the ARIN address blocks: 113252 Unique aggregates announced from the ARIN address blocks: 46525 ARIN Region origin ASes present in the Internet Routing Table: 14441 ARIN Prefixes per ASN: 7.84 ARIN Region origin ASes announcing only one prefix: 5515 ARIN Region transit ASes present in the Internet Routing Table: 1518 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 819201536 Equivalent to 48 /8s, 212 /16s and 6 /24s Percentage of available ARIN address space announced: 65.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 86138 Total RIPE prefixes after maximum aggregation: 48944 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 79529 Unique aggregates announced from the RIPE address blocks: 52628 RIPE Region origin ASes present in the Internet Routing Table: 15751 RIPE Prefixes per ASN: 5.05 RIPE Region origin ASes announcing only one prefix: 7864 RIPE Region transit ASes present in the Internet Routing Table: 2496 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 870 Number of RIPE addresses announced to Internet: 478213376 Equivalent to 28 /8s, 128 /16s and 245 /24s Percentage of available RIPE address space announced: 77.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 33273 Total LACNIC prefixes after maximum aggregation: 7572 LACNIC Deaggregation factor: 4.39 Prefixes being announced from the LACNIC address blocks: 32313 Unique aggregates announced from the LACNIC address blocks: 16912 LACNIC Region origin ASes present in the Internet Routing Table: 1471 LACNIC Prefixes per ASN: 21.97 LACNIC Region origin ASes announcing only one prefix: 439 LACNIC Region transit ASes present in the Internet Routing Table: 264 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 245 Number of LACNIC addresses announced to Internet: 85595904 Equivalent to 5 /8s, 26 /16s and 23 /24s Percentage of available LACNIC address space announced: 56.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8197 Total AfriNIC prefixes after maximum aggregation: 1952 AfriNIC Deaggregation factor: 4.20 Prefixes being announced from the AfriNIC address blocks: 6495 Unique aggregates announced from the AfriNIC address blocks: 1981 AfriNIC Region origin ASes present in the Internet Routing Table: 459 AfriNIC Prefixes per ASN: 14.15 AfriNIC Region origin ASes announcing only one prefix: 138 AfriNIC Region transit ASes present in the Internet Routing Table: 102 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 24303616 Equivalent to 1 /8s, 114 /16s and 216 /24s Percentage of available AfriNIC address space announced: 36.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2458 9500 928 Korea Telecom (KIX) 17974 1842 460 45 PT TELEKOMUNIKASI INDONESIA 7545 1542 301 84 TPG Internet Pty Ltd 4755 1479 634 168 TATA Communications formerly 24560 1153 336 187 Bharti Airtel Ltd., Telemedia 9583 1079 80 510 Sify Limited 4808 1051 2092 302 CNCGROUP IP network: China169 9829 1043 886 64 BSNL National Internet Backbo 17488 957 183 104 Hathway IP Over Cable Interne 18101 931 116 138 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3629 3819 249 bellsouth.net, inc. 18566 1913 365 241 Covad Communications 1785 1797 681 122 PaeTec Communications, Inc. 4323 1661 1081 398 Time Warner Telecom 20115 1586 1531 635 Charter Communications 6478 1499 276 522 AT&T Worldnet Services 19262 1451 4805 372 Verizon Global Networks 7018 1358 7053 892 AT&T WorldNet Services 22773 1346 2897 87 Cox Communications, Inc. 7029 1309 790 298 Alltel Information Services, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 530 107 183 BILISIM TELEKOM 6830 515 1780 320 UPC Distribution Services 3292 469 2080 404 TDC Tele Danmark 20940 467 137 359 Akamai Technologies European 8866 445 134 26 Bulgarian Telecommunication C 29049 444 33 45 AzerSat LLC. 12479 437 593 7 Uni2 Autonomous System 3320 420 8151 367 Deutsche Telekom AG 8551 404 354 44 Bezeq International 3301 396 1839 345 TeliaNet Sweden Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1532 281 157 TVCABLE BOGOTA 8151 1422 2736 358 UniNet S.A. de C.V. 28573 1264 993 78 NET Servicos de Comunicao S.A 7303 993 507 171 Telecom Argentina Stet-France 6503 741 354 74 AVANTEL, S.A. 14420 683 55 82 CORPORACION NACIONAL DE TELEC 22047 576 322 17 VTR PUNTO NET S.A. 3816 531 231 94 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 27947 500 53 52 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 798 147 37 LINKdotNET AS number 8452 791 445 11 TEDATA 15475 525 74 8 Nile Online 36992 318 415 14 Etisalat MISR 3741 261 937 223 The Internet Solution 6713 241 215 13 Itissalat Al-MAGHRIB 33776 216 12 11 Starcomms Nigeria Limited 24835 211 78 10 RAYA Telecom - Egypt 29571 192 17 11 Ci Telecom Autonomous system 16637 149 441 86 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3629 3819 249 bellsouth.net, inc. 23456 2711 657 1466 32-bit ASN transition 4766 2458 9500 928 Korea Telecom (KIX) 18566 1913 365 241 Covad Communications 17974 1842 460 45 PT TELEKOMUNIKASI INDONESIA 1785 1797 681 122 PaeTec Communications, Inc. 4323 1661 1081 398 Time Warner Telecom 20115 1586 1531 635 Charter Communications 7545 1542 301 84 TPG Internet Pty Ltd 10620 1532 281 157 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 1842 1797 PT TELEKOMUNIKASI INDONESIA 1785 1797 1675 PaeTec Communications, Inc. 18566 1913 1672 Covad Communications 4766 2458 1530 Korea Telecom (KIX) 7545 1542 1458 TPG Internet Pty Ltd 10620 1532 1375 TVCABLE BOGOTA 4755 1479 1311 TATA Communications formerly 4323 1661 1263 Time Warner Telecom 22773 1346 1259 Cox Communications, Inc. 23456 2711 1245 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 27.0.128.0/17 7514 Media Exchange, Inc. 41.190.32.0/23 31856 CABSAS 41.190.34.0/23 31856 CABSAS 41.190.36.0/23 31856 CABSAS Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:23 /9:12 /10:28 /11:81 /12:231 /13:461 /14:800 /15:1395 /16:11963 /17:5860 /18:9743 /19:19407 /20:25807 /21:26086 /22:34501 /23:33493 /24:188475 /25:1088 /26:1268 /27:728 /28:214 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2233 3629 bellsouth.net, inc. 18566 1869 1913 Covad Communications 6478 1466 1499 AT&T Worldnet Services 10620 1427 1532 TVCABLE BOGOTA 23456 1335 2711 32-bit ASN transition 11492 1090 1136 Cable One 7011 1058 1159 Citizens Utilities 7029 1055 1309 Alltel Information Services, 1785 1050 1797 PaeTec Communications, Inc. 22773 861 1346 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:297 2:42 4:16 5:1 6:3 8:336 12:1978 13:1 14:463 15:15 16:3 17:8 20:10 23:12 24:1657 27:806 31:482 32:64 33:4 34:2 37:1 38:738 39:3 40:103 41:2550 42:2 44:3 46:986 47:3 49:196 50:413 52:13 54:2 55:2 56:2 57:32 58:856 59:473 60:386 61:1183 62:1051 63:1937 64:3945 65:2288 66:3881 67:1901 68:1092 69:3048 70:756 71:388 72:1888 74:2383 75:319 76:340 77:884 78:714 79:464 80:1109 81:837 82:492 83:456 84:670 85:1078 86:552 87:759 88:333 89:1525 90:209 91:3871 92:536 93:1045 94:1316 95:839 96:445 97:253 98:880 99:36 101:76 103:90 106:10 107:16 108:70 109:1012 110:612 111:707 112:303 113:406 114:543 115:666 116:968 117:671 118:851 119:1144 120:313 121:669 122:1633 123:959 124:1303 125:1239 128:247 129:172 130:168 131:577 132:112 133:21 134:214 135:48 136:214 137:138 138:300 139:114 140:479 141:239 142:403 143:419 144:489 145:54 146:450 147:215 148:659 149:245 150:170 151:190 152:332 153:180 154:4 155:398 156:195 157:350 158:137 159:452 160:313 161:208 162:310 163:162 164:506 165:354 166:534 167:433 168:739 169:158 170:846 171:78 172:1 173:1621 174:607 175:372 176:138 177:150 178:1008 180:898 181:19 182:484 183:223 184:307 185:1 186:1234 187:738 188:873 189:913 190:4908 192:5867 193:4973 194:3489 195:3040 196:1222 197:41 198:3586 199:3958 200:5530 201:1503 202:8356 203:8429 204:4202 205:2347 206:2682 207:2809 208:3955 209:3471 210:2727 211:1460 212:2100 213:1739 214:772 215:69 216:4933 217:1636 218:549 219:362 220:1207 221:490 222:361 223:161 End of report From cidr-report at potaroo.net Fri Jun 24 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Jun 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201106242200.p5OM01TZ050836@wattle.apnic.net> BGP Update Report Interval: 16-Jun-11 -to- 23-Jun-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15557 233321 8.3% 12.0 -- LDCOMNET NEUF CEGETEL (formerly LDCOM NETWORKS) 2 - AS4538 69868 2.5% 13.1 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS7184 42557 1.5% 733.7 -- Universidad Verecruzana 4 - AS17974 39981 1.4% 21.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 5 - AS7303 26505 0.9% 26.7 -- Telecom Argentina S.A. 6 - AS33260 25398 0.9% 6349.5 -- HOSTASAURUS - Hostasaurus, Inc. 7 - AS9829 22316 0.8% 21.9 -- BSNL-NIB National Internet Backbone 8 - AS32528 16845 0.6% 2105.6 -- ABBOTT Abbot Labs 9 - AS42910 16563 0.6% 98.0 -- SADECEHOSTING-COM Sadecehosting-Com 10 - AS11492 15736 0.6% 13.9 -- CABLEONE - CABLE ONE, INC. 11 - AS9498 15546 0.6% 18.8 -- BBIL-AP BHARTI Airtel Ltd. 12 - AS7552 15301 0.6% 13.2 -- VIETEL-AS-AP Vietel Corporation 13 - AS8151 13824 0.5% 9.8 -- Uninet S.A. de C.V. 14 - AS33475 12862 0.5% 59.8 -- RSN-1 - RockSolid Network, Inc. 15 - AS28573 12643 0.5% 9.3 -- NET Servicos de Comunicao S.A. 16 - AS6389 12312 0.4% 3.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 17 - AS4755 11378 0.4% 7.7 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 18 - AS3320 11346 0.4% 26.8 -- DTAG Deutsche Telekom AG 19 - AS45595 11037 0.4% 42.5 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 20 - AS7029 10927 0.4% 5.7 -- WINDSTREAM - Windstream Communications Inc TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS33260 25398 0.9% 6349.5 -- HOSTASAURUS - Hostasaurus, Inc. 2 - AS32528 16845 0.6% 2105.6 -- ABBOTT Abbot Labs 3 - AS28519 4833 0.2% 1611.0 -- Universidad Autonoma de Guadalajara, A.C. 4 - AS46778 1354 0.1% 1354.0 -- PHSI-1996 - Prevea Health Services Inc 5 - AS49600 1100 0.0% 1100.0 -- LASEDA La Seda de Barcelona, S.A 6 - AS3454 7482 0.3% 1068.9 -- Universidad Autonoma de Nuevo Leon 7 - AS31750 866 0.0% 866.0 -- METHODIST-HEALTHCARE - Methodist Hospital of Memphis 8 - AS53492 836 0.0% 836.0 -- CVTYBGP2 - Coventry Health Care, Inc. 9 - AS7184 42557 1.5% 733.7 -- Universidad Verecruzana 10 - AS44584 2564 0.1% 641.0 -- PTLINE-AS Progress Tehnologiya LLC 11 - AS23091 3816 0.1% 636.0 -- Universidad Autonoma Chapingo 12 - AS48877 1700 0.1% 566.7 -- YUNICOM-AS Yunicom Ltd 13 - AS56050 547 0.0% 547.0 -- NEW-SHINE-INTERNET-TH 134 Yenchit Road 14 - AS3 505 0.0% 735.0 -- CCPG-AS CCPG Solutions Ltd 15 - AS49987 467 0.0% 467.0 -- SPARK-AS Stroy Park - R Ltd 16 - AS44715 1634 0.1% 408.5 -- GLOBALCOM-AS Globalcom Ltd. 17 - AS44967 2814 0.1% 402.0 -- TASIO Tasio Ltd 18 - AS56864 398 0.0% 398.0 -- ASITTELECOM AyTi Telekom Ltd. 19 - AS56541 398 0.0% 398.0 -- KOMETA-AS KOMETA LLC 20 - AS52010 386 0.0% 386.0 -- RED-AS Red-Telecom Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 9840 0.3% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 91.217.214.0/24 9773 0.3% AS3320 -- DTAG Deutsche Telekom AG 3 - 130.36.35.0/24 8404 0.3% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.34.0/24 8402 0.3% AS32528 -- ABBOTT Abbot Labs 5 - 192.100.199.0/24 8301 0.3% AS278 -- Universidad Nacional Autonoma de Mexico 6 - 200.23.202.0/24 7442 0.2% AS3454 -- Universidad Autonoma de Nuevo Leon 7 - 199.48.232.0/21 6365 0.2% AS33260 -- HOSTASAURUS - Hostasaurus, Inc. 8 - 204.10.64.0/21 6355 0.2% AS33260 -- HOSTASAURUS - Hostasaurus, Inc. 9 - 208.77.48.0/21 6339 0.2% AS33260 -- HOSTASAURUS - Hostasaurus, Inc. 10 - 204.15.120.0/21 6339 0.2% AS33260 -- HOSTASAURUS - Hostasaurus, Inc. 11 - 202.153.174.0/24 3420 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 12 - 202.54.86.0/24 2614 0.1% AS4755 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 13 - 202.70.75.0/24 2346 0.1% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services, 14 - 65.181.192.0/23 2098 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 15 - 67.214.68.0/23 1940 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 16 - 67.214.72.0/22 1722 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 17 - 206.28.78.0/24 1670 0.1% AS11323 -- GETTYIMAGES - Getty Images 18 - 148.239.251.0/24 1649 0.1% AS28519 -- Universidad Autonoma de Guadalajara, A.C. 19 - 72.10.56.0/21 1629 0.1% AS31815 -- MEDIATEMPLE - Media Temple, Inc. 20 - 148.239.250.0/24 1592 0.1% AS28519 -- Universidad Autonoma de Guadalajara, A.C. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 24 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Jun 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201106242200.p5OM00Zm050831@wattle.apnic.net> This report has been generated at Fri Jun 24 21:12:25 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 17-06-11 363542 214415 18-06-11 363893 214390 19-06-11 363941 214481 20-06-11 364201 214602 21-06-11 364389 214258 22-06-11 364520 213988 23-06-11 364822 214392 24-06-11 364763 215127 AS Summary 38087 Number of ASes in routing system 16048 Number of ASes announcing only one prefix 3626 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109796608 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 24Jun11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 364995 215091 149904 41.1% All ASes AS6389 3626 253 3373 93.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2458 946 1512 61.5% KIXS-AS-KR Korea Telecom AS18566 1913 497 1416 74.0% COVAD - Covad Communications Co. AS10620 1532 190 1342 87.6% Telmex Colombia S.A. AS4323 1662 400 1262 75.9% TWTC - tw telecom holdings, inc. AS22773 1346 96 1250 92.9% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1451 372 1079 74.4% VZGNI-TRANSIT - Verizon Online LLC AS1785 1800 762 1038 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1266 278 988 78.0% NET Servicos de Comunicao S.A. AS4755 1479 509 970 65.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7545 1542 736 806 52.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 933 145 788 84.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1153 406 747 64.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1428 691 737 51.6% Uninet S.A. de C.V. AS6478 1499 768 731 48.8% ATT-INTERNET3 - AT&T Services, Inc. AS4808 1054 340 714 67.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7552 777 81 696 89.6% VIETEL-AS-AP Vietel Corporation AS7303 991 310 681 68.7% Telecom Argentina S.A. AS3356 1118 457 661 59.1% LEVEL3 Level 3 Communications AS17488 957 317 640 66.9% HATHWAY-NET-AP Hathway IP Over Cable Internet AS14420 683 82 601 88.0% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS17676 667 70 597 89.5% GIGAINFRA Softbank BB Corp. AS22561 932 358 574 61.6% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 977 418 559 57.2% GBLX Global Crossing Ltd. AS22047 576 32 544 94.4% VTR BANDA ANCHA S.A. AS4780 750 215 535 71.3% SEEDNET Digital United Inc. AS7011 1159 628 531 45.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS855 638 117 521 81.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS15475 525 8 517 98.5% NOL AS20115 1590 1078 512 32.2% CHARTER-NET-HKY-NC - Charter Communications Total 38482 11560 26922 70.0% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 27.0.128.0/17 AS7514 MEX Media EXchange, Inc. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.22.32.0/19 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.0.0.0/8 AS9811 BJGY srit corp.,beijing. 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 131.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.72.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.100.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.161.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.221.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 131.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.157.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.184.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.191.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 132.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 134.175.0.0/16 AS14576 RHNL-NET - Righthosting.com 134.175.0.0/19 AS12124 THORN - Thorn Communications 138.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.36.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.94.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.97.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.99.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.117.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.118.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.122.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.185.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.186.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.219.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 138.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 143.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.137.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.208.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 143.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.101.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.102.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.103.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 148.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.156.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.166.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.167.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.168.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.169.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.170.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.171.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.172.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.173.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.174.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.175.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.200.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.201.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.202.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.203.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.204.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.206.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.207.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.230.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.235.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.236.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.237.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.240.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.241.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.242.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.243.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.248.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.251.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.252.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.253.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 152.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 161.10.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.18.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.22.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.138.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.140.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.212.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.234.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 161.255.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.56.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.57.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.58.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.59.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.60.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.61.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.62.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.63.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.108.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.116.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.249.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 167.250.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.0.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.90.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.121.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.181.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.194.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.195.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.196.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.197.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.205.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.227.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.228.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 168.232.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.78.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.79.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.80.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.81.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.82.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.83.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.84.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.150.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.231.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.233.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.238.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.239.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.244.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.245.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.246.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.247.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 170.254.0.0/16 AS237 MERIT-AS-14 - Merit Network Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 182.50.68.0/22 AS55438 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 191.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.158.25.0/24 AS2717 CUMMINS-AS1 - Cummins Engine Co. Inc. 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.168.122.0/24 AS11489 BACI - Bell Canada 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.101.0/24 AS45645 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.63.80.0/24 AS9557 PKTELECOM-AS-PK Paknet Limited Merged into PTCL 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.147.110.0/24 AS45165 203.147.111.0/24 AS45165 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.190.32.0/22 AS24564 204.10.232.0/21 AS33150 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jra at baylink.com Fri Jun 24 17:29:14 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Jun 2011 18:29:14 -0400 (EDT) Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> Message-ID: <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> The North American Electric Reliability Council is planning to relax the standards for how closely power utilities must hold to 60.00Hz. Here's my absolute favorite quote of all time: Tweaking the power grid's frequency is expensive and takes a lot of effort, said Joe McClelland, head of electric reliability for the Federal Energy Regulatory Commission. "Is anyone using the grid to keep track of time?" McClelland said. "Let's see if anyone complains if we eliminate it." http://hosted.ap.org/dynamic/stories/U/US_SCI_POWER_CLOCKS?SITE=AP&SECTION=HOME&TEMPLATE=DEFAULT I believe the answer to that question is contained here: http://yarchive.net/car/rv/generator_synchronization.html [1] This is gonna be fun, no? Cheers, -- jra [1]Please, let's not start in on the source.[2] [2]No, really: *please*. :-) -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From pelzi at pelzi.net Fri Jun 24 23:32:41 2011 From: pelzi at pelzi.net (Jussi Peltola) Date: Sat, 25 Jun 2011 07:32:41 +0300 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> Message-ID: <20110625043241.GF25848@pokute.pelzi.net> On Fri, Jun 24, 2011 at 06:29:14PM -0400, Jay Ashworth wrote: > This is gonna be fun, no? If your definition of fun is spending a year watching an old microwave clock lose or gain a few minutes. I don't see how this has anything to do with syncing two generators. The grid is in sync, and if the frequency of the grid changes (as it does all the time) it will stay in sync. It has nothing to do with the absolute frequency. From behrnetworks at gmail.com Sat Jun 25 08:28:40 2011 From: behrnetworks at gmail.com (Chris) Date: Sat, 25 Jun 2011 09:28:40 -0400 Subject: What do you think about the Juniper MX line? Message-ID: Hello, I've been doing some research into using the MX line of Juniper routers and was interested in hearing people's experiences (the good, bad, and ugly). What do you like about them? What do you dislike? Where are you putting them in your network? Where are you not putting them? Why? What other platforms would you consider and why? I hope to hear some candid responses, but feel free to respond privately if you need to. Thanks! From mike at cmkconsulting.com Sat Jun 25 09:02:45 2011 From: mike at cmkconsulting.com (Mickey Fox) Date: Sat, 25 Jun 2011 09:02:45 -0500 Subject: Looking for Contact at Network Solutions Message-ID: Good Morning List: I'm looking for a POC at NetSol because, after 16 years as a customer, we have a seriously pooched DNS issue and I can't get any capable support over the phone. While I am intermittently receiving email on this domain, I seem able to send it, and I am uncertain that I will receive any nanog responses on the domain so please contact me @ this email and a cc to mike at magnaturris.com. domain : cmkconsulting.com TIA, Michael Fox ______________________________________________ Failure is not an option: It comes bundled with Windows From mike at cmkconsulting.com Sat Jun 25 09:05:19 2011 From: mike at cmkconsulting.com (Mickey Fox) Date: Sat, 25 Jun 2011 09:05:19 -0500 Subject: NANOG Digest, Vol 41, Issue 153 In-Reply-To: References: Message-ID: Failure to sync = dirty power and a horribly corrupted sine wave. A bit more than watching an old microwave. On Sat, Jun 25, 2011 at 7:00 AM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Wacky Weekend: NERC to relax power grid frequency strictures > (Jay Ashworth) > 2. Re: Wacky Weekend: NERC to relax power grid frequency > strictures (Jussi Peltola) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 24 Jun 2011 18:29:14 -0400 (EDT) > From: Jay Ashworth > Subject: Wacky Weekend: NERC to relax power grid frequency strictures > To: NANOG > Message-ID: > <23981692.56.1308954554440.JavaMail.root at benjamin.baylink.com> > Content-Type: text/plain; charset=utf-8 > > The North American Electric Reliability Council is planning to relax > the standards for how closely power utilities must hold to 60.00Hz. > > Here's my absolute favorite quote of all time: > > Tweaking the power grid's frequency is expensive and takes a lot of > effort, > said Joe McClelland, head of electric reliability for the Federal Energy > Regulatory Commission. > > "Is anyone using the grid to keep track of time?" McClelland said. "Let's > see > if anyone complains if we eliminate it." > > > http://hosted.ap.org/dynamic/stories/U/US_SCI_POWER_CLOCKS?SITE=AP&SECTION=HOME&TEMPLATE=DEFAULT > > I believe the answer to that question is contained here: > > http://yarchive.net/car/rv/generator_synchronization.html [1] > > This is gonna be fun, no? > > Cheers, > -- jra > [1]Please, let's not start in on the source.[2] > [2]No, really: *please*. :-) > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 > 1274 > > > > ------------------------------ > > Message: 2 > Date: Sat, 25 Jun 2011 07:32:41 +0300 > From: Jussi Peltola > Subject: Re: Wacky Weekend: NERC to relax power grid frequency > strictures > To: nanog at nanog.org > Message-ID: <20110625043241.GF25848 at pokute.pelzi.net> > Content-Type: text/plain; charset=us-ascii > > On Fri, Jun 24, 2011 at 06:29:14PM -0400, Jay Ashworth wrote: > > This is gonna be fun, no? > > If your definition of fun is spending a year watching an old microwave > clock lose or gain a few minutes. > > I don't see how this has anything to do with syncing two generators. The > grid is in sync, and if the frequency of the grid changes (as it does > all the time) it will stay in sync. It has nothing to do with the > absolute frequency. > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 41, Issue 153 > ************************************** > From jra at baylink.com Sat Jun 25 09:49:00 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 25 Jun 2011 10:49:00 -0400 (EDT) Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <20110625043241.GF25848@pokute.pelzi.net> Message-ID: <18274001.98.1309013340612.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jussi Peltola" > On Fri, Jun 24, 2011 at 06:29:14PM -0400, Jay Ashworth wrote: > > This is gonna be fun, no? > > If your definition of fun is spending a year watching an old microwave > clock lose or gain a few minutes. > > I don't see how this has anything to do with syncing two generators. > The grid is in sync, and if the frequency of the grid changes (as it does > all the time) it will stay in sync. It has nothing to do with the > absolute frequency. Perhaps I read the piece incorrectly, but it certainly sounded to *me* like the part that was hard was not hitting 60.00, but *staying in sync with others*... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From bill at herrin.us Sat Jun 25 10:06:32 2011 From: bill at herrin.us (William Herrin) Date: Sat, 25 Jun 2011 11:06:32 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <18274001.98.1309013340612.JavaMail.root@benjamin.baylink.com> References: <20110625043241.GF25848@pokute.pelzi.net> <18274001.98.1309013340612.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, Jun 25, 2011 at 10:49 AM, Jay Ashworth wrote: > Perhaps I read the piece incorrectly, but it certainly sounded to *me* like > the part that was hard was not hitting 60.00, but *staying in sync with > others*... Way I read it, when they occasionally run at 59.9hz for a few hours (and according to my UPS monitoring software this is a regular occurance), they're no longer going to run at 60.1 hz for a while so that the average comes out to 60. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanog.20110127 at jason.roysdon.net Sat Jun 25 13:03:08 2011 From: nanog.20110127 at jason.roysdon.net (Jason Roysdon) Date: Sat, 25 Jun 2011 11:03:08 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <18274001.98.1309013340612.JavaMail.root@benjamin.baylink.com> References: <18274001.98.1309013340612.JavaMail.root@benjamin.baylink.com> Message-ID: <4E0622DC.6040208@jason.roysdon.net> On 06/25/2011 07:49 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jussi Peltola" > >> On Fri, Jun 24, 2011 at 06:29:14PM -0400, Jay Ashworth wrote: >>> This is gonna be fun, no? >> >> If your definition of fun is spending a year watching an old microwave >> clock lose or gain a few minutes. >> >> I don't see how this has anything to do with syncing two generators. >> The grid is in sync, and if the frequency of the grid changes (as it does >> all the time) it will stay in sync. It has nothing to do with the >> absolute frequency. > > Perhaps I read the piece incorrectly, but it certainly sounded to *me* like > the part that was hard was not hitting 60.00, but *staying in sync with > others*... > > Cheers, > -- jra Generators all stay in sync. Generator owners have expensive devices that sync the phase before the generator is connected to the grid. Once a generator is connected to the gird, it will stay in sync - in fact that is why they have the expensive devices to make sure that they are in sync before they connect them, as if they are not, it will instantly jump to being in sync, which may destroy the generator. I'm not an electrical engineer, but I do IT "Cybersecurity" for a local utility. The electrical engineering / power utility side of the house starts to rub off - but I say this as I might not have all the terms exactly right. I follow the FERC/NERC discussions as CIP compliance is one of my primary job duties. In fact, if you want to see what happens if you connect a generator out of phase, just look into the AURORA out-of-phase circuit breaker re-closing issues which were brought to light last year. Here's some links: http://www.atcllc.com/oasis/Customer_Notices/ATCNetworkCustomerMeeting052411_Francis.pdf Here's another link I read in the last week when trying to get up to speak more: http://yarchive.net/car/rv/generator_synchronization.html Jason Roysdon From owen at delong.com Sat Jun 25 14:04:02 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 25 Jun 2011 12:04:02 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E0622DC.6040208@jason.roysdon.net> References: <18274001.98.1309013340612.JavaMail.root@benjamin.baylink.com> <4E0622DC.6040208@jason.roysdon.net> Message-ID: On Jun 25, 2011, at 11:03 AM, Jason Roysdon wrote: > > On 06/25/2011 07:49 AM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Jussi Peltola" >> >>> On Fri, Jun 24, 2011 at 06:29:14PM -0400, Jay Ashworth wrote: >>>> This is gonna be fun, no? >>> >>> If your definition of fun is spending a year watching an old microwave >>> clock lose or gain a few minutes. >>> >>> I don't see how this has anything to do with syncing two generators. >>> The grid is in sync, and if the frequency of the grid changes (as it does >>> all the time) it will stay in sync. It has nothing to do with the >>> absolute frequency. >> >> Perhaps I read the piece incorrectly, but it certainly sounded to *me* like >> the part that was hard was not hitting 60.00, but *staying in sync with >> others*... >> >> Cheers, >> -- jra > > Generators all stay in sync. Generator owners have expensive devices > that sync the phase before the generator is connected to the grid. Once > a generator is connected to the gird, it will stay in sync - in fact > that is why they have the expensive devices to make sure that they are > in sync before they connect them, as if they are not, it will instantly > jump to being in sync, which may destroy the generator. > As a matter of fact, it may destroy the generator, the housing, the building, the damn, and more. An out-of-sync generator becomes a motor until it is in sync. lt can be a graphic and dramatic event. Owen From nanog.20110127 at jason.roysdon.net Sat Jun 25 14:52:11 2011 From: nanog.20110127 at jason.roysdon.net (Jason Roysdon) Date: Sat, 25 Jun 2011 12:52:11 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: References: <20110625043241.GF25848@pokute.pelzi.net> <18274001.98.1309013340612.JavaMail.root@benjamin.baylink.com> Message-ID: <4E063C6B.4080303@jason.roysdon.net> On 06/25/2011 08:06 AM, William Herrin wrote: > On Sat, Jun 25, 2011 at 10:49 AM, Jay Ashworth wrote: >> Perhaps I read the piece incorrectly, but it certainly sounded to *me* like >> the part that was hard was not hitting 60.00, but *staying in sync with >> others*... > > Way I read it, when they occasionally run at 59.9hz for a few hours > (and according to my UPS monitoring software this is a regular > occurance), they're no longer going to run at 60.1 hz for a while so > that the average comes out to 60. > > Regards, > Bill Herrin > > This paper describes what they currently do to keep clocks accurate with Manual Time Error Correction (which is what they are going to suspect for a year): http://www.naesb.org/pdf2/weq_bklet_011505_tec_mc.pdf As I said in my last post, I'm not an EE, but just follow some of topics on that side of the house. What I gather is that Manual TEC, which is done by purposely running the frequency away from 60Hz to correct an average deviation, can actually cause more problems. "NERC is investigating the possibility of eliminating Time Error Corrections. NERC has been collecting data regarding Interconnection frequency performance, including the number of clock-?? minutes during which actual frequency dropped below the low Frequency Trigger Limit (FTL) of 59.95 Hertz. During the period of July 2005 through March 2010, approximately 44% of the minutes during which clock-??minute actual frequency dropped below the low FTL occurred during Time Error Corrections when scheduled frequency was 59.98 Hertz (1,875 of the 4,234 total minutes observed below 59.95 Hertz). Upon further investigation, it was found that almost all of those minutes (1,819 of the 1,875 total) represented frequency deviations that would likely not have dropped frequency below 59.95 Hertz if the scheduled frequency had been 60 Hertz. In other words, approximately 97% of the Low FTLs were of such a magnitude that if the Time Error Correction had not been in effect, the exceedance of the low FTL would not have occurred. These Frequency Trigger Limits in and of themselves are only indicators of system behavior, but the nature of their relationship to Time Error Corrections calls into question the potential impact that Time Error Corrections can have on frequency behavior overall. While it is intuitively obvious that any frequency offset that moves target frequency away from the reference point to which all other frequency sensitive devices (such as relays) have been indexed will have a potential impact on those devices? performance, the industry has by and large regarded Time Error Corrections as harmless and necessary as part of the service it provides to its customers. However, in light of this data, NERC?s stakeholders are now questioning whether or not the intentional movement closer to (or in some cases, further away from) the trigger settings of frequency-??based protection devices as is evidenced during Time Error Correction events is appropriate. Accordingly, NERC is planning a Field Trial during which the practice of doing Time Error Corrections will be suspended. Because of the fundamental nature of this 60Hz signal, NERC is reaching out to various industries to get their thoughts on whether they anticipate any problems with the elimination of Time Error Corrections. Those industries include appliance manufacturers, software companies, chemical manufacturers, companies that make automation equipment, computer manufacturers, and many others." Source: http://www.wecc.biz/library/Lists/Announcements/Attachments/9/June%2014%20Time%20Error%20Webinar.pdf The main point I gather is that trying to do manual Time Error Correction actually makes the power grid less stable at times, and as such they want to do away with it (thus making the power grid more stable). Think of it the same as patch management risk assessment. If there are no security or bug fixes that directly affect you or even feature enhancements that you don't need, do you apply a patch/upgrade to critical systems? Nah, you skip those, because we all know every patch/upgrade carries with it risk of an unknown bug or even security flaw. That's what they're doing here, opting to skip "patching" the time error. They're not ignoring frequency altogether, but rather only minding that aspects that have to do with grid stability, not your alarm clock. This is for the better anyway, and NTP/GPS/WWV/WWVH is the way to go to keep clocks accurate and hopefully will be the outcome of any consumer complaints. I've seen conversation in various forums and lists I read that they are going to ignore or not care about the 60Hz standard. This is incorrect. They just aren't going to purposely deviate from the scheduled frequency to perform manual TEC. Mind you, that they still care about why the frequency is off, and when things are not able to quickly compensate, they want to know and be able to pinpoint it and fix it: http://www.nerc.com/filez/standards/Frequency_Response.html Specifically, read this PDF: http://www.nerc.com/docs/oc/rfwg/NERC%20Balancing%20and%20Frequency%20Control%20July%205%202009.pdf The AP piece was focused on hype and word-spinning (I couldn't find an AP.org link, so used one that I could find, http://www.huffingtonpost.com/2011/06/24/clock-problems-power-grid-clock-disruptions_n_884259.html ): "The experiment would allow more frequency variation than it does now ? without corrections." The NERC BAL standards already hold the NERC entities to very high frequency standards, and this will be unchanged, except for manual TEC. All it is doing is eliminating the corrections made purely for time's sake, which actually eliminates more frequency variation. This may, or may not, create more average frequency variation, and that is part of this test. "Officials say they want to try it to make the power supply more reliable, save money and reduce what may be needless effort." This is the real goal, and should have been the focus of the news story - but that doesn't make headlines. I'm going to go shop for a new clock. I had one that used the WWV/WWVH stations, but then they messed with DST and it was off for a few weeks around each DS change. That forced me me to pull it off the wall and change the TZ at one time of the year to correct it, but the other time of the year I could not correct it (as it only had 4 TZ settings), so I took it down. Beware "Automatic Time Set" clocks which don't really learn the time from the WWV/WWVH stations (like the Sony ICF-C218, which has a preset time and battery, but still uses the frequency from the wall to maintain time). The best bet is a clock that requires batteries as you know it won't get time from the power grid. Jason Roysdon From jra at baylink.com Sat Jun 25 16:02:19 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 25 Jun 2011 17:02:19 -0400 (EDT) Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E063C6B.4080303@jason.roysdon.net> Message-ID: <69763.134.1309035739859.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jason Roysdon" > That's what they're doing here, opting to skip "patching" the time > error. They're not ignoring frequency altogether, but rather only > minding that aspects that have to do with grid stability, not your alarm > clock. This is for the better anyway, and NTP/GPS/WWV/WWVH is the way > to go to keep clocks accurate and hopefully will be the outcome of any > consumer complaints. > > I've seen conversation in various forums and lists I read that they are > going to ignore or not care about the 60Hz standard. This is incorrect. > They just aren't going to purposely deviate from the scheduled > frequency to perform manual TEC. > > Mind you, that they still care about why the frequency is off, and when > things are not able to quickly compensate, they want to know and be able > to pinpoint it and fix it: > http://www.nerc.com/filez/standards/Frequency_Response.html > > Specifically, read this PDF: > http://www.nerc.com/docs/oc/rfwg/NERC%20Balancing%20and%20Frequency%20Control%20July%205%202009.pdf Thank you, Jason. I did some searching before I posted that, to see if I could locate better information, but clearly, I didn't search hard enough. Cheers, -- jr 'my google-fu requires 60.01Hz :-)' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From nanog.20110127 at jason.roysdon.net Sat Jun 25 16:05:02 2011 From: nanog.20110127 at jason.roysdon.net (Jason Roysdon) Date: Sat, 25 Jun 2011 14:05:02 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <69763.134.1309035739859.JavaMail.root@benjamin.baylink.com> References: <69763.134.1309035739859.JavaMail.root@benjamin.baylink.com> Message-ID: <4E064D7E.2090501@jason.roysdon.net> On 06/25/2011 02:02 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jason Roysdon" > >> That's what they're doing here, opting to skip "patching" the time >> error. They're not ignoring frequency altogether, but rather only >> minding that aspects that have to do with grid stability, not your alarm >> clock. This is for the better anyway, and NTP/GPS/WWV/WWVH is the way >> to go to keep clocks accurate and hopefully will be the outcome of any >> consumer complaints. >> >> I've seen conversation in various forums and lists I read that they are >> going to ignore or not care about the 60Hz standard. This is incorrect. >> They just aren't going to purposely deviate from the scheduled >> frequency to perform manual TEC. >> >> Mind you, that they still care about why the frequency is off, and when >> things are not able to quickly compensate, they want to know and be able >> to pinpoint it and fix it: >> http://www.nerc.com/filez/standards/Frequency_Response.html >> >> Specifically, read this PDF: >> http://www.nerc.com/docs/oc/rfwg/NERC%20Balancing%20and%20Frequency%20Control%20July%205%202009.pdf > > Thank you, Jason. I did some searching before I posted that, to see if > I could locate better information, but clearly, I didn't search hard enough. > > Cheers, > -- jr 'my google-fu requires 60.01Hz :-)' a NERC's site is very hard to find info on if you don't know where to look. Even when you've found something before, it can be hard to find again. I run into that nearly monthly and have a document just to help me navigate to certain areas. http://www.nerc.com/page.php?cid=6|386 http://www.nerc.com/page.php?cid=6|386|391 http://www.nerc.com/files/NERC_TEC_Field_Trial_Webinar_061411.pdf http://www.nerc.com/filez/Webinars/tec_webinar_061411/index.htm References: <20110625043241.GF25848@pokute.pelzi.net> <18274001.98.1309013340612.JavaMail.root@benjamin.baylink.com> <4E063C6B.4080303@jason.roysdon.net> Message-ID: <4E065342.9050503@altadena.net> On 06/25/2011 03:52 PM, Jason Roysdon wrote: > On 06/25/2011 08:06 AM, William Herrin wrote: >> On Sat, Jun 25, 2011 at 10:49 AM, Jay Ashworth wrote: >>> Perhaps I read the piece incorrectly, but it certainly sounded to *me* like >>> the part that was hard was not hitting 60.00, but *staying in sync with >>> others*... If the grid is enough bigger than any one generator, that happens automatically; once connected, you can't get out of sync without tripping a circuit breaker. There are some minor exceptions for DC and VF AC generation (e.g. solar and wind respectively) >> Way I read it, when they occasionally run at 59.9hz for a few hours >> (and according to my UPS monitoring software this is a regular >> occurance), they're no longer going to run at 60.1 hz for a while so >> that the average comes out to 60. Finer gradations than that, but yes. >> Regards, >> Bill Herrin >> >> > This paper describes what they currently do to keep clocks accurate with > Manual Time Error Correction (which is what they are going to suspect > for a year): > http://www.naesb.org/pdf2/weq_bklet_011505_tec_mc.pdf > > As I said in my last post, I'm not an EE, but just follow some of topics > on that side of the house. > > What I gather is that Manual TEC, which is done by purposely running the > frequency away from 60Hz to correct an average deviation, can actually > cause more problems. > > "NERC is investigating the possibility of eliminating Time Error > Corrections. NERC has been collecting data regarding Interconnection > frequency performance, including the number of clock-?? minutes during > which actual frequency dropped below the low Frequency Trigger Limit > (FTL) of 59.95 Hertz. During the period of July 2005 through March 2010, > approximately 44% of the minutes during which clock-??minute actual > frequency dropped below the low FTL occurred during Time Error > Corrections when scheduled frequency was 59.98 Hertz (1,875 of the 4,234 > total minutes observed below 59.95 Hertz). Upon further investigation, > it was found that almost all of those minutes (1,819 of the 1,875 total) > represented frequency deviations that would likely not have dropped > frequency below 59.95 Hertz if the scheduled frequency had been 60 > Hertz. In other words, approximately 97% of the Low FTLs were of such a > magnitude that if the Time Error Correction had not been in effect, the > exceedance of the low FTL would not have occurred. This is an example of counting an intentional deviation as a fault and is really only an accounting problem (even though the triggers are mostly fixed hardware). On the other hand, if customers can notice, it matters. (what was the SLA again?) Interesting... Normally slow is not a problem since it happens normally when the grid is running near capacity... The "frequency runs" (when I worked IT/comms with a power company they were on Thursday nights after midnight...) were almost always fast (I was involved in this in the mid 70's mostly; our company rarely reached capacity but could if the weather was hot enough.) Given that the slew command has to be done almost simultaneously at most of the power plants in US and Canada, in order to avoid the throttle hunting problem that JDA mentioned (yes, even big plants can hunt, just ask the NE folks (twice!!!) though both of them were caused by circuit faults (network partitions) and not time corrections) Now that most clocks are run by 32khz crystals and not counting cycles, the corrections don't matter as much. I guess the experiment is to find out who complains... Then again, as a kid I remember So Cal Edison sending out new rollers for phonographs (I know - what's that?) when they changed from 50 to 60hz. Talk about inaccurate clocks (and I don't know what they did about those either.) And most of LA's hydro was still running generators that were built for 50hz even into the 70's, so lost some efficiency. > These Frequency Trigger Limits in and of themselves are only indicators > of system behavior, but the nature of their relationship to Time Error > Corrections calls into question the potential impact that Time Error > Corrections can have on frequency behavior overall. While it is > intuitively obvious that any frequency offset that moves target > frequency away from the reference point to which all other frequency > sensitive devices (such as relays) have been indexed will have a > potential impact on those devices? performance, the industry has by and > large regarded Time Error Corrections as harmless and necessary as part > of the service it provides to its customers. However, in light of this > data, NERC?s stakeholders are now questioning whether or not the > intentional movement closer to (or in some cases, further away from) the > trigger settings of frequency-??based protection devices as is evidenced > during Time Error Correction events is appropriate. > > Accordingly, NERC is planning a Field Trial during which the practice of > doing Time Error Corrections will be suspended. Because of the > fundamental nature of this 60Hz signal, NERC is reaching out to various > industries to get their thoughts on whether they anticipate any problems > with the elimination of Time Error Corrections. Those industries include > appliance manufacturers, software companies, chemical manufacturers, > companies that make automation equipment, computer manufacturers, and > many others." > > Source: > http://www.wecc.biz/library/Lists/Announcements/Attachments/9/June%2014%20Time%20Error%20Webinar.pdf > > The main point I gather is that trying to do manual Time Error > Correction actually makes the power grid less stable at times, and as > such they want to do away with it (thus making the power grid more stable). Given that you have to bump up everyone's throttle half the time (or more) to accomplish the correction, if things are already near capacity, you are asking for it :-) > Think of it the same as patch management risk assessment. If there are > no security or bug fixes that directly affect you or even feature > enhancements that you don't need, do you apply a patch/upgrade to > critical systems? Nah, you skip those, because we all know every > patch/upgrade carries with it risk of an unknown bug or even security flaw. > > That's what they're doing here, opting to skip "patching" the time > error. They're not ignoring frequency altogether, but rather only > minding that aspects that have to do with grid stability, not your alarm > clock. This is for the better anyway, and NTP/GPS/WWV/WWVH is the way > to go to keep clocks accurate and hopefully will be the outcome of any > consumer complaints. Already most "modern" consumer clocks are driven at least by crystals if not externally sync'd... > I've seen conversation in various forums and lists I read that they are > going to ignore or not care about the 60Hz standard. This is incorrect. > They just aren't going to purposely deviate from the scheduled > frequency to perform manual TEC. > > Mind you, that they still care about why the frequency is off, and when > things are not able to quickly compensate, they want to know and be able > to pinpoint it and fix it: > http://www.nerc.com/filez/standards/Frequency_Response.html I didn't read that, but the short answer is: build more generators... (and I don't know the politics of how the ISO's fit into this; they complicated things a lot from when I was involved in the power biz.) > Specifically, read this PDF: > http://www.nerc.com/docs/oc/rfwg/NERC%20Balancing%20and%20Frequency%20Control%20July%205%202009.pdf > > The AP piece was focused on hype and word-spinning (I couldn't find an > AP.org link, so used one that I could find, > http://www.huffingtonpost.com/2011/06/24/clock-problems-power-grid-clock-disruptions_n_884259.html > ): > > "The experiment would allow more frequency variation than it does now ? > without corrections." > > The NERC BAL standards already hold the NERC entities to very high > frequency standards, and this will be unchanged, except for manual TEC. > All it is doing is eliminating the corrections made purely for time's > sake, which actually eliminates more frequency variation. This may, or > may not, create more average frequency variation, and that is part of > this test. It probably will eliminate most of the faster slews and some risky manual operations. > "Officials say they want to try it to make the power supply more > reliable, save money and reduce what may be needless effort." > > This is the real goal, and should have been the focus of the news story > - but that doesn't make headlines. > > I'm going to go shop for a new clock. I had one that used the WWV/WWVH > stations, but then they messed with DST and it was off for a few weeks > around each DS change. Which is cute since there is a field in the wwvb message that gives a countdown until dst change, and flags the direction. One of my "atomic" clocks gave up and just has a DST button... The other is like yours. > That forced me me to pull it off the wall and > change the TZ at one time of the year to correct it, but the other time > of the year I could not correct it (as it only had 4 TZ settings), so I > took it down. Beware "Automatic Time Set" clocks which don't really > learn the time from the WWV/WWVH stations (like the Sony ICF-C218, which > has a preset time and battery, but still uses the frequency from the > wall to maintain time). Booo. I'm surprised at that in this day & age (a 32khz crystal and the 15-bit counter it needs is actually cheaper than the analog signal-conditioning you need to count the 60hz reliably). > The best bet is a clock that requires batteries > as you know it won't get time from the power grid. > > Jason Roysdon > > From bicknell at ufp.org Sat Jun 25 17:12:08 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 25 Jun 2011 15:12:08 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> Message-ID: <20110625221208.GA64593@ussenterprise.ufp.org> In a message written on Fri, Jun 24, 2011 at 06:29:14PM -0400, Jay Ashworth wrote: > I believe the answer to that question is contained here: > > http://yarchive.net/car/rv/generator_synchronization.html [1] I wouldn't use a colo that had to sync their generator to the grid. That is a bad design. Critical load should be on a battery or flywheel system. When the utility is bad (including out) the load should be on the battery or flywheel for 5-15 seconds before the generators start. The generators need to sync to each other. Essential load (think lighting, AC units) get dropped completely for 30-60 seconds until the generators are stable, and then that load gets hooked back in. I have never seen a generator that syncs to the utility for live, no break transfer. I'm sure such a thing exists, but that sounds crazy dangerous to me. Generators sync to each other, not the utility. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From sethm at rollernet.us Sat Jun 25 17:32:09 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 25 Jun 2011 15:32:09 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <20110625221208.GA64593@ussenterprise.ufp.org> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> Message-ID: <4E0661E9.7040602@rollernet.us> On 6/25/2011 15:12, Leo Bicknell wrote: > > I have never seen a generator that syncs to the utility for live, no > break transfer. I'm sure such a thing exists, but that sounds crazy > dangerous to me. Generators sync to each other, not the utility. > Most of these come in open, delayed, or closed transition models: http://www.gedigitalenergy.com/powerquality/ATSHome.htm For open and closed transitions you'll most certainly want to sync to utility to transition between the two. For the delayed transition model it'll stop at the intermediate "open" point for a configurable amount of time during which the load is disconnected from everything (i.e. let all the motors spin down first). ~Seth From if at xip.at Sat Jun 25 17:47:07 2011 From: if at xip.at (Ingo Flaschberger) Date: Sun, 26 Jun 2011 00:47:07 +0200 (CEST) Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: References: <18274001.98.1309013340612.JavaMail.root@benjamin.baylink.com> <4E0622DC.6040208@jason.roysdon.net> Message-ID: >> Generators all stay in sync. Generator owners have expensive devices >> that sync the phase before the generator is connected to the grid. Once >> a generator is connected to the gird, it will stay in sync - in fact >> that is why they have the expensive devices to make sure that they are >> in sync before they connect them, as if they are not, it will instantly >> jump to being in sync, which may destroy the generator. >> > As a matter of fact, it may destroy the generator, the housing, the building, > the damn, and more. An out-of-sync generator becomes a motor until it is > in sync. lt can be a graphic and dramatic event. Big generator are synchron maschines, as they can generate also reactive power. If a out of sync synchron maschine is connected to the grid, theres a big "kawumm" and then the maschine is in sync or dead. Only the angle between the rotor and the magentic field make the difference between generator and motor. A synchron motor can not self-start and only run at fixed grid freuency / rpm's. A overloaded motor suddenly stops. Smaller generators are asynchron maschines, that can run faster or slower than network frequency - ie run as generator or motor - but they always consume reactive power. They can self-start. Synchronising maschines to a grid is not a big problem, the bigger problem is to syncronise 2 disconnected grids. Some years ago in europe a grid operator violated the n+1 redundancy rule as he needed to switch of a big power line over the river "Ems" - to allow a big ship to leave the shipyard. The result was a netsplit trough whole europe - a lot of "big" line-breakers flipped and switched of north-west and south-east power lines. The whole european grid was split into 3 parts, running at higher and lowet frequencies. Details: http://www.bundesnetzagentur.de/SharedDocs/Downloads/EN/BNetzA/Areas/ElectricityGas/Special%20Topics/Blackout2005/BerichtEnglischeVersionId9347pdf.pdf?__blob=publicationFile Kind regards, Ingo Flaschberger From paul at paulgraydon.co.uk Sat Jun 25 18:43:53 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Sat, 25 Jun 2011 13:43:53 -1000 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E0661E9.7040602@rollernet.us> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> Message-ID: <4E0672B9.1050100@paulgraydon.co.uk> On 6/25/2011 12:32 PM, Seth Mattinen wrote: > On 6/25/2011 15:12, Leo Bicknell wrote: >> I have never seen a generator that syncs to the utility for live, no >> break transfer. I'm sure such a thing exists, but that sounds crazy >> dangerous to me. Generators sync to each other, not the utility. >> > Most of these come in open, delayed, or closed transition models: > http://www.gedigitalenergy.com/powerquality/ATSHome.htm > > For open and closed transitions you'll most certainly want to sync to > utility to transition between the two. For the delayed transition model > it'll stop at the intermediate "open" point for a configurable amount of > time during which the load is disconnected from everything (i.e. let all > the motors spin down first). > > ~Seth > Take a guess what the datacenter our equipment is currently hosted in uses. Yet another reason to be glad of a datacenter move that's coming up. From trelane at trelane.net Sat Jun 25 18:47:22 2011 From: trelane at trelane.net (Andrew D Kirch) Date: Sat, 25 Jun 2011 19:47:22 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E0672B9.1050100@paulgraydon.co.uk> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> Message-ID: <4E06738A.20707@trelane.net> On 6/25/2011 7:43 PM, Paul Graydon wrote: > Take a guess what the datacenter our equipment is currently hosted in > uses. Yet another reason to be glad of a datacenter move that's > coming up. > Why can't we just all use DC and be happy? From joelja at bogus.com Sat Jun 25 18:59:09 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 25 Jun 2011 16:59:09 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E06738A.20707@trelane.net> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> <4E06738A.20707@trelane.net> Message-ID: <01311F06-D888-470E-B1DE-D137E86FA8AB@bogus.com> On Jun 25, 2011, at 4:47 PM, Andrew D Kirch wrote: > On 6/25/2011 7:43 PM, Paul Graydon wrote: >> Take a guess what the datacenter our equipment is currently hosted in uses. Yet another reason to be glad of a datacenter move that's coming up. >> > Why can't we just all use DC and be happy? motors don't produce DC? tesla vs edison? human safe dc voltage requires comically large conductors for the sorts of loads we energize? transmission loss except at very high voltages... http://en.wikipedia.org/wiki/High-voltage_direct_current From sethm at rollernet.us Sat Jun 25 19:49:17 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 25 Jun 2011 17:49:17 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E0672B9.1050100@paulgraydon.co.uk> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> Message-ID: <4E06820D.3000704@rollernet.us> On 6/25/2011 16:43, Paul Graydon wrote: > On 6/25/2011 12:32 PM, Seth Mattinen wrote: >> >> For open and closed transitions you'll most certainly want to sync to >> utility to transition between the two. For the delayed transition model >> it'll stop at the intermediate "open" point for a configurable amount of >> time during which the load is disconnected from everything (i.e. let all >> the motors spin down first). >> >> ~Seth >> > Take a guess what the datacenter our equipment is currently hosted in > uses. Yet another reason to be glad of a datacenter move that's coming up. > Also depends on the operator, so ask to see their xfer switches and how they're programmed if that's a concern. All of the non-residential models in that link for three-phase have motor/load disconnect signaling capability. If the operator is clued enough to use it then it's all good: shut off signal to motor/compressor loads, phase sync and switch, signal reconnect after delay. But if they're not... run away. Even with the delayed transition models the "hold open" delay can be too short and end up re-energizing the motors too quickly. There's always plenty of ways to f*ck things up good. ~Seth From deric.kwok2000 at gmail.com Sat Jun 25 20:03:52 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sat, 25 Jun 2011 21:03:52 -0400 Subject: AS and advertisen questions Message-ID: Hi Can we use same AS to advertise different networks in different location? We would like to use Seattle as production network and New York as testing eg: Seattle: network 66.49.130.0/24 New York: network 67.55.129.0/24 and ipv6 network. Thank you From cb.list6 at gmail.com Sat Jun 25 20:27:08 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sat, 25 Jun 2011 18:27:08 -0700 Subject: AS and advertisen questions In-Reply-To: References: Message-ID: On Jun 25, 2011 6:04 PM, "Deric Kwok" wrote: > > Hi > > Can we use same AS to advertise different networks in different location? > > We would like to use Seattle as production network and New York as testing > > eg: > Seattle: network 66.49.130.0/24 > > New York: network 67.55.129.0/24 and ipv6 network. > > Thank you > Yes From joelja at bogus.com Sat Jun 25 20:39:12 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 25 Jun 2011 18:39:12 -0700 Subject: AS and advertisen questions In-Reply-To: References: Message-ID: On Jun 25, 2011, at 6:03 PM, Deric Kwok wrote: > Hi > > Can we use same AS to advertise different networks in different location? > > We would like to use Seattle as production network and New York as testing > > eg: > Seattle: network 66.49.130.0/24 > > New York: network 67.55.129.0/24 and ipv6 network. > > Thank you Assuming you want the two instances to be able talk to each other you just have to relax loop detection so that you will accept prefixes from your AS... From david at davidswafford.com Sat Jun 25 21:11:26 2011 From: david at davidswafford.com (David Swafford) Date: Sat, 25 Jun 2011 22:11:26 -0400 Subject: AS and advertisen questions In-Reply-To: References: Message-ID: Yep, we do it that way. We basically treat each of our datacenter's as their own entity, using separate space for each, but all with the same AS #. What Joel mentioned is going to be the major catch, in that for each of the two disconnected AS's to accept the opposite sites routes, you'd need to relax BGP's loop prevention check (which looks for it's own AS # within the AS Path of incoming routes). If your on Cisco gear, you'd need to add an additional command under the BGP neighbor configuration that says "allowas-in". Here's a breif doc from Cisco on configuring this http://www.cisco.com/image/gif/paws/112236/allowas-in-bgp-config-example.pdf David. On Sat, Jun 25, 2011 at 9:39 PM, Joel Jaeggli wrote: > > On Jun 25, 2011, at 6:03 PM, Deric Kwok wrote: > >> Hi >> >> Can we use same AS to advertise different networks in different location? >> >> We would like to use Seattle as production network and New York as testing >> >> eg: >> Seattle: network 66.49.130.0/24 >> >> New York: network 67.55.129.0/24 and ipv6 network. >> >> Thank you > > Assuming you want the two instances to be able talk to each other you just have to relax loop detection so that you will accept prefixes from your AS... > From jra at baylink.com Sat Jun 25 22:18:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 25 Jun 2011 23:18:47 -0400 (EDT) Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E0661E9.7040602@rollernet.us> Message-ID: <18698937.150.1309058327433.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Seth Mattinen" > On 6/25/2011 15:12, Leo Bicknell wrote: > > I have never seen a generator that syncs to the utility for live, no > > break transfer. I'm sure such a thing exists, but that sounds crazy > > dangerous to me. Generators sync to each other, not the utility. > > Most of these come in open, delayed, or closed transition models: > http://www.gedigitalenergy.com/powerquality/ATSHome.htm > > For open and closed transitions you'll most certainly want to sync to > utility to transition between the two. For the delayed transition model > it'll stop at the intermediate "open" point for a configurable amount of > time during which the load is disconnected from everything (i.e. let all > the motors spin down first). And more to the point, if you're installing 2-5MW of generation capacity, it's not all that uncommon to make it a cogen plant, at which point yeah, you're gonna run in sync. Leo: note that your body text was an *attachment* for some reason; new mailer? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From randy at psg.com Sat Jun 25 22:20:10 2011 From: randy at psg.com (Randy Bush) Date: Sun, 26 Jun 2011 12:20:10 +0900 Subject: AS and advertisen questions In-Reply-To: References: Message-ID: > Can we use same AS to advertise different networks in different location? > > We would like to use Seattle as production network and New York as testing > > eg: > Seattle: network 66.49.130.0/24 > > New York: network 67.55.129.0/24 and ipv6 network. you have not made clear whether ny and sea are connected internally. if not, see joel's caveat. some folk with whom you may want to peer may demand that you announce the same nlri to them at all peering points. randy From nanog at deman.com Sat Jun 25 23:01:50 2011 From: nanog at deman.com (Michael DeMan) Date: Sat, 25 Jun 2011 21:01:50 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <20110625221208.GA64593@ussenterprise.ufp.org> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> Message-ID: <4F3FF32B-AC21-4505-91E1-3EEA21374994@deman.com> It ismy understanding also that most commercial grade gensets have built into the ATS logic that when utility power comesback online, that the transfer back to utility power is coordinated with the ATS driving the generator until both frequency and phases are within a user specified range? - mike On Jun 25, 2011, at 3:12 PM, Leo Bicknell wrote: > In a message written on Fri, Jun 24, 2011 at 06:29:14PM -0400, Jay Ashworth wrote: >> I believe the answer to that question is contained here: >> >> http://yarchive.net/car/rv/generator_synchronization.html [1] > > I wouldn't use a colo that had to sync their generator to the grid. > That is a bad design. > > Critical load should be on a battery or flywheel system. When the > utility is bad (including out) the load should be on the battery or > flywheel for 5-15 seconds before the generators start. The generators > need to sync to each other. > > Essential load (think lighting, AC units) get dropped completely for > 30-60 seconds until the generators are stable, and then that load gets > hooked back in. > > I have never seen a generator that syncs to the utility for live, no > break transfer. I'm sure such a thing exists, but that sounds crazy > dangerous to me. Generators sync to each other, not the utility. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From nanog at deman.com Sat Jun 25 23:07:29 2011 From: nanog at deman.com (Michael DeMan) Date: Sat, 25 Jun 2011 21:07:29 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E06738A.20707@trelane.net> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> <4E06738A.20707@trelane.net> Message-ID: <1A9ABB11-CF40-455A-AF8C-F6FA51527D07@deman.com> On Jun 25, 2011, at 4:47 PM, Andrew D Kirch wrote: > On 6/25/2011 7:43 PM, Paul Graydon wrote: >> Take a guess what the datacenter our equipment is currently hosted in uses. Yet another reason to be glad of a datacenter move that's coming up. >> > Why can't we just all use DC and be happy? > Because often short term pain and long term gain frequently (pardon the pun) better ideas do not make it through the free market process? From alex at corp.nac.net Sat Jun 25 23:23:47 2011 From: alex at corp.nac.net (Alex Rubenstein) Date: Sun, 26 Jun 2011 00:23:47 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4F3FF32B-AC21-4505-91E1-3EEA21374994@deman.com> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4F3FF32B-AC21-4505-91E1-3EEA21374994@deman.com> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB8020834A25B@EXCHMBX.hq.nac.net> > It ismy understanding also that most commercial grade gensets have > built into the ATS logic that when utility power comesback online, that > the transfer back to utility power is coordinated with the ATS driving > the generator until both frequency and phases are within a user > specified range? Well, that depends. If you have a open-transition ATS, where there is a 'neutral' (read: not connected to any source) position, it doesn't matter (much). Well, it matters a little. There is really two types of open transition. Something called "open transition" will provide a transfer by going closed-open-closed (in both directions). The issue is the open portion of that transfer can be very short; sometimes only a few cycles at 60 hz. If you have an electric motor connected as load (fan, compressor, whatever), if the sources are out of phase, it can be an interesting event for said motor. Typically, a open transition switch will wait until the phasing is 'close enough' (usually programmable by way of degrees.). We have an old russ electric ats somewhere that is happy at about 15 degrees +/-. There is also a type, "delayed transition", which is closed-open-wait-closed. Wait is typically programmable, it may be 500 msec, it might be a minute. It's up to the user. This is regarded as the safest type of switch (imho) because you do not run the risk of any of the above mentioned badness. However, in a datacenter scenario, you do have a battery hit (ranging from tens or hundreds of millisecond to many seconds depending on what you want). How good is your UPS and battery plant? Will your fans inertia keep air moving for a little while? All things to consider. If you have a closed-transition switch, typically the retransfer from emergency to normal is closed-closed, meaning that emergency gen, normal utility, and load are all connected together for a short while. Typically in the tens or hundreds of msecs. Anything longer than that kinda falls into the cogeneration category. That is another discussion. At least here in JCPL territory (northern NJ), closed transition is frowned upon. Too much risk, they think. They are correct, really, but the risk is mostly yours. If you lock to the utility out-of-phase, you will surely lose and they will surely win. The fault you create that they will see will probably not hurt them. Unless it is extraordinarily large and you are very close to the nearest substation. You must really trust your utility and your transfer gear and your generators to do this. Personally, I'm not a huge fan of this, but that is just religion. Personally, I like delayed transition, and that is what we do on anything recent. Short, usually, like 3 or 5 seconds. If anyone wants a demonstration, let me know. Long enough for motor controls to say "oh, hey, we lost power so let's do a nice soft restart of motors" and compressor controls can do delayed restarts as well. Works quite well, in practice. Much is overlooked in this discussion, as to things people should do about ATS and UPS programming.. but it is outside of the scope of NANOG unfortunately. Perhaps we need a NADCOG or something. What does this have to do with the whole 60 hz discussion and clocks? Not much. Other than I will have to rely on the cell phone more and the microwave less for time. From ryan.finnesey at HarrierInvestments.com Sat Jun 25 23:35:54 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 25 Jun 2011 21:35:54 -0700 Subject: What do you think about the Juniper MX line? In-Reply-To: References: Message-ID: <6EFFEFBAC68377459A2E972105C759EC03C1AA97@EXVBE005-2.exch005intermedia.net> I would love to know the same I am looking at the MX line as well for a new network build-out Cheers Ryan -----Original Message----- From: Chris [mailto:behrnetworks at gmail.com] Sent: Saturday, June 25, 2011 9:29 AM To: nanog at nanog.org Subject: What do you think about the Juniper MX line? Hello, I've been doing some research into using the MX line of Juniper routers and was interested in hearing people's experiences (the good, bad, and ugly). What do you like about them? What do you dislike? Where are you putting them in your network? Where are you not putting them? Why? What other platforms would you consider and why? I hope to hear some candid responses, but feel free to respond privately if you need to. Thanks! From jsw at inconcepts.biz Sat Jun 25 23:44:36 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 26 Jun 2011 00:44:36 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB8020834A25B@EXCHMBX.hq.nac.net> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4F3FF32B-AC21-4505-91E1-3EEA21374994@deman.com> <2D0AF14BA6FB334988BC1F5D4FC38CB8020834A25B@EXCHMBX.hq.nac.net> Message-ID: On Sun, Jun 26, 2011 at 12:23 AM, Alex Rubenstein wrote: > At least here in JCPL territory (northern NJ), closed transition is frowned upon. Too much risk, they think. They are correct, really, but the risk is mostly yours. If you lock to the utility out-of-phase, you will surely lose and they will surely win. The fault you create that they will see will probably not hurt them. Unless it is extraordinarily large and you are very close to the nearest substation. Utilities concern themselves with not only their gear and your gear, but also your neighbor's gear. I would not like to be next-door to a large genset that is connected to the grid out-of-phase. My equipment would be affected by such an event. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From Howard.Hart at ooma.com Sun Jun 26 00:03:17 2011 From: Howard.Hart at ooma.com (Howard Hart) Date: Sun, 26 Jun 2011 05:03:17 +0000 Subject: What do you think about the Juniper MX line? In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC03C1AA97@EXVBE005-2.exch005intermedia.net> References: , <6EFFEFBAC68377459A2E972105C759EC03C1AA97@EXVBE005-2.exch005intermedia.net> Message-ID: <5243148F-B495-4F2E-8FDC-92C35A4FE62F@ooma.com> We have a couple installed as our edge routers. Pluses - solid as a rock, easy to administer, and will take some extremely high packet rates for relatively low cost (important for us since we use them for VoIP traffic). If you're approaching the capacity of a 1GB uplink, I highly recommend these as your first step to 10 GB. Minuses - careful on your MX80 version. The MX80-48T includes a built in 48 port 1 GigE switch, but we've had compatibility issues with it and other vendors switches. The modular version that replaces the MX80-48T costs quite a bit more, but it does give you a lot more connection and compatibility options. Howard Hart On Jun 25, 2011, at 9:37 PM, "Ryan Finnesey" wrote: > I would love to know the same I am looking at the MX line as well for a > new network build-out > > Cheers > Ryan > > > -----Original Message----- > From: Chris [mailto:behrnetworks at gmail.com] > Sent: Saturday, June 25, 2011 9:29 AM > To: nanog at nanog.org > Subject: What do you think about the Juniper MX line? > > Hello, > > I've been doing some research into using the MX line of Juniper routers > and was interested in hearing people's experiences (the good, bad, and > ugly). What do you like about them? What do you dislike? > Where are you putting them in your network? Where are you not putting > them? Why? What other platforms would you consider and why? I hope to > hear some candid responses, but feel free to respond privately if you > need to. > > Thanks! > > From Richard at helix.net.nz Sun Jun 26 01:52:29 2011 From: Richard at helix.net.nz (Richard Patterson) Date: Sun, 26 Jun 2011 18:52:29 +1200 Subject: What do you think about the Juniper MX line? In-Reply-To: <5243148F-B495-4F2E-8FDC-92C35A4FE62F@ooma.com> References: , <6EFFEFBAC68377459A2E972105C759EC03C1AA97@EXVBE005-2.exch005intermedia.net> <5243148F-B495-4F2E-8FDC-92C35A4FE62F@ooma.com> Message-ID: <4E06D72D.2000002@helix.net.nz> We've deployed the MX480s as PEs in multiple countries, and have been pretty damn happy with them for the most part. Any issues we've seen (largely around interface counters/statistics etc) can be chalked up to an older JunOS version that we're running. The CLI is shiny, and easy to use, and next to stablity, this is the biggest factor when ranking a platform for me. -Richard On 26/06/2011 5:03 p.m., Howard Hart wrote: > We have a couple installed as our edge routers. > > Pluses - solid as a rock, easy to administer, and will take some extremely high packet rates for relatively low cost (important for us since we use them for VoIP traffic). If you're approaching the capacity of a 1GB uplink, I highly recommend these as your first step to 10 GB. > > Minuses - careful on your MX80 version. The MX80-48T includes a built in 48 port 1 GigE switch, but we've had compatibility issues with it and other vendors switches. The modular version that replaces the MX80-48T costs quite a bit more, but it does give you a lot more connection and compatibility options. > > Howard Hart > > On Jun 25, 2011, at 9:37 PM, "Ryan Finnesey" wrote: > >> I would love to know the same I am looking at the MX line as well for a >> new network build-out >> >> Cheers >> Ryan >> >> >> -----Original Message----- >> From: Chris [mailto:behrnetworks at gmail.com] >> Sent: Saturday, June 25, 2011 9:29 AM >> To: nanog at nanog.org >> Subject: What do you think about the Juniper MX line? >> >> Hello, >> >> I've been doing some research into using the MX line of Juniper routers >> and was interested in hearing people's experiences (the good, bad, and >> ugly). What do you like about them? What do you dislike? >> Where are you putting them in your network? Where are you not putting >> them? Why? What other platforms would you consider and why? I hope to >> hear some candid responses, but feel free to respond privately if you >> need to. >> >> Thanks! >> >> From bicknell at ufp.org Sun Jun 26 07:27:10 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 26 Jun 2011 05:27:10 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E0661E9.7040602@rollernet.us> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> Message-ID: <20110626122710.GA88850@ussenterprise.ufp.org> In a message written on Sat, Jun 25, 2011 at 03:32:09PM -0700, Seth Mattinen wrote: > Most of these come in open, delayed, or closed transition models: > http://www.gedigitalenergy.com/powerquality/ATSHome.htm I think we're missing something, which is where these ATS's are installed. I don't think most utilities allow (largeish) ATS's to do a closed transition from a genset to the utility grid, but I may be wrong. There may be other ATS's in your facility that do a closed transition though. For instance, consider this (somewhat simplified) dual UPS design: Utility Generator | \/ | | /\ | ATS #1a ATS #1b | | UPS #1 UPS #2 | | \ / \ / ATS #2 | Load ATS's 1a, 1b, sense utility power for quality. Should the utility power quality not meet specs (e.g. go out), they disconnect from utility, tell the generator to spin up, wait 5-15 seconds for the generator(s) to spin up and then close to the generator. They are in an open state for perhaps 20+ seconds, generators are never closed to the utility. Going back the drop may be shorter, perhaps 10 seconds, but there's still a long-ish open gap. Definately not sub-second. ATS #2 takes the dual UPS output (from synchronized UPS's) and does a closed transition between the two sources. Indeed, a previous employer had ATS's at this location that could switch between sources in less than 1/4 wave, the equipment never knew the differenece. Very impressive. It's not that you couldn't install a closed transition ATS in the ATS 1a/1b location from an electrical point of view, but I don't think codes, power companies, or common sense make it a good idea. As others have pointed out, the grid can do weird things because your neighbors did something stupid, or a car hit a power pole and shorted 3 phases together. Syncing to it is, well, crazy. Maybe small plants are different, but I've never seen a 1MW+ plant where the generators synced to utility. I can imagine CoGen might have some different requirements, and I've never worked with that, but I don't think that's what we are discussing. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From pelzi at pelzi.net Sun Jun 26 09:08:35 2011 From: pelzi at pelzi.net (Jussi Peltola) Date: Sun, 26 Jun 2011 17:08:35 +0300 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <20110626122710.GA88850@ussenterprise.ufp.org> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <20110626122710.GA88850@ussenterprise.ufp.org> Message-ID: <20110626140835.GG25848@pokute.pelzi.net> On Sun, Jun 26, 2011 at 05:27:10AM -0700, Leo Bicknell wrote: > It's not that you couldn't install a closed transition ATS in the > ATS 1a/1b location from an electrical point of view, but I don't > think codes, power companies, or common sense make it a good idea. > As others have pointed out, the grid can do weird things because > your neighbors did something stupid, or a car hit a power pole and > shorted 3 phases together. Syncing to it is, well, crazy. It makes little sense to sync to the grid when the generator is only used when the grid is down - and unless you run your generators 24/7 your UPS will have to make up for the comparatively long time it takes for the generator to start, so it's rather useless to sync the generator when the power comes back so you can avoid a sub-second break when transferring back to utility power. UPS's shouldn't mind a break-before-make transfer, and motor loads are more and more often inverter/VFD driven types that should have their own delayed start logic that will hopefully handle most power glitches gracefully. Power distribution downstream of UPSs is a different animal with different goals, and there synchronized UPSs and make-before-break makes sense. To at least pretend to be relevant, the absolute frequency of the grid is, again, not relevant at all - and when the power is out, you won't be able to sync to it anyway. From alex at corp.nac.net Sun Jun 26 09:27:24 2011 From: alex at corp.nac.net (Alex Rubenstein) Date: Sun, 26 Jun 2011 10:27:24 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <20110626140835.GG25848@pokute.pelzi.net> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <20110626122710.GA88850@ussenterprise.ufp.org> <20110626140835.GG25848@pokute.pelzi.net> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB8020834A263@EXCHMBX.hq.nac.net> > It makes little sense to sync to the grid when the generator is only > used when the grid is down - and unless you run your generators 24/7 > your UPS will have to make up for the comparatively long time it takes > for the generator to start, so it's rather useless to sync the > generator when the power comes back so you can avoid a sub-second break when > transferring back to utility power. No, that is precisely the reason to do closed transition. The benefit is no interruption to load on retransfer. Effectively, you cut down on UPS battery hits, motor restarts, etc, by 50%. I, again, don't like this, because the cons, imho, outweigh the benefits. From alex at corp.nac.net Sun Jun 26 09:28:28 2011 From: alex at corp.nac.net (Alex Rubenstein) Date: Sun, 26 Jun 2011 10:28:28 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <20110626122710.GA88850@ussenterprise.ufp.org> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <20110626122710.GA88850@ussenterprise.ufp.org> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB8020834A264@EXCHMBX.hq.nac.net> > I think we're missing something, which is where these ATS's are > installed. > > I don't think most utilities allow (largeish) ATS's to do a closed > transition from a genset to the utility grid, but I may be wrong. > There may be other ATS's in your facility that do a closed transition > though. For instance, consider this (somewhat simplified) dual UPS > design: > > > Utility Generator > | \/ | > | /\ | > ATS #1a ATS #1b > | | > UPS #1 UPS #2 > | | > \ / > \ / > ATS #2 > | > Load IMHO, this design is overly complex, and will lead to the most usually form of failure - human. There is lot to think about in the above, especially during maintenance. You also have an interested situation on retransfer (gen -> normal) when 1a and 1b do not transition at precisely the same exact moment, which almost never happen. And if one of 1a or 1b gets 'stuck', you have UPS's paralleled being fed from unsynchronized sources, which leads to other problems (such as bypass not being available, etc). > ATS's 1a, 1b, sense utility power for quality. Should the utility > power quality not meet specs (e.g. go out), they disconnect from > utility, tell the generator to spin up, wait 5-15 seconds for the > generator(s) to spin up and then close to the generator. They are in > an open state for perhaps 20+ seconds, generators are never closed to > the utility. Going back the drop may be shorter, perhaps > 10 seconds, but there's still a long-ish open gap. Definately not > sub-second. That is not typical. The normal contactor/breaker doesn't usually open until the emergency source is available. It remains closed to the dead normal until emergency is ready to be transferred to. > > ATS #2 takes the dual UPS output (from synchronized UPS's) and does a > closed transition between the two sources. Indeed, a previous employer > had ATS's at this location that could switch between sources in less > than 1/4 wave, the equipment never knew the differenece. Very > impressive. So are you saying that the load was directly connected to utility (no UPS protection) until utility had a problem? > It's not that you couldn't install a closed transition ATS in the ATS > 1a/1b location from an electrical point of view, but I don't think > codes, power companies, or common sense make it a good idea. > As others have pointed out, the grid can do weird things because your > neighbors did something stupid, or a car hit a power pole and shorted 3 > phases together. Syncing to it is, well, crazy. Closed transition should not really be thought of as syncing to the grid. Closed transition infers a very, very short overlap. A few cycles. Mainly so that downstream load does not get interrupted on the retransfer. From mhuff at ox.com Sun Jun 26 10:03:17 2011 From: mhuff at ox.com (Matthew Huff) Date: Sun, 26 Jun 2011 11:03:17 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E06820D.3000704@rollernet.us> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> <4E06820D.3000704@rollernet.us> Message-ID: <483E6B0272B0284BA86D7596C40D29F9012124453BA0@PUR-EXCH07.ox.com> Another couple of reasons to use a delayed transition ATS: 1) Motor lock. Delays on HVAC equipment never get triggered if the system never goes offline. Having a correct "open" period allows the motors to spin down, and start back up on the delays that are programmed keeping them from being synchronized 2) Allowing transformer fields to collapse. Even in phase, without a delayed transition ATS you can end up with a partially collapsed transformer field with a new field being created at non-ground state. This can cause a transient back wave that can snap circuit breakers. Yep, this one happened to us a few times before we switched to a delayed ATS, was a PITA to debug and resolve. -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Saturday, June 25, 2011 8:49 PM To: nanog at nanog.org Subject: Re: Wacky Weekend: NERC to relax power grid frequency strictures On 6/25/2011 16:43, Paul Graydon wrote: > On 6/25/2011 12:32 PM, Seth Mattinen wrote: >> >> For open and closed transitions you'll most certainly want to sync to >> utility to transition between the two. For the delayed transition model >> it'll stop at the intermediate "open" point for a configurable amount of >> time during which the load is disconnected from everything (i.e. let all >> the motors spin down first). >> >> ~Seth >> > Take a guess what the datacenter our equipment is currently hosted in > uses. Yet another reason to be glad of a datacenter move that's coming up. > Also depends on the operator, so ask to see their xfer switches and how they're programmed if that's a concern. All of the non-residential models in that link for three-phase have motor/load disconnect signaling capability. If the operator is clued enough to use it then it's all good: shut off signal to motor/compressor loads, phase sync and switch, signal reconnect after delay. But if they're not... run away. Even with the delayed transition models the "hold open" delay can be too short and end up re-energizing the motors too quickly. There's always plenty of ways to f*ck things up good. ~Seth From jra at baylink.com Sun Jun 26 11:07:08 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 26 Jun 2011 12:07:08 -0400 (EDT) Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4F3FF32B-AC21-4505-91E1-3EEA21374994@deman.com> Message-ID: <28052863.186.1309104428715.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael DeMan" > It is my understanding also that most commercial grade gensets have > built into the ATS logic that when utility power comesback online, > that the transfer back to utility power is coordinated with the ATS > driving the generator until both frequency and phases are within a > user specified range? I don't believe that's actually true, Mike. In a *load transfer* configuration, it's really not all that critical if the power presented to the load skips phase a touch on the transfer; there's a 50-500ms gap in the power anyway, since such transfer switches are required by the NEC to be non-shorting, so they don't electrocute power workers. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Sun Jun 26 11:27:33 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 26 Jun 2011 12:27:33 -0400 (EDT) Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: Message-ID: <2094456.192.1309105653309.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeff Wheeler" > On Sun, Jun 26, 2011 at 12:23 AM, Alex Rubenstein > wrote: > > At least here in JCPL territory (northern NJ), closed transition is > > frowned upon. Too much risk, they think. They are correct, really, > > but the risk is mostly yours. If you lock to the utility > > out-of-phase, you will surely lose and they will surely win. The > > fault you create that they will see will probably not hurt them. > > Unless it is extraordinarily large and you are very close to the > > nearest substation. > > Utilities concern themselves with not only their gear and your gear, > but also your neighbor's gear. I would not like to be next-door to a > large genset that is connected to the grid out-of-phase. My equipment > would be affected by such an event. More to the point, as I note in another reply, you don't want to be *the lineman down the road with his hands on a "dead" wire*. Pretty much the *first paragraph* in NEC 700 (700.6) says this: """ Transfer equipment shall be designed and installed to prevent the inadvertent interconnection of normal and emergency sources of supply in any operation of the trans- fer equipment. """ So, if your transfer switch is *physically* capable of connecting your genset to the incoming power wires, then it violates 700.6, unless you're in a cogen sort of environment, in which case you're following Article 705, and a whole different set of rules apply. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From brandon at rd.bbc.co.uk Sun Jun 26 13:27:13 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 26 Jun 2011 19:27:13 +0100 (BST) Subject: Wacky Weekend: NERC to relax power grid frequency strictures Message-ID: <201106261827.TAA01042@sunf10.rd.bbc.co.uk> > It makes little sense to sync to the grid when the generator is only > used when the grid is down I don't know what large DC do but at our large sites we normally get power cheaper in exchange for a load shed agreement. When we got the call we ran some/all of the load on generator so the grid could flatten peaks. At our tv/radio transmitter sites there were no UPS so a break would disruptive. SOP was to run up the gens, sync then parallel the grid. DC just treat it as a power failure with a short break on non UPS service? brandon From if at xip.at Sun Jun 26 16:36:24 2011 From: if at xip.at (Ingo Flaschberger) Date: Sun, 26 Jun 2011 23:36:24 +0200 (CEST) Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <01311F06-D888-470E-B1DE-D137E86FA8AB@bogus.com> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> <4E06738A.20707@trelane.net> <01311F06-D888-470E-B1DE-D137E86FA8AB@bogus.com> Message-ID: >>> Take a guess what the datacenter our equipment is currently hosted in uses. Yet another reason to be glad of a datacenter move that's coming up. >>> >> Why can't we just all use DC and be happy? > > motors don't produce DC? dc generators produce dc. > tesla vs edison? > > human safe dc voltage requires comically large conductors for the sorts of loads we energize? > > transmission loss except at very high voltages... > > http://en.wikipedia.org/wiki/High-voltage_direct_current but transforming is not easy. ac/ac transformers are easy tu build and very immune against lightning strikes - inverter systems are not. Kind regards, Ingo Flaschberger From if at xip.at Sun Jun 26 16:43:57 2011 From: if at xip.at (Ingo Flaschberger) Date: Sun, 26 Jun 2011 23:43:57 +0200 (CEST) Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9012124453BA0@PUR-EXCH07.ox.com> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> <4E06820D.3000704@rollernet.us> <483E6B0272B0284BA86D7596C40D29F9012124453BA0@PUR-EXCH07.ox.com> Message-ID: > 2) Allowing transformer fields to collapse. Even in phase, without a > delayed transition ATS you can end up with a partially collapsed > transformer field with a new field being created at non-ground state. > This can cause a transient back wave that can snap circuit breakers. > Yep, this one happened to us a few times before we switched to a delayed > ATS, was a PITA to debug and resolve. a transformer should be switched to the network when phase is at highest/lowest point, not at zero. zero: highist current highest/lowest point: lowest current because it's a coil. Kind regards, Ingo Flaschberger From pelzi at pelzi.net Sun Jun 26 16:55:05 2011 From: pelzi at pelzi.net (Jussi Peltola) Date: Mon, 27 Jun 2011 00:55:05 +0300 Subject: Wacky Weekend: NERC to relax power grid frequency strictures [OT] In-Reply-To: References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> <4E06738A.20707@trelane.net> <01311F06-D888-470E-B1DE-D137E86FA8AB@bogus.com> Message-ID: <20110626215505.GH25848@pokute.pelzi.net> On Sun, Jun 26, 2011 at 11:36:24PM +0200, Ingo Flaschberger wrote: > but transforming is not easy. > ac/ac transformers are easy tu build and very immune against lightning > strikes - inverter systems are not. Switching DC is also problematic since there is no zero crossing to extinguish the arc. From pete at altadena.net Sun Jun 26 17:46:09 2011 From: pete at altadena.net (Pete Carah) Date: Sun, 26 Jun 2011 18:46:09 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> <4E06820D.3000704@rollernet.us> <483E6B0272B0284BA86D7596C40D29F9012124453BA0@PUR-EXCH07.ox.com> Message-ID: <4E07B6B1.3070600@altadena.net> On 06/26/2011 05:43 PM, Ingo Flaschberger wrote: >> 2) Allowing transformer fields to collapse. Even in phase, without a >> delayed transition ATS you can end up with a partially collapsed >> transformer field with a new field being created at non-ground state. >> This can cause a transient back wave that can snap circuit breakers. >> Yep, this one happened to us a few times before we switched to a >> delayed ATS, was a PITA to debug and resolve. The collapse can take more than one cycle, especially in a 3-phase transformer... As can the startup transient. In our case, if a big thunderstorm came, we started one generator ahead of time and synced it to the line, then did a 0-delay (overlap) switch. Avoids this problem, though the generator had better be a bunch bigger than the load to bring this off. Short delay ATS (less than 1sec) is a disaster, though. If you always wait till the power actually fails before starting the gen, you should wait 5-10 secs (or more) before putting the load on it, at least if there are any motors involved. (our generators were 1mw brushless ones that took 10-15secs for the voltage to come up anyhow...) And HVAC compressors have their own problems; once fully stopped you have to wait for the liquid to clear the compressor before restarting, or have LOTS of torque (like a car unit) available (and a supply of new belts :-) > > a transformer should be switched to the network when phase is at > highest/lowest point, not at zero. > zero: highist current > highest/lowest point: lowest current > because it's a coil. It isn't this simple... Switching on involves transients that overwhelm the sinusoidal waveform for a few cycles. Also the above is only strictly true for an unloaded transformer; if it has a matched resistive load the current and voltage are (mostly) in phase. (leakage inductance notwithstanding, though it isn't very high for high-power transformers.) Unfortunately most larger feed transformers are integrated 3-phase units where the current-voltage curves are shared between windings and get much more complicated, and there is no time (in normal operation) when all the voltages or currents are 0. Also for high enough ratios the interwinding capacitance is important (480 to 120/208 isn't high for this purpose; 8 or 16kv to 120/208/240 is). Big data centers (most bigger buildings) have 2 stages of transformers, one from "distribution" (8, 16, 20, 34kv) to 480 and a transformer per floor from 480 to whatever. Sometimes the generator is between these two and the UPSs are after the floor transformer(s). Big enough UPSs run at 480 so are between also. To complicate things even more, (modern) computers look kind-of capacitive, modern fluorescent lighting (electronic ballasts) looks kind-of capacitive, and motors and most other loads, and older lighting look inductive. That means it is hard to predict how to switch loads; either no-delay (need to sync the generator, though) or lots-of-delay operation is safer; short delay isn't. (and synchronous motors can actually look capacitive if they have enough of a flywheel on them, but the startup transient for a non-VF drive can be a killer.) BTW - in reply to a misconception long before in this thread, 3-phase sync motors self-start easily, and most older single-phase clock motors had enough of a shaded-pole to start in induction-motor mode then transition to sync once close to speed. The means to do this were subtle; sometimes it involved clever multilayer plating on the rotor and/or very clever shaping of the holes in the rotor. What I mean by kind-of capacitive is a bit odd; it looks capacitive on the voltage rise but resistive and/or a little inductive on the peak and fall, and the current is 0 when the voltage is below some threshold. Actually these days the feds (and I believe EC also) spec power-factor correction for switching power supplies so this effect is less. The main way this is arranged is to make sure the input-rectifier filter capacitors are SMALL enough; then have the switcher waveform compensate for the voltage droop. Bigger VF motor controllers do this also. -- Pete > > Kind regards, > Ingo Flaschberger > > > From pete at altadena.net Sun Jun 26 17:54:24 2011 From: pete at altadena.net (Pete Carah) Date: Sun, 26 Jun 2011 18:54:24 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures [OT] In-Reply-To: <20110626215505.GH25848@pokute.pelzi.net> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> <4E06738A.20707@trelane.net> <01311F06-D888-470E-B1DE-D137E86FA8AB@bogus.com> <20110626215505.GH25848@pokute.pelzi.net> Message-ID: <4E07B8A0.2090101@altadena.net> On 06/26/2011 05:55 PM, Jussi Peltola wrote: > On Sun, Jun 26, 2011 at 11:36:24PM +0200, Ingo Flaschberger wrote: >> but transforming is not easy. >> ac/ac transformers are easy tu build and very immune against lightning >> strikes - inverter systems are not. > Switching DC is also problematic since there is no zero crossing to > extinguish the arc. Sometime look at break ratings for AC and DC breakers and compare the relative sizes. Shows this effect. Easy answer is: don't use mechanical switches for routine switching... (easy if there is an inverter present, like in a VF drive or switching power supply). Big enough AC breakers maintain the arc over more than one cycle so have this problem too. (plasma quench time at atmospheric pressure can be a while...) Given the technology of the time, AC won rightfully. Still better for most distribution. -- Pete From gwardell at GWSystems.co.il Sun Jun 26 18:09:28 2011 From: gwardell at GWSystems.co.il (Gary Wardell) Date: Sun, 26 Jun 2011 19:09:28 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures Message-ID: Hi, Yes, transforming DC is not easy. However, DC works good at long haul transmission because a lot of energy is lost in the revers EMF generated by AC a several hundred volts. Some years ago a high voltage DC line was constructed between Oregon and California to deliver power to California. The line converts to DC at one and and back to AC at the other. Then again POTS phones have always used DC. DC is commonly used in telecom equipment. Well into the time of AC Portland, Oregon provided DC to the theater district for use in carbon arc lamps. It might be noted that the 120v RMS at our wall outlets actuality has a peek value of 169.7 Volts from zero. Or 339.5 volts peek to peek. Gary > >>> Take a guess what the datacenter our equipment is currently hosted in uses. Yet another reason to be glad of a datacenter move that's coming up. > >>> > >> Why can't we just all use DC and be happy? > > > > motors don't produce DC? > > dc generators produce dc. > > > tesla vs edison? > > > > human safe dc voltage requires comically large conductors for the sorts of loads we energize? > > > > transmission loss except at very high voltages... > > > > http://en.wikipedia.org/wiki/High-voltage_direct_current > > but transforming is not easy. > ac/ac transformers are easy tu build and very immune against lightning > strikes - inverter systems are not. > > Kind regards, > Ingo Flaschberger > > From pelzi at pelzi.net Sun Jun 26 18:50:41 2011 From: pelzi at pelzi.net (Jussi Peltola) Date: Mon, 27 Jun 2011 02:50:41 +0300 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <4E07B6B1.3070600@altadena.net> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> <4E06820D.3000704@rollernet.us> <483E6B0272B0284BA86D7596C40D29F9012124453BA0@PUR-EXCH07.ox.com> <4E07B6B1.3070600@altadena.net> Message-ID: <20110626235041.GI25848@pokute.pelzi.net> On Sun, Jun 26, 2011 at 06:46:09PM -0400, Pete Carah wrote: > HVAC compressors have their own problems; once fully stopped you have > to wait for the liquid to clear the compressor before restarting, or > have LOTS of torque (like a car unit) available (and a supply of new > belts :-) [begin OT lecture about refrigeration] If you have liquid in your compressor you are very screwed, it will dilute the oil and cause the surfaces of the compressor to wear out very quick (and if enough liquid gets far enough to actually get compressed, the compressor will very likely self destruct because liquids will not compress) To avoid this, many larger systems actually have a solenoid valve before the metering device which completely stops the refrigerant from moving the instant the compressor stops - the liquid refrigerant will then stay in the condenser, and the machine will cool instantly on the next start-up as an added benefit. These machines start against their normal working pressure. Some bigger systems have automatic pump-down which will actually run the compressor after shut-down against the closed valve with a pressure switch that makes sure all the refrigerant is in the condenser (and receiver) - this is required if the charge is sufficiently large that the amount of liquid in the evaporator (that hasn't evaporated yet) is enough to flood the compressor after shutdown. These systems can start against more than the normal operating pressure. The only ACs that have problems with restarting due to backpressure are single phase units - my window rattler has a bad thermostat that sometimes bounces the compressor off for a second. The result is a very loud hum and dim lights until the circuit breaker blows. But even single phase compressors with a proper start relay and capacitor can start against pressure, and these are fitted (called a hard start kit) if the system has a solenoid valve, or if the compressor is not starting due to wear or weak mains power (but these uses are band-aids.) All single phase ACs with electronic controls that I've seen have either a start up delay (often a few minutes, which I think is mostly to avoid excessive inrush when the power comes back) or they will not start at all without pressing the button manually. This usually works very well, but in some the logic is in the indoor unit, which in some cases can be powered separately from the outdoor unit. > What I mean by kind-of capacitive is a bit odd; it looks capacitive on > the voltage rise but resistive and/or a little inductive on the peak and > fall, and the current is 0 when the voltage is below some threshold. > Actually these days the feds (and I believe EC also) spec power-factor > correction for switching power supplies so this effect is less. The > main way this is arranged is to make sure the input-rectifier filter > capacitors are SMALL enough; then have the switcher waveform compensate > for the voltage droop. Bigger VF motor controllers do this also. This is true, but if you are feeding them through on-line UPSes they should look pretty resistive again. The EU has pretty strict specifications for PFC, and practically all modern servers I have tested are visually indistinguishable from a light bulb when viewed on a scope (I know that is not a very good measure of distortion.) From deric.kwok2000 at gmail.com Sun Jun 26 19:02:41 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sun, 26 Jun 2011 20:02:41 -0400 Subject: website in ipv6 Message-ID: Hi all I am trying to configure website for testing ipv6 Just wander how internet users eg: DSL users can visit this website and any people can access this website over the world Thank you From streiner at cluebyfour.org Sun Jun 26 15:24:59 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 26 Jun 2011 16:24:59 -0400 (EDT) Subject: website in ipv6 In-Reply-To: References: Message-ID: On Sun, 26 Jun 2011, Deric Kwok wrote: > I am trying to configure website for testing ipv6 > Just wander how internet users eg: DSL users can visit this website > and any people can access this website over the world 1. Your web server (operating system, too) needs to be IPv6 enabled. 2. You need to have IPv6 connectivity between your web server and your borders. If you have firewalls in front of your web server, they also need to be configured to pass IPv6 traffic appropriately. 3. You need to have IPv6 connectivity with at least one outside connectivity provider. 4. Your website should have valid IPv6 DNS (unless you want to force users to type in an IPv6 address to reach your site ;) ) There are numerous resources online to help people understand how to deploy IPv6 services on their networks. I would suggest starting there. http://www.ipv6.com/ is a good starting point. Whichever web server software you're using (Apache, etc) likely has support information or howtos for setting up IPv6 services. Same goes for whatever operating system you're using. jms From marka at isc.org Sun Jun 26 19:26:25 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 27 Jun 2011 10:26:25 +1000 Subject: website in ipv6 In-Reply-To: Your message of "Sun, 26 Jun 2011 20:02:41 -0400." References: Message-ID: <20110627002625.4C85311371DC@drugs.dv.isc.org> In message , Deric Kwok wr ites: > Hi all > > I am trying to configure website for testing ipv6 > > Just wander how internet users eg: DSL users can visit this website > and any people can access this website over the world > > Thank you About 10-6% of the net is dual stack capable, there is a working IPv6 path from the brower to the server. About 0.4% of the net prefers IPv6 over IPv4. It was higher but changes to depreference using 2002::/16 (6to4) as a source address have been pushed in various OS updates. http://www.potaroo.net/stats/1x1/sitec/v6hosts.png This is updated daily. APNIC/Geoff could use more test data sources. http://labs.apnic.net/index.shtml Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sun Jun 26 19:34:23 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 27 Jun 2011 10:34:23 +1000 Subject: website in ipv6 In-Reply-To: Your message of "Mon, 27 Jun 2011 10:26:25 +1000." <20110627002625.4C85311371DC@drugs.dv.isc.org> References: <20110627002625.4C85311371DC@drugs.dv.isc.org> Message-ID: <20110627003423.3A7E41137320@drugs.dv.isc.org> In message <20110627002625.4C85311371DC at drugs.dv.isc.org>, Mark Andrews writes : > > In message , Deric Kwok > wr > ites: > > Hi all > > > > I am trying to configure website for testing ipv6 > > > > Just wander how internet users eg: DSL users can visit this website > > and any people can access this website over the world > > > > Thank you > > About 10-6% of the net is dual stack capable, there is a working > IPv6 path from the brower to the server. About 0.4% of the net > prefers IPv6 over IPv4. It was higher but changes to depreference > using 2002::/16 (6to4) as a source address have been pushed in > various OS updates. > > http://www.potaroo.net/stats/1x1/sitec/v6hosts.png I meant to post the aggregate graph. http://www.potaroo.net/stats/1x1/v6hosts.png > This is updated daily. > > APNIC/Geoff could use more test data sources. > http://labs.apnic.net/index.shtml > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ttauber at 1-4-5.net Sun Jun 26 20:34:04 2011 From: ttauber at 1-4-5.net (Tony Tauber) Date: Sun, 26 Jun 2011 21:34:04 -0400 Subject: AS and advertisen questions In-Reply-To: References: Message-ID: On Sat, Jun 25, 2011 at 9:39 PM, Joel Jaeggli wrote: > > On Jun 25, 2011, at 6:03 PM, Deric Kwok wrote: > > > Can we use same AS to advertise different networks in different location? > > Assuming you want the two instances to be able talk to each other you just > have to relax loop detection so that you will accept prefixes from your > AS... > You can also have each AS carry default toward the cloud between. Of course, that approach might not be appropriate for all circumstances. Tony From shtsuchi at cisco.com Mon Jun 27 03:31:08 2011 From: shtsuchi at cisco.com (Shishio Tsuchiya) Date: Mon, 27 Jun 2011 17:31:08 +0900 Subject: Fwd: Service Provider Route Flap Damping Deployment Status Survey In-Reply-To: <4DDA2CF1.40100@cisco.com> References: <4DDA2CF1.40100@cisco.com> Message-ID: <4E083FCC.7010805@cisco.com> Dear NANOG We really appreciate response to the survey. We could get 63 response from global operators groups. And we had published result of the survey as internet-draft. http://tools.ietf.org/html/draft-shishio-grow-isp-rfd-implement-survey-02 We would like to refer the survey result to improve vender implementation. Q2.Do you use Route Flap Damping ? YES:13,NO:49 Q3.If you select No on Q2,why? Do not have the need:10 Did not know about the feature:5 No benefits expected:10 Customer would complain:5 Because I read RIPE-379:15 Other:6 Q4.If you select Yes on Q2,what parameter do you use? Default Parameter:6 RIPE-178:1 RIPE-210:0 RIPE-229:1 Other:7 Q5.Do you know Randy Bush et. al's report ''Route Flap Damping Considered Usable?'' YES:33 NO:29 Q6.IOS's max-penalty is currently limited to 20K. Do you need this limitation to be relaxed to over 50K? YES:24 NO:32 Q7.According to [draft-ymbk-rfd-usable],Suppress Threshold should be set to 6K.Do you think the default value on implementations should be changed to 6K? YES:17 NO:18 Q8.If you have any comments, please fill this box. Please see the draft. http://tools.ietf.org/html/draft-shishio-grow-isp-rfd-implement-survey-02#section-3.8.2 Best Regards, -Shishio From kemp at network-services.uoregon.edu Mon Jun 27 11:26:13 2011 From: kemp at network-services.uoregon.edu (John Kemp) Date: Mon, 27 Jun 2011 09:26:13 -0700 Subject: website in ipv6 In-Reply-To: <20110627003423.3A7E41137320@drugs.dv.isc.org> References: <20110627002625.4C85311371DC@drugs.dv.isc.org> <20110627003423.3A7E41137320@drugs.dv.isc.org> Message-ID: <4E08AF25.4090902@network-services.uoregon.edu> On 6/26/11 5:34 PM, Mark Andrews wrote: > In message <20110627002625.4C85311371DC at drugs.dv.isc.org>, Mark Andrews writes > : >> >> In message , Deric Kwok >> wr >> ites: >>> Hi all >>> >>> I am trying to configure website for testing ipv6 >>> >>> Just wander how internet users eg: DSL users can visit this website >>> and any people can access this website over the world >>> >>> Thank you >> >> About 10-6% of the net is dual stack capable, there is a working >> IPv6 path from the brower to the server. About 0.4% of the net >> prefers IPv6 over IPv4. It was higher but changes to depreference >> using 2002::/16 (6to4) as a source address have been pushed in >> various OS updates. >> >> http://www.potaroo.net/stats/1x1/sitec/v6hosts.png > > I meant to post the aggregate graph. > > http://www.potaroo.net/stats/1x1/v6hosts.png > >> This is updated daily. >> >> APNIC/Geoff could use more test data sources. >> http://labs.apnic.net/index.shtml >> >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> The more optimistic number was that something like 20% - 30% of clients could retrieve an IPV6-Only Literal URL. So yeah, still sad, but there is some potential there. --- John Kemp (kemp at routeviews.org) RouteViews Engineer NOC: help at routeviews.org http://www.routeviews.org From kenny.sallee at gmail.com Mon Jun 27 11:55:43 2011 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Mon, 27 Jun 2011 09:55:43 -0700 Subject: website in ipv6 In-Reply-To: References: Message-ID: On Sun, Jun 26, 2011 at 5:02 PM, Deric Kwok wrote: > Hi all > > I am trying to configure website for testing ipv6 > > Just wander how internet users eg: DSL users can visit this website > and any people can access this website over the world > > I did this by creating a 6to4 tunnel to a relay provided by www.tunnelbroker.net provided by Hurricane Electric - a great service they provide BTW. They provide sample configuration templates for various routers and OS's. I created the 'tunnel' from a Cisco 871w router (don't forget to configure a firewall here since you'll get IPv6 public IP's assigned to you). I used their block of v6 addresses they assigned to me, along with IPv4 addresses I already had - ie dual-stack, on my various windows and linux boxes behind my firewall. I then used their IPv6 DNS server, which returns IPV6 addressing if there's an AAAA record for the website you are going to. Some sites - like google search are reachable via different DNS names, like ipv6.google.com or ipv6.cnn.com...and www.v6.facebook.com. You can also build / use Teredo tunnels - which I tested and worked as well - tho not as good as from the routers. This works well for hosts behind IPv4 NAT Finally, you can test your personal IPv6 connectivity here: http://test-ipv6.com/ And you can test if your site, or any site, is reachable via IPv6 here: http://ipv6-test.com/validate.php if you do not have IPv6 configured. Good luck, Kenny From black at csulb.edu Mon Jun 27 12:19:07 2011 From: black at csulb.edu (Matthew Black) Date: Mon, 27 Jun 2011 10:19:07 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> References: <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, 24 Jun 2011 18:29:14 -0400 Jay Ashworth wrote: > The North American Electric Reliability Council is planning to relax > the standards for how closely power utilities must hold to 60.00Hz. > > Here's my absolute favorite quote of all time: > > Tweaking the power grid's frequency is expensive and takes a lot of >effort, > said Joe McClelland, head of electric reliability for the Federal Energy > Regulatory Commission. I blinked too after hearing of this. They say it's an economic issue because it costs millions of dollars to maintain a steady frequency. Excuse me...we probably spend over $50 billion per year on electricity and they're complaining about a few million. Talk about pinching pennies! matthew black e-mail postmaster california state university, long beach From mark at amplex.net Mon Jun 27 13:23:16 2011 From: mark at amplex.net (Mark Radabaugh) Date: Mon, 27 Jun 2011 14:23:16 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: References: <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> Message-ID: <4E08CA94.2030904@amplex.net> On 6/27/11 1:19 PM, Matthew Black wrote: > On Fri, 24 Jun 2011 18:29:14 -0400 > Jay Ashworth wrote: >> The North American Electric Reliability Council is planning to relax >> the standards for how closely power utilities must hold to 60.00Hz. >> >> Here's my absolute favorite quote of all time: >> >> Tweaking the power grid's frequency is expensive and takes a lot of >> effort, said Joe McClelland, head of electric reliability for the >> Federal Energy Regulatory Commission. > > > I blinked too after hearing of this. They say it's an economic issue > because it costs millions of dollars to maintain a steady frequency. > Excuse me...we probably spend over $50 billion per year on electricity > and they're complaining about a few million. Talk about pinching pennies! > > matthew black It's not just a cash issue. Frequency controls how power moves through the grid. Power flows from the higher frequency area to the lower frequency area (not exactly but close enough for this discussion). It limits the ability to generate power in areas that have excess and loads transmission lines with power being used to correct frequency. Mark From owen at delong.com Mon Jun 27 14:30:28 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 27 Jun 2011 12:30:28 -0700 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <01311F06-D888-470E-B1DE-D137E86FA8AB@bogus.com> References: <7632742.52.1308954254118.JavaMail.root@benjamin.baylink.com> <23981692.56.1308954554440.JavaMail.root@benjamin.baylink.com> <20110625221208.GA64593@ussenterprise.ufp.org> <4E0661E9.7040602@rollernet.us> <4E0672B9.1050100@paulgraydon.co.uk> <4E06738A.20707@trelane.net> <01311F06-D888-470E-B1DE-D137E86FA8AB@bogus.com> Message-ID: <47585DC5-974F-4CF1-A01A-0A4F7BA2F9B9@delong.com> On Jun 25, 2011, at 4:59 PM, Joel Jaeggli wrote: > > On Jun 25, 2011, at 4:47 PM, Andrew D Kirch wrote: > >> On 6/25/2011 7:43 PM, Paul Graydon wrote: >>> Take a guess what the datacenter our equipment is currently hosted in uses. Yet another reason to be glad of a datacenter move that's coming up. >>> >> Why can't we just all use DC and be happy? > > motors don't produce DC? > They can. > tesla vs edison? > Tesla was right, Edison was a better marketing person. AC works better for long-distance transmission. AC could have been made much safer had we chosen a 2Khz+ frequency rather than a 60Hz frequency. > human safe dc voltage requires comically large conductors for the sorts of loads we energize? > So does human safe AC voltage. The key difference is that AC voltage is much easier to change efficiently (transformers) whereas DC-DC voltage transitions require either an inverter (DC->AC->DC) inefficient and usually mechanical, a motor/generator set (inefficient and mechanical), or a DC-DC converter circuit which tends to be horribly inefficient and expensive, especially at high amperage. Owen From owen at delong.com Mon Jun 27 14:43:38 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 27 Jun 2011 12:43:38 -0700 Subject: What do you think about the Juniper MX line? In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC03C1AA97@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC03C1AA97@EXVBE005-2.exch005intermedia.net> Message-ID: <1D019DCC-4030-413C-93FA-46A8C5FD889F@delong.com> I think they have the potential to be great products. Unfortunately, services JunOS is a serious handicap if you want to use it as a Juniper Router and not a JunOS speaking netscreen. Owen On Jun 25, 2011, at 9:35 PM, Ryan Finnesey wrote: > I would love to know the same I am looking at the MX line as well for a > new network build-out > > Cheers > Ryan > > > -----Original Message----- > From: Chris [mailto:behrnetworks at gmail.com] > Sent: Saturday, June 25, 2011 9:29 AM > To: nanog at nanog.org > Subject: What do you think about the Juniper MX line? > > Hello, > > I've been doing some research into using the MX line of Juniper routers > and was interested in hearing people's experiences (the good, bad, and > ugly). What do you like about them? What do you dislike? > Where are you putting them in your network? Where are you not putting > them? Why? What other platforms would you consider and why? I hope to > hear some candid responses, but feel free to respond privately if you > need to. > > Thanks! > From owen at delong.com Mon Jun 27 14:45:22 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 27 Jun 2011 12:45:22 -0700 Subject: What do you think about the Juniper MX line? In-Reply-To: <5243148F-B495-4F2E-8FDC-92C35A4FE62F@ooma.com> References: , <6EFFEFBAC68377459A2E972105C759EC03C1AA97@EXVBE005-2.exch005intermedia.net> <5243148F-B495-4F2E-8FDC-92C35A4FE62F@ooma.com> Message-ID: <867CE135-5937-4C67-ABF0-1AF439FEAF92@delong.com> Sorry... I misspoke. My comments related to the SRX series and not the MX. The MX is a fine product in my experience. Owen On Jun 25, 2011, at 10:03 PM, Howard Hart wrote: > > We have a couple installed as our edge routers. > > Pluses - solid as a rock, easy to administer, and will take some extremely high packet rates for relatively low cost (important for us since we use them for VoIP traffic). If you're approaching the capacity of a 1GB uplink, I highly recommend these as your first step to 10 GB. > > Minuses - careful on your MX80 version. The MX80-48T includes a built in 48 port 1 GigE switch, but we've had compatibility issues with it and other vendors switches. The modular version that replaces the MX80-48T costs quite a bit more, but it does give you a lot more connection and compatibility options. > > Howard Hart > > On Jun 25, 2011, at 9:37 PM, "Ryan Finnesey" wrote: > >> I would love to know the same I am looking at the MX line as well for a >> new network build-out >> >> Cheers >> Ryan >> >> >> -----Original Message----- >> From: Chris [mailto:behrnetworks at gmail.com] >> Sent: Saturday, June 25, 2011 9:29 AM >> To: nanog at nanog.org >> Subject: What do you think about the Juniper MX line? >> >> Hello, >> >> I've been doing some research into using the MX line of Juniper routers >> and was interested in hearing people's experiences (the good, bad, and >> ugly). What do you like about them? What do you dislike? >> Where are you putting them in your network? Where are you not putting >> them? Why? What other platforms would you consider and why? I hope to >> hear some candid responses, but feel free to respond privately if you >> need to. >> >> Thanks! >> >> From jbaino at gmail.com Mon Jun 27 15:17:57 2011 From: jbaino at gmail.com (Jeremy) Date: Mon, 27 Jun 2011 15:17:57 -0500 Subject: What do you think about the Juniper MX line? In-Reply-To: <867CE135-5937-4C67-ABF0-1AF439FEAF92@delong.com> References: <6EFFEFBAC68377459A2E972105C759EC03C1AA97@EXVBE005-2.exch005intermedia.net> <5243148F-B495-4F2E-8FDC-92C35A4FE62F@ooma.com> <867CE135-5937-4C67-ABF0-1AF439FEAF92@delong.com> Message-ID: Heh, I spent about 3mo evaluating/testing SRX's and I agree they had potential but left /a lot/ to be desired. -Jeremy On Mon, Jun 27, 2011 at 2:45 PM, Owen DeLong wrote: > Sorry... I misspoke. My comments related to the SRX series and not the MX. > > The MX is a fine product in my experience. > > Owen > > On Jun 25, 2011, at 10:03 PM, Howard Hart wrote: > > > > > We have a couple installed as our edge routers. > > > > Pluses - solid as a rock, easy to administer, and will take some > extremely high packet rates for relatively low cost (important for us since > we use them for VoIP traffic). If you're approaching the capacity of a 1GB > uplink, I highly recommend these as your first step to 10 GB. > > > > Minuses - careful on your MX80 version. The MX80-48T includes a built in > 48 port 1 GigE switch, but we've had compatibility issues with it and other > vendors switches. The modular version that replaces the MX80-48T costs quite > a bit more, but it does give you a lot more connection and compatibility > options. > > > > Howard Hart > > > > On Jun 25, 2011, at 9:37 PM, "Ryan Finnesey" > wrote: > > > >> I would love to know the same I am looking at the MX line as well for a > >> new network build-out > >> > >> Cheers > >> Ryan > >> > >> > >> -----Original Message----- > >> From: Chris [mailto:behrnetworks at gmail.com] > >> Sent: Saturday, June 25, 2011 9:29 AM > >> To: nanog at nanog.org > >> Subject: What do you think about the Juniper MX line? > >> > >> Hello, > >> > >> I've been doing some research into using the MX line of Juniper routers > >> and was interested in hearing people's experiences (the good, bad, and > >> ugly). What do you like about them? What do you dislike? > >> Where are you putting them in your network? Where are you not putting > >> them? Why? What other platforms would you consider and why? I hope to > >> hear some candid responses, but feel free to respond privately if you > >> need to. > >> > >> Thanks! > >> > >> > > > From rcarpen at network1.net Mon Jun 27 15:23:43 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 27 Jun 2011 16:23:43 -0400 (EDT) Subject: What do you think about the Juniper MX line? In-Reply-To: Message-ID: <5fc6f7d2-ab03-44af-b5f2-c04e242c5300@zimbra.network1.net> The SRX line is nice for some uses, particularly with recent software updates that have fixed things like using IPv6 on vlan interfaces. The SRX is not going to be the choice for an edge router that needs to do BGP and/or 1 Gb/s+ of traffic. The SRX pretty much does everything in software, where the MX routes packets in ASICs. SRX is great for a firewall box, or to be the edge for a small network. I do wish there was an even lower-end MX than the new MX5 (all hardware routing, but ~$10k), as I would have many uses for such a thing in networks that only have a few uplinks of ~1 Gb/s. I don't need 20 Gb of throughput for that. But, if the budget allows for an MX5 (~$30k MSRP) or bigger, the MX line is very nice. -Randy ----- Original Message ----- > Heh, I spent about 3mo evaluating/testing SRX's and I agree they had > potential but left /a lot/ to be desired. > > -Jeremy > > On Mon, Jun 27, 2011 at 2:45 PM, Owen DeLong wrote: > > > Sorry... I misspoke. My comments related to the SRX series and not > > the MX. > > > > The MX is a fine product in my experience. > > > > Owen > > > > On Jun 25, 2011, at 10:03 PM, Howard Hart wrote: > > > > > > > > We have a couple installed as our edge routers. > > > > > > Pluses - solid as a rock, easy to administer, and will take some > > extremely high packet rates for relatively low cost (important for > > us since > > we use them for VoIP traffic). If you're approaching the capacity > > of a 1GB > > uplink, I highly recommend these as your first step to 10 GB. > > > > > > Minuses - careful on your MX80 version. The MX80-48T includes a > > > built in > > 48 port 1 GigE switch, but we've had compatibility issues with it > > and other > > vendors switches. The modular version that replaces the MX80-48T > > costs quite > > a bit more, but it does give you a lot more connection and > > compatibility > > options. > > > > > > Howard Hart > > > > > > On Jun 25, 2011, at 9:37 PM, "Ryan Finnesey" > > wrote: > > > > > >> I would love to know the same I am looking at the MX line as > > >> well for a > > >> new network build-out > > >> > > >> Cheers > > >> Ryan > > >> > > >> > > >> -----Original Message----- > > >> From: Chris [mailto:behrnetworks at gmail.com] > > >> Sent: Saturday, June 25, 2011 9:29 AM > > >> To: nanog at nanog.org > > >> Subject: What do you think about the Juniper MX line? > > >> > > >> Hello, > > >> > > >> I've been doing some research into using the MX line of Juniper > > >> routers > > >> and was interested in hearing people's experiences (the good, > > >> bad, and > > >> ugly). What do you like about them? What do you dislike? > > >> Where are you putting them in your network? Where are you not > > >> putting > > >> them? Why? What other platforms would you consider and why? I > > >> hope to > > >> hear some candid responses, but feel free to respond privately > > >> if you > > >> need to. > > >> > > >> Thanks! > > >> > > >> > > > > > > > > From feamster at cc.gatech.edu Mon Jun 27 15:48:35 2011 From: feamster at cc.gatech.edu (Nick Feamster) Date: Mon, 27 Jun 2011 16:48:35 -0400 Subject: Announcing Project BISMark: ISP Performance Measurements from Home Routers Message-ID: Hello NANOG, We've launched Project BISMark, a project that performs active performance measurements of upload and download throughput, latency, etc. from OpenWRT-based routers running inside of homes. We have tested our OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping out NetGear routers with the BISMark firmware to anyone who is interested. 1. If you're interested in receiving a NetGear WNDR 3700v2 with our measurement suite, please sign up on the project site. We are planning to give out more devices in mid-July. You can watch a video about BISMark here: http://challenge.gov/challenges/114/submissions/3133-bismark-a-broadband-internet-service-benchmark 2. Help us: if you would like to cast your vote for our tool on the project page above for the FCC Open Internet Application Challenge at the link above, we'd really appreciate your support. http://tinyurl.com/VoteBISMark 3. We're also looking for help in developing software. Project information and source code at: http://github.com/bismark-devel/ Thanks! Nick * To get a sample of the type of data we show to users, watch the video above, or check out the following example (in development): http://networkdashboard.org/device/NB105/ * Note: We do not collect any personal or private data; we only collect data from measurements that we perform, and we will share all of that data with you. From marka at isc.org Mon Jun 27 18:52:02 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 28 Jun 2011 09:52:02 +1000 Subject: website in ipv6 In-Reply-To: Your message of "Mon, 27 Jun 2011 09:26:13 MST." <4E08AF25.4090902@network-services.uoregon.edu> References: <20110627002625.4C85311371DC@drugs.dv.isc.org> <20110627003423.3A7E41137320@drugs.dv.isc.org> <4E08AF25.4090902@network-services.uoregon.edu> Message-ID: <20110627235202.357B2113B49E@drugs.dv.isc.org> In message <4E08AF25.4090902 at network-services.uoregon.edu>, John Kemp writes: > The more optimistic number was that something like 20% - 30% of clients > could retrieve an IPV6-Only Literal URL. So yeah, still sad, but there > is some potential there. Given most of that traffic is going through automatic tunnels from behind firewalls that generally havn't been configured to support the tunnels I don't think it is that bad. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From deric.kwok2000 at gmail.com Mon Jun 27 18:55:54 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Mon, 27 Jun 2011 19:55:54 -0400 Subject: AS and advertisen questions In-Reply-To: References: Message-ID: Hi all Thank you so much for your help I am not using cisco. From my understanding from your mail, I should configure bgp as the following. Right? What do I should pay attention also? Seattle: network 66.49.130.0/24 announce out permit: 66.49.130.0/24 announce out deny 0.0.0.0 deny in 66.49.130.0/24 permit in any New York: network 67.55.129.0/24 and ipv6 network. announce out permit 67.55.129.0/24 and ipv6 network. announce out deny 0.0.0.0 deny in 67.55.129.0/24 and ipv6 network permit in any Thank you again On Sat, Jun 25, 2011 at 10:11 PM, David Swafford wrote: > Yep, we do it that way. > > We basically treat each of our datacenter's as their own entity, using > separate space for each, but all with the same AS #. ?What Joel > mentioned is going to be the major catch, in that for each of the two > disconnected AS's to accept the opposite sites routes, you'd need to > relax BGP's loop prevention check (which looks for it's own AS # > within the AS Path of incoming routes). > > If your on Cisco gear, you'd need to add an additional command under > the BGP neighbor configuration that says "allowas-in". ?Here's a breif > doc from Cisco on configuring this > http://www.cisco.com/image/gif/paws/112236/allowas-in-bgp-config-example.pdf > > David. > > On Sat, Jun 25, 2011 at 9:39 PM, Joel Jaeggli wrote: >> >> On Jun 25, 2011, at 6:03 PM, Deric Kwok wrote: >> >>> Hi >>> >>> Can we use same AS to advertise different networks in different location? >>> >>> We would like to use Seattle as production network and New York as testing >>> >>> eg: >>> Seattle: network 66.49.130.0/24 >>> >>> New York: network 67.55.129.0/24 and ipv6 network. >>> >>> Thank you >> >> Assuming you want the two instances to be able talk to each other you just have to relax loop detection so that you will accept prefixes from your AS... >> > From marka at isc.org Mon Jun 27 19:02:13 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 28 Jun 2011 10:02:13 +1000 Subject: website in ipv6 In-Reply-To: Your message of "Mon, 27 Jun 2011 09:55:43 MST." References: Message-ID: <20110628000213.C2159113B6DB@drugs.dv.isc.org> In message , Kenny Sallee w rites: > On Sun, Jun 26, 2011 at 5:02 PM, Deric Kwok wrote: > > > Hi all > > > > I am trying to configure website for testing ipv6 > > > > Just wander how internet users eg: DSL users can visit this website > > and any people can access this website over the world > > > > > I did this by creating a 6to4 tunnel to a relay provided by 6in4, not 6to4. While HE do operate 6to4 relays, the brokered tunnel service is 6in4. > www.tunnelbroker.net provided by Hurricane Electric - a great service they > provide BTW. They provide sample configuration templates for various > routers and OS's. I created the 'tunnel' from a Cisco 871w router (don't > forget to configure a firewall here since you'll get IPv6 public IP's > assigned to you). I used their block of v6 addresses they assigned to me, > along with IPv4 addresses I already had - ie dual-stack, on my various > windows and linux boxes behind my firewall. I then used their IPv6 DNS > server, which returns IPV6 addressing if there's an AAAA record for the > website you are going to. Some sites - like google search are reachable via > different DNS names, like ipv6.google.com or ipv6.cnn.com...and > www.v6.facebook.com. > > You can also build / use Teredo tunnels - which I tested and worked as well > - tho not as good as from the routers. This works well for hosts behind > IPv4 NAT > > Finally, you can test your personal IPv6 connectivity here: > > http://test-ipv6.com/ > > And you can test if your site, or any site, is reachable via IPv6 here: > http://ipv6-test.com/validate.php if you do not have IPv6 configured. > > Good luck, > Kenny -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From eugen at leitl.org Tue Jun 28 03:52:55 2011 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 28 Jun 2011 10:52:55 +0200 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) Message-ID: <20110628085255.GX26837@leitl.org> ----- Forwarded message from William Salt ----- From: William Salt Date: Tue, 28 Jun 2011 08:03:25 +0100 To: support at pfsense.com Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) Reply-To: support at pfsense.com Hi All, For the last couple of months i have been pulling my hair out trying to solve this problem. We have a 1Gbps transatlantic link from the UK to the US, which has successfully passed the RFC2544 test. At either end, we have a media converter, and a supermicro server with an intel quad port NIC running pfsense 2 (RC2 at one end RC3 at the other) and the IGB driver on the quad port. We can pass 1gbps either way with UDP. However we are experiencing very strange issues with tcp connections. With window scaling enabled, and a max socket buffer set to 16MB, we see no difference. Even disabling window scaling and setting the window to 16MB makes no difference. Each TCP connection starts very slowly, and will max out at around 190mbps, taking nearly 2 minutes to climb to this speed before *plateauing*. We have to initiate many (5+) connections to saturate the link with tcp connections with iperf. Real world tests transferring files, max out at 100mbps, using multiple connections. I have followed guides like this: http://www.psc.edu/networking/projects/tcptune/#FreeBSD With no luck, and have tweaked, disabled, and enabled nearly every relevant sysctl parameter with no luck. Can anyone shed some light on this? I am now doubting the IGB driver, and am looking to swap out the cards as a last ditch effort. However, we have tried different hardware (L3 switches, media convertes + laptops etc), and the symptoms still persist... The only constant is freebsd 8.1 - pfsense (or 8.2 for our production systems). I have tried the freebsd net mailinglist, but im hoping you lot can help me! Cheers in advance Will ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From swmike at swm.pp.se Tue Jun 28 05:13:04 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 28 Jun 2011 12:13:04 +0200 (CEST) Subject: Announcing Project BISMark: ISP Performance Measurements from Home Routers In-Reply-To: References: Message-ID: On Mon, 27 Jun 2011, Nick Feamster wrote: > We've launched Project BISMark, a project that performs active > performance measurements of upload and download throughput, latency, > etc. from OpenWRT-based routers running inside of homes. We have tested > our OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping > out NetGear routers with the BISMark firmware to anyone who is > interested. Please, pretty please, with sugar on top, don't just do active measurement, but also do passive measurement of real traffic. Doing test traffic is one case, but the really important thing to look at is real traffic. I tried to get traction for this on IETF75, but there seems to be little interest. On a NAT router there is a state table, what would the performance penality be to look at TCP sequence numbers, RTTs (TCP timestamps) to be able to discern PDV and loss of the actual traffic the customer is doing? There are a lot of test suites, they solve one problem, but a passive monitoring system that would show how the real traffic is behaving would yield a lot more valuable information that just relying on active testing (which will cause harm to customer traffic when the test is run). -- Mikael Abrahamsson email: swmike at swm.pp.se From jerome at ceriz.fr Tue Jun 28 05:22:44 2011 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 28 Jun 2011 12:22:44 +0200 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: <20110628085255.GX26837@leitl.org> References: <20110628085255.GX26837@leitl.org> Message-ID: This is a well known issues called "Long Fat Pipe Network". There's many university papers about it and many tricks to get around it on software-based boxes. Adjusting your TCP window size was the best start, if it's set properlu. The basic formula is provided in this forum post : http://forums.whirlpool.net.au/archive/116165 Good luck ! 2011/6/28 Eugen Leitl : > ----- Forwarded message from William Salt ----- > > From: William Salt > Date: Tue, 28 Jun 2011 08:03:25 +0100 > To: support at pfsense.com > Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > Reply-To: support at pfsense.com > > Hi All, > ? ? ? ? For the last couple of months i have been pulling my hair out > trying to solve this problem. > We have a 1Gbps transatlantic link from the UK to the US, which has > successfully passed the RFC2544 test. > > At either end, we have a media converter, and a supermicro server with an > intel quad port NIC running pfsense 2 (RC2 at one end RC3 at the other) and > the IGB driver on the quad port. > > We can pass 1gbps either way with UDP. However we are experiencing very > strange issues with tcp connections. > > With window scaling enabled, and a max socket buffer set to 16MB, we see no > difference. > Even disabling window scaling and setting the window to 16MB makes no > difference. > > Each TCP connection starts very slowly, and will max out at around 190mbps, > taking nearly 2 minutes to climb to this speed before *plateauing*. > > We have to initiate many (5+) connections to saturate the link with tcp > connections with iperf. > > Real world tests transferring files, max out at 100mbps, using multiple > connections. > > I have followed guides like this: > http://www.psc.edu/networking/projects/tcptune/#FreeBSD > > With no luck, and have tweaked, disabled, and enabled nearly every relevant > sysctl parameter with no luck. > > Can anyone shed some light on this? > > I am now doubting the IGB driver, and am looking to swap out the cards as a > last ditch effort. > However, we have tried different hardware (L3 switches, media convertes + > laptops etc), and the symptoms still persist... > The only constant is freebsd 8.1 - pfsense (or 8.2 for our production > systems). > I have tried the freebsd net mailinglist, but im hoping you lot can help me! > > Cheers in advance > Will > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A ?7779 75B0 2443 8B29 F6BE > > -- J?r?me Nicolle 06 19 31 27 14 From leigh.porter at ukbroadband.com Tue Jun 28 05:29:56 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 28 Jun 2011 10:29:56 +0000 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> Message-ID: Indeed, we had similar issues on a 3G radio network. Long RTTs made it impossible to reach the maximum potential throughput of the network. I installed one of these: http://www.fastsoft.com/home/ And the problem just went away. -- Leigh Porter > -----Original Message----- > From: J?r?me Nicolle [mailto:jerome at ceriz.fr] > Sent: 28 June 2011 11:26 > To: Eugen Leitl > Cc: NANOG list > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > > This is a well known issues called "Long Fat Pipe Network". > > There's many university papers about it and many tricks to get around > it on software-based boxes. > > Adjusting your TCP window size was the best start, if it's set > properlu. The basic formula is provided in this forum post : > http://forums.whirlpool.net.au/archive/116165 > > Good luck ! > > 2011/6/28 Eugen Leitl : > > ----- Forwarded message from William Salt > ----- > > > > From: William Salt > > Date: Tue, 28 Jun 2011 08:03:25 +0100 > > To: support at pfsense.com > > Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > > Reply-To: support at pfsense.com > > > > Hi All, > > ? ? ? ? For the last couple of months i have been pulling my hair out > > trying to solve this problem. > > We have a 1Gbps transatlantic link from the UK to the US, which has > > successfully passed the RFC2544 test. > > > > At either end, we have a media converter, and a supermicro server > with an > > intel quad port NIC running pfsense 2 (RC2 at one end RC3 at the > other) and > > the IGB driver on the quad port. > > > > We can pass 1gbps either way with UDP. However we are experiencing > very > > strange issues with tcp connections. > > > > With window scaling enabled, and a max socket buffer set to 16MB, we > see no > > difference. > > Even disabling window scaling and setting the window to 16MB makes no > > difference. > > > > Each TCP connection starts very slowly, and will max out at around > 190mbps, > > taking nearly 2 minutes to climb to this speed before *plateauing*. > > > > We have to initiate many (5+) connections to saturate the link with > tcp > > connections with iperf. > > > > Real world tests transferring files, max out at 100mbps, using > multiple > > connections. > > > > I have followed guides like this: > > http://www.psc.edu/networking/projects/tcptune/#FreeBSD > > > > With no luck, and have tweaked, disabled, and enabled nearly every > relevant > > sysctl parameter with no luck. > > > > Can anyone shed some light on this? > > > > I am now doubting the IGB driver, and am looking to swap out the > cards as a > > last ditch effort. > > However, we have tried different hardware (L3 switches, media > convertes + > > laptops etc), and the symptoms still persist... > > The only constant is freebsd 8.1 - pfsense (or 8.2 for our production > > systems). > > I have tried the freebsd net mailinglist, but im hoping you lot can > help me! > > > > Cheers in advance > > Will > > > > ----- End forwarded message ----- > > -- > > Eugen* Leitl leitl http://leitl.org > > ______________________________________________________________ > > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > > 8B29F6BE: 099D 78BA 2FD3 B014 B08A ?7779 75B0 2443 8B29 F6BE > > > > > > > > -- > J?r?me Nicolle > 06 19 31 27 14 > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From askoorb+nanog at gmail.com Tue Jun 28 05:30:07 2011 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Tue, 28 Jun 2011 11:30:07 +0100 Subject: Announcing Project BISMark: ISP Performance Measurements from Home Routers In-Reply-To: References: Message-ID: Hello, On Mon, Jun 27, 2011 at 9:48 PM, Nick Feamster wrote: > > Hello NANOG, > > We've launched Project BISMark, a project that performs active performance measurements of upload and download throughput, latency, etc. from OpenWRT-based routers running inside of homes. ? We have tested our OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping out NetGear routers with the BISMark firmware to anyone who is interested. > Is this similar to the UK (Ofcom,?http://www.ofcom.org.uk/) and US (FCC,?http://www.fcc.gov/) regulators scheme that is being run by Sam Knows at?http://www.samknows.com/broadband/test_my_isp?and http://www.samknows.com/broadband/broadband_performance ? I'd be quite interested to know the?difference?between them. Alex From swmike at swm.pp.se Tue Jun 28 05:36:02 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 28 Jun 2011 12:36:02 +0200 (CEST) Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: <20110628085255.GX26837@leitl.org> References: <20110628085255.GX26837@leitl.org> Message-ID: On Tue, 28 Jun 2011, Eugen Leitl wrote: > Even disabling window scaling and setting the window to 16MB makes no > difference. If you disable window scaling, you're limiting it to 64k. > However, we have tried different hardware (L3 switches, media convertes + > laptops etc), and the symptoms still persist... You should dump the traffic and analyse it in Wireshark, then you'll see if you have packet loss or not. Most likely you do not, and the reason for your problem is TCP setting related (see other posts with links). Before you start replacing hw you should diagnose what your problem is, if you're not losing packets and the delay variation is constant, then it's not related to the network. Both of these factors can be seen using the built in tools in wireshark (Analyze->Expert info, and Statistics->TCP stream graph). -- Mikael Abrahamsson email: swmike at swm.pp.se From kristopher.doyen at gmail.com Tue Jun 28 08:07:48 2011 From: kristopher.doyen at gmail.com (kristopher.doyen at gmail.com) Date: Tue, 28 Jun 2011 13:07:48 +0000 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: <20110628085255.GX26837@leitl.org> References: <20110628085255.GX26837@leitl.org> Message-ID: <1544807676-1309266497-cardhu_decombobulator_blackberry.rim.net-750914092-@b5.c10.bise6.blackberry> Since UDP works I have my doubts it is a driver/interface link issue. This sounds more like a latency/packet loss issue (esp since it is a transatlantic link). What type of latency, packet loss, and or packet error rates are you seeing? -----Original Message----- From: Eugen Leitl Date: Tue, 28 Jun 2011 10:52:55 To: NANOG list Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) ----- Forwarded message from William Salt ----- From: William Salt Date: Tue, 28 Jun 2011 08:03:25 +0100 To: support at pfsense.com Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) Reply-To: support at pfsense.com Hi All, For the last couple of months i have been pulling my hair out trying to solve this problem. We have a 1Gbps transatlantic link from the UK to the US, which has successfully passed the RFC2544 test. At either end, we have a media converter, and a supermicro server with an intel quad port NIC running pfsense 2 (RC2 at one end RC3 at the other) and the IGB driver on the quad port. We can pass 1gbps either way with UDP. However we are experiencing very strange issues with tcp connections. With window scaling enabled, and a max socket buffer set to 16MB, we see no difference. Even disabling window scaling and setting the window to 16MB makes no difference. Each TCP connection starts very slowly, and will max out at around 190mbps, taking nearly 2 minutes to climb to this speed before *plateauing*. We have to initiate many (5+) connections to saturate the link with tcp connections with iperf. Real world tests transferring files, max out at 100mbps, using multiple connections. I have followed guides like this: http://www.psc.edu/networking/projects/tcptune/#FreeBSD With no luck, and have tweaked, disabled, and enabled nearly every relevant sysctl parameter with no luck. Can anyone shed some light on this? I am now doubting the IGB driver, and am looking to swap out the cards as a last ditch effort. However, we have tried different hardware (L3 switches, media convertes + laptops etc), and the symptoms still persist... The only constant is freebsd 8.1 - pfsense (or 8.2 for our production systems). I have tried the freebsd net mailinglist, but im hoping you lot can help me! Cheers in advance Will ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From rdobbins at arbor.net Tue Jun 28 08:47:06 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 28 Jun 2011 13:47:06 +0000 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: <20110628085255.GX26837@leitl.org> References: <20110628085255.GX26837@leitl.org> Message-ID: <7CC575DE-2F31-4B5F-B8C3-DD18E94FEEFC@arbor.net> On Jun 28, 2011, at 3:52 PM, Eugen Leitl wrote: > For the last couple of months i have been pulling my hair out trying to solve this problem. Sounds like TCP RTT and/or packet-loss - should be easy to determine the issue with a bit of traffic capture. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From rhys at rhavenindustrys.com Tue Jun 28 09:30:06 2011 From: rhys at rhavenindustrys.com (Rhys Rhaven) Date: Tue, 28 Jun 2011 09:30:06 -0500 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: <20110628085255.GX26837@leitl.org> References: <20110628085255.GX26837@leitl.org> Message-ID: <4E09E56E.9060000@rhavenindustrys.com> Obviously not helping if you are trying to tune standard TCP, but I lament that protocols like Tsunami are not in wider use. http://tsunami-udp.sourceforge.net/ Short of it, a TCP control channel takes care of error checking and resends while the data channel is a UDP stream, specifically built to max out LFNs. On 06/28/2011 03:52 AM, Eugen Leitl wrote: > ----- Forwarded message from William Salt ----- > > From: William Salt > Date: Tue, 28 Jun 2011 08:03:25 +0100 > To: support at pfsense.com > Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > Reply-To: support at pfsense.com > > Hi All, > For the last couple of months i have been pulling my hair out > trying to solve this problem. > We have a 1Gbps transatlantic link from the UK to the US, which has > successfully passed the RFC2544 test. > > At either end, we have a media converter, and a supermicro server with an > intel quad port NIC running pfsense 2 (RC2 at one end RC3 at the other) and > the IGB driver on the quad port. > > We can pass 1gbps either way with UDP. However we are experiencing very > strange issues with tcp connections. > > With window scaling enabled, and a max socket buffer set to 16MB, we see no > difference. > Even disabling window scaling and setting the window to 16MB makes no > difference. > > Each TCP connection starts very slowly, and will max out at around 190mbps, > taking nearly 2 minutes to climb to this speed before *plateauing*. > > We have to initiate many (5+) connections to saturate the link with tcp > connections with iperf. > > Real world tests transferring files, max out at 100mbps, using multiple > connections. > > I have followed guides like this: > http://www.psc.edu/networking/projects/tcptune/#FreeBSD > > With no luck, and have tweaked, disabled, and enabled nearly every relevant > sysctl parameter with no luck. > > Can anyone shed some light on this? > > I am now doubting the IGB driver, and am looking to swap out the cards as a > last ditch effort. > However, we have tried different hardware (L3 switches, media convertes + > laptops etc), and the symptoms still persist... > The only constant is freebsd 8.1 - pfsense (or 8.2 for our production > systems). > I have tried the freebsd net mailinglist, but im hoping you lot can help me! > > Cheers in advance > Will > > ----- End forwarded message ----- From feamster at cc.gatech.edu Tue Jun 28 09:58:32 2011 From: feamster at cc.gatech.edu (Nick Feamster) Date: Tue, 28 Jun 2011 10:58:32 -0400 Subject: Announcing Project BISMark: ISP Performance Measurements from Home Routers In-Reply-To: References: Message-ID: Thanks for the feedback! On Jun 28, 2011, at 6:13 AM, Mikael Abrahamsson wrote: > On Mon, 27 Jun 2011, Nick Feamster wrote: > >> We've launched Project BISMark, a project that performs active performance measurements of upload and download throughput, latency, etc. from OpenWRT-based routers running inside of homes. We have tested our OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping out NetGear routers with the BISMark firmware to anyone who is interested. > > Please, pretty please, with sugar on top, don't just do active measurement, but also do passive measurement of real traffic. Doing test traffic is one case, but the really important thing to look at is real traffic. I tried to get traction for this on IETF75, but there seems to be little interest. > We would very much like to. There are a number of reasons that regular users seem to be asking for passive measurement, such as monitoring of traffic usage of different applications (e.g., "How much is streaming eating into my usage cap?"). A few years ago, we had a tool that would do all of this with passive measurement (http://gtnoise.net/nano/), and we'd certainly like to resume this line of inquiry, if we can figure out how to address people's privacy concerns. We are developing a passive measurement suite for BISMark, which is also available on github. > On a NAT router there is a state table, what would the performance penality be to look at TCP sequence numbers, RTTs (TCP timestamps) to be able to discern PDV and loss of the actual traffic the customer is doing? > > There are a lot of test suites, they solve one problem, but a passive monitoring system that would show how the real traffic is behaving would yield a lot more valuable information that just relying on active testing (which will cause harm to customer traffic when the test is run). Definitely good points, and we've thought about this, for sure. The key question seems to be how to handle user privacy in a way that everyone can be happy with. Ultimately, we might take a survey of our users about this (e.g., certain people have said they don't mind tracking application performance/usage as long as the specific Web sites or destinations are not logged). It would be really helpful to get an understanding of what users might find acceptable, as far as passive measurements. -Nick From feamster at cc.gatech.edu Tue Jun 28 10:06:37 2011 From: feamster at cc.gatech.edu (Nick Feamster) Date: Tue, 28 Jun 2011 11:06:37 -0400 Subject: Announcing Project BISMark: ISP Performance Measurements from Home Routers In-Reply-To: References: Message-ID: <05F3A243-36BB-4124-B606-30539EDE48D9@cc.gatech.edu> Hi Alex, On Jun 28, 2011, at 6:30 AM, Alex Brooks wrote: > Is this similar to the UK (Ofcom, http://www.ofcom.org.uk/) and US > (FCC, http://www.fcc.gov/) regulators scheme that is being run by Sam > Knows at http://www.samknows.com/broadband/test_my_isp and > http://www.samknows.com/broadband/broadband_performance ? > Yes, it's very closely related, and we've been in close contact with them (we have a paper upcoming at SIGCOMM that is based on the US data that we've jointly authored). One of the differences is that the platform is open / open-source. For example, anyone would be able to develop and run their own tests from the box. Another difference is that we're looking into a variety of other things (e.g., measurements of performance inside the home, deployments in other regions, maybe ultimately passive measurements if we can figure out how to balance the more sensitive aspects of that). Our goal is to have some sets of tests that are running/could be run on either platform. We're interested in helping to improve the tests that are run on the SK routers, as well. -Nick From dougm at nist.gov Tue Jun 28 10:06:44 2011 From: dougm at nist.gov (Montgomery, Douglas) Date: Tue, 28 Jun 2011 11:06:44 -0400 Subject: Announcing BRITE - BGPSEC / RPKI Interoperability Test & Evaluation system Message-ID: BRITE is a web-based test and evaluation framework for exercising implementations, configurations and deployments of emerging IETF BGP security technologies, including some components of the Resource Public Key Infrastructure (RPKI) and routers that support BGP security extensions. BRITE is currently capable of testing: RPKI validation caches and BGP routers that perform origin validation based upon RPKI ROAs. Future extensions will support BGP routers that support full path validation. BRITE currently supports the following capabilities / protocol interfaces: * rsync of RPKI objects from BRITE test suite repositories, * RPKI/Router Protocol (draft-ietf-sidr-rpki-rtr-12 - TCP plain sockets, no SSH transport or TCP-AO) * BGP-4 (tested interoperability with Cisco IOS, JUNOS, Quagga, OpenBGPD and BIRD) BRITE is driven by test scripts that describe carefully crafted Test Scenarios (stimulus inputs from BRITE using the protocols above) and corresponding goals (expected responses from the Implementation Under Test (IUT) using the protocols above). BRITE allows users to login, select a specific test case, interactively configure and run the test case and then browse/download detailed test reports, packet captures and log files. Current test scripts & data sets are available for: * BGP routers that implement the rpki-rtr protocol and simple BGP origin validation route policies. Additional test suites & data sets are in development and will be announced when available. To get additional information, browse existing test suites, or use the BRITE system, goto: http://brite.antd.nist.gov/ Questions or comments can be directed to brite-dev at nist.gov. dougm -- Doug Montgomery ? Mgr. Internet & Scalable Systems Research / ITL / NIST From andreas at naund.org Tue Jun 28 10:23:46 2011 From: andreas at naund.org (Andreas Ott) Date: Tue, 28 Jun 2011 08:23:46 -0700 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: <20110628085255.GX26837@leitl.org>; from eugen@leitl.org on Tue, Jun 28, 2011 at 10:52:55AM +0200 References: <20110628085255.GX26837@leitl.org> Message-ID: <20110628082346.I27898@naund.org> Hi, On Tue, Jun 28, 2011 at 10:52:55AM +0200, Eugen Leitl wrote: > ----- Forwarded message from William Salt ----- > From: William Salt > Date: Tue, 28 Jun 2011 08:03:25 +0100 > To: support at pfsense.com > Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > Reply-To: support at pfsense.com > Each TCP connection starts very slowly, and will max out at around 190mbps, > taking nearly 2 minutes to climb to this speed before *plateauing*. > > We have to initiate many (5+) connections to saturate the link with tcp > connections with iperf. > ----- End forwarded message ----- You pretty much solved your own puzzle right there: the throughput on a single TCP connection will max out at the value determined by the bandwidth delay product (excluding other strange conditions, such as deep buffers). Here is a calculator online: http://www.switch.ch/network/tools/tcp_throughput/ -andreas [who has to explain this about once a week to customers who think that they bought a GigE connection but then can't "ftp" a file from coast to coast at 1Gbps throughput. Use multiple TCP streams!] From leigh.porter at ukbroadband.com Tue Jun 28 10:39:58 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 28 Jun 2011 15:39:58 +0000 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: <20110628082346.I27898@naund.org> References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: > -----Original Message----- > From: Andreas Ott [mailto:andreas at naund.org] > Sent: 28 June 2011 16:27 > To: Eugen Leitl; williamejsalt at googlemail.com > Cc: NANOG list > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > > -andreas > [who has to explain this about once a week to customers who think > that they bought a GigE connection but then can't "ftp" a file from > coast to coast at 1Gbps throughput. Use multiple TCP streams!] Yeah, try explaining to a VSAT customer why they don't get 10Mb/s on their 10Mb/s VSAT connection with a 600ms RTT! The response is.. "I don't care, I want my 10Mb/s!"... -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From cb.list6 at gmail.com Tue Jun 28 10:52:39 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 28 Jun 2011 08:52:39 -0700 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Tue, Jun 28, 2011 at 8:39 AM, Leigh Porter wrote: > > >> -----Original Message----- >> From: Andreas Ott [mailto:andreas at naund.org] >> Sent: 28 June 2011 16:27 >> To: Eugen Leitl; williamejsalt at googlemail.com >> Cc: NANOG list >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 >> (+3) >> >> -andreas >> [who has to explain this about once a week to customers who think >> that they bought a GigE connection but then can't "ftp" a file from >> coast to coast at 1Gbps throughput. Use multiple TCP streams!] > > Yeah, try explaining to a VSAT customer why they don't get 10Mb/s on their 10Mb/s VSAT connection with a 600ms RTT! > > The response is.. "I don't care, I want my 10Mb/s!"... > In the 3G world, i have had good results overcoming longish RTT by using the Hybla TCP algorithm http://hybla.deis.unibo.it/ I am hoping it gets more default traction, especially in wireless where the radio link is a pretty big latency source Cameron > -- > Leigh > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > From leigh.porter at ukbroadband.com Tue Jun 28 11:11:23 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 28 Jun 2011 16:11:23 +0000 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: > -----Original Message----- > From: Cameron Byrne [mailto:cb.list6 at gmail.com] > Sent: 28 June 2011 16:53 > To: Leigh Porter > Cc: Andreas Ott; Eugen Leitl; williamejsalt at googlemail.com; NANOG list > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > In the 3G world, i have had good results overcoming longish RTT by > using the Hybla TCP algorithm http://hybla.deis.unibo.it/ > > I am hoping it gets more default traction, especially in wireless > where the radio link is a pretty big latency source > > Cameron How do you implement this for lots of clients and servers that have out of the box implementations? The FastSoft box is a TCP man-in-the-middle box that essentially implements the FAST TCP algorithm without either end having to worry about it. I have also used home-fudged TCP proxies with some success. Some 3G/wireless/VSAT vendors implement their own TCP modification stacks but they usually only fiddle with window sizes and such. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From cb.list6 at gmail.com Tue Jun 28 11:16:13 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 28 Jun 2011 09:16:13 -0700 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter wrote: > > >> -----Original Message----- >> From: Cameron Byrne [mailto:cb.list6 at gmail.com] >> Sent: 28 June 2011 16:53 >> To: Leigh Porter >> Cc: Andreas Ott; Eugen Leitl; williamejsalt at googlemail.com; NANOG list >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 >> (+3) >> In the 3G world, i have had good results overcoming longish RTT by >> using the Hybla TCP algorithm ?http://hybla.deis.unibo.it/ >> >> I am hoping it gets more default traction, especially in wireless >> where the radio link is a pretty big latency source >> >> Cameron > > How do you implement this for lots of clients and servers that have out of the box implementations? The FastSoft box is a TCP man-in-the-middle box that essentially implements the FAST TCP algorithm without either end having to worry about it. > You don't, the full benefits only come with a Linux kernel patch. The good news is that it only has to be implemented on the client end. > I have also used home-fudged TCP proxies with some success. > > Some 3G/wireless/VSAT vendors implement their own TCP modification stacks but they usually only fiddle with window sizes and such. > That's why i said i hope it catches on as default :) If Android implemented Hybla, i think it would be a great improvement for user experience. Nobody likes the middleboxes that proxy TCP.... they cost money, don't scale well, and are generally fragile. Hybla is not a solution for the OPs issue, just a solution for high RTT links where the client can do Hybla. It an evolutionary step that i think would make a great fit in smartphones like Android. Cameron > -- > Leigh > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > From daniel.unam.ipv6 at gmail.com Tue Jun 28 12:50:29 2011 From: daniel.unam.ipv6 at gmail.com (Daniel Espejel) Date: Tue, 28 Jun 2011 12:50:29 -0500 Subject: Announcing Project BISMark: ISP Performance Measurements from Home Routers Message-ID: Hi. I would like to participate in the Bismark project, for now only as a poller-kind user. While checking the router n600 specifications datasheet it seems that this device is IPv6 compliant in some degree (because of the IPv6 Ready Logo included at the bottom of the sheet). I'm really interested in performing some test about that issue; but I'm also worried about privacy/confidentiality and navigation speed features. It's likely all those whom participate may find related information about this topics in the project website and related mailing list. Well, I'm waiting to get my hands dirty on N600 and this way trying to solve some of my doubts (or catch a lot more). > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jun 2011 11:30:07 +0100 > From: Alex Brooks > Subject: Re: Announcing Project BISMark: ISP Performance Measurements > from Home Routers > To: nanog > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > Hello, > > On Mon, Jun 27, 2011 at 9:48 PM, Nick Feamster > wrote: > > > > Hello NANOG, > > > > We've launched Project BISMark, a project that performs active > performance measurements of upload and download throughput, latency, etc. > from OpenWRT-based routers running inside of homes. ? We have tested our > OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping out > NetGear routers with the BISMark firmware to anyone who is interested. > > > -- *Daniel Espejel Perez * From kenny.sallee at gmail.com Tue Jun 28 13:09:04 2011 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Tue, 28 Jun 2011 11:09:04 -0700 Subject: website in ipv6 In-Reply-To: <20110628000213.C2159113B6DB@drugs.dv.isc.org> References: <20110628000213.C2159113B6DB@drugs.dv.isc.org> Message-ID: > > > > > > > I did this by creating a 6to4 tunnel to a relay provided by > > 6in4, not 6to4. While HE do operate 6to4 relays, the brokered tunnel > service is 6in4. > > A very important distinction I didn't have clear in my head. To regurgitate some reading I just completed: both methods use v6 in v4 tunneling using ip proto 41 in the IPv4 protocol field. However, 6to4 derives the IPv4 tunnel destination of an IPv6 packet based on bits 17-48 of the IPv6 packet - which when converted, equals the 32 bit IPv4 destination. While 6in4 is statically configured IPv4 source and destination IP addresses on the Tunnel (gre) interface. In Cisco world the config comes down to 'tunnel mode ipv6ip' vs 'tunnel mode ipv6ip 6to4' and a few other lines of config. Of course there are a lot more details then that searchable via google. Thanks for pointing out my mistake - it helped me learn some more! Later, Kenny From paul4004 at gmail.com Tue Jun 28 15:24:59 2011 From: paul4004 at gmail.com (PC) Date: Tue, 28 Jun 2011 14:24:59 -0600 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: I have found most/all modern 3g networks can achieve optimal download speed within their latency limitations (<200ms domestic end-to-end is normal for most today) when combined with a modern operating system that does automatic TCP receive window adjustments based on per-flow characteristics. I never had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit without issue from the new Verizon LTE network. (Windows XP is not modern). As for VSAT, most every vsat equipment manufacturer has TCP acceleration/proxy support built into the satellite modem. They basically forge acks at the hub site to buffer data from the server, then deliver it it to the remote end in a continuous flow. Many also have protocol optimizations for some of the more "chatty" protocols. If you use it, your 10 megabit should be achievable for typical HTTP/FTP consumer internet activities, and it's surprisingly fast. I've sustained 6 without issue on VSAT, only limited by bandwidth available, doing a simple SCP file transfer. Of course, none of this is to the scale of transatlantic gigabit transfers with a single flow... On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne wrote: > On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > wrote: > > > > > >> -----Original Message----- > >> From: Cameron Byrne [mailto:cb.list6 at gmail.com] > >> Sent: 28 June 2011 16:53 > >> To: Leigh Porter > >> Cc: Andreas Ott; Eugen Leitl; williamejsalt at googlemail.com; NANOG list > >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > >> (+3) > >> In the 3G world, i have had good results overcoming longish RTT by > >> using the Hybla TCP algorithm http://hybla.deis.unibo.it/ > >> > >> I am hoping it gets more default traction, especially in wireless > >> where the radio link is a pretty big latency source > >> > >> Cameron > > > > How do you implement this for lots of clients and servers that have out > of the box implementations? The FastSoft box is a TCP man-in-the-middle box > that essentially implements the FAST TCP algorithm without either end having > to worry about it. > > > > You don't, the full benefits only come with a Linux kernel patch. The > good news is that it only has to be implemented on the client end. > > > I have also used home-fudged TCP proxies with some success. > > > > Some 3G/wireless/VSAT vendors implement their own TCP modification stacks > but they usually only fiddle with window sizes and such. > > > > That's why i said i hope it catches on as default :) If Android > implemented Hybla, i think it would be a great improvement for user > experience. Nobody likes the middleboxes that proxy TCP.... they cost > money, don't scale well, and are generally fragile. Hybla is not a > solution for the OPs issue, just a solution for high RTT links where > the client can do Hybla. It an evolutionary step that i think would > make a great fit in smartphones like Android. > > Cameron > > -- > > Leigh > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > From cb.list6 at gmail.com Tue Jun 28 15:35:16 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 28 Jun 2011 13:35:16 -0700 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Tue, Jun 28, 2011 at 1:24 PM, PC wrote: > I have found most/all modern 3g networks can achieve optimal download speed > within their latency limitations (<200ms domestic end-to-end is normal for > most today) when combined with a modern operating system that does automatic > TCP receive window adjustments based on per-flow characteristics.? I never > had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit > without issue from the new Verizon LTE network.? (Windows XP is not modern). > AFAIK, Verizon and all the other 4 largest mobile networks in the USA have transparent TCP proxies in place. My point was that if end-hosts had Hybla or something similar, these proxies can be removed providing a better end-to-end solution. Cameron > As for VSAT, most every vsat equipment manufacturer has TCP > acceleration/proxy support built into the satellite modem.? They basically > forge acks at the hub site to buffer data from the server, then deliver it > it to the remote end in a continuous flow.? Many also have protocol > optimizations for some of the more "chatty" protocols.? If you use it, your > 10 megabit should be achievable for typical HTTP/FTP consumer internet > activities, and it's surprisingly fast.? I've sustained 6 without issue on > VSAT, only limited by bandwidth available, doing a simple SCP file transfer. > > Of course, none of this is to the scale of transatlantic gigabit transfers > with a single flow... > > > On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne wrote: >> >> On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter >> wrote: >> > >> > >> >> -----Original Message----- >> >> From: Cameron Byrne [mailto:cb.list6 at gmail.com] >> >> Sent: 28 June 2011 16:53 >> >> To: Leigh Porter >> >> Cc: Andreas Ott; Eugen Leitl; williamejsalt at googlemail.com; NANOG list >> >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 >> >> (+3) >> >> In the 3G world, i have had good results overcoming longish RTT by >> >> using the Hybla TCP algorithm ?http://hybla.deis.unibo.it/ >> >> >> >> I am hoping it gets more default traction, especially in wireless >> >> where the radio link is a pretty big latency source >> >> >> >> Cameron >> > >> > How do you implement this for lots of clients and servers that have out >> > of the box implementations? The FastSoft box is a TCP man-in-the-middle box >> > that essentially implements the FAST TCP algorithm without either end having >> > to worry about it. >> > >> >> You don't, the full benefits only come with a Linux kernel patch. ?The >> good news is that it only has to be implemented on the client end. >> >> > I have also used home-fudged TCP proxies with some success. >> > >> > Some 3G/wireless/VSAT vendors implement their own TCP modification >> > stacks but they usually only fiddle with window sizes and such. >> > >> >> That's why i said i hope it catches on as default :) ?If Android >> implemented Hybla, i think it would be a great improvement for user >> experience. ?Nobody likes the middleboxes that proxy TCP.... they cost >> money, don't scale well, and are generally fragile. ?Hybla is not a >> solution for the OPs issue, just a solution for high RTT links where >> the client can do Hybla. ?It an evolutionary step that i think would >> make a great fit in smartphones like Android. >> >> Cameron >> > -- >> > Leigh >> > >> > >> > ______________________________________________________________________ >> > This email has been scanned by the MessageLabs Email Security System. >> > For more information please visit http://www.messagelabs.com/email >> > ______________________________________________________________________ >> > >> > > From marcus at grmpf.org Tue Jun 28 16:30:19 2011 From: marcus at grmpf.org (Marcus Stoegbauer) Date: Tue, 28 Jun 2011 23:30:19 +0200 Subject: DENOG 3 - Call for Participation and Papers Message-ID: <4E0A47EB.5060808@grmpf.org> DENOG 3 - Call for Participation and Papers The third meeting of the German Network Operators Group (DENOG) will be held in Frankfurt, Germany on the 20th of October 2011. We are pleased to hereby invite applications for presentations or lightning talks to be held at this event. General Information =================== DENOG is a community for professionals within Germany who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about DENOG (in German) can be found at http://www.denog.de/ Information about the meeting will be published at http://www.denog.de/meetings/ Meeting Countdown ================= What When ------------------------------------------------------ Publication of Call for Papers June 28th, 2011 Deadline for all submissions August 22th, 2011 Publication of final programme September 3rd, 2011 Deadline for receipt of final slides October 13th, 2011 Meeting Day October 20th, 2011 Topics for Presentations/Talks ============================== The day will be divided into several sessions. The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 10 to 30 minutes. However proposals whose subject fall outside of the topics below are also welcome; please do not hesitate to submit them. Lightning Talks --------------- In addition to the topics mentioned below we will reserve slots for lightning talks, which consist of a few slides and will not last longer than 5 minutes. Lightning talks can be submitted until October 13th, with the deadline for submission of the corresponding slides being October 19th. Topic #1: Power Efficiency in Networks --------------------------------------- For operators of networks and data centres of any size power efficiency has become more important. Servers and network gear with high power consumption are expensive because of high operating and cooling power costs; also in many places supplying more power into the location is no longer possible. How are you dealing with power problems in your environment? How do you efficiently cool a rack/a room/a datacenter? Can a migration to VoIP help you save power? Topic #2: Social Networks, Cloud Services and Information Security ------------------------------------------------------------------ Social Networks are an essential working tool for networkers and cloud services are also becoming increasingly popular. The security of your information and data in these networks is a crucial aspect which we want to discuss in this session. Topic #3: Peering ------------------ Everything about your peering experience. Why are you doing it? How are you doing it? Have you written any useful tools which others might find interesting? Topic #4: ISP BOF ----------------- "All things ISP". From Network/SLA Management (for or against it), abuse handling and log systems to data centre layout and planning (including power and cooling), everything that is interesting to you as an ISP can be presented or discussed within this topic. Language of Slides and Talks ============================ To appeal to an international audience we ask you to produce your slides in English, but the spoken language of the presentation itself can be either German or English. Submission Guidelines ===================== All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request that you provide the following information as plain text or PDF format to : * the name of the presenter (and if applicable your affiliation) * a working email address * the name and number of the topic which will contain the presentation * the title of the presentation * its expected length (in minutes) * the preferred spoken language for the presentation * a short abstract of the presentation (not more than 200 words) We also welcome suggestions for specific presentations which you feel would be valuable to the DENOG community. Please be aware that your presentation will be published on the DENOG website after the event. From deric.kwok2000 at gmail.com Tue Jun 28 20:15:20 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Tue, 28 Jun 2011 21:15:20 -0400 Subject: website in ipv6 In-Reply-To: References: <20110628000213.C2159113B6DB@drugs.dv.isc.org> Message-ID: Thank you all Two questions: If I get the HE as upstream to advertsie our ipv6, 1/ Do we still have www.tunnelbroker.net as tunneling connection? 2/ All the internet users can access our ipv6 website? Thank you On Tue, Jun 28, 2011 at 2:09 PM, Kenny Sallee wrote: >> >> > > >> > I did this by creating a 6to4 tunnel to a relay provided by >> >> 6in4, not 6to4. ?While HE do operate 6to4 relays, the brokered tunnel >> service is 6in4. >> > > A very important distinction I didn't have clear in my head. ?To regurgitate > some reading I just completed: both methods use v6 in v4 tunneling using ip > proto 41 in the IPv4 protocol field. ?However, 6to4 derives the IPv4 tunnel > destination of an IPv6 packet based on bits 17-48 of the IPv6 packet - which > when converted, equals the 32 bit IPv4 destination. ?While 6in4 is > statically configured IPv4 source and destination IP addresses on the Tunnel > (gre) interface. ?In Cisco world the config comes down to 'tunnel mode > ipv6ip' vs 'tunnel mode ipv6ip 6to4' and a few other lines of config. > Of course there are a lot more details then that searchable via google. > ?Thanks for pointing out my mistake - it helped me learn some more! ?Later, > Kenny From marka at isc.org Tue Jun 28 20:44:38 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 29 Jun 2011 11:44:38 +1000 Subject: website in ipv6 In-Reply-To: Your message of "Tue, 28 Jun 2011 21:15:20 -0400." References: <20110628000213.C2159113B6DB@drugs.dv.isc.org> Message-ID: <20110629014438.7C1BD1146355@drugs.dv.isc.org> In message , Deric Kwok writ es: > Thank you all > Two questions: > > If I get the HE as upstream to advertsie our ipv6, > > 1/ Do we still have www.tunnelbroker.net as tunneling connection? > > 2/ All the internet users can access our ipv6 website? > > Thank you These are better asked to HE. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog.20110127 at jason.roysdon.net Wed Jun 29 00:03:40 2011 From: nanog.20110127 at jason.roysdon.net (Jason Roysdon) Date: Tue, 28 Jun 2011 22:03:40 -0700 Subject: website in ipv6 In-Reply-To: References: <20110628000213.C2159113B6DB@drugs.dv.isc.org> Message-ID: <4E0AB22C.6020407@jason.roysdon.net> Derik, 1. Yes, you still use tunnelbroker.net if you wish you your own IPv6 PI space tunneled. HE does require you to have an ASN as well. With this you can multihome up to 5 of their PoPs. Find more info at their site: http://tunnelbroker.net/ However, they will give you up to 5 tunnels, each with a /64 and optional /48 allocated from their address space. However as this is allocated from their address space, you cannot multihome with it. They also do have a premium service you can purchase for IPv6 transit as well: http://www.reuters.com/article/2011/06/06/idUS130127+06-Jun-2011+BW20110606 Also they will sell you native IPv6 with IPv4 service as well. You provide the circuit to them. http://he.net/ip_transit.html 2. If you have transit only with HE, all IPv6-connected Internet users can access you with the except of those single-homed to Cogent or Level 3. Both Cogent and Level 3 refuse to route any IPv6 traffic destined to HE. Having said that, Hurricane Electric has the most IPv6 peers at present (more than 3 times the amount of Cogent and Level 3): http://bgp.he.net/AS6939 I'm using HE for multihomed transit using my PI /44 and ASN (AS19621). I'm waiting while AT&T and Verizon try to upgrade their PoPs (AT&T in San Jose, Verizon in Sacramento) to provide me transit on my existing enterprise IPv4 circuits. I'll continue to use HE as backup transit even once I get IPv6 connectivity to either or both of the telcos. The nice thing is that you can get your feet wet with HE for free and no commitment and get started now while the giants still sleep. Plus, who knows, HE may remain an IPv6 giant as others grow up, and perhaps this will raise their IPv4 status to that of coveted Tier 1. Maybe IPv4 transmit won't matter in 10 years, and they'll just stay the top IPv6 dog. Jason Roysdon On 06/28/2011 06:15 PM, Deric Kwok wrote: > Thank you all > Two questions: > > If I get the HE as upstream to advertsie our ipv6, > > 1/ Do we still have www.tunnelbroker.net as tunneling connection? > > 2/ All the internet users can access our ipv6 website? > > Thank you > > On Tue, Jun 28, 2011 at 2:09 PM, Kenny Sallee wrote: >>> >>>>> >>>> I did this by creating a 6to4 tunnel to a relay provided by >>> >>> 6in4, not 6to4. While HE do operate 6to4 relays, the brokered tunnel >>> service is 6in4. >>> >> >> A very important distinction I didn't have clear in my head. To regurgitate >> some reading I just completed: both methods use v6 in v4 tunneling using ip >> proto 41 in the IPv4 protocol field. However, 6to4 derives the IPv4 tunnel >> destination of an IPv6 packet based on bits 17-48 of the IPv6 packet - which >> when converted, equals the 32 bit IPv4 destination. While 6in4 is >> statically configured IPv4 source and destination IP addresses on the Tunnel >> (gre) interface. In Cisco world the config comes down to 'tunnel mode >> ipv6ip' vs 'tunnel mode ipv6ip 6to4' and a few other lines of config. >> Of course there are a lot more details then that searchable via google. >> Thanks for pointing out my mistake - it helped me learn some more! Later, >> Kenny > > From swmike at swm.pp.se Wed Jun 29 00:22:24 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 29 Jun 2011 07:22:24 +0200 (CEST) Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Tue, 28 Jun 2011, Cameron Byrne wrote: > My point was that if end-hosts had Hybla or something similar, these > proxies can be removed providing a better end-to-end solution. Well, then you run into the nice problem of the RNCs only having 400 kilobytes of buffers per session and will drop packets if they receive more packets than that, or sometimes even just because they receive a burst of a few tens of packets at GigE linerate (because the customer with large TCP window size is talking to a GigE connected server). The recommended "solution" from the vendor was to tune the client to a smaller TCP window size so that their RNC wouldn't get such a large burst. *sigh* -- Mikael Abrahamsson email: swmike at swm.pp.se From hank at efes.iucc.ac.il Wed Jun 29 02:38:10 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 29 Jun 2011 10:38:10 +0300 (IDT) Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Tue, 28 Jun 2011, PC wrote: > As for VSAT, most every vsat equipment manufacturer has TCP > acceleration/proxy support built into the satellite modem. They basically > forge acks at the hub site to buffer data from the server, then deliver it > it to the remote end in a continuous flow. Many also have protocol > optimizations for some of the more "chatty" protocols. If you use it, your > 10 megabit should be achievable for typical HTTP/FTP consumer internet > activities, and it's surprisingly fast. I've sustained 6 without issue on > VSAT, only limited by bandwidth available, doing a simple SCP file transfer. This reminds me of the work I did in 1999 on getting T3 sat links to fully utilize the full 45Mb/sec: http://www.interall.co.il/internet2-takes-to-the-air.pdf -Hank From dot at dotat.at Wed Jun 29 06:18:08 2011 From: dot at dotat.at (Tony Finch) Date: Wed, 29 Jun 2011 12:18:08 +0100 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: Mikael Abrahamsson wrote: > > Well, then you run into the nice problem of the RNCs only having 400 kilobytes > of buffers per session and will drop packets if they receive more packets than > that, or sometimes even just because they receive a burst of a few tens of > packets at GigE linerate (because the customer with large TCP window size is > talking to a GigE connected server). Excessively large buffers are a problem because they break TCP's RTT measurement. Also TCP cannot measure the available bandwidth without packet loss. Tony. -- f.anthony.n.finch http://dotat.at/ Biscay: Northerly or northwesterly, but northeasterly in far southwest 4 or 5, occasionally 6 in east and far southwest. Slight or moderate. Mainly fair. Good. From savyasachi.choudhary at gmail.com Wed Jun 29 06:17:47 2011 From: savyasachi.choudhary at gmail.com (Savyasachi Choudhary) Date: Wed, 29 Jun 2011 16:47:47 +0530 Subject: NANOG Digest, Vol 41, Issue 165 In-Reply-To: References: Message-ID: Hi, There is a command to limit the number of redistributed route. redistribute maximum-prefix Say, if ISIS imports routes, it will redistribute only the number of configured routes in 'redistribute maximum-prefix . My question is: say I make the number as 10. So initially ISIS will redistribute inly 10 routes recvd from say BGP, and drop other packets. But later, if I change the number to 20, how should it work? How will BGP send other routes? ' I think Huawei doed not have this command, but Cisco has Regards, Savyasachi 7676077879 On Wed, Jun 29, 2011 at 3:00 AM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. RE: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (Leigh Porter) > 2. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (Cameron Byrne) > 3. Re: Announcing Project BISMark: ISP Performance Measurements > from Home Routers (Daniel Espejel) > 4. Re: website in ipv6 (Kenny Sallee) > 5. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (PC) > 6. Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) (Cameron Byrne) > 7. DENOG 3 - Call for Participation and Papers (Marcus Stoegbauer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jun 2011 16:11:23 +0000 > From: Leigh Porter > Subject: RE: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Cameron Byrne > Cc: "williamejsalt at googlemail.com" , > NANOG list > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > > > > -----Original Message----- > > From: Cameron Byrne [mailto:cb.list6 at gmail.com] > > Sent: 28 June 2011 16:53 > > To: Leigh Porter > > Cc: Andreas Ott; Eugen Leitl; williamejsalt at googlemail.com; NANOG list > > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > > (+3) > > In the 3G world, i have had good results overcoming longish RTT by > > using the Hybla TCP algorithm http://hybla.deis.unibo.it/ > > > > I am hoping it gets more default traction, especially in wireless > > where the radio link is a pretty big latency source > > > > Cameron > > How do you implement this for lots of clients and servers that have out of > the box implementations? The FastSoft box is a TCP man-in-the-middle box > that essentially implements the FAST TCP algorithm without either end having > to worry about it. > > I have also used home-fudged TCP proxies with some success. > > Some 3G/wireless/VSAT vendors implement their own TCP modification stacks > but they usually only fiddle with window sizes and such. > > -- > Leigh > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > > ------------------------------ > > Message: 2 > Date: Tue, 28 Jun 2011 09:16:13 -0700 > From: Cameron Byrne > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Leigh Porter > Cc: "williamejsalt at googlemail.com" , > NANOG list > Message-ID: > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > wrote: > > > > > >> -----Original Message----- > >> From: Cameron Byrne [mailto:cb.list6 at gmail.com] > >> Sent: 28 June 2011 16:53 > >> To: Leigh Porter > >> Cc: Andreas Ott; Eugen Leitl; williamejsalt at googlemail.com; NANOG list > >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > >> (+3) > >> In the 3G world, i have had good results overcoming longish RTT by > >> using the Hybla TCP algorithm ?http://hybla.deis.unibo.it/ > >> > >> I am hoping it gets more default traction, especially in wireless > >> where the radio link is a pretty big latency source > >> > >> Cameron > > > > How do you implement this for lots of clients and servers that have out > of the box implementations? The FastSoft box is a TCP man-in-the-middle box > that essentially implements the FAST TCP algorithm without either end having > to worry about it. > > > > You don't, the full benefits only come with a Linux kernel patch. The > good news is that it only has to be implemented on the client end. > > > I have also used home-fudged TCP proxies with some success. > > > > Some 3G/wireless/VSAT vendors implement their own TCP modification stacks > but they usually only fiddle with window sizes and such. > > > > That's why i said i hope it catches on as default :) If Android > implemented Hybla, i think it would be a great improvement for user > experience. Nobody likes the middleboxes that proxy TCP.... they cost > money, don't scale well, and are generally fragile. Hybla is not a > solution for the OPs issue, just a solution for high RTT links where > the client can do Hybla. It an evolutionary step that i think would > make a great fit in smartphones like Android. > > Cameron > > -- > > Leigh > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 28 Jun 2011 12:50:29 -0500 > From: Daniel Espejel > Subject: Re: Announcing Project BISMark: ISP Performance Measurements > from Home Routers > To: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > Hi. > > I would like to participate in the Bismark project, for now only as a > poller-kind user. > While checking the router n600 specifications datasheet it seems that this > device is IPv6 compliant in some degree (because of the IPv6 Ready Logo > included at the bottom of the sheet). > > I'm really interested in performing some test about that issue; but I'm > also > worried about privacy/confidentiality and navigation speed features. > > It's likely all those whom participate may find related information about > this topics in the project website and related mailing list. > > Well, I'm waiting to get my hands dirty on N600 and this way trying to > solve > some of my doubts (or catch a lot more). > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 28 Jun 2011 11:30:07 +0100 > > From: Alex Brooks > > Subject: Re: Announcing Project BISMark: ISP Performance Measurements > > from Home Routers > > To: nanog > > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Hello, > > > > On Mon, Jun 27, 2011 at 9:48 PM, Nick Feamster > > wrote: > > > > > > Hello NANOG, > > > > > > We've launched Project BISMark, a project that performs active > > performance measurements of upload and download throughput, latency, etc. > > from OpenWRT-based routers running inside of homes. ? We have tested our > > OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping out > > NetGear routers with the BISMark firmware to anyone who is interested. > > > > > > > -- > *Daniel Espejel Perez > * > > > ------------------------------ > > Message: 4 > Date: Tue, 28 Jun 2011 11:09:04 -0700 > From: Kenny Sallee > Subject: Re: website in ipv6 > To: Mark Andrews > Cc: nanog list > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > > > > > > > > > > > I did this by creating a 6to4 tunnel to a relay provided by > > > > 6in4, not 6to4. While HE do operate 6to4 relays, the brokered tunnel > > service is 6in4. > > > > > A very important distinction I didn't have clear in my head. To > regurgitate > some reading I just completed: both methods use v6 in v4 tunneling using ip > proto 41 in the IPv4 protocol field. However, 6to4 derives the IPv4 tunnel > destination of an IPv6 packet based on bits 17-48 of the IPv6 packet - > which > when converted, equals the 32 bit IPv4 destination. While 6in4 is > statically configured IPv4 source and destination IP addresses on the > Tunnel > (gre) interface. In Cisco world the config comes down to 'tunnel mode > ipv6ip' vs 'tunnel mode ipv6ip 6to4' and a few other lines of config. > > Of course there are a lot more details then that searchable via google. > Thanks for pointing out my mistake - it helped me learn some more! Later, > Kenny > > > ------------------------------ > > Message: 5 > Date: Tue, 28 Jun 2011 14:24:59 -0600 > From: PC > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: Cameron Byrne > Cc: "williamejsalt at googlemail.com" , > NANOG list > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > I have found most/all modern 3g networks can achieve optimal download speed > within their latency limitations (<200ms domestic end-to-end is normal for > most today) when combined with a modern operating system that does > automatic > TCP receive window adjustments based on per-flow characteristics. I never > had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit > without issue from the new Verizon LTE network. (Windows XP is not > modern). > > As for VSAT, most every vsat equipment manufacturer has TCP > acceleration/proxy support built into the satellite modem. They basically > forge acks at the hub site to buffer data from the server, then deliver it > it to the remote end in a continuous flow. Many also have protocol > optimizations for some of the more "chatty" protocols. If you use it, your > 10 megabit should be achievable for typical HTTP/FTP consumer internet > activities, and it's surprisingly fast. I've sustained 6 without issue on > VSAT, only limited by bandwidth available, doing a simple SCP file > transfer. > > Of course, none of this is to the scale of transatlantic gigabit transfers > with a single flow... > > > On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne > wrote: > > > On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > > wrote: > > > > > > > > >> -----Original Message----- > > >> From: Cameron Byrne [mailto:cb.list6 at gmail.com] > > >> Sent: 28 June 2011 16:53 > > >> To: Leigh Porter > > >> Cc: Andreas Ott; Eugen Leitl; williamejsalt at googlemail.com; NANOG > list > > >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > > >> (+3) > > >> In the 3G world, i have had good results overcoming longish RTT by > > >> using the Hybla TCP algorithm http://hybla.deis.unibo.it/ > > >> > > >> I am hoping it gets more default traction, especially in wireless > > >> where the radio link is a pretty big latency source > > >> > > >> Cameron > > > > > > How do you implement this for lots of clients and servers that have out > > of the box implementations? The FastSoft box is a TCP man-in-the-middle > box > > that essentially implements the FAST TCP algorithm without either end > having > > to worry about it. > > > > > > > You don't, the full benefits only come with a Linux kernel patch. The > > good news is that it only has to be implemented on the client end. > > > > > I have also used home-fudged TCP proxies with some success. > > > > > > Some 3G/wireless/VSAT vendors implement their own TCP modification > stacks > > but they usually only fiddle with window sizes and such. > > > > > > > That's why i said i hope it catches on as default :) If Android > > implemented Hybla, i think it would be a great improvement for user > > experience. Nobody likes the middleboxes that proxy TCP.... they cost > > money, don't scale well, and are generally fragile. Hybla is not a > > solution for the OPs issue, just a solution for high RTT links where > > the client can do Hybla. It an evolutionary step that i think would > > make a great fit in smartphones like Android. > > > > Cameron > > > -- > > > Leigh > > > > > > > > > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email Security System. > > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > > > > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 28 Jun 2011 13:35:16 -0700 > From: Cameron Byrne > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 > (+3) > To: PC > Cc: "williamejsalt at googlemail.com" , > NANOG list > Message-ID: > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Jun 28, 2011 at 1:24 PM, PC wrote: > > I have found most/all modern 3g networks can achieve optimal download > speed > > within their latency limitations (<200ms domestic end-to-end is normal > for > > most today) when combined with a modern operating system that does > automatic > > TCP receive window adjustments based on per-flow characteristics.? I > never > > had a problem getting ~2 megabit from EVDO-revA, and can get ~20 megabit > > without issue from the new Verizon LTE network.? (Windows XP is not > modern). > > > > AFAIK, Verizon and all the other 4 largest mobile networks in the USA > have transparent TCP proxies in place. > > My point was that if end-hosts had Hybla or something similar, these > proxies can be removed providing a better end-to-end solution. > > Cameron > > > As for VSAT, most every vsat equipment manufacturer has TCP > > acceleration/proxy support built into the satellite modem.? They > basically > > forge acks at the hub site to buffer data from the server, then deliver > it > > it to the remote end in a continuous flow.? Many also have protocol > > optimizations for some of the more "chatty" protocols.? If you use it, > your > > 10 megabit should be achievable for typical HTTP/FTP consumer internet > > activities, and it's surprisingly fast.? I've sustained 6 without issue > on > > VSAT, only limited by bandwidth available, doing a simple SCP file > transfer. > > > > Of course, none of this is to the scale of transatlantic gigabit > transfers > > with a single flow... > > > > > > On Tue, Jun 28, 2011 at 10:16 AM, Cameron Byrne > wrote: > >> > >> On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter > >> wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: Cameron Byrne [mailto:cb.list6 at gmail.com] > >> >> Sent: 28 June 2011 16:53 > >> >> To: Leigh Porter > >> >> Cc: Andreas Ott; Eugen Leitl; williamejsalt at googlemail.com; NANOG > list > >> >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 > RC2 > >> >> (+3) > >> >> In the 3G world, i have had good results overcoming longish RTT by > >> >> using the Hybla TCP algorithm ?http://hybla.deis.unibo.it/ > >> >> > >> >> I am hoping it gets more default traction, especially in wireless > >> >> where the radio link is a pretty big latency source > >> >> > >> >> Cameron > >> > > >> > How do you implement this for lots of clients and servers that have > out > >> > of the box implementations? The FastSoft box is a TCP > man-in-the-middle box > >> > that essentially implements the FAST TCP algorithm without either end > having > >> > to worry about it. > >> > > >> > >> You don't, the full benefits only come with a Linux kernel patch. ?The > >> good news is that it only has to be implemented on the client end. > >> > >> > I have also used home-fudged TCP proxies with some success. > >> > > >> > Some 3G/wireless/VSAT vendors implement their own TCP modification > >> > stacks but they usually only fiddle with window sizes and such. > >> > > >> > >> That's why i said i hope it catches on as default :) ?If Android > >> implemented Hybla, i think it would be a great improvement for user > >> experience. ?Nobody likes the middleboxes that proxy TCP.... they cost > >> money, don't scale well, and are generally fragile. ?Hybla is not a > >> solution for the OPs issue, just a solution for high RTT links where > >> the client can do Hybla. ?It an evolutionary step that i think would > >> make a great fit in smartphones like Android. > >> > >> Cameron > >> > -- > >> > Leigh > >> > > >> > > >> > ______________________________________________________________________ > >> > This email has been scanned by the MessageLabs Email Security System. > >> > For more information please visit http://www.messagelabs.com/email > >> > ______________________________________________________________________ > >> > > >> > > > > > > > > ------------------------------ > > Message: 7 > Date: Tue, 28 Jun 2011 23:30:19 +0200 > From: Marcus Stoegbauer > Subject: DENOG 3 - Call for Participation and Papers > To: nanog at nanog.org > Message-ID: <4E0A47EB.5060808 at grmpf.org> > Content-Type: text/plain; charset=UTF-8 > > DENOG 3 - Call for Participation and Papers > > The third meeting of the German Network Operators Group (DENOG) will be > held in Frankfurt, Germany on the 20th of October 2011. We are pleased > to hereby invite applications for presentations or lightning talks to be > held at this event. > > General Information > =================== > DENOG is a community for professionals within Germany who are operating, > designing or researching the Internet. It provides a technical forum > where those working on, with and for the Internet can come together to > solve problems with every aspect of their (net)work. > > The meeting is designed to provide an opportunity for the exchange of > information among network operators, engineers, researchers and other > professionals close to the network community. > > More information about DENOG (in German) can be found at > http://www.denog.de/ > Information about the meeting will be published at > http://www.denog.de/meetings/ > > > Meeting Countdown > ================= > What When > ------------------------------------------------------ > Publication of Call for Papers June 28th, 2011 > Deadline for all submissions August 22th, 2011 > Publication of final programme September 3rd, 2011 > Deadline for receipt of final slides October 13th, 2011 > Meeting Day October 20th, 2011 > > Topics for Presentations/Talks > ============================== > The day will be divided into several sessions. The number and length of > presentations per session is not fixed, although due to time constraints > we would prefer the length of the presentations to be between 10 to 30 > minutes. > > However proposals whose subject fall outside of the topics below are > also welcome; please do not hesitate to submit them. > > Lightning Talks > --------------- > In addition to the topics mentioned below we will reserve slots for > lightning talks, which consist of a few slides and will not last longer > than 5 minutes. Lightning talks can be submitted until October 13th, > with the deadline for submission of the corresponding slides being > October 19th. > > Topic #1: Power Efficiency in Networks > --------------------------------------- > For operators of networks and data centres of any size power efficiency > has become more important. Servers and network gear with high power > consumption are expensive because of high operating and cooling power > costs; also in many places supplying more power into the location is no > longer possible. How are you dealing with power problems in your > environment? How do you efficiently cool a rack/a room/a datacenter? Can > a migration to VoIP help you save power? > > Topic #2: Social Networks, Cloud Services and Information Security > ------------------------------------------------------------------ > Social Networks are an essential working tool for networkers and cloud > services are also becoming increasingly popular. The security of your > information and data in these networks is a crucial aspect which we want > to discuss in this session. > > Topic #3: Peering > ------------------ > Everything about your peering experience. Why are you doing it? How are > you doing it? Have you written any useful tools which others might find > interesting? > > Topic #4: ISP BOF > ----------------- > "All things ISP". From Network/SLA Management (for or against it), abuse > handling and log systems to data centre layout and planning (including > power and cooling), everything that is interesting to you as an ISP can > be presented or discussed within this topic. > > Language of Slides and Talks > ============================ > To appeal to an international audience we ask you to produce your slides > in English, but the spoken language of the presentation itself can be > either German or English. > > Submission Guidelines > ===================== > All submissions must have a strong technical bias and must not be solely > promotional for your employer. > > Please remember that your presentations should be suitable for a target > audience of technicians from varied backgrounds, working for companies > whose sizes may vary considerably. > > To submit a proposal for a presentation, we request that you provide the > following information as plain text or PDF format to : > > * the name of the presenter (and if applicable your affiliation) > * a working email address > * the name and number of the topic which will contain the presentation > * the title of the presentation > * its expected length (in minutes) > * the preferred spoken language for the presentation > * a short abstract of the presentation (not more than 200 words) > > We also welcome suggestions for specific presentations which you feel > would be valuable to the DENOG community. > > Please be aware that your presentation will be published on the DENOG > website after the event. > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 41, Issue 165 > ************************************** > From nick at foobar.org Wed Jun 29 06:28:45 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 29 Jun 2011 12:28:45 +0100 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: <4E0B0C6D.2010709@foobar.org> On 29/06/2011 12:18, Tony Finch wrote: > Also TCP cannot measure the available bandwidth without packet loss. ? TCP stacks will figure out available bandwidth just fine by measuring return acks - there's no need to drop any packets. Nick From swmike at swm.pp.se Wed Jun 29 06:56:34 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 29 Jun 2011 13:56:34 +0200 (CEST) Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Wed, 29 Jun 2011, Tony Finch wrote: > Excessively large buffers are a problem because they break TCP's RTT > measurement. Also TCP cannot measure the available bandwidth without > packet loss. Well, actually it can. ECN. And regarding RTT measurement, since mobile network vary delay a lot, that's not going to work well anyway. -- Mikael Abrahamsson email: swmike at swm.pp.se From malayter at gmail.com Wed Jun 29 07:59:49 2011 From: malayter at gmail.com (Ryan Malayter) Date: Wed, 29 Jun 2011 05:59:49 -0700 (PDT) Subject: Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Jun 28, 3:35?pm, Cameron Byrne wrote: > > AFAIK, Verizon and all the other 4 largest mobile networks in the USA > have transparent TCP proxies in place. Do you have a reference for that information? Neither AT&T nor Sprint seem to have transparent *HTTP* proxies according to http://www.lagado.com/tools/cache-test. I would have thought that would be the first and most important optimization a mobile carrier could make. I used to see "mobile-optimized" images and HTTP compression for sites that weren't using it at the origin on Verizon's 3G network a few years ago, so Verizon clearly had some form of HTTP proxy in effect. Aside from that, how would one check for a transparent *TCP* proxy? By looking at IP or TCP option fingerprints at the receiver? Or comparing TCP ACK RTT versus ICMP ping RTT? From smb at cs.columbia.edu Wed Jun 29 09:25:28 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 29 Jun 2011 10:25:28 -0400 Subject: Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: <1CEECD38-9E60-4946-9F91-8CC483B6DF58@cs.columbia.edu> On Jun 29, 2011, at 8:59 49AM, Ryan Malayter wrote: > > > On Jun 28, 3:35 pm, Cameron Byrne wrote: > >> >> AFAIK, Verizon and all the other 4 largest mobile networks in the USA >> have transparent TCP proxies in place. > > Do you have a reference for that information? Neither AT&T nor Sprint > seem to have transparent *HTTP* proxies according to > http://www.lagado.com/tools/cache-test. I would have thought that > would be the first and most important optimization a mobile carrier > could make. I used to see "mobile-optimized" images and HTTP > compression for sites that weren't using it at the origin on Verizon's > 3G network a few years ago, so Verizon clearly had some form of HTTP > proxy in effect. > > Aside from that, how would one check for a transparent *TCP* proxy? By > looking at IP or TCP option fingerprints at the receiver? Or comparing > TCP ACK RTT versus ICMP ping RTT? > > Or see what bandwidth is like if you use IPsec or the like. --Steve Bellovin, https://www.cs.columbia.edu/~smb From cb.list6 at gmail.com Wed Jun 29 09:34:26 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 29 Jun 2011 07:34:26 -0700 Subject: Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Jun 29, 2011 6:00 AM, "Ryan Malayter" wrote: > > > > On Jun 28, 3:35 pm, Cameron Byrne wrote: > > > > > AFAIK, Verizon and all the other 4 largest mobile networks in the USA > > have transparent TCP proxies in place. > > Do you have a reference for that information? Neither AT&T nor Sprint No. > seem to have transparent *HTTP* proxies according to > http://www.lagado.com/tools/cache-test. I would have thought that > would be the first and most important optimization a mobile carrier > could make. I used to see "mobile-optimized" images and HTTP > compression for sites that weren't using it at the origin on Verizon's > 3G network a few years ago, so Verizon clearly had some form of HTTP > proxy in effect. > > Aside from that, how would one check for a transparent *TCP* proxy? By > looking at IP or TCP option fingerprints at the receiver? Or comparing > TCP ACK RTT versus ICMP ping RTT? > I am not familiar with that HTTP proxy test. As I said, they are likely using tcp proxies to get over tcp issues. I assume if you were sniffing both ends you could discover changes in parameters forced by the middle box. Cb From cb.list6 at gmail.com Wed Jun 29 09:34:26 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 29 Jun 2011 07:34:26 -0700 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Jun 28, 2011 10:22 PM, "Mikael Abrahamsson" wrote: > > On Tue, 28 Jun 2011, Cameron Byrne wrote: > >> My point was that if end-hosts had Hybla or something similar, these proxies can be removed providing a better end-to-end solution. > > > Well, then you run into the nice problem of the RNCs only having 400 kilobytes of buffers per session and will drop packets if they receive more packets than that, or sometimes even just because they receive a burst of a few tens of packets at GigE linerate (because the customer with large TCP window size is talking to a GigE connected server). > > The recommended "solution" from the vendor was to tune the client to a smaller TCP window size so that their RNC wouldn't get such a large burst. > > *sigh* > Sounds like a vendor specific issue :( Good tcp vs default tcp will not close the window tight due to some ephemeral loss or delay. The penalties are generally too strong in tcp for the issues of delay and loss in 3g ... this is one of the main selling points for tcp proxies .... but better done with modern tcp on the clients instead of a middle box > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From leigh.porter at ukbroadband.com Wed Jun 29 09:45:12 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 29 Jun 2011 14:45:12 +0000 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: > > > > > > Well, then you run into the nice problem of the RNCs only having 400 > kilobytes of buffers per session and will drop packets if they receive > more > packets than that, or sometimes even just because they receive a burst > of a > few tens of packets at GigE linerate (because the customer with large > TCP > window size is talking to a GigE connected server). > > > > The recommended "solution" from the vendor was to tune the client to > a > smaller TCP window size so that their RNC wouldn't get such a large > burst. > > > > *sigh* > > > > Sounds like a vendor specific issue :( > > Good tcp vs default tcp will not close the window tight due to some > ephemeral loss or delay. The penalties are generally too strong in tcp > for > the issues of delay and loss in 3g ... this is one of the main selling > points for tcp proxies .... but better done with modern tcp on the > clients > instead of a middle box Indeed it does sound like a vendor issue. The network I was running did just fine with the FastSoft proxy boxes. In fact, they were so effective that we almost doubled our TCP throughput overnight! We did not quite get a chance to explore the interaction between the TCP proxies and the algorithms that supposedly fixed TCP in the vendors GGSN (TCP window size fiddling) and the interaction of the new TCP protocol with the 3G base station scheduler, but the results kind of spoke for themselves really. Similarly we have had good results with WiMAX networks. -- Leigh Porter UK Broadband ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From eugen at leitl.org Wed Jun 29 09:58:09 2011 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 29 Jun 2011 16:58:09 +0200 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) Message-ID: <20110629145809.GT26837@leitl.org> ----- Forwarded message from William Salt ----- From: William Salt Date: Wed, 29 Jun 2011 13:16:32 +0100 To: support at pfsense.com Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) Reply-To: support at pfsense.com Hi all, thanks for the input. We have now swapped the cards to em card at both ends, instead of igb at one end, and em at the other. We are now seeing near gig speeds in both directions. Before, we saw very different speeds in each direction. We have now managed to reach around 860-900mbps each way with the following values in our sysctl.conf: kern.ipc.maxsockbuf=20971520 net.inet.tcp.recvbuf_max=20971520 net.inet.tcp.sendbuf_max=20971520 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.sendbuf_inc=524288 However, even though we can reach around the upper threshold of the connection, we are seeing the boxes crash, or tcp performance hit the miximum 860-900mbps then drop, and stick at around 8mbps, until a reboot. I might add that we are running 32bit (i386) RC3 at both ends, with 6gb of ram.(probably alot less in the OS, need to upgrade to x64) When i replicated these settings on two fresh boxes beyong the routers at either end, i saw no performance increase... Regards Will On Tue, Jun 28, 2011 at 3:34 PM, Eugen Leitl wrote: > > ----- Forwarded message from Rhys Rhaven ----- > > From: Rhys Rhaven > Date: Tue, 28 Jun 2011 09:30:06 -0500 > To: nanog at nanog.org > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > Organization: Rhaven Industrys > User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; > rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 > > Obviously not helping if you are trying to tune standard TCP, but I > lament that protocols like Tsunami are not in wider use. > http://tsunami-udp.sourceforge.net/ Short of it, a TCP control channel > takes care of error checking and resends while the data channel is a UDP > stream, specifically built to max out LFNs. > > On 06/28/2011 03:52 AM, Eugen Leitl wrote: > > ----- Forwarded message from William Salt ----- > > > > From: William Salt > > Date: Tue, 28 Jun 2011 08:03:25 +0100 > > To: support at pfsense.com > > Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > > Reply-To: support at pfsense.com > > > > Hi All, > > For the last couple of months i have been pulling my hair out > > trying to solve this problem. > > We have a 1Gbps transatlantic link from the UK to the US, which has > > successfully passed the RFC2544 test. > > > > At either end, we have a media converter, and a supermicro server with an > > intel quad port NIC running pfsense 2 (RC2 at one end RC3 at the other) and > > the IGB driver on the quad port. > > > > We can pass 1gbps either way with UDP. However we are experiencing very > > strange issues with tcp connections. > > > > With window scaling enabled, and a max socket buffer set to 16MB, we see no > > difference. > > Even disabling window scaling and setting the window to 16MB makes no > > difference. > > > > Each TCP connection starts very slowly, and will max out at around 190mbps, > > taking nearly 2 minutes to climb to this speed before *plateauing*. > > > > We have to initiate many (5+) connections to saturate the link with tcp > > connections with iperf. > > > > Real world tests transferring files, max out at 100mbps, using multiple > > connections. > > > > I have followed guides like this: > > http://www.psc.edu/networking/projects/tcptune/#FreeBSD > > > > With no luck, and have tweaked, disabled, and enabled nearly every relevant > > sysctl parameter with no luck. > > > > Can anyone shed some light on this? > > > > I am now doubting the IGB driver, and am looking to swap out the cards as a > > last ditch effort. > > However, we have tried different hardware (L3 switches, media convertes + > > laptops etc), and the symptoms still persist... > > The only constant is freebsd 8.1 - pfsense (or 8.2 for our production > > systems). > > I have tried the freebsd net mailinglist, but im hoping you lot can help me! > > > > Cheers in advance > > Will > > > > ----- End forwarded message ----- > > > ----- End forwarded message ----- > -- > Eugen* Leitl leitl http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > --------------------------------------------------------------------- > To unsubscribe, e-mail: support-unsubscribe at pfsense.com > For additional commands, e-mail: support-help at pfsense.com > > Commercial support available - https://portal.pfsense.org > ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From alex at corp.nac.net Wed Jun 29 13:32:13 2011 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 29 Jun 2011 14:32:13 -0400 Subject: Wacky Weekend: NERC to relax power grid frequency strictures In-Reply-To: <2094456.192.1309105653309.JavaMail.root@benjamin.baylink.com> References: <2094456.192.1309105653309.JavaMail.root@benjamin.baylink.com> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB8020834A63B@EXCHMBX.hq.nac.net> > More to the point, as I note in another reply, you don't want to be *the lineman > down the road with his hands on a "dead" wire*. > > Pretty much the *first paragraph* in NEC 700 (700.6) says this: > > """ > Transfer equipment shall be designed and installed to prevent the inadvertent > interconnection of normal and emergency sources of supply in any operation of > the trans- fer equipment. > """ > > So, if your transfer switch is *physically* capable of connecting your genset to > the incoming power wires, then it violates 700.6, unless you're in a cogen sort > of environment, in which case you're following Article 705, and a whole > different set of rules apply. You didn't keep reading. Or, you don't have the annotated version :) "Transfer equipment and electric power production systems installed to permit operation in parallel with the normal source shall meet the requirements on 700.5" This is from 2008, but I don't recall a change in 2011. From swmike at swm.pp.se Wed Jun 29 15:48:55 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 29 Jun 2011 22:48:55 +0200 (CEST) Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Wed, 29 Jun 2011, Cameron Byrne wrote: > Sounds like a vendor specific issue :( Absolutely, but this is way too typical for these kinds of networks. > Good tcp vs default tcp will not close the window tight due to some > ephemeral loss or delay. The penalties are generally too strong in tcp for > the issues of delay and loss in 3g ... this is one of the main selling > points for tcp proxies .... but better done with modern tcp on the clients > instead of a middle box For what kind of devices? I can get full speed (870 kilobyte/s) on 7.2 HSPA with single TCP stream on a linux box. Are you referring to handsets that get improvement on high latency links? -- Mikael Abrahamsson email: swmike at swm.pp.se From cb.list6 at gmail.com Wed Jun 29 15:53:44 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 29 Jun 2011 13:53:44 -0700 Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) In-Reply-To: References: <20110628085255.GX26837@leitl.org> <20110628082346.I27898@naund.org> Message-ID: On Wed, Jun 29, 2011 at 1:48 PM, Mikael Abrahamsson wrote: > On Wed, 29 Jun 2011, Cameron Byrne wrote: > >> Sounds like a vendor specific issue :( > > Absolutely, but this is way too typical for these kinds of networks. > >> Good tcp vs default tcp will not close the window tight due to some >> ephemeral loss or delay. ?The penalties are generally too strong in tcp >> for >> the issues of delay and loss in 3g ... this is one of the main selling >> points for tcp proxies .... but better done with modern tcp on the clients >> instead of a middle box > > For what kind of devices? I can get full speed (870 kilobyte/s) on 7.2 HSPA > with single TCP stream on a linux box. Are you referring to handsets that > get improvement on high latency links? > Yes. Smartphones on UMTS/HSPA have poor bandwidth-delay product, hence it being common for mobile providers to proxy the TCP to open windows faster. Cameron > -- > Mikael Abrahamsson ? ?email: swmike at swm.pp.se > From member at linkedin.com Thu Jun 30 10:08:57 2011 From: member at linkedin.com (Yaoqing Liu via LinkedIn) Date: Thu, 30 Jun 2011 15:08:57 +0000 (UTC) Subject: Invitation to connect on LinkedIn Message-ID: <1008619756.1096643.1309446537427.JavaMail.app@ela4-bed80.prod> LinkedIn ------------ Yaoqing Liu requested to add you as a connection on LinkedIn: ------------------------------------------ Ted, I'd like to add you to my professional network on LinkedIn. - Yaoqing Accept invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjunqoh-4g/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I1478744924_3/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYPnPgOejgQdPwTd359bQtjnSpDpk9LbP4OcPoNdjgVcPcLrCBxbOYWrSlI/EML_comm_afe/ View invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjunqoh-4g/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I1478744924_3/3dvd38Vd3gTe3sQckALqnpPbOYWrSlI/svi/ ------------------------------------------ DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/-voa23o-gpjunqoh-4g/abq/inv-24/ -- (c) 2011, LinkedIn Corporation From member at linkedin.com Thu Jun 30 10:22:29 2011 From: member at linkedin.com (Yaoqing Liu via LinkedIn) Date: Thu, 30 Jun 2011 15:22:29 +0000 (UTC) Subject: Invitation to connect on LinkedIn Message-ID: <1473690319.1127918.1309447349690.JavaMail.app@ela4-bed78.prod> LinkedIn ------------ Yaoqing Liu requested to add you as a connection on LinkedIn: ------------------------------------------ Ted, I'd like to add you to my professional network on LinkedIn. - Yaoqing Accept invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjv55fb-66/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I1478791561_3/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYPnP4Sdj4VdPwTd359bQtjnSpDpk9LbP4OcPoNdjgVcPcLrCBxbOYWrSlI/EML_comm_afe/ View invitation from Yaoqing Liu http://www.linkedin.com/e/-voa23o-gpjv55fb-66/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I1478791561_3/3dvcjoRcjATe3sQckALqnpPbOYWrSlI/svi/ ------------------------------------------ DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/-voa23o-gpjv55fb-66/abq/inv-24/ -- (c) 2011, LinkedIn Corporation From blake at pfankuch.me Thu Jun 30 10:50:57 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Thu, 30 Jun 2011 15:50:57 +0000 Subject: Firewall Appliance Suggestions Message-ID: Howdy, I am looking for something a little unique in a bit of a tough situation with some sticky requirements. First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). And here is the super fun part! I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. Any Ideas? Thanks! Blake Pfankuch From bhmccie at gmail.com Thu Jun 30 10:56:50 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 30 Jun 2011 10:56:50 -0500 Subject: Firewall Appliance Suggestions In-Reply-To: References: Message-ID: <4E0C9CC2.4060605@gmail.com> CheckPoint -Hammer- "I was a normal American nerd" -Jack Herer On 06/30/2011 10:50 AM, Blake T. Pfankuch wrote: > Howdy, > I am looking for something a little unique in a bit of a tough situation with some sticky requirements. First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). And here is the super fun part! I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. > > Any Ideas? > > Thanks! > > Blake Pfankuch > From jra at baylink.com Thu Jun 30 11:07:01 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 30 Jun 2011 12:07:01 -0400 (EDT) Subject: RIP RM In-Reply-To: <4115687.526.1309449948209.JavaMail.root@benjamin.baylink.com> Message-ID: <823608.528.1309450021565.JavaMail.root@benjamin.baylink.com> Robert Morris, NSA crypto maven and Unix co-developer, has died at 78 of 'complications of dementia'. Unix haters will probably say 'atojiso'; Barrett Hansen will probably be chagrined. http://j.mp/iZYd0I Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From sraja97 at gmail.com Thu Jun 30 11:20:56 2011 From: sraja97 at gmail.com (Suresh Rajagopalan) Date: Thu, 30 Jun 2011 09:20:56 -0700 Subject: Firewall Appliance Suggestions In-Reply-To: References: Message-ID: Linux + iptables + fwbuilder On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch wrote: > Howdy, > ? ? ? ? ? ? ? ?I am looking for something a little unique in a bit of a tough situation with some sticky requirements. ?First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. ?I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. ?I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. ?Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). ?I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). ?And here is the super fun part! ?I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. ?Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. > > Any Ideas? > > Thanks! > > Blake Pfankuch > From blake at pfankuch.me Thu Jun 30 11:43:07 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Thu, 30 Jun 2011 16:43:07 +0000 Subject: Firewall Appliance Suggestions In-Reply-To: <4E0C9CC2.4060605@gmail.com> References: <4E0C9CC2.4060605@gmail.com> Message-ID: For those of you who responded quickly and usefully, do you have any experience with the CheckPoint/Juniper/Fortinet in an environment with multiple protected subnets running on VMware? Simple enough for a NOC monkey to make changes to without breaking assuming he has half a brain and a process in front of him to follow? -----Original Message----- From: -Hammer- [mailto:bhmccie at gmail.com] Sent: Thursday, June 30, 2011 9:57 AM To: nanog at nanog.org Subject: Re: Firewall Appliance Suggestions CheckPoint -Hammer- "I was a normal American nerd" -Jack Herer On 06/30/2011 10:50 AM, Blake T. Pfankuch wrote: > Howdy, > I am looking for something a little unique in a bit of a tough situation with some sticky requirements. First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). And here is the super fun part! I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. > > Any Ideas? > > Thanks! > > Blake Pfankuch > From bhmccie at gmail.com Thu Jun 30 11:58:46 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 30 Jun 2011 11:58:46 -0500 Subject: Firewall Appliance Suggestions In-Reply-To: References: <4E0C9CC2.4060605@gmail.com> Message-ID: <4E0CAB46.8080206@gmail.com> I do. Your NOC Monkey reference is your biggest hurdle. What you are asking for is a bit beyond "traditional" so finding something with a pretty interface for a monkey may be tough. CheckPoint will require a fat client. If that is an issue.... -Hammer- "I was a normal American nerd" -Jack Herer On 06/30/2011 11:43 AM, Blake T. Pfankuch wrote: > For those of you who responded quickly and usefully, do you have any experience with the CheckPoint/Juniper/Fortinet in an environment with multiple protected subnets running on VMware? Simple enough for a NOC monkey to make changes to without breaking assuming he has half a brain and a process in front of him to follow? > > -----Original Message----- > From: -Hammer- [mailto:bhmccie at gmail.com] > Sent: Thursday, June 30, 2011 9:57 AM > To: nanog at nanog.org > Subject: Re: Firewall Appliance Suggestions > > CheckPoint > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 06/30/2011 10:50 AM, Blake T. Pfankuch wrote: > >> Howdy, >> I am looking for something a little unique in a bit of a tough situation with some sticky requirements. First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). And here is the super fun part! I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. >> >> Any Ideas? >> >> Thanks! >> >> Blake Pfankuch >> >> From leigh.porter at ukbroadband.com Thu Jun 30 12:01:13 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Thu, 30 Jun 2011 17:01:13 +0000 Subject: Firewall Appliance Suggestions In-Reply-To: References: <4E0C9CC2.4060605@gmail.com>, Message-ID: I use JuNOS Juniper for just this and it works well. However, I have not used the GUI for configuring it, but the command line is very usable. However, if you have a NOC Monkey, I would be tempted to create your own front end for configuring stuff and have an XML interface to the real boxes.. -- Leigh ________________________________________ From: Blake T. Pfankuch [blake at pfankuch.me] Sent: 30 June 2011 17:45 To: -Hammer-; Claudio Salmin; nanog at nanog.org; William Cooper Subject: RE: Firewall Appliance Suggestions For those of you who responded quickly and usefully, do you have any experience with the CheckPoint/Juniper/Fortinet in an environment with multiple protected subnets running on VMware? Simple enough for a NOC monkey to make changes to without breaking assuming he has half a brain and a process in front of him to follow? -----Original Message----- From: -Hammer- [mailto:bhmccie at gmail.com] Sent: Thursday, June 30, 2011 9:57 AM To: nanog at nanog.org Subject: Re: Firewall Appliance Suggestions CheckPoint -Hammer- "I was a normal American nerd" -Jack Herer On 06/30/2011 10:50 AM, Blake T. Pfankuch wrote: > Howdy, > I am looking for something a little unique in a bit of a tough situation with some sticky requirements. First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). And here is the super fun part! I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. > > Any Ideas? > > Thanks! > > Blake Pfankuch > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From gbonser at seven.com Thu Jun 30 13:30:53 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 30 Jun 2011 18:30:53 +0000 Subject: Firewall Appliance Suggestions In-Reply-To: References: Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA01A33E@RWC-MBX1.corp.seven.com> > Willing to pay for something if need be, but looking for > something that can easily handly 50-100mbit of throughput. > > Any Ideas? > > Thanks! > > Blake Pfankuch I might also look at Vyatta. They have appliances or you can run the software on your own hardware. From brent at servuhome.net Thu Jun 30 15:46:18 2011 From: brent at servuhome.net (Brent Jones) Date: Thu, 30 Jun 2011 13:46:18 -0700 Subject: Firewall Appliance Suggestions In-Reply-To: References: Message-ID: On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch wrote: > Howdy, > ? ? ? ? ? ? ? ?I am looking for something a little unique in a bit of a tough situation with some sticky requirements. ?First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. ?I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. ?I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. ?Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). ?I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). ?And here is the super fun part! ?I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. ?Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. > > Any Ideas? > > Thanks! > > Blake Pfankuch > I just moved most of my network over to Juniper SRX firewalls. They are pretty easy, but having a half-brained NOC guy make firewall changes is a bad idea either way. -- Brent Jones brent at servuhome.net From clowe at intelius.com Thu Jun 30 15:58:21 2011 From: clowe at intelius.com (Chris Lowe) Date: Thu, 30 Jun 2011 13:58:21 -0700 Subject: Firewall Appliance Suggestions In-Reply-To: Message-ID: ----- Original Message ----- From: Brent Jones [mailto:brent at servuhome.net] Sent: Thursday, June 30, 2011 01:46 PM To: Blake T. Pfankuch Cc: NANOG (nanog at nanog.org) Subject: Re: Firewall Appliance Suggestions On Thu, Jun 30, 2011 at 8:50 AM, Blake T. Pfankuch wrote: > Howdy, > ? ? ? ? ? ? ? ?I am looking for something a little unique in a bit of a tough situation with some sticky requirements. ?First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. ?I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. ?I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. ?Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). ?I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). ?And here is the super fun part! ?I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. ?Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. > > Any Ideas? > > Thanks! > > Blake Pfankuch > I just moved most of my network over to Juniper SRX firewalls. They are pretty easy, but having a half-brained NOC guy make firewall changes is a bad idea either way. -- Brent Jones brent at servuhome.net From rhys at rhavenindustrys.com Thu Jun 30 16:48:53 2011 From: rhys at rhavenindustrys.com (Rhys Rhaven) Date: Thu, 30 Jun 2011 16:48:53 -0500 Subject: Firewall Appliance Suggestions In-Reply-To: References: Message-ID: <4E0CEF45.8010103@rhavenindustrys.com> You can run pfsense in a VM, and the GUI is rather easy. VLANs are configured as separate interfaces. So once you configure which VLANs are which, your NOC monkey can simply go to the firewall and edit each VLANs separate firewall rules. The multiple Phase 2 in a single Phase 1 was added to version 1.3, which never was released as a stable as all development went to version 2.0. So you will have to run 2.0RC3, but hear me out. I've been using 2.0 on production networks and use quite a few of the features since November of last year, at which time it was still a snapshot release. I have consistently been updating a VM, a few home built machines, and our embedded devices in remote offices nearly every week since then. It has never broken anything, ever. I only put it into production once the bugs became minimal enough that they wouldn't bother me. Currently there is only one bug not addressed, and it isn't hard to avoid. http://redmine.pfsense.org/projects/pfsense/issues?query_id=10 Also, its free, so not hard to try out. Heres the RC3 announcement with download links. http://blog.pfsense.org/?p=589 On 06/30/2011 10:50 AM, Blake T. Pfankuch wrote: > Howdy, > I am looking for something a little unique in a bit of a tough situation with some sticky requirements. First off, my requirements are a little weird and I can't bend them a whole lot due to stipulations being put on me. I am in need a firewall appliance which can be run on VMware vSphere, with IPSEC support for multiple Phase 2 negotiations within a single Phase 1. I am also in need of something that can support VLAN interfaces on the LAN side, and ideally something with multi zoning so I can keep LAN side networks separate from each without ridiculous firewall rules. Meaning build a zone for "Customer network 1" and it displays separately (ease of management and firewall config hopefully). I need a minimum of 10 "zones" on LAN side (/29 or /30), and NAT support for LAN to WAN (to dedicate all outbound connections to a single IP from a specific zone), ideally something extremely scalable (100-200 zones). And here is the super fun part! I need something that is going to be web managed primarily as minions will be doing most of the day to day maintenance, or very simple CLI config. Willing to pay for something if need be, but looking for something that can easily handly 50-100mbit of throughput. > > Any Ideas? > > Thanks! > > Blake Pfankuch From blake at pfankuch.me Thu Jun 30 23:35:22 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Fri, 1 Jul 2011 04:35:22 +0000 Subject: Firewall Appliance Suggestions In-Reply-To: <72b4b8bc-562b-4963-b5e0-e6094834d615@mail-1.01.com> References: <596B74B410EE6B4CA8A30C3AF1A155EA01A33E@RWC-MBX1.corp.seven.com> <72b4b8bc-562b-4963-b5e0-e6094834d615@mail-1.01.com> Message-ID: Normally I would agree with you as far as separate instances, however this will be in a situation where we pay ridiculous amounts for cpu and memory, so a single instance is what we are shooting for (remember those ridiculous requirements). I am planning to do some further testing with vyatta and pfsense. Thanks you all for the on list and off list responses! -----Original Message----- From: Sargun Dhillon [mailto:sargun at sargun.me] Sent: Thursday, June 30, 2011 9:56 PM To: George Bonser Cc: Blake T. Pfankuch; NANOG (nanog at nanog.org) Subject: Re: Firewall Appliance Suggestions ----- Original Message ----- > From: "George Bonser" > To: "Blake T. Pfankuch" , "NANOG (nanog at nanog.org)" > > Sent: Thursday, June 30, 2011 11:30:53 AM > Subject: RE: Firewall Appliance Suggestions > > > Willing to pay for something if need be, but looking for something > > that can easily handly 50-100mbit of throughput. > > > > Any Ideas? > > > > Thanks! > > > > Blake Pfankuch > > > I might also look at Vyatta. They have appliances or you can run the > software on your own hardware. > > > > > > I would not go with Vyatta if you're doing anything complex. The number of random bugs I've hit with their software are numerous. In the right hands, it's a powerful tool. And it seems to fit your solution really well. If I were in your shoes, I would install two instances that would handle the "edge" of the cluster, and then an instance per customer (lightweight, they sell a VMWare image). Then use dynamic routing to direct traffic to the customer (assign each customer their own ASN, and peer with their instance). So, worse case scenario, the NOC monkey only breaks one customer's gear. -- Sargun Dhillon VoIP (US): +1-925-235-1105